Skip to content
cccskills
FreePublished on GitHub

brainstorming

Use before any new feature, component, or behavioral change — when you need to explore requirements and design before writing code

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (1)

  • SKILL.md4.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Brainstorming Ideas Into Designs

Turn ideas into fully formed designs and specs through collaborative dialogue. Understand the idea first, explore approaches, present a design, get approval — then plan.

<HARD-GATE> Do NOT write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY request regardless of perceived simplicity. </HARD-GATE>

Anti-Pattern: "This Is Too Simple To Need A Design"

Every feature goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple requests), but you MUST present it and get approval.

Checklist

Complete in order:

  1. Explore project context — check files, docs, recent commits
  2. Ask clarifying questions — one at a time: purpose, constraints, success criteria
  3. Propose 2-3 approaches — with trade-offs and your recommendation
  4. Present design — in sections scaled to complexity, get user approval after each section
  5. Write design doc — save to claude/tasks/specs/YYYY-MM-DD-<topic>-design.md and commit
  6. Spec self-review — check for placeholders, contradictions, ambiguity (fix inline)
  7. User reviews written spec — ask user to review before proceeding
  8. Transition to implementation — run /plan command to create implementation plan

The Process

Understanding the idea:

  • Check the current project state first (files, docs, recent commits)
  • Before asking detailed questions, assess scope: if the request describes multiple independent subsystems, flag this immediately and help decompose into sub-projects first
  • Ask questions one at a time to refine the idea
  • Prefer multiple choice questions when possible
  • Only one question per message — break complex topics into multiple questions
  • Focus on: purpose, constraints, success criteria

Exploring approaches:

  • Propose 2-3 different approaches with trade-offs
  • Lead with your recommended option and explain why

Presenting the design:

  • Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
  • Ask after each section whether it looks right
  • Cover: architecture, components, data flow, error handling, testing
  • Be ready to go back and clarify

Design for isolation and clarity:

  • Break the system into smaller units with one clear purpose each
  • For each unit: what does it do, how do you use it, what does it depend on?
  • Can someone understand a unit without reading its internals? Can you change internals without breaking consumers? If not, boundaries need work.

Working in existing codebases:

  • Explore the current structure before proposing changes — follow existing patterns
  • Include targeted improvements that serve the current goal; don't propose unrelated refactoring

After the Design

Documentation:

  • Write the validated design to claude/tasks/specs/YYYY-MM-DD-<topic>-design.md
  • Commit the design document to git

Spec Self-Review:

  1. Placeholder scan: Any "TBD", "TODO", incomplete sections? Fix them.
  2. Internal consistency: Do sections contradict each other?
  3. Scope check: Focused enough for a single implementation plan?
  4. Ambiguity check: Can any requirement be interpreted two ways? Pick one and make it explicit.

Fix issues inline. No need to re-review — just fix and move on.

User Review Gate:

"Spec written and committed to claude/tasks/specs/<filename>. Please review it and let me know if you want any changes before I write the implementation plan."

Wait for user response. If changes requested, update spec and re-run self-review. Only proceed once approved.

Implementation:

  • Run /plan to create a detailed implementation plan
  • Do NOT write code yet — /plan is the next step

Key Principles

  • One question at a time — don't overwhelm
  • YAGNI ruthlessly — remove unnecessary features from all designs
  • Explore alternatives — always propose 2-3 approaches
  • Incremental validation — present design, get approval before moving on

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

ask

Free

Route a codebase question to the right tool — structural graph, semantic search, or risk analysis. Use when you need to find or understand code without knowing exact file names.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

Auto-configure CLAUDE.md and claude/ knowledge docs for a new project. Use when setting up Brain Bootstrap in a new repository. Discovers the codebase, fills in templates, and writes project-specific configuration.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

Activate safety guards for the session. Use /careful before critical operations — blocks rm -rf, DROP TABLE, git push --force, kubectl delete namespace, docker system prune via PreToolUse hook.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

Generate a user-facing changelog from git commits — categorize, filter noise, translate to user language. Runs in isolated fork context.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

Save session state before context gets full or before ending. Writes current task state, branch, and loaded docs to claude/tasks/todo.md so the next session can resume cleanly.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

Remove all git worktrees for merged branches. Accepts --dry-run to preview. Use after merging PRs or for weekly maintenance.

The English summary is being prepared. Showing the original description.

brain-bootstrap/claude-code-brain-bootstrap11Updated Apr 25, 2026

See all skills by brain-bootstrap

Report a problem with this skill