workflow-brainstorm
Skill337 starsChanged 10 months agoMITView on GitHub
Use when you need to turn a vague idea into a confirmed design spec before implementation (new feature/component/behavior change). First check project context, then ask one question at a time, provide 2-3 options with trade-offs, finally output design in segments (~200-300 words each) with confirmation after each. Triggers: brainstorm, clarify idea, design spec, refine concept, requirement clarification.
In this repository40 other files it gives its agents.
- review-clean-codeSkill
- review-doc-consistencySkill
- review-merge-readinessSkill
- workflow-execute-plansSkill
- workflow-template-extractorSkill
- workflow-template-seederSkill
- cloudflareSkill
- deep-researchSkill
- mcp-cloudflareSkill
- mcp-stripeSkill
- mcp-supabaseSkill
- publish-x-articleSkill
- review-clean-codeSkill
- review-doc-consistencySkill
- review-merge-readinessSkill
- review-qualitySkill
- review-react-best-practicesSkill
- review-seo-auditSkill
- skill-creatorSkill
- skill-evolutionSkill
- skill-improverSkill
- stripeSkill
- supabaseSkill
- tool-ast-grep-rulesSkill
- tool-better-authSkill
- tool-design-style-selectorSkill
- tool-hooks-doctorSkill
- tool-openclawSkill
- tool-programmatic-seoSkill
- tool-schema-markupSkill
- tool-systematic-debuggingSkill
- tool-ui-ux-pro-maxSkill
- tool-x-article-publisherSkill
- workflow-creatorSkill
- workflow-execute-plansSkill
- workflow-feature-shipperSkill
- workflow-project-intakeSkill
- workflow-ship-fasterSkill
- workflow-template-extractorSkill
- workflow-template-seederSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 10 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈10
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 18
Before asking questions, quickly check:
- Distinctive: line 32
Prefer multiple choice (reduce user's cognitive load), use open questions only when necessary
- Distinctive: line 33
Ask direction-determining questions first (goals/success criteria/non-goals), then details
- Distinctive: line 37
After you understand the requirements:
- Distinctive: line 44
When you're confident you understand what needs to be done, start outputting the design spec.
- Distinctive: line 48
Ask for confirmation at the end of each segment: e.g., "Does this look good?"
- Distinctive: line 55
If user disagrees with a segment: go back to questioning/option phase to clarify—don't push forward.
- Distinctive: line 61
Prefer writing to run directory (artifact-first):
- Very specific: line 64
If there's no run_dir but there is a repo_root:
- Very specific: line 65
Create runs/brainstorm/active/<run_id>/, and write design to evidence/
- Distinctive: line 71
After design is confirmed, ask one question to let user choose next step:
- Very specific: line 73
Write implementation plan first (persist as checklist items in run_dir/tasks.md, then wait for confirmation)
- Distinctive: line 78
One question at a time: Never ask 5 questions in one message
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Brainstorming Ideas Into Designs
Goal
Transform "vague ideas/requirements" into actionable designs and specifications, producing reusable file artifacts (rather than just staying in chat).
Key requirement: Ask only one question at a time. If a topic is complex, break it into multiple rounds of Q&A—don't throw out a checklist all at once.
Core Process (Must Follow)
0) Check Project Context First (Required When Repo Exists)
Before asking questions, quickly check:
- Key documentation:
README.md,docs/,design-system.md(if exists) - Tech stack and constraints:
package.json/Cargo.toml/pyproject.tomletc. - Structure overview: top-level directories, main modules
- Recent changes:
git log -n 10 --oneline(if it's a git repo)
Output a very brief context summary: what you observed + possible constraint points (don't start designing yet).
1) Understand the Idea (One Question at a Time)
Goal is to gather the minimum information set (purpose / constraints / success criteria).
Rules:
- Each message asks 1 question only
- Prefer multiple choice (reduce user's cognitive load), use open questions only when necessary
- Ask direction-determining questions first (goals/success criteria/non-goals), then details
2) Explore Solutions (2-3 Options + Trade-offs)
After you understand the requirements:
- Provide 2-3 options (A/B/C)
- Explain trade-offs for each (complexity/risk/iteration speed/long-term cost)
- Give your recommended option first, then explain why
3) Output Design (200-300 Word Segments + Confirm Each)
When you're confident you understand what needs to be done, start outputting the design spec.
Requirements:
- Output in segments (~200-300 words each)
- Ask for confirmation at the end of each segment: e.g., "Does this look good?"
- Design should at least cover:
- Architecture and module boundaries
- Core data flow (input → processing → output)
- Error handling and edge cases
- Testing and validation strategy (minimum viable set)
If user disagrees with a segment: go back to questioning/option phase to clarify—don't push forward.
Artifacts and Persistence (Strongly Recommended)
Write Design Document
Prefer writing to run directory (artifact-first):
run_dir/evidence/YYYY-MM-DD-<topic>-design.md
If there's no run_dir but there is a repo_root:
- Create
runs/brainstorm/active/<run_id>/, and write design toevidence/
Note: Writing files is a write operation; if this is the user's project repo, confirm "should I persist to the project?" before writing.
Enter Implementation (Optional)
After design is confirmed, ask one question to let user choose next step:
- Enter implementation directly (recommend
workflow-ship-fasterorworkflow-feature-shipper) - Write implementation plan first (persist as checklist items in
run_dir/tasks.md, then wait for confirmation) - Need research/code reading first (split to
run_dir/evidence/parallel/<task-name>/and do in parallel)
Key Principles
- One question at a time: Never ask 5 questions in one message
- Multiple choice preferred: Help user respond faster and more effectively
- YAGNI: Actively remove "not needed yet" features from the design
- Incremental validation: Output design in segments, confirm each one
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

