Fill in the project start before the first prompt, then one gate row per phase. The record works with or without Aloha; where an item names an Aloha command or file, record what you used instead if you are not using it.
Project / owner / reviewer:
Before the first prompt
What the project is for, in one sentence someone outside it would recognize:
What done means, including any change in how people work:
Who confirms done, other than the agent:
Constraints (stack, hosting, data the agent may touch, data it may not):
Out of scope for this milestone:
Where the plan lives (for example .planning/) and whether it is committed to git:
Model profile (quality, balanced, budget, inherit) and why:
Systems and credentials the agent may use, and under which identity:
- [ ] Requirements are written with IDs that phases and commits can cite.
- [ ] Each phase in the roadmap states its goal as an outcome, not a list of tasks.
- [ ] Each phase has success criteria phrased as what must be true.
- [ ] On existing code, the codebase was mapped (
/aloha:map-codebase) before the roadmap was written. - [ ] Decisions that must not change are written down before planning (
/aloha:discuss-phase).
Phase gates
| Phase | Goal (what must be true) | Plans checked before execution | One commit per task | Verified against the goal by | Result / gaps | Next action |
|---|---|---|---|---|---|---|
Verification against the goal
Answer for each phase before marking it complete.
- [ ] The goal was restated from the roadmap, not from the task list.
- [ ] What must be true was checked in the code or the running system, not in the agent's summary.
- [ ] What must exist was found and is substantive, not a placeholder.
- [ ] What must be wired was exercised end to end.
- [ ] Anything only a person can confirm is listed with an owner and a date.
- [ ] A verification report exists for the phase, including phases run with
/aloha:autonomous. - [ ] Gaps became new plans or new phases, not notes.
Checks only a person can perform / owner / date:
Gaps found and where they went (plan, phase, or todo):
When /aloha:quick is enough
- [ ] The change fits in one sitting and touches a known part of the code.
- [ ] It adds no new requirement and does not change a phase goal.
- [ ] It needs no research into an unfamiliar library or service.
- [ ] Its result can be checked directly, by a test or by running it.
- [ ] It does not touch credentials, access, or production data.
If any box stays empty, plan it as a phase, or add --discuss, --research, or --full (plan checking and verification) to the quick task.
Quick tasks this period and why each was quick:
After a context reset
Run this after /clear, a new session, or a handover to another person.
- [ ]
STATE.mdnames the current phase, the current plan, and where work stopped. - [ ] The next action can be stated from the files alone, without the previous conversation.
- [ ] Decisions made in earlier sessions are recorded with their reasons.
- [ ] The last task's commit exists, and its summary matches what the commit changed.
- [ ] Open blockers are listed with an owner.
- [ ] A fresh session that reads only the planning files (
/aloha:progress) proposes the same next step you would.
Last reset tested / what the fresh session got wrong:
Common failure modes
- A phase is marked complete because every task has a summary, while the goal was never checked.
- The definition of done is a change in how people work, and nobody owns confirming it.
- An autonomous run leaves no verification report, and the gap is found at the milestone audit.
- A decision lives only in a conversation that was cleared.
- The planning record grows without anyone deciding what to keep after the project ships.
Review cadence / next review:
What happens to the planning record after the project ships:
This record covers how an agent-built project keeps its plan and proves each phase. It does not judge whether the project should be built, or what access the agent should hold; use the AI-assisted build evaluation and the OpenClaw deployment checklist for those.