refactor(skills): move orchestration state files to docs/superpowers/states/

README.md

@@ -100,7 +100,8 @@ This plugin depends on the [superpowers](https://github.com/obra/superpowers) pl
 skills directly: `superpowers:brainstorming`, `superpowers:writing-plans`,
 `superpowers:test-driven-development`, `superpowers:verification-before-completion`, and
 `superpowers:dispatching-parallel-agents`. It also uses superpowers' `docs/superpowers/{specs,plans}/`
-path convention. Install superpowers first.
+path convention, adding a sibling `docs/superpowers/states/` directory for orchestration state files.
+Install superpowers first.
 
 The skills also assume the [`gh`](https://cli.github.com/) CLI is installed and authenticated.
 

skills/developing-a-feature/SKILL.md

@@ -17,7 +17,7 @@ ad-hoc fixes — those go directly through `superpowers:test-driven-development`
 
 ### 1. Read the state file first, then plan + spec
 
-The orchestration state file (`docs/superpowers/plans/<date>-<slug>-state.md`, created by `feature-dev-workflow:planning-a-feature` Step 8)
+The orchestration state file (`docs/superpowers/states/<date>-<slug>-state.md`, created by `feature-dev-workflow:planning-a-feature` Step 8)
 is the entry point — it points at the plan, the spec, the tracking issue, the open PRs, the worktrees, and any
 bubble-up concerns logged so far. Read it in full before anything else; follow the file's "Resume checklist"
 section to verify reality against the recorded state.

skills/fanning-out-with-worktrees/SKILL.md

@@ -16,7 +16,7 @@ When you're the orchestrator for multi-PR feature work and these prerequisites a
   invoking this skill).
 - The plan (`docs/superpowers/plans/<date>-<slug>-plan.md`) has a `## Contracts` section with a Realization strategy
   per row.
-- The state file (`docs/superpowers/plans/<date>-<slug>-state.md`) has rows for each sub-issue.
+- The state file (`docs/superpowers/states/<date>-<slug>-state.md`) has rows for each sub-issue.
 
 Skip for single-PR features — there's no fan-out, just one branch off main.
 

skills/planning-a-feature/SKILL.md

@@ -159,7 +159,7 @@ single "yes to all": a wall of bodies gets rubber-stamped instead of read.
 
 ### 8. Initialize the orchestration state file
 
-Before handing off, create `docs/superpowers/plans/YYYY-MM-DD-<slug>-state.md` from
+Before handing off, create `docs/superpowers/states/YYYY-MM-DD-<slug>-state.md` from
 `${CLAUDE_PLUGIN_ROOT}/skills/planning-a-feature/templates/feature-state.md`. This is the **orchestration state** — phases, PRs, worktrees, contract realization,
 bubble-up log. It's what a future Claude session reads first to resume the work without a massive user prompt.
 

skills/reviewing-feature-progress/SKILL.md

@@ -34,7 +34,7 @@ accumulates silently across waves; this skill catches it at the boundary.
 
 Open these in order:
 
-- The state file (`docs/superpowers/plans/<date>-<slug>-state.md`).
+- The state file (`docs/superpowers/states/<date>-<slug>-state.md`).
 - The plan (`docs/superpowers/plans/<date>-<slug>-plan.md`), with focus on the `## Contracts` section and the
   PR-by-PR breakdown.
 - The spec (`docs/superpowers/specs/<date>-<slug>-design.md`), with focus on goals + non-goals.

templates/project-CLAUDE.md

@@ -73,4 +73,4 @@ so sessions don't have to guess:
 - **Never `--no-verify`, never `git add -A` / `git add .`.** Stage by name; pre-commit hooks exist for a reason.
 - **No GitHub mutation without a fresh confirmation against the specific body about to land.** Paste the body inline, name the target, wait for an explicit yes.
 - **PR titles outlive lifecycle state.** No `wip` / `draft` / `plan` suffixes; GitHub's chip carries lifecycle.
-- **Specs in `docs/superpowers/specs/` are durable; plans in `docs/superpowers/plans/` are scratch** (deleted once the plan ships). State files live beside the plan.
+- **Specs in `docs/superpowers/specs/` are durable; plans in `docs/superpowers/plans/` are scratch** (deleted once the plan ships). State files live in `docs/superpowers/states/` and share the plan's scratch lifecycle.