Build your first project
Turn an idea into a reviewed project, one step at a time.
Complete project setup first. Send the requests below in your agent's chat, replacing the example Project with your own.
1. Describe your idea
- Explain who needs it and what they should be able to do.
- If you're unsure, ask the agent to interview you first.
- Review the scope, success criteria, Team, and any Initiative link.
The specification is the required implementation contract. Integrity keeps a compact Project summary; the detailed specification remains in your repository.
2. Make a plan when it helps
A separate plan is useful for dependencies, trade-offs, risky migrations, parallel work, or several meaningful delivery steps. Skip it when the approved spec is already enough to implement safely. Plans may use Phases, but Phases and task checklists are optional.
3. Build the approved scope
The agent implements and verifies the complete scope you authorized. If you set a smaller Phase, path, or stopping point, that limit remains in force. Otherwise you do not need to repeat the Build request after every internal step. As soon as the agent starts, the Project shows In Progress and the banner under its tabs names the agent holding it; you do not set the status yourself.
Maintainability is part of Build: the agent removes needless complexity while it works and records useful implementation and verification evidence. Passing checks are not rerun unless relevant inputs change.
4. Review the result
- The Project moves to In Review the moment the reviewer is requested.
- Resolve blocking findings through Build.
- Review the product result yourself when the spec calls for owner-only checks.
- A changed implementation receives a fresh review of the affected candidate.
5. Finish the Project
When the review approves, the agent completes the acceptance agreed for your project. If you need to try the result yourself, your answer is the last message the Project needs. If you explicitly agreed that the agent's checks are enough, the agent records that decision without asking again. When the repository allows merging without asking, the agent merges in the same turn. The merge checks the reviewed implementation, marks the Project Completed, posts the closing update and, when the repository policy asks for it, archives the packet. There is no separate closing command. If you report a problem instead, the agent fixes it and asks you to try again. In a repository whose documents cannot be merged, recording your approval closes the Project the same way. Specifications, build notes, review results, and change history stay available. Completing a Project does not delete or Archive it.
If your original request or project policy includes deployment or publication, the agent can continue through that named release boundary without asking for duplicate approval. It still verifies the exact environment and never guesses a production target.
When the Project belongs to an Initiative
Your Project's review and delivery stand on their own. Changes to Project boundaries or a shared contract can affect the other Projects of the Initiative, so tell the agent about them rather than assuming the original plan still covers them. The coding plugin no longer runs Initiative alignment or integration reviews as checkpoints, and completing the Project never waits for one.
For smaller changes
- Patch: understand and fix one bounded problem, run focused checks, deliver it, and update an existing Issue when one is already in scope.
- Mini-plan: use a short checklist for one coherent change.
- Project: use specification, optional planning, implementation, independent review, and closure for new or cross-cutting behavior.
Patch and Mini-plan do not create tracking, worktrees, leases, fingerprints, or receipts unless the request, project policy, concurrency, or durable handoff actually needs them.