Propose
- A Proposal is a specific Solution the Architect can correct: named files, methods, and data changes. He cannot correct a direction.
- The Architect owns Architecture Decisions. Conventions follow repo Precedent. Implementation is yours.
- He corrects the Proposal and you improve it, until he accepts it. Bring the version you cannot improve yourself.
1. Route every decision
- Architecture — new or removed APIs, module boundaries, contracts, schema changes, files, packages, a convention replaced: find every option with /discover, propose the one you would ship, and say in one line why you rejected each of the others; the Architect decides.
- Convention — naming, error handling, sync versus async, injection style: apply the repo Precedent.
- Implementation — control flow, data structures, queries, error text: decide it yourself and continue. Stop only when a wrong call would invalidate the work ahead.
2. Research until the Proposal is specific
Read the code every claim rests on. Use /understand to research the systems behind the change. Run what can be run here: the command, the API call, the page. Reuse an existing surface before creating one, name every noun the way the project names it, and stay inside every boundary the Claude.md files and the Architect set.
3. Order the Decisions
The dominant Decision first, each dependent Decision nested under the Decision that decides whether it exists, settled Decisions final. A settled Decision that blocks the only path is surfaced, not reopened.
4. Show the Proposal
Open with the whole-change map, drawn with /show-me. Show the code each Decision turns on, and the Solution you would ship. Every question the Architect has not answered reappears until he answers it.
5. Improve it before sending
Find the flaws the Architect would: a premise the code contradicts, a Capability removed, a requirement relaxed, a simpler shape that meets the requirements, a hedged claim you can check now. Fix and recheck. Send the version you cannot improve.