agentleFS
cperlercperler/sous/.claude/skills/brainstorm/SKILL.md

brainstorm

Skill1 starsChanged 7 days agoMITView on GitHub

Turn a fuzzy area or goal into a ranked shortlist of concrete, scored ideas and hand the human's picks off — small ones filed as standalone enhancement issues, larger ones fed to spec-intake. You run the divergent exploration and the idea authoring over the real codebase, backlog, and run history; deterministic `orchestrator brainstorm` code ranks and files. The front door ABOVE intake — ideas out, not issues-from-a-known-idea and not code.

190 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use playtest-report, team-polish and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • CoralGameSkill

    playtest-report

    Generates a structured playtest report template or analyzes existing playtest notes into a structured format. Use this to standardize playtest feedback collection and analysis.

    Also in 9 projects that use this

  • CoralGameSkill

    team-polish

    Orchestrate the polish team: coordinates performance-analyst, technical-artist, sound-designer, and qa-tester to optimize, polish, and harden a feature or area for release quality.

    Also in 11 projects that use this

  • lilangMaxSkill

    soak-test

    Generate a soak test protocol for extended play sessions. Defines what to observe, measure, and log during long play sessions to surface slow leaks, fatigue effects, and edge cases that only appear after sustained play. Primarily used in Polish and Release phases.

    Also in 6 projects that use this

  • lilangMaxSkill

    team-live-ops

    Orchestrate the live-ops team for post-launch content planning: coordinates live-ops-designer, economy-designer, analytics-engineer, community-manager, writer, and narrative-director to design and plan a season, event, or live content update.

    Also in 6 projects that use this

  • +8 more from CoralGame

The file

We split this skill into the rules it gives an agent

2 rules. 0 are common, 2 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 157 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Don't re-propose something already tracked.

    line 27
  2. Distinctive:

    The codebase: read structure, TODOs, rough edges near the area.

    line 28

“Common” is measured: kept by at least 6 in 10 of the 157 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 — a fuzzy area → divergent ideas → ranked shortlist → filed picks

You are the front door above the front door. spec-intake turns a known idea into dependency-ordered issues; batch-plan turns already-filed issues into a scheduled batch. Neither invents the idea. This skill does: it takes a fuzzy area/goal, diverges (explores the codebase, the issue backlog, and run history to generate N candidate ideas), then converges (a deterministic ranked shortlist the human picks from) and hands off. You own the exploration and the idea authoring; the deterministic orchestrator brainstorm commands own ranking and filing. Filing is outward-facing: the human selects from the shortlist before anything is created.

Constants

  • PROJECT = the project-config module/dir supplying the task source (e.g. adapters.project.selfhost).
  • Command shape: uv run orchestrator [--project "$PROJECT"] brainstorm <validate|capture> <file> [flags].

The flow

  1. Clarify the area. Pin down the fuzzy goal in one or two questions — what outcome are we chasing, what's explicitly out of bounds. Don't interview; just enough to aim the divergence.
  2. Gather evidence (READ-ONLY). Explore for opportunities. Good sources:

    • The backlog: uv run orchestrator --project "$PROJECT" batch-plan candidates [--label X] (or gh issue list) — what's already filed, what clusters, what's stale. Don't re-propose something already tracked; build on it or say why it's insufficient.
    • The codebase: read structure, TODOs, rough edges near the area. Cite real paths.
    • Run history (if present): retrospectives / learnings under runs/<run>/ — recurring failure patterns and the self-improvement loop's filed ideas are rich seams. Read only.

    On a brand-new project all three are empty — substitute the product's own domain. A repo created an hour ago has no backlog to cluster, no rough edges to read, and no run history; going through the motions on empty sources produces generic ideas dressed as grounded ones. The evidence base is the domain instead: what the external APIs/venues in this space actually offer, what the obvious v1 slices are, what is cheap versus load-bearing, what the thinnest end-to-end path looks like. That satisfies the schema — evidence is optional and ranking is on impact/effort/risk — but cite real reasoning ("Polymarket's public API paginates markets, so a client + fixtures is a small first slice"), never file paths or issue refs that do not exist yet.

  3. Diverge — the model work. Generate N candidate ideas (aim wide, ~5–10; quantity before judgment). Each idea needs: a concrete problem (the gap/pain), a proposal sketch (how you'd address it), and honest impact (high/medium/low), effort (small/medium/large), risk (low/medium/high), plus evidence pointers (file paths, issue refs, run-log observations) that ground it. Cheap wins and moonshots both belong here.
  4. Write the session JSON to a file (schema: orchestrator/schemas/brainstorm.json):
    {
      "area": "reduce batch-run cost",
      "ideas": [
        { "title": "Cache install layers across tasks",
          "problem": "every task in a batch re-runs `uv sync` from cold — minutes of wall time",
          "proposal": "hash the lockfile set, reuse a warm venv across a run's worktrees",
          "impact": "high", "effort": "small", "risk": "low",
          "evidence": ["adapters/execution/install_cache.py", "runs/2026-07-02-*/stage-costs.jsonl"] }
      ]
    }
  5. Converge — rank and show the shortlist. uv run orchestrator brainstorm capture <file> prints the deterministic ranked shortlist: impact descending, then effort ascending (cheaper first), then risk ascending (safer first); ties keep authored order. The score is named-weight math, not a model opinion — it's reproducible from the file. Present the shortlist to the human with your read on the top few.
  6. STOP for the human's pick. Filing opens real issues. Do not file until the human names which ranks to take. (brainstorm validate <file> schema-checks without printing.)
  7. Hand off per pick. For each selected idea, route by size:
    • Small / self-contained → file it as a standalone enhancement issue: uv run orchestrator --project "$PROJECT" brainstorm capture <file> --file-selected 1,3 (add --dry-run first to preview). Each files with the brainstorm label and a body carrying its problem/proposal/evidence plus a provenance line — the rationale travels with the issue instead of vaporizing in this conversation. --file-selected takes the 1-based shortlist ranks exactly as printed.
    • Larger / multi-task → don't file a lone issue; carry the idea into spec-intake as the raw idea. It decomposes into a dependency-ordered spec and files the batch. (A brainstorm idea and a spec are different altitudes — one enhancement vs. a whole feature.)

Notes

  • Three producers, one scheduler. brainstorm (fuzzy area → ideas) sits above spec-intake (a known idea → a batch of issues) and batch-plan (existing issues → a scheduled DAG). Each hands the next stage its input; don't skip the altitude that fits the request.
  • Durable + replayable. The session JSON is the record: brainstorm capture re-prints the exact same ranked shortlist from it any time, and filing is a separate, explicit step. Keep the file (e.g. under a scratch dir) so a brainstorm doesn't evaporate.
  • Lineage. The old bash system surfaced innovation ideas only as a free-text innovation_brainstorm reflection stapled to a PR at task completion. This rebuilds the capability as a structured, standalone front door; the per-run reflection it also served now lives in the retrospective + the self-improvement loop's issue-filing.
  • validate / capture-print are pure (no --project); only capture --file-selected (real, not --dry-run) needs the task source. You explore and author ideas; the deterministic code ranks and files. Don't re-implement scoring or filing here.

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.