# Fr Brainstorming

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

- Skill: `derio-net/fr-brainstorming` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add derio-net/fr-brainstorming`
- Raw SKILL.md: https://api.skillmd.com/api/skills/derio-net/fr-brainstorming/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: derio-net (https://skillmd.com/u/derio-net)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/derio-net/fr-brainstorming

---


# 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:

```bash
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).