AGENT SKILL

brainstorm

Runs a brainstorming session on any topic: a problem to solve, an opportunity, names, an event, a strategy. Generates far more and better ideas than the user would alone by rotating creative techniques, then optionally narrows them. Use when the user says "brainstorm", "ideas for", "ways to solve", "help me think of", "I'm stuck on", "what are my options for", or "let's ideate", even without the word brainstorm. Not for stress-testing one existing plan (use grilling), deciding what to build next in the current repo (use ideate), or turning a chosen idea into a spec.

License 许可
MIT
最近更新
2026-11-11
Stars
★ 0
Forks
0

01 前言 Front Matter

name
brainstorm
description
Runs a brainstorming session on any topic: a problem to solve, an opportunity, names, an event, a strategy. Generates far more and better ideas than the user would alone by rotating creative techniques, then optionally narrows them. Use when the user says "brainstorm", "ideas for", "ways to solve", "help me think of", "I'm stuck on", "what are my options for", or "let's ideate", even without the word brainstorm. Not for stress-testing one existing plan (use grilling), deciding what to build next in the current repo (use ideate), or turning a chosen idea into a spec.

02 资源文件 2

03 SKILL.md 正文

Brainstorm

You run a brainstorming session. Divergence is the core; convergence is an optional phase the user opts into. A problem is just one kind of topic: reframe it as "How might we…".

Start

  1. Resume check. Glob ~/brainstorms/*.md and read each frontmatter. If any has status: active, offer (AskUserQuestion) to resume it or start fresh. To resume, read the log in full and continue from its last technique line in the same stance.
  2. Frame. Ask one combined question: what are we brainstorming, what's the goal or why behind it, and any inputs to read. Skip it if the request already answers all three; confirm instead. The why steers technique choice ("apps to build with my kids" vs "apps to win market share").
  3. Prior thinking. Ask what they've already considered, tried or ruled out, before you offer a single idea. Log their answers as ideas; they are the baseline to push past.
  4. Stance. AskUserQuestion, Creative Partner first and recommended. The stance holds for the whole session unless the user switches it.
  5. Create the log (see Capture) and tell the user its path.

Stances

  • Facilitator. You never supply ideas. Your moves are questions, provocations, constraints and reflections. If the user directly asks for an idea, give exactly one spark and hand back. When they run dry, change technique or push harder; don't fill the gap yourself.
  • Creative Partner. The user does most of the generating. You add sparks and "yes, and" builds: take their idea one rung higher, then dare them to top it. After every idea you offer, hand back with a question. If you've out-produced them over the last few turns, pull back to questions. Tell them up front they can reject your ideas or ask for more or less help.
  • Generate for me. You run the techniques yourself and present the ideas grouped by technique. One confirm of topic and goal up front, then no questions until you're done. Afterwards, offer to continue together in Facilitator or Creative Partner (log the switch).

Diverge

  1. Read references/techniques.md. From the goal, propose a batch of 3–4 techniques with AskUserQuestion (recommended batch first); the user can swap any.
  2. Announce each technique by name and run it until it stops producing, then rotate. The change of technique is what shifts the creative domain; never let one run past ~10 ideas of sameness.
  3. If the user says they're stuck or the output sounds alike, use the symptom table at the top of references/techniques.md to choose the next technique instead of the batch order.
  4. The first 3–5 ideas on any technique are what anyone would think of. Push past them every time.
  5. Aim for ~30+ ideas across a batch. When the batch is spent, offer with AskUserQuestion: another batch, converge, or wrap up. Never offer to converge while ideas are still flowing.

Prompting rules while generating

  • One open, provocative prompt per message, in plain chat. No multiple choice, no stacked questions: menus invite lazy picking and walls of questions stop people generating.
  • AskUserQuestion is only for process choices: resume, stance, technique batch, continue/converge/wrap, convergence method.
  • Don't evaluate feasibility while generating. Judgment waits for Converge.
  • No research while generating; search results anchor ideas. If the session keeps circling a factual unknown, or converging needs a fact, offer to look it up. Read files the user points to.

Honesty

  • Show dead ideas as dead (~~struck~~ with a few words on why) rather than pretending every idea works. A session where everything works was faked.
  • Anti-genericness: if an idea would appear in a generic listicle for this topic, sharpen it against the user's specifics or drop it.
  • Ideas must differ by mechanism, not wording. A rephrase of an earlier idea is not a new idea.
  • Be a sparring partner, not a yes-machine. Name traps out loud: solutioning before framing, a one-idea brainstorm ("that's one approach; what are three others?"), copying a competitor.

Converge (optional)

  1. Reflect the field back from the log, including odd and early ideas, not just recent ones.
  2. Choose ONE method that fits the decision, name it, and run it to a result:
    • Affinity clustering: many scattered ideas; group into named themes first.
    • Impact–effort: the goal is action; harvest high-impact, low-effort.
    • NUF (New, Useful, Feasible, 1–10 each): novelty matters.
    • Forced ranking: a top-N is needed, no ties.
    • PMI (Plus, Minus, Interesting): one front-runner needs pressure-testing.
    • MoSCoW: scoping a build. Chaining two (e.g. cluster, then impact–effort) is fine; more is over-processing.
  3. In Facilitator mode the user makes every judgment; you only structure. In the other stances, give your view and log it as yours.
  4. For each surviving direction, name its riskiest assumption and the cheapest way to test it.

Wrap up

  1. Mirror first. Reflect a vivid sample of the user's own ideas (odd and buried ones included) and ask what they see: themes, synergies, the few that matter. Let them connect first.
  2. Then add what they'd miss: non-obvious links across techniques ("this idea from inversion quietly solves the tension from six hats"; "these three are one idea wearing three hats").
  3. Append the synthesis to the log, then set status: complete.
  4. Offer next steps: hand a chosen direction to grilling to stress-test it, or produce a one-pager or page only if the user asks.

Capture

Log file: ~/brainstorms/YYYY-MM-DD-<topic-slug>.md, whatever directory the session started in. Create it with this frontmatter once topic, goal and stance are known:

---
topic: <topic>
goal: <why>
stance: facilitator | partner | generate
status: active
---

Append one line per entry, in time order, as it happens (cat >> <log> <<'EOF'). Never edit or reorder logged lines; only stance and status in the frontmatter change.

- [technique] started Inversion
- [idea] (user) Let customers set their own delivery window
- [idea] (claude) Charge for speed, not distance
- [dead] Same-day drones (needs airspace approval we can't get)
- [direction] User wants to focus on the pricing cluster
- [decision] Impact–effort: pricing-by-speed and self-serve windows go forward

Tag the author in Creative Partner mode only; in Facilitator every idea is the user's, in Generate for me every idea is yours. Log ideas in the user's meaning, one line each; skip your prompts and small talk.

04 同仓库更多 Skills

O-Marsters-1997
O-Marsters-1997/my-claude-code

to-tickets

Breaks a source into independently-grabbable GitHub tickets. For a code feature the source is the plan (`docs/plans/<feature>.md`, from /to-plan) and every new or changed symbol lands in exactly one ticket, its signatures copied into the ticket body; a non-code feature is cut from the PRD's slices. Cuts tickets for one feature per run. If a code feature has no approved plan, offers /to-plan instead of cutting from prose. In a repo that runs command-centre, also emits `[[task]]` blocks into its config; in a plain treepad repo, emits a Batch Manifest instead so the tickets materialise as stacked worktrees.

★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

to-seams

Records an agreed-but-unlanded cross-repo interface as a seam: the file a consumer's agent gets pasted into its prompt as ground truth, plus the `[[seam]]` block command-centre reads for the retirement pointer. Use when two repos need to build against an interface neither has landed yet — "record a seam for X", "we agreed on this schema, seam it", "add a seam so Y can build against Z's new field". Halts for approval before writing either file.

Skill与智能体开发
★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

to-roadmap

Prioritises settled features into a Now / Next / Later kanban board, rendered as a self-contained ./ideas/roadmap.html. Each card is a feature, not a ticket — one card later becomes several tickets via /to-prd -> /to-plan -> /to-tickets. Boards the features in ./docs/approach.md, or the "## Accepted ideas" in ./ideas/CONTEXT.md when there is no approach doc. The approach doc is settled truth: this assigns tiers and reasons about ordering, it never re-litigates what was decided.

产品经理
★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

to-prd

Turns one feature idea into a PRD built on journeys: a one-line problem, journeys (each ending in an observable state) and delivery slices that say what is usable after each. Interviews, explores the codebase, and saves to docs/prds/<feature>.md. Covers exactly one feature: given a multi-feature source, ask which one. Reads any approach doc or ideate report as priors so it doesn't re-ask what's settled, but needs none. Starts the per-feature spine (/to-prd -> /to-plan -> /to-tickets).

产品经理
★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

to-plan

Turns one feature's PRD into a skimmable plan in docs/plans/<feature>.md: a short overview, then per phase a glossary, the journeys it satisfies, and its new and modified definitions (types, enums, ports, schema), with the project:<slug> label. No code, branch or PR; the user's review of the file is the gate. Use for "plan this feature", "write the contract", "what are the types". One feature per run. Slash-only.

★ 0
O-Marsters-1997
O-Marsters-1997/my-claude-code

ticket-tracker

Use when the request is about the *current state* of GitHub issues rather than creating new ones: "where are my tickets", "show the board", "what's in progress", "what's ready to pick up", "move issue N to in-review", "mark N done", "update the ticket status". Live triage board over GitHub issues via the gh CLI, moving each between backlog -> ready -> in-progress -> in-review -> done using status labels. This is the ticket-level board; ./ideas/roadmap.html is the feature-level one. To file new tickets, use /to-tickets, file-issue for a single ad-hoc one, or /sweep for a batch of small fixes.

★ 0