Drive the acceptance matrix: backfill an existing repo's business-level acceptance tests into docs/acceptance/matrix.yaml, flip row statuses as evidence lands, and keep the CI gate honest. Use when: "backfill the acceptance matrix", "acceptance debt", "add acceptance rows", a session starts with an acceptance-debt…
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…
Debug a bug, test failure, or unexpected behavior INSIDE an isolated workspace and deliver a reviewed fix-PR. Wraps superpowers:systematic-debugging — enters fr-isolation first (reusing an active workspace, else a fresh fix branch), runs the four phases via the exec-bridge, autonomous to a PR with hard stops only at…
Run a feature goal end-to-end autonomously via the fr-goal workflow shape (optional shape-name argument; no argument resolves fr-goal): brainstorm, one question round sized to the feature (rarely two), then spec → review → fr-plan → review → TDD implementation → review → single PR, fixing every finding in scope and…
Initialize a repo for isolated runs: scan it, interview the operator about working patterns, tools, and credentials, then scaffold one or more devcontainer profiles via fr init scaffold. Use when a repo has no devcontainer profile, when fr-isolation or fr-brainstorming hard-stops asking for one, when the operator says…
Run work in an isolated workspace: git worktree + devcontainer, driven through the fr isolation CLI (exec-bridge). Use when feature work must not touch the base repo, when fr-brainstorming or fr-goal needs a workspace, when the operator says "isolate this" / "run it in the container", or to clean up after a merged PR.…
Plan / spec progress reporting, and the repo-state preflight for any repo with docs/superpowers/ or fr config. Use when: "what's in progress", "status board", "audit drift", "spec rollup", "is this plan up to date", "is this repo fr-managed", "legacy v1 plans", "before archiving or moving files under…
Use when asked to triage, rank, prioritise or organise the open issues of a repo or of a whole org; when asked for a backlog board or "what should we work on next"; or when asked to refresh or sync an existing triage.
Use when asked what a run or session cost, where the money went, whether a process change made the pipeline cheaper, or to compare runs before and after a change; when asked for an audit page or an architecture page of the fr pipeline; or when a PR body needs its usage table.
Use when asked where a repo's recent bugs came from, to classify the issues filed in a window by origin (latent, regression, new feature, leftover, gap, duplicate), to build a defect-origins page, or to explain which process change would have prevented them.
★not rated 2▲
+1 todayA56 tokens
originalMIT
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: