agentleFS
HeyvhuangHeyvhuang/ship-faster/skills/workflow-brainstorm/SKILL.md

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.

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
  1. Distinctive:

    Before asking questions, quickly check:

    line 18
  2. Distinctive:

    Prefer multiple choice (reduce user's cognitive load), use open questions only when necessary

    line 32
  3. Distinctive:

    Ask direction-determining questions first (goals/success criteria/non-goals), then details

    line 33
  4. Distinctive:

    After you understand the requirements:

    line 37
  5. Distinctive:

    When you're confident you understand what needs to be done, start outputting the design spec.

    line 44
  6. Distinctive:

    Ask for confirmation at the end of each segment: e.g., "Does this look good?"

    line 48
  7. Distinctive:

    If user disagrees with a segment: go back to questioning/option phase to clarify—don't push forward.

    line 55
  8. Distinctive:

    Prefer writing to run directory (artifact-first):

    line 61
  9. Very specific:

    If there's no run_dir but there is a repo_root:

    line 64
  10. Very specific:

    Create runs/brainstorm/active/<run_id>/, and write design to evidence/

    line 65
  11. Distinctive:

    After design is confirmed, ask one question to let user choose next step:

    line 71
  12. Very specific:

    Write implementation plan first (persist as checklist items in run_dir/tasks.md, then wait for confirmation)

    line 73
  13. Distinctive:

    One question at a time: Never ask 5 questions in one message

    line 78

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.toml etc.
  • 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 to evidence/

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:

  1. Enter implementation directly (recommend workflow-ship-faster or workflow-feature-shipper)
  2. Write implementation plan first (persist as checklist items in run_dir/tasks.md, then wait for confirmation)
  3. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.