Getting started

The best way to learn the stack is to take one small, real piece of work around the loop. Thirty minutes, one card, all three checkpoints.

1. Bring a raw idea (Discover)

Say cpo-intake: <your idea>. You get one decision back: build, drop, or later. If the answer is build, say cpo-shape and answer only the real product questions. You end with a card — the problem, user stories, and acceptance criteria, in user terms.

For a UI-bearing card, cpo-brief adds the design brief: what a prototype must demonstrate.

2. Prototype it (Prototype)

Hand the brief to your design hire. You get back something clickable. The brief’s demonstration list tells you when it is done.

3. Approve the stories (Plan)

Say cpo-breakdown. It walks the prototype and shows you a diff: what the prototype promises versus what the card asked for — added, changed, dropped. Approve the behavior, then run cpo-shape to complete the card’s scope, acceptance criteria, proof, and dependencies. Shape grades the card agent-ready when its requirements are complete. Dispatch checks whether its prerequisites and capacity allow work to start.

4. Let it build (Build)

Say cpo-dispatch, or cpo-build in the card’s workspace. Build invokes the configured engineering lead. With pstack, /poteto-mode chooses and runs the engineering workflow. The lead returns reviewed implementation and builder proof. CPO then completes validation, independent cpo-verify, and PR preparation. The second checkpoint is human review, with evidence for every acceptance criterion.

5. Ship it (Ship)

Approve, then say cpo-ship. The queue merges in a safe order. Release notes draft themselves (cpo-announce); the knowledge base stays current (cpo-kb). Your approval was the third checkpoint.

6. Close the loop

Say cpo-retro at the end of the week. What shipped, what stalled, and what to fix — fed straight back into Discover.

Any time

• cpo-standup — where everything is, and what is waiting on you
• “wait what” — the last explanation re-pitched in plain words