Phase	Key Activities	Tool Usage	Output
Prep: Autonomous Recon	Inspect repo/docs/commits, form initial model	Native tools (ls, cat, git log, etc.)	Draft understanding to confirm
1. Understanding	Share findings, ask only for missing context	AskUserQuestion for real decisions	Purpose, constraints, criteria (confirmed)
2. Exploration	Propose 2-3 approaches	AskUserQuestion for approach selection	Architecture options with trade-offs
3. Design Presentation	Present in 200-300 word sections	Open-ended questions	Complete design with validation
4. Design Documentation	Write design document	writing-clearly-and-concisely skill	Design doc in docs/plans/
5. Worktree Setup	Set up isolated workspace	ring:using-git-worktrees skill	Ready development environment
6. Planning Handoff	Create implementation plan	ring:writing-plans skill	Detailed task breakdown

The Process

Copy this checklist to track progress:

Brainstorming Progress:
- [ ] Prep: Autonomous Recon (repo/docs/commits reviewed, initial model shared)
- [ ] Phase 1: Understanding (purpose, constraints, criteria gathered)
- [ ] Phase 2: Exploration (2-3 approaches proposed and evaluated)
- [ ] Phase 3: Design Presentation (design validated in sections)
- [ ] Phase 4: Design Documentation (design written to docs/plans/)
- [ ] Phase 5: Worktree Setup (if implementing)
- [ ] Phase 6: Planning Handoff (if implementing)

Prep: Autonomous Recon

MANDATORY evidence (paste ALL): ls -la, git log --oneline -10, head -50 README.md, find . -name "*test*" | wc -l, check package.json/requirements.txt/go.mod.

Only after ALL evidence pasted: Form your model and share findings. Skip any = not following skill.

Question Budget

Maximum 3 questions per phase. More = insufficient research.

Question count:

Phase 1: ___/3
Phase 2: ___/3
Phase 3: ___/3

Hit limit? Do research instead of asking.

Phase 1: Understanding

Share your synthesized understanding first, then invite corrections or additions.
Ask one focused question at a time, only for gaps you cannot close yourself.
Use AskUserQuestion tool only when you need the human to make a decision among real alternatives.
Gather: Purpose, constraints, success criteria (confirmed or amended by your partner)

Example summary + targeted question:

Based on the README and yesterday's commit, we're expanding localization to dashboard and billing emails; admin console is still untouched. Only gap I see is whether support responses need localization in this iteration. Did I miss anything important?

Phase Lock Rules

CRITICAL: Once you enter a phase, you CANNOT skip ahead.

Asked a question? → WAIT for answer before solutions
Proposed approaches? → WAIT for selection before design
Started design? → COMPLETE before documentation

Violations:

"While you consider that, here's my design..." → WRONG
"I'll proceed with option 1 unless..." → WRONG
"Moving forward with the assumption..." → WRONG

WAIT means WAIT. No assumptions.

Phase 2: Exploration

Propose 2-3 different approaches
For each: Core architecture, trade-offs, complexity assessment, and your recommendation
Use AskUserQuestion tool to present approaches when you truly need a judgement call
Lead with the option you prefer and explain why; invite disagreement if your partner sees it differently
Own prioritization: if the repo makes priorities clear, state them and proceed rather than asking

Example using AskUserQuestion:

Question: "Which architectural approach should we use?"
Options:
  - "Direct API calls with retry logic" (simple, synchronous, easier to debug) ← recommended for current scope
  - "Event-driven with message queue" (scalable, complex setup, eventual consistency)
  - "Hybrid with background jobs" (balanced, moderate complexity, best of both)

I recommend the direct API approach because it matches existing patterns and minimizes new infrastructure. Let me know if you see a blocker that pushes us toward the other options.

Phase 3: Design Presentation

Present in coherent sections; use ~200-300 words when introducing new material, shorter summaries once alignment is obvious
Cover: Architecture, components, data flow, error handling, testing
Check in at natural breakpoints rather than after every paragraph: "Stop me if this diverges from what you expect."
Use open-ended questions to allow freeform feedback
Assume ownership and proceed unless your partner redirects you

Design Acceptance Gate:

Design is NOT approved until human EXPLICITLY says one of:

"Approved" / "Looks good" / "Proceed"
"Let's implement that" / "Ship it"
"Yes" (in response to "Shall I proceed?")

These do NOT mean approval:

Silence / No response
"Interesting" / "I see" / "Hmm"
Questions about the design
"What about X?" (that's requesting changes)

No explicit approval = keep refining

Phase 4: Design Documentation

After validating the design, write it to a permanent document:

File location: docs/plans/YYYY-MM-DD-<topic>-design.md (use actual date and descriptive topic)
RECOMMENDED SUB-SKILL: Use elements-of-style:writing-clearly-and-concisely (if available) for documentation quality
Content: Capture the design as discussed and validated in Phase 3, organized into sections that emerged from the conversation
Commit the design document to git before proceeding

Phase 5: Worktree Setup (for implementation)

When design is approved and implementation will follow:

Announce: "I'm using the ring:using-git-worktrees skill to set up an isolated workspace."
REQUIRED SUB-SKILL: Use ring:using-git-worktrees
Follow that skill's process for directory selection, safety verification, and setup
Return here when worktree ready

Phase 6: Planning Handoff

Ask: "Ready to create the implementation plan?"

When your human partner confirms (any affirmative response):

Announce: "I'm using the ring:writing-plans skill to create the implementation plan."
REQUIRED SUB-SKILL: Use ring:writing-plans
Create detailed plan in the worktree

Question Patterns

When to Use AskUserQuestion Tool

Use AskUserQuestion when:

You need your partner to make a judgement call among real alternatives
You have a recommendation and can explain why it’s your preference
Prioritization is ambiguous and cannot be inferred from existing materials

Best practices:

State your preferred option and rationale inside the question so your partner can agree or redirect
If you know the answer from repo/docs, state it as fact and proceed—no question needed
When priorities are spelled out, acknowledge them and proceed rather than delegating the choice back to your partner

When to Use Open-Ended Questions

Use open-ended questions for:

Phase 3: Design validation ("Does this look right so far?")
When you need detailed feedback or explanation
When partner should describe their own requirements
When structured options would limit creative input

Frame them to confirm or expand your current understanding rather than reopening settled topics.

Example decision flow:

"What authentication method?" → Use AskUserQuestion (2-4 options)
"Does this design handle your use case?" → Open-ended (validation)

When to Revisit Earlier Phases

Trigger	Action
New constraint revealed	→ Return to Phase 1
Partner questions approach	→ Return to Phase 2
Requirements unclear	→ Return to Phase 1
Something doesn't make sense	→ Go back and clarify

Avoid forcing forward linearly when going backward would give better results.

Required Patterns

This skill uses these universal patterns:

State Tracking: See skills/shared-patterns/state-tracking.md
Failure Recovery: See skills/shared-patterns/failure-recovery.md
Exit Criteria: See skills/shared-patterns/exit-criteria.md
TodoWrite: See skills/shared-patterns/todowrite-integration.md

Apply ALL patterns when using this skill.

Key Principles

Principle	Application
One question at a time	Phase 1: Single targeted question only for gaps you can’t close yourself
Structured choices	Use AskUserQuestion tool for 2-4 options with trade-offs
YAGNI ruthlessly	Remove unnecessary features from all designs
Explore alternatives	Always propose 2-3 approaches before settling
Incremental validation	Present design in sections, validate each
Flexible progression	Go backward when needed - flexibility > rigidity
Own the initiative	Recommend priorities and next steps; ask if you should proceed only when requirements conflict
Announce usage	State skill usage at start of session

Blocker Criteria

STOP and report if:

Decision Type	Blocker Condition	Required Action
Phase progression	User has not explicitly approved design	STOP and wait for explicit approval
Question budget	Exceeded 3 questions per phase	STOP asking questions, do research instead
Phase lock	Attempting to skip ahead before phase completion	STOP and complete current phase first
Design validation	Received ambiguous response (not explicit approval)	STOP and clarify approval status
Sub-skill handoff	Required sub-skill unavailable or blocked	STOP and report blocker

Cannot Be Overridden

The following requirements CANNOT be waived:

MUST follow phase lock rules - CANNOT skip ahead while waiting for answers
MUST have explicit design approval - silence or "interesting" does not mean approval
CANNOT exceed question budget of 3 per phase - research instead
MUST paste autonomous recon evidence before forming model
CANNOT skip sub-skill usage (ring:writing-plans, ring:using-git-worktrees) when applicable

Severity Calibration

Severity	Condition	Required Action
CRITICAL	Proceeding without explicit design approval	MUST stop immediately and obtain approval
CRITICAL	Skipping phases or phase lock violation	MUST return to correct phase
HIGH	Exceeding question budget without research	MUST do research before asking more questions
HIGH	Missing autonomous recon evidence	MUST gather and paste evidence
MEDIUM	Not using AskUserQuestion for structured choices	Should use proper tool for decisions
LOW	Minor documentation gaps in design doc	Fix in next iteration

Pressure Resistance

User Says	Your Response
"Just skip the exploration phase, I know what I want"	"MUST complete Phase 2 exploration to ensure we consider alternatives. This prevents costly rework later."
"I said it looks good, just proceed"	"MUST have explicit approval like 'approved' or 'proceed'. 'Looks good' is ambiguous - shall I proceed with implementation?"
"Stop asking questions and just build it"	"MUST gather understanding before building. I'll research the codebase to minimize questions while ensuring we build the right thing."
"We don't have time for all these phases"	"Phases exist to prevent expensive mistakes. Skipping them creates technical debt. MUST follow the process."

Anti-Rationalization Table

Rationalization	Why It's WRONG	Required Action
"User seems to approve, no need for explicit confirmation"	Implicit approval leads to misaligned implementations and wasted effort	MUST obtain explicit approval words
"I already know the codebase, skip autonomous recon"	Assumptions cause errors; evidence ensures accuracy	MUST paste recon evidence before proceeding
"This is a simple feature, phases are overkill"	Complexity is often hidden; phases reveal it	MUST complete all applicable phases
"User is impatient, I'll ask questions later"	Phase lock exists to prevent building wrong things	MUST wait for answers before solutions
"I can infer the decision from context"	Inference is not explicit choice; user must decide	MUST use AskUserQuestion for real decisions

ring:brainstorming

Brainstorming Ideas Into Designs

Overview

Quick Reference