Audience guide
You do not need to author YAML. You run two loops that close each other: shape the experience on a running application, then close it so contracts, text, and code still describe what you approved.
The loop you own
Every initiative runs the same closure cycle. You iterate on a running preview until the experience is right, then one sign-off turns that accepted experience into durable truth. The next prototype starts from that truth instead of from a chat nobody still has.
Loop one · Product outlook
You do not need a complete implementation plan before the first preview. The agent starts from the relevant contracts, launches the application, and makes small changes you judge as a user. Acceptance is about the experience, not production readiness, and silence never approves it.
/cg-prototype
Loop two · Closure
When you accept the experience, sign-off finishes the rest: unfinished behaviour, deferred tests, contract updates, documentation, and repairs. It closes only when the gate is green, so “approved” and “done” stop being the same sentence.
/cg-sign-off
Where your model budget goes
The two loops need different things. Prototyping is judgement: reading your reaction and making one surgical change to a running application. Closure is procedure: a recorded scope, named files, and a gate that either passes or does not.
Prototype
This is where a stronger model earns its cost. The loop stays open as long as you want it, and each iteration is a surgical change to the experience rather than a rewrite. Contracts route that change to the smallest owning boundary, so the model spends its capability on your product outlook instead of rediscovering the architecture.
Sign-off
Closure is bounded work: fix the contracts that drifted, fix the text that no longer matches, update the code the prototype left unfinished, and run the repository’s gate. The scope is already on disk, so an ordinary model can carry it while you still see whether it closed on a truthful graph.
Contract Graph does not pick your model. It makes the split affordable by writing the scope down—the prototype record, the roadmap, the contracts, and the gate—so closure does not depend on the session that produced it. You choose the model in your coding host.
What closure is for
Producing code is dramatically faster; understanding, integrating, and maintaining the accumulated result is not. An unclosed prototype leaves the fastest-moving part of your product described by the least reliable record you have. Sign-off is the stage that repairs it.
The prototype moved where responsibility sits, but the graph still describes last month’s design. The next session routes the next change to the wrong place and nobody notices for weeks.
Docs and product rules describe an experience you already replaced. Every later reader—person or agent—inherits the error and builds on it.
Tests, integration gaps, and known failures are invisible once the conversation scrolls away. Closure turns them into ordinary delivery work with an actual gate.
Where you sit in the workflow
Plan and decisions sit inside the same cycle. Whether an initiative starts as a prototype or as a plan, it finishes at the same closure.
When the experience is still unclear, iterate on a running preview. Your acceptance is about the experience, not production readiness.
Agree ordered phase outcomes and what “done” looks like. You are not yet deciding files, branches, or implementation.
Expensive or protected choices are logged before they are asked. Silence is never approval. Independent work can continue while you answer.
Close only when the gate is green and durable knowledge has moved into contracts, product rules, or lasting docs—not a plan you are about to delete.
Plans are temporary. If deleting docs/plans/ would lose a rule, the rule was stored in the wrong place. The next session should trust the contract graph, remaining roadmap items, and accepted decisions.
How to work with the team
A durable overview of the system, a route to the smallest responsible piece of work, and a record of what must stay true while implementation changes.
The prototype experience, phase outcomes, acceptance gates, recorded decisions, and whether sign-off actually closed on a truthful graph.
Skill protocol, hop tokens, and most YAML field names. Those are for the agent and the engineer maintaining the graph.
The useful first question is which contract owns the request. If nobody can answer from the graph, the work is not ready to fan out to agents.
Accepting the experience does not merge code or prove production readiness. Ask which programme is still open and what its remaining sign-off owes.
Public beta: review contracts, product rules, and structural findings before merging. Warmup describes existing behavior; restructuring it identifies should become planned work.
Repository-specific constraints belong in P rules bound to the contracts they constrain. Global architecture opinions are not yours to invent in chat.
Verification today proves the authored graph is closed. It does not yet prove the implementation contains no undeclared child or that every import matches the graph. That honesty is part of the product.