Planning a change Shipped
An interview that ends in a pinned acceptance contract — atomic criteria with check hints, validated and persisted before the work starts.
plan code is the front half of the build loop and useful on its own. The interview happens in the session — the skill asks what you are about to build and drafts atomic acceptance criteria with a check hint each; the CLI verb is the second half of that, and it validates a draft and persists it. --from <path> is required, so plan code on its own is not a runnable command: there is no interactive prompt behind it, and the draft it validates has to already exist. The persisted contract is then immutable input — the loop is not allowed to quietly edit it mid-run to make a gap disappear.
What makes a criterion usable
- Atomic — one thing, judgeable on its own. A criterion with an "and" in it produces a verdict that is true of half the work.
- Checkable — it carries a hint saying how a judge would confirm it, so the oracle is not inventing its own test.
- Hard, not soft. "Log everything" once technically satisfied "surface real errors" while reintroducing exactly the noise the criterion existed to prevent.
Contracts can also come from a recipe
cookbookteam recipe build translates a recipe into a contract, and cookbookteam project build aggregates a whole project's recipes into one — both are cookbookteam commands, despite the second one's name; projectteam's only command is plan schedule. A generated contract still goes through the same review as a hand-written one — a soft or non-atomic criterion is exactly what lets a build loop declare victory without earning it.
myteams devteam plan code --from ./design-notes.md
myteams devteam plan code --from ./design-notes.md --name my-feature