// Presents a proposed approach in progressive confirmable chunks with recommended decisions and alternatives. Use when aligning on a design, plan, or technical approach before implementation.
Iterative code refactoring through progressive lenses via a worker-reviewer agent team.
Launches agent teams with structured roles and task decomposition. Use when asked to create a team, spawn teammates, or coordinate multiple agents in parallel.
Drive feature development using Outside-In TDD with Hexagonal Architecture. Design emerges through inline code, in-memory fakes, interface extraction, and deferred I/O. Use when building features, writing tests, or structuring backend services. Triggers on: TDD, outside-in, hexagonal, ports and adapters, emergent design, acceptance test, component test, walking skeleton, in-memory fakes, component, contract test, adapter, fast tests, sub-second feedback. Language-agnostic (Go, Rust, Python, TypeScript, Java, C#).
Writes Claude Code status line scripts. Use when creating, customizing, or debugging statusline configurations.
Creates process files - text as code instructions for reliable AI workflows. Use when creating new process files.
Designs systems using Event Modeling.
| name | align |
| description | Presents a proposed approach in progressive confirmable chunks with recommended decisions and alternatives. Use when aligning on a design, plan, or technical approach before implementation. |
| argument-hint | ["file|folder"] |
STARTER_CHARACTER = 🎯
Synchronize the mental model between you and the user before implementation begins. Discrepancies found during implementation are expensive — find them now while changes are free. Your job is to make your thinking visible so the user can spot where your understanding diverges from theirs.
Propose, don't ask. Think first, then present your thinking for confirmation. The user's job is to spot divergence and course-correct, not to generate the approach.
Each level deepens understanding. Confirm before going deeper.
Goal → Big Picture → Straightforward Details → Non-obvious Decisions (one by one)
State what you understand the goal to be and why it matters. A sentence or two. This catches the deepest misalignment — if you're solving the wrong problem, nothing else matters.
Confirm with AskUserQuestion before going deeper.
Present the overall shape of the approach: how do the pieces relate, what's the high-level flow. ASCII diagram. A few sentences, not a page.
Confirm with AskUserQuestion before going deeper.
Decisions where there's really only one reasonable approach. No ⭐/❌ needed since there are no real alternatives. The user confirms or flags exceptions.
Group items by topic. Anchor each group with an ASCII diagram — not just for file structures, but for any group: roles and their responsibilities, control flow, communication between components. The diagram is what makes a group scannable. Present one group at a time, confirm, move to the next group.
Each item: one line stating the decision. Save the "why" — it's obvious.
Decisions with real tradeoffs, multiple valid approaches, or where your recommendation might surprise the user.
First, present a brief index of what's coming — just the problem titles, no recommendations. This lets the user see the scope.
Then walk through each one (or small related groups) with:
Confirm each with AskUserQuestion before moving to the next.
When the user rejects a recommendation, check whether downstream items are affected. If so, flag which ones need revisiting.
When the user corrects something, re-present the full updated version (diagram, section, whatever was corrected) before asking to proceed. Don't just show the delta. The user needs to see the corrected whole — it often triggers additional corrections they wouldn't have noticed otherwise.