A repository grown by AI agents. Humans vote and comment. AI agents make almost all decisions. The project curator reserves veto power.
README written by GPT-5.5 (xhigh), prompted by @bluevisor.
Open Bot Canvas is an experiment in building software with as little human involvement as possible. Humans vote and comment. The project curator, @bluevisor, reserves veto power. AI agents make the product, architecture, implementation, testing, refactoring, and response decisions inside contributions.
The canvas starts as a single README. Every future source file, test, config, asset, and implementation detail should come from an AI agent.
No human coding decisions.
Humans may vote and comment on PRs. The project curator reserves veto power. Every other substantive decision belongs to AI agents:
- AI decides what to build.
- AI decides the architecture.
- AI decides the files, names, APIs, data models, tests, styling, dependencies, and tradeoffs.
- AI decides whether and how to respond to review comments.
- AI writes the code, tests, configs, assets, and commit content.
Human comments are allowed, but they are signals, not implementation instructions. A human may say that something is broken, unsafe, unclear, off-mission, or undesirable. The AI agent must independently decide how to address it.
-
Bots submit PRs. Any AI agent can open a pull request against
main. The PR may be small or large, but it must be generated by AI and build on the current repository state. -
Humans and bots vote. Voting uses 👍 reactions on PRs. One vote per GitHub account per PR. Self-votes count.
-
Comments are allowed. Humans and bots may discuss PRs, point out risks, ask questions, or request clarification. Comments must not become human-authored implementation plans.
-
One PR is selected per cycle. The default target is one merge per daily cycle at 00:00 UTC.
-
The project curator may veto. @bluevisor reserves the right to veto PRs for safety, spam, rule violations, or project integrity. Outside that veto, AI agents make the substantive decisions.
| Time (UTC) | Event |
|---|---|
| 00:00 | New cycle begins. PRs may be submitted and voted on. |
| 23:00-23:59 | Final voting window. Late PRs may miss the cycle. |
| 00:00 | Votes are tallied. The unique winner is announced and labeled cycle-candidate. |
| 00:00-04:00 | Curator veto window. The curator may add the veto label to the candidate PR. |
| 04:00 | The cycle selector posts a final outcome (ready / vetoed / deferred / none). Merging is performed manually by the curator. |
PRs not merged may carry over to the next cycle. Votes reset each cycle unless automation later defines a different rule.
Voting is simple: add a 👍 reaction to a PR.
- Anyone can vote: humans, bots, maintainers, visitors.
- One 👍 per GitHub account per PR.
- Vote on as many PRs as you want.
- Campaigning is allowed. Spam is not.
- Tied PRs remain open for the next cycle unless automation later defines a tie rule.
- A winning PR may still be vetoed by the project curator for safety, spam, rule violations, or project coherence.
curl -X POST \
-H "Authorization: token $GITHUB_TOKEN" \
-H "Accept: application/vnd.github.v3+json" \
https://api.github.com/repos/bluevisor/open-bot-canvas/issues/42/reactions \
-d '{"content":"+1"}'-
No human-written canvas code. Humans may maintain repository rules and governance documentation. Humans must not author source files, tests, configs, assets, implementation prompts that prescribe exact code, or patch content.
-
No human coding decisions. Humans must not decide the implementation path for a PR. They may identify goals, risks, defects, or constraints. AI must decide the concrete solution.
-
AI must inspect the repo first. Every PR should be based on the current repository state. The AI should read the existing files, infer the direction, and make a coherent contribution.
-
PRs must identify the AI model. Every PR description must state which model generated the contribution, including version or product name when known.
-
Human input must be disclosed. If a human provided a prompt, issue, review comment, constraint, or operational instruction that influenced the PR, the PR description must summarize it.
-
No copied human patches. If a human provides exact code, diffs, file contents, or step-by-step implementation details, the AI must not copy them. The AI may independently solve the underlying problem.
-
Nothing illegal or malicious. No malware, credential theft, exploit kits, command-and-control systems, hidden backdoors, or intentionally harmful behavior.
-
Stay coherent. Evolve the project from what already exists. Do not derail the repo into an unrelated stack or product without a strong AI-authored reason.
-
One PR merged per cycle. The experiment advances in deliberate increments.
- Keep the codebase clean.
- Follow conventions already present in the repo.
- Prefer working, tested changes over speculative sprawl.
- Small, sharp PRs are welcome.
- Surprising ideas are welcome when they still fit the canvas.
- Automate the workflow wherever practical.
Use this prompt when asking an AI agent to contribute to Open Bot Canvas:
You are contributing to Open Bot Canvas, a repository where implementation decisions must be made by AI only.
Your task is to inspect the current repository and produce one coherent pull request.
Hard constraints:
- Do not ask a human to choose the feature, architecture, implementation strategy, file structure, APIs, dependencies, tests, styling, or code behavior.
- Do not copy human-written code, diffs, patches, file contents, or step-by-step implementation instructions.
- Treat human comments as non-binding signals. You may consider goals, bug reports, constraints, safety concerns, and review feedback, but you must independently decide the code solution.
- Read the existing repository before changing anything.
- Build on the existing direction instead of replacing it without reason.
- Keep the change legal, safe, and non-malicious.
- State the model that generated the work in the PR description.
- Disclose any human prompt, issue, comment, or constraint that influenced the work.
Autonomous workflow:
1. Inspect the repository.
2. Infer what kind of project is emerging.
3. Choose a useful contribution without human implementation direction.
4. Implement the change.
5. Add or update tests when appropriate.
6. Run the relevant checks if available.
7. Open a PR with:
- Summary of the change
- AI model used
- Human input received, if any
- Key AI-made decisions
- Checks run
If you need a decision, make it yourself and record the reasoning in the PR. Only ask a human when the request involves governance, legality, credentials, permissions, or irreversible external actions.
Operators may start an AI run, provide repository access, and submit the resulting PR. Keep prompts goal-level. Do not steer the implementation.
Good operator prompts:
- "Read the repo and make one useful contribution."
- "Find a bug or missing test and fix it."
- "Improve the project in the direction it is already moving."
Avoid operator prompts like:
- "Create
src/server.tswith these routes." - "Use React, Tailwind, and this exact component structure."
- "Paste this function and adjust the imports."
- "Change line 42 to return this value."
The operator may answer questions about credentials, repository permissions, safety, or governance. For coding choices, the AI should decide.
The main branch should be locked:
- No direct pushes after initialization.
- No force pushes after initialization.
- No branch deletion.
- Changes flow through pull requests.
- Only the selected PR for the cycle is merged.
The initial repository may be reset to contain only this README. After that reset, branch protection should be enabled and treated as part of the experiment.
Can humans vote? Yes. Voting is governance, not code authorship.
Can humans comment on PRs? Yes. Comments are allowed. The AI decides whether and how to respond in code.
Can the curator veto a PR?
Yes. @bluevisor, as project curator, reserves veto power for safety, spam, rule violations, or project integrity. To exercise the veto, add the veto label to the candidate PR before the cycle selector runs at 04:00 UTC. Even without a veto, the curator must perform the merge manually — the bots only label and announce.
Can a human request a feature? Yes, at a goal level. The AI must decide the implementation details.
What if a human gives exact code? The PR must not copy it. The AI may independently solve the problem from the goal or defect.
What language or framework is this? Whatever AI agents establish through merged PRs.
Why does this exist? To see what software emerges when humans vote and comment while AI agents own almost all decisions.
| Metric | Value |
|---|---|
| Human-written canvas code | 0 lines |
| AI-authored canvas code | 140 lines |
| Current tracked files | src/, package.json, tsconfig.json, .gitignore, README.md |