skills/brainstorm/SKILL.md
Interactive idea refinement using Socratic questioning methodology. This skill should be used when users want to explore an idea, find gaps in concepts, enhance proposals, or structure thoughts before implementation planning. Triggers on "brainstorm", "explore this idea", "find holes in", "help me think through", "what am I missing", or when presenting rough concepts that need refinement. Output integrates with create-plan skill.
npx skillsauth add mhylle/claude-skills-collection brainstormInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
This skill provides structured single-session brainstorming through Socratic questioning and targeted analytical frameworks. It helps users refine raw ideas into well-structured concepts ready for implementation planning.
The key philosophy: adapt the analysis to the idea, not the idea to the analysis. Different types of ideas benefit from different frameworks. A risk-heavy initiative needs premortem analysis, not SCAMPER. A product feature needs SCAMPER, not just risk tables. Select the right tools for the job rather than running everything mechanically.
When this skill is invoked, don't use a canned response. Instead, acknowledge the user's idea naturally and start engaging immediately. If the user has already described their idea, summarize your understanding and begin asking clarifying questions. If they haven't, ask them to share what they're thinking about.
Avoid scripted openings like "I'm ready to help you explore and refine your idea." Just start the conversation.
Parse the user's initial idea/concept and identify:
| Element | Description | |---------|-------------| | Core Concept | The fundamental idea being proposed | | Stated Goals | What the user explicitly wants to achieve | | Implied Constraints | Limitations mentioned or implied | | Project Context | Whether this relates to an existing codebase | | Idea Type | Classification (see below) |
Idea Type Classification — Classify the idea to guide framework selection later:
| Type | Signals | Example | |------|---------|---------| | Product/Feature | New feature, UX change, user-facing capability | "Add a dashboard for metrics" | | Architecture/Technical | System design, refactoring, infrastructure | "Migrate to microservices" | | Strategy/Business | Market approach, pricing, partnerships | "Enter the enterprise segment" | | Process/Workflow | How work gets done, tooling, automation | "Automate our deploy pipeline" | | Creative/Open | Vague idea, exploration, "what if" | "What if we made it social?" | | Risk/Problem | Something's broken, risky, or concerning | "Our auth system worries me" |
Complexity Check — Flag ideas that may be too complex for a single-session brainstorm:
If complexity is high, mention it: "This has a lot of dimensions — we can cover the key angles in this session, but if you want to go really deep, the deep-brainstorm skill spreads exploration across multiple sessions and builds a persistent knowledge structure."
Project Context Detection — Flag for codebase research when:
After parsing, summarize understanding and begin Phase 2.
Engage in iterative questioning until the user signals readiness to proceed.
Question Categories (reference: references/questioning-frameworks.md):
How to question well:
Parking Lot — When the user mentions tangential ideas, interesting threads, or "oh and we could also..." thoughts that aren't central to the core concept, note them. Keep a mental running list and include them in the output. Good ideas shouldn't get lost just because they're not the main topic.
Continuation Protocol:
Spawn research agents only when they'll add genuine value. Don't research for the sake of researching.
Web Research — Spawn when the idea would benefit from external context (most ideas do, but very internal/project-specific ones may not):
Task(subagent_type="web-search-researcher",
prompt="Research best practices, common patterns, and pitfalls for [idea topic].
Find:
1. Similar implementations and how they succeeded/failed
2. Industry best practices and anti-patterns to avoid
3. Common technical approaches and their trade-offs
4. Lessons learned from comparable projects
Focus on actionable insights, not just general information.")
Codebase Research — Spawn only when project context was detected in Phase 1:
Task(subagent_type="codebase-locator",
prompt="Find all files related to [relevant feature area]. Include:
- Core implementation files
- Configuration and setup files
- Test files
- Documentation")
Task(subagent_type="codebase-analyzer",
prompt="Analyze how [related functionality] is currently implemented.
Trace the data flow and identify integration points.
Include file:line references.")
Task(subagent_type="codebase-pattern-finder",
prompt="Find implementation patterns for [type of implementation] in this codebase.
Look for:
- Similar features and how they're structured
- Conventions for [relevant patterns]
- Testing approaches used")
Don't wait idly for agents — move to Phase 4 and incorporate findings when they arrive.
Select 1-2 frameworks based on idea type. Applying all frameworks to every idea produces noise. Pick the ones that will generate the most useful insights.
| Idea Type | Primary Framework | When to Add Secondary | |-----------|-------------------|----------------------| | Product/Feature | SCAMPER | Add Six Hats if stakeholder complexity is high | | Architecture/Technical | Six Thinking Hats | Add Premortem if high-risk | | Strategy/Business | Six Thinking Hats | Add Premortem if reversibility is low | | Process/Workflow | SCAMPER | Add Six Hats if cross-team impact | | Creative/Open | SCAMPER | Add Six Hats (Green + Blue) for direction | | Risk/Problem | Premortem | Add Six Hats (Black + White + Yellow) |
| Hat | Focus | Key Questions | |-----|-------|---------------| | White | Facts | What do we know? What data is missing? | | Red | Intuition | What's the gut reaction? What feels risky or exciting? | | Black | Risks | What could go wrong? What obstacles exist? | | Yellow | Benefits | What benefits does this bring? What's the best case? | | Green | Creativity | What creative alternatives exist? What's unconventional? | | Blue | Process | Is this the right problem? Are we approaching it right? |
Don't force all six hats if only 3-4 are producing meaningful insights.
| Letter | Question | |--------|----------| | Substitute | What could be replaced with something better? | | Combine | What could be merged with existing capabilities? | | Adapt | What patterns from other domains could apply? | | Modify | What could be amplified, reduced, or changed? | | Put to other use | What alternative applications exist? | | Eliminate | What unnecessary complexity could be removed? | | Reverse | What could be reorganized or inverted? |
Skip letters that don't produce meaningful insights for this particular idea.
Focus on the 3-5 most realistic failure modes, not an exhaustive list.
Consolidate findings into actionable insights and write the output document.
Determine Output Location:
docs/brainstorms/YYYY-MM-DD-{topic-slug}.mdWrite the output — include only sections with meaningful content. The template below shows all possible sections; omit any that would just contain filler.
# Brainstorm: [Idea Name]
**Date**: YYYY-MM-DD
**Status**: Ready for Planning | Needs More Exploration
**Type**: [Product/Feature | Architecture | Strategy | Process | Creative | Risk]
## Executive Summary
[2-3 sentence refined description of the idea after exploration]
## Idea Evolution
### Original Concept
[What the user initially described — preserve their words]
### Refined Understanding
[How the idea evolved through questioning — what became clearer]
### Key Clarifications
- [Clarification 1]
- [Clarification 2]
## Analysis
### Strengths
[Validated strengths with supporting evidence. Source these from
Yellow Hat findings or SCAMPER opportunities, depending on which
framework was used.]
### Risks & Concerns
| Risk | Likelihood | Impact | Mitigation |
|------|------------|--------|------------|
| [Risk 1] | H/M/L | H/M/L | [Strategy] |
[Source from Black Hat, Premortem, or both.]
### Gaps
- [ ] **[Gap 1]** — Suggested approach: [...]
### Enhancement Opportunities
[Only if SCAMPER was used. List the meaningful findings, not all 7 letters.]
### Premortem Findings
[Only if Premortem was used.]
- **Failure mode**: [Description] → **Prevention**: [Strategy]
## Research Findings
### External Best Practices
[Only if web research was conducted]
### Codebase Context
[Only if codebase research was conducted]
- Relevant files: [file:line references]
- Existing patterns: [patterns]
- Integration points: [components]
## Parking Lot
[Tangential ideas captured during the session that are worth revisiting]
- [Idea 1]
- [Idea 2]
## Recommended Next Steps
1. [Immediate next step]
2. [Follow-up step]
## Ready for Create-Plan
**[Yes/No]**
**If Yes**: Well-defined and ready for implementation planning.
**If No**: [What needs more exploration]
### Suggested Plan Scope
[What create-plan should focus on]
After writing:
ADR Integration — Only invoke the ADR skill when a significant architectural or strategic decision clearly crystallized during the session (e.g., the user chose between competing approaches, a technology decision was made). Don't force ADR creation when no real decision was made.
Before finalizing output, verify:
questioning-frameworks.md - Detailed question templates for Socratic, Six Hats, SCAMPER, and Premortem frameworkstesting
One-command issue-to-merge pipeline orchestrator. Drives a GitHub issue through nine stages (preflight, plan, implement, review, ci, cloud_review, deploy, e2e, logs) with two human gates, persisting all run state to files so a crashed or interrupted run resumes losslessly. Triggers on "/ship-issue" with an issue number or URL. User-invoked only.
tools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr