lerianstudio/ring:brainstorming

Brainstorming Ideas Into Designs

Overview

Transform rough ideas into fully-formed designs through structured questioning and alternative exploration.

Core principle: Research first, ask targeted questions to fill gaps, explore alternatives, present design incrementally for validation.

Announce at start: "I'm using the ring:brainstorming skill to refine your idea into a design."

Quick Reference

| 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 |