fr-brainstorming
superpowers:brainstorming, wrapped in isolation. Exploration commands,
spec drafts, and everything downstream happen in the isolation workspace,
so a brainstorm that becomes a build never has to relocate, and a brainstorm
that dies leaves the base repo pristine.
Announce at start: "I'm using fr-brainstorming to design this in isolation."
0. Isolation first — hard gate
Before ANY command — exploration, measurement, cluster reads included; an
operator "start with X" never reorders this:
fr isolation up --branch <feature-branch> [--profile <name>]
- Name the branch for the feature now (
feat/<slug>); the worktree, the
eventual PR, and cleanup all key off it. The new feat/<slug> is cut from
freshly-fetched origin/<default> (#322) — pass --base <ref> only to
stack on something else.
- No devcontainer profile → HARD STOP — but only in devcontainer mode.
Offer to run the fr-init interview immediately; if the operator declines,
the brainstorm does not proceed. (Under fr-goal, treat it as a blocker:
pause, fr-init, resume.) On a docker-less host that declares
FR_ISOLATION_TARGET=worktree (or in a prepared external container), up
succeeds without a profile — no stop, the worktree is the isolation.
- From here on, follow the fr-isolation skill's exec-bridge discipline:
read/edit files in the worktree, run every command through
fr isolation exec -- ....
1. Brainstorm
Run superpowers:brainstorming as usual — understand the context and goal,
explore the codebase (in the worktree), propose approaches, refine into a
design.
- Standalone invocation: fully interactive — ask questions as they
arise, section-by-section validation, the normal brainstorming flow.
- Under fr-goal: the batched-Q&A contract applies instead — collect
every operator-owned decision and ask ONCE (fr-goal's rules win while it
drives).
2. Hand off
The brainstorm's design document becomes the spec
(docs/superpowers/specs/<YYYY-MM-DD-slug>-design.md, committed in the
worktree). Hand off to fr-plan (the fr-plan-override rule already routes
writing-plans there). The isolation workspace stays up — planning and
implementation continue in it; cleanup belongs to whoever finishes the run
(fr isolation down after the PR merges).
3. Acceptance rows — born with the spec, presented at the close
Each key "operator can do X" claim in the design becomes a matrix row:
fr acceptance add --status not-implemented --origin <repo>:<new-spec-path>
(run fr acceptance init first if the repo has no matrix). The brainstorm
ENDS by presenting the rows to the operator with a one-line defense each —
the business claim it pins, the target verification level, why it is
business-level rather than an implementation detail. Silent row creation is
not acceptance-of-scope; the presentation is. Under fr-goal the presentation
rides the spec-review step. Hand-off checklist: rows added AND presented.
Scope notes
- This skill owns WHERE brainstorming happens, not HOW — brainstorming's
own craft (questions, alternatives, YAGNI) is unchanged.
- Multi-repo features: brainstorm in the repo that owns the spec; other
repos get their own isolation workspaces when their plans dispatch
(one workspace, one branch, one PR per repo).
1---2name: fr-brainstorming3description: Brainstorm a feature INSIDE an isolated workspace: invokes fr-isolation first, then runs superpowers brainstorming in the worktree/devcontainer — the base repo is never touched from the first command on. Use for any feature brainstorm in a vk-enabled repo (vk plans or devcontainer profiles present), when fr-goal starts its pipeline, or when the operator says "brainstorm this feature", "let's design X", or starts creative work that will become a spec. devcontainer mode hard-stops without a profile; docker- less host/external modes isolate via the worktree instead.4---56# fr-brainstorming78`superpowers:brainstorming`, wrapped in isolation. Exploration commands,9spec drafts, and everything downstream happen in the isolation workspace,10so a brainstorm that becomes a build never has to relocate, and a brainstorm11that dies leaves the base repo pristine.1213**Announce at start:** "I'm using fr-brainstorming to design this in isolation."1415## 0. Isolation first — hard gate1617Before ANY command — exploration, measurement, cluster reads included; an18operator "start with X" never reorders this:1920```bash21fr isolation up --branch <feature-branch> [--profile <name>]22```2324- Name the branch for the feature now (`feat/<slug>`); the worktree, the25 eventual PR, and cleanup all key off it. The new `feat/<slug>` is cut from26 freshly-fetched `origin/<default>` (#322) — pass `--base <ref>` only to27 stack on something else.28- **No devcontainer profile → HARD STOP — but only in devcontainer mode.**29 Offer to run the fr-init interview immediately; if the operator declines,30 the brainstorm does not proceed. (Under fr-goal, treat it as a blocker:31 pause, fr-init, resume.) On a docker-less host that declares32 `FR_ISOLATION_TARGET=worktree` (or in a prepared external container), `up`33 succeeds without a profile — no stop, the worktree is the isolation.34- From here on, follow the fr-isolation skill's exec-bridge discipline:35 read/edit files in the worktree, run every command through36 `fr isolation exec -- ...`.3738## 1. Brainstorm3940Run `superpowers:brainstorming` as usual — understand the context and goal,41explore the codebase (in the worktree), propose approaches, refine into a42design.4344- **Standalone invocation:** fully interactive — ask questions as they45 arise, section-by-section validation, the normal brainstorming flow.46- **Under fr-goal:** the batched-Q&A contract applies instead — collect47 every operator-owned decision and ask ONCE (fr-goal's rules win while it48 drives).4950## 2. Hand off5152The brainstorm's design document becomes the spec53(`docs/superpowers/specs/<YYYY-MM-DD-slug>-design.md`, committed in the54worktree). Hand off to `fr-plan` (the fr-plan-override rule already routes55`writing-plans` there). The isolation workspace stays up — planning and56implementation continue in it; cleanup belongs to whoever finishes the run57(`fr isolation down` after the PR merges).5859## 3. Acceptance rows — born with the spec, presented at the close6061Each key "operator can do X" claim in the design becomes a matrix row:62`fr acceptance add --status not-implemented --origin <repo>:<new-spec-path>`63(run `fr acceptance init` first if the repo has no matrix). **The brainstorm64ENDS by presenting the rows to the operator with a one-line defense each** —65the business claim it pins, the target verification level, why it is66business-level rather than an implementation detail. Silent row creation is67not acceptance-of-scope; the presentation is. Under fr-goal the presentation68rides the spec-review step. Hand-off checklist: rows added AND presented.6970## Scope notes7172- This skill owns WHERE brainstorming happens, not HOW — brainstorming's73 own craft (questions, alternatives, YAGNI) is unchanged.74- Multi-repo features: brainstorm in the repo that owns the spec; other75 repos get their own isolation workspaces when their plans dispatch76 (one workspace, one branch, one PR per repo).
derio-net