agentleFS
Sign inStart free
gclmgclm/super-stack/skills/planning/brainstorm/SKILL.md

brainstorm

Skill0 starsChanged 7 months agoMITView on GitHub

Explore 2-3 credible implementation approaches, compare trade-offs, and converge on a recommendation before detailed planning.

We split this skill into the rules it gives an agent

9 rules. 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 151 edited versions we read keep these.

  • 6

    Distinctive

    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:

    Use this skill when the user has a feature idea, architecture question, workflow choice, or a non-trivial design decision that should be …

    line 8
  2. Distinctive:

    Do not use this skill when the work is already obvious and low risk.

    line 42
  3. Distinctive:

    Before comparing options, if the problem statement is likely carrying hidden assumptions, briefly surface:

    line 46
  4. Distinctive:

    when this option is best

    line 59
  5. Distinctive:

    Keep options credible. Avoid fake alternatives that only exist to make one recommendation look easy.

    line 61
  6. Distinctive:

    When a reference project is involved, explicitly say whether each option reuses:

    line 63
  7. Very specific:

    If harness/state.md exists, update current focus to reflect the decision being shaped.

    line 83
  8. Very specific:

    If docs/overview/project-overview.md or docs/reference/requirements.md exist, add a concise note about:

    line 85
  9. Very specific:

    If the repository does not yet have usable docs/ + harness/ state files, provide the recommendation in chat and note that discuss or plan …

    line 92

“Common” is measured: kept by at least 6 in 10 of the 151 edited versions of this file we could read. “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

Brainstorm

Use this skill when the user has a feature idea, architecture question, workflow choice, or a non-trivial design decision that should be compared before committing to a plan.

Read First

  • docs/overview/project-overview.md if it exists
  • docs/reference/requirements.md if it exists
  • harness/state.md if it exists
  • harness/history.md if it exists
  • docs/reference/conventions.md if it exists
  • relevant local code and docs when the request targets an existing codebase
  • references/reference-reuse-boundary.md when the decision involves reusing another project's structure or implementation

Goals

  • surface the real decision
  • generate 2-3 realistic approaches
  • explain trade-offs in plain language
  • recommend the strongest option
  • persist the decision context for later planning
  • expose hidden assumptions and missing facts when they materially change which option is best

When To Use

Good triggers:

  • new feature architecture
  • build vs buy decision
  • data model or API shape decision
  • background job or workflow choice
  • frontend interaction pattern choice
  • validation sample vs product implementation path
  • reference structure reuse vs direct implementation reuse
  • "what's the best way to do this?"

Do not use this skill when the work is already obvious and low risk.

Approach Rules

Before comparing options, if the problem statement is likely carrying hidden assumptions, briefly surface:

  • the main hidden assumptions
  • the missing information that would change the recommendation
  • the most common mistake people make on this kind of decision

For each option, include:

  • approach name
  • what it looks like in practice
  • main advantages
  • main costs or risks
  • implementation complexity: low, medium, or high
  • when this option is best

Keep options credible. Avoid fake alternatives that only exist to make one recommendation look easy.

When a reference project is involved, explicitly say whether each option reuses:

  • information architecture
  • interaction structure
  • implementation details

Decision Format

Use this structure:

  1. Problem framing
  2. Assumptions and missing information when relevant
  3. Option A
  4. Option B
  5. Option C if a third option adds real value
  6. Recommendation
  7. Open questions, if any

Persistence

If harness/state.md exists, update current focus to reflect the decision being shaped.

If docs/overview/project-overview.md or docs/reference/requirements.md exist, add a concise note about:

  • chosen approach
  • important rejected alternative
  • why the chosen option won
  • the scope mode, such as validation-first or implementation-first

If the repository does not yet have usable docs/ + harness/ state files, provide the recommendation in chat and note that discuss or plan should capture it next.

Output

Tell the user:

  • what decision was analyzed
  • the recommended approach
  • the biggest trade-off they are accepting
  • that the next step is usually plan

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.

Reviews can't be read right now.

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.

Check your setup, free