@jakkrichm/create-nexus-devflow 2.7.0 → 2.9.0

package/template/.agents/skills/implement/SKILL.md

@@ -13,7 +13,7 @@ Where this sits in the workflow:
                                         reviewed)        merge + log)
 
 `/feature`, `/fix`, or `/rollback` wrote the spec to
-`devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`) and stopped.
+`devflow/context/{xxx-slug}/spec.md` and stopped.
 This skill turns that spec into code, following the build loop in
 `devflow/context/ai-interaction.md`, without vibe coding: small steps, a visible diff plus
 a plain-English explanation for each, testing, and iteration until it works, all
@@ -24,11 +24,11 @@ checkpoint after each step; the work-level commit, merging, and logging are
 ## Multi-Run Target Resolution
 
 - **Given an ID or name** (e.g. `/implement 12`, `/implement 012`, `/implement kanban`) -> locates the matching run folder `devflow/context/{xxx-slug}/`, checks out `feature/{xxx-slug}`, and loads only that run's `spec.md`.
-- **With no argument** (`/implement`) -> checks current git branch, or auto-picks if only 1 spec is active, or prompts the user if multiple specs are queued.
+- **With no argument** (`/implement`) -> checks current git branch matching `feature/{xxx-slug}`, or auto-picks if only 1 spec is active in `devflow/context/`, or prompts the user if multiple specs are queued.
 
 ## Before you start
 
-Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`). If it has no real spec (still the stub, or its
+Read the target spec from `devflow/context/{xxx-slug}/spec.md`. If it has no real spec (missing or its
 status is already complete), stop and tell the user to run `/feature` (for a
 planned feature), `/fix` (for an ad-hoc bug or change), or `/rollback` (for a
 completed feature reversal) first. Pull the
@@ -45,13 +45,12 @@ feature was started earlier and interrupted (often a cleared context). The spec
 its ticked steps are files, so pick up where it left off: read which steps are done,
 check the git branch and `git status`/log to see what is committed and what is still
 in the working tree, then continue from the **first unchecked step** instead of
-starting over. No separate save/load is needed - the project instructions load
-`current-feature.md` every session.
+starting over.
 
 ## Step 1 - branch
 
-Create and check out a branch named from the spec: `feature/<name>` for a feature,
-`fix/<name>` for a fix, or `rollback/<name>` for a Type: Rollback spec. If the
+Create and check out a branch named from the spec: `feature/{xxx-slug}` for a feature,
+`fix/{xxx-slug}` for a fix, or `rollback/{xxx-slug}` for a Type: Rollback spec. If the
 project isn't a git repo yet, say so and ask the user to run `git init` first;
 the loop needs branches. On resume, the branch already exists - check it out
 instead of creating a new one.
@@ -60,7 +59,7 @@ instead of creating a new one.
 
 For a rollback spec, do not hand-delete the old feature and do not run a whole
 commit `git revert`. Completed feature commits also contain Blueprint history and
-plan bookkeeping, while `current-feature.md` now contains the active rollback
+plan bookkeeping, while `devflow/context/{xxx-slug}/spec.md` now contains the active rollback
 spec. Reversing the whole commit would damage that state.
 
 Before the first rollback build step:
@@ -133,9 +132,9 @@ Work through the spec's build steps in order, one at a time. For each step:
    Repeat until it works and the user approves. Nothing is committed until the
    user is happy with the step.
 6. **Mark it done, then prompt to move on.** Once the step is approved, check that
-   step off (`- [x]`) in `devflow/context/current-feature.md` so progress survives a context
+   step off (`- [x]`) in `devflow/context/{xxx-slug}/spec.md` so progress survives a context
    clear. If the step repaired a finding tracked in
-   `devflow/context/findings.md`, set that finding's status to `fixed` now too
+   `devflow/context/{xxx-slug}/findings.md`, set that finding's status to `fixed` now too
    and note the repair in its **Resolution** line. Never set `closed`: a repair
    is re-reviewed by `/audit` before it clears, because a fix can introduce a
    worse defect than the one it removed. Then offer a short choice, noting that checkpoints are optional since
@@ -164,12 +163,12 @@ pass before any commit.
 
 ## Step 3 - hand off to /complete
 
-Before handing off, check `devflow/context/findings.md`. A P0 or P1 finding
+Before handing off, check `devflow/context/{xxx-slug}/findings.md`. A P0 or P1 finding
 still `open` or `fixed` there means `/complete` will refuse the merge, so close
 the loop now:
 
 - Repair each `open` P0 or P1 as an extra reviewed step. First append it to the
-  spec's build steps in `current-feature.md` (`- [ ] Repair F-03 - <title>`) so
+  spec's build steps in `devflow/context/{xxx-slug}/spec.md` (`- [ ] Repair F-03 - <title>`) so
   the repair is on the record and survives a context clear, then run the same
   loop as Step 2: smallest change, diff, plain-English explanation, evidence.
   Check the step off and mark the finding `fixed` together.

package/template/.agents/skills/release/SKILL.md

@@ -46,7 +46,7 @@ Read:
 - `devflow/project-plan.md`
 - `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/current-feature.md`
+- `devflow/context/{xxx-slug}/spec.md` (when a task is active)
 - package or build files such as `package.json`, lockfiles, framework config,
   Dockerfile, `render.yaml`, `vercel.json`, `.env.example`, and README files
 - git branch and working tree status

package/template/.agents/skills/report-html/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: report-html
-description: "[devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from current-feature.md or history archives on demand."
+description: "[devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from devflow/context/{xxx-slug}/spec.md or history archives on demand."
 argument-hint: "[{running-id or workspace path}]"
 ---
 
@@ -8,7 +8,7 @@ argument-hint: "[{running-id or workspace path}]"
 
 $ARGUMENTS
 
-Standalone companion command to generate an interactive, self-contained HTML report dashboard on demand from `current-feature.md`, task-specific context `devflow/context/{xxx-slug}/spec.md`, or archived history files in `devflow/history/`.
+Standalone companion command to generate an interactive, self-contained HTML report dashboard on demand from task-specific context `devflow/context/{xxx-slug}/spec.md`, or archived history files in `devflow/history/`.
 
 > [!NOTE]
 > HTML reports are **never automatically generated** during normal mainline stages (`/complete`). Use this command whenever you or stakeholders wish to view or share an interactive web report.
@@ -26,7 +26,7 @@ When invoked:
 
 ### 1. Identify Target Run
 1. Locate target markdown document:
-   - Active Living Spec: `devflow/context/current-feature.md` or `devflow/context/{xxx-slug}/spec.md`
+   - Active Living Spec: `devflow/context/{xxx-slug}/spec.md`
    - Archived History: `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`
 2. Parse spec sections, checklist steps, QA evidence, and verification logs.
 

package/template/.agents/skills/rollback/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rollback
-description: "[devflow] Plan a safe reversal of a completed Blueprint feature using its archived spec and squashed git commit. Finds the exact feature commit, reviews later commits for dependency risk, writes a Type: Rollback spec to devflow/context/current-feature.md, and stops for review before /implement applies any code change. Use when the user runs /rollback, asks to remove or undo a completed feature, or wants to return the app to its pre-feature behavior without erasing Blueprint history."
+description: "[devflow] Plan a safe reversal of a completed Blueprint feature using its archived spec and squashed git commit. Finds the exact feature commit, reviews later commits for dependency risk, writes a Type: Rollback spec to devflow/context/{xxx-slug}/spec.md, and stops for review before /implement applies any code change. Use when the user runs /rollback, asks to remove or undo a completed feature, or wants to return the app to its pre-feature behavior without erasing Blueprint history."
 ---
 
 # rollback - safely reverse a completed feature
@@ -33,14 +33,12 @@ the feature was removed.
 
 ## Step 0 - preflight
 
-Read `AGENTS.md`, `devflow/build-plan.md`,
-`devflow/context/current-feature.md`, the completed feature archives, and git
+Read `AGENTS.md`, `devflow/build-plan.md`, the completed feature archives, and git
 state.
 
 Stop before writing when:
 
 - the directory is not a git repository
-- `current-feature.md` already holds active work
 - the working tree is dirty, including unrelated untracked work
 - the current branch is not the local main or default branch
 - the target is not a checked build-plan feature with a matching archive
@@ -107,8 +105,8 @@ remediation or explicitly plan the dependent rollbacks.
 
 ## Step 4 - write the rollback spec
 
-Write `devflow/context/current-feature.md` using
-`reference/rollback-spec-template.md`. Fill in:
+Allocate sequential ID (`xxx-slug`) and create `devflow/context/{xxx-slug}/`. Write `devflow/context/{xxx-slug}/spec.md` using
+`reference/rollback-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Fill in:
 
 - target feature, archive, exact commit, and parent commit
 - user's reason

package/template/.agents/skills/status/SKILL.md

@@ -34,14 +34,13 @@ state.
 1. **Build plan** - `devflow/build-plan.md`. Count checked vs unchecked leaf
    items. Name the next unchecked leaf, the same target `/feature` would pick,
    and note if a parent item was split into sub-items (`4a`, `4b`, ...).
-2. **Current work** - `devflow/context/current-feature.md`. Is something in
-   progress, or is it the reset stub? If a feature, fix, or rollback spec is
-   present, report its type and name, which build steps are checked, and the
-   first unchecked step where `/implement` resumes.
-3. **Findings** - `devflow/context/findings.md`. Count findings by status and
+2. **Current work & Spec Queue** - scan `devflow/context/{xxx-slug}/`. Is something in
+   progress? If a feature, fix, or rollback spec is
+   present, report its type, name, running ID, which build steps are checked, and the
+   first unchecked step where `/implement` resumes. If multiple tasks are queued, list the active spec queue.
+3. **Findings** - `devflow/context/{xxx-slug}/findings.md`. Count findings by status and
    report open and fixed counts next to build-plan progress. Call out any P0 or
-   P1 still `open` or `fixed` by ID, since those block `/complete`. A missing
-   file means no findings.
+   P1 still `open` or `fixed` by ID, since those block `/complete`.
 4. **Overview freshness** - if `devflow/context/project-overview.md` is missing,
    or if `project-plan.md` or `build-plan.md` appears newer than it by filesystem
    time, mention that `/overview` should run before new feature work.
@@ -49,38 +48,32 @@ state.
    changes, roughly how many files changed, last commit subject, and whether the
    branch is ahead of its remote. If the directory is not a git repo, say so and
    skip this part rather than failing.
-6. **Progress drift** - flag active spec on `main`, a spec in progress but no
-   matching `feature/`, `fix/`, or `rollback/` branch, all spec steps checked but
-   not completed, or disagreement between `build-plan.md` and
-   `current-feature.md`. A rollback legitimately targets a checked build-plan
-   item until `/complete` unchecks it, so do not compare it to the next unchecked
-   feature.
+6. **Progress drift** - flag active task on `main`, a spec in progress but no
+   matching `feature/{xxx-slug}`, `fix/{xxx-slug}`, or `rollback/{xxx-slug}` branch, all spec steps checked but
+   not completed, or disagreement between `build-plan.md` and active specs.
 
 ## Output
 
 A short, scannable summary, not a wall of text. Aim for something like:
 
-    Status: Building feature 4 - PDF export
-    Plans: Overview current. Build plan 3 of 9 complete.
-    Current work: Step 2 of 3 done. Next step: Download PDF button.
-    Findings: 1 open P2 (F-04), 1 fixed P1 awaiting re-review (F-02).
-    Git: branch feature/pdf-export, 3 uncommitted files, last commit "feat: widen export helper".
-    Watch: F-02 is fixed but not re-reviewed; it blocks /complete until /audit closes it.
+    Status: Building feature 061 - Pure Multi-Run Architecture
+    Plans: Overview current. Build plan 13 of 14 complete.
+    Current work: Step 2 of 4 done. Next step: Update Directives & Documentation.
+    Findings: 0 blockers in 061-pure-multi-run-task-isolated-architecture/findings.md.
+    Git: branch feature/061-pure-multi-run-task-isolated-architecture, 3 uncommitted files.
 
-    Next action: run /implement for Step 3.
+    Next action: run /implement 061 for Task 2.
 
 End with a single suggested next action, chosen in this order:
 
 - The overview is missing or stale and no feature is in progress -> `/overview`.
-- A spec is in progress with unchecked steps -> `/implement` and name the step.
-- A spec is in progress and all implementation steps are checked -> `/check` if
+- A spec is in progress with unchecked steps -> `/implement [id]` and name the step.
+- A spec is in progress and all implementation steps are checked -> `/check [id]` if
   proof is not recorded, `/try` if the user wants a manual review path,
-  `/implement` when a P0 or P1 finding is still `open` (the repair is an extra
+  `/implement [id]` when a P0 or P1 finding is still `open` (the repair is an extra
   reviewed step), `/audit` when one is `fixed` and awaiting re-review (both
-  block `/complete`), otherwise `/complete`.
-- `current-feature.md` is the reset stub and a P0 or P1 finding is `open` ->
-  `/fix <finding id>`; when one is `fixed`, `/audit` to re-review and close it.
-- `current-feature.md` is the reset stub and unchecked build-plan items remain ->
+  block `/complete`), otherwise `/complete [id]`.
+- No active tasks in `devflow/context/` and unchecked build-plan items remain ->
   `/feature` and name the next build-plan item.
 - All build-plan items are checked -> say the current milestone is complete;
   suggest hardening, release, or docs when appropriate, or

package/template/.agents/skills/try/SKILL.md

@@ -23,10 +23,10 @@ merge, push, or run destructive commands.
 Optional scope:
 
 - no argument: use the active feature, fix, or rollback in
-  `devflow/context/current-feature.md`
+  `devflow/context/{xxx-slug}/spec.md`
 - `latest`: use the most recent archive under `devflow/history/features/`,
   `devflow/history/fixes/`, or `devflow/history/rollbacks/`
-- a step name or number: focus the guide on that current-feature step
+- a step name or number: focus the guide on that active step
 - a path, route, or command: include it as the main thing to try
 
 If there is no active feature and no useful archive, ask what change the user
@@ -37,16 +37,15 @@ wants to try instead of guessing.
 Read:
 
 - `AGENTS.md`
-- `devflow/context/current-feature.md`
+- `devflow/context/{xxx-slug}/spec.md` (or active task workspace)
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
 - `devflow/build-plan.md`
 - latest files under `devflow/history/features/`,
-  `devflow/history/fixes/`, and `devflow/history/rollbacks/`, if the current
-  feature is reset
+  `devflow/history/fixes/`, and `devflow/history/rollbacks/`, if no task is active
 - git branch and working tree status
 
-Prefer the active spec. If `current-feature.md` is the reset stub, use the most
+Prefer the active task spec. If no active task directory exists, use the most
 recent archived feature, fix, or rollback by filename or modification time and
 say that is what you used.
 

package/template/.claude/skills/audit/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: audit
-description: "[devflow] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/findings.md. Reviews the active feature, changed files, a selected path, or the full project through all concerns or a focused quality, security, performance, or tests lens. Use when the user runs /audit, invokes $audit, asks for a code or quality audit, security review, performance review, test quality review, dead-code or duplication check, vibe-coded project cleanup, or standards review."
+description: "[devflow] Read-only code audit for a Blueprint project, except for the findings ledger it maintains at devflow/context/{xxx-slug}/findings.md. Reviews the active feature, changed files, a selected path, or the full project through all concerns or a focused quality, security, performance, or tests lens. Use when the user runs /audit, invokes $audit, asks for a code or quality audit, security review, performance review, test quality review, dead-code or duplication check, vibe-coded project cleanup, or standards review."
 ---
 
 # audit - review code quality against the project standards
@@ -17,7 +17,7 @@ or one focused lens: quality, security, performance, or tests.
 
 It reviews code without changing it: it never edits source files, installs
 dependencies, commits, merges, pushes, or starts product work. Its one write is
-the findings ledger at `devflow/context/findings.md` (Step 4), the durable
+the findings ledger at `devflow/context/{xxx-slug}/findings.md` (Step 4), the durable
 record of findings and their status.
 
 ## Input
@@ -29,7 +29,7 @@ Optional scope:
 
 - no scope argument: use `current` when an active feature exists, otherwise use
   `changed` when local changes exist, otherwise use `full`
-- `current`: audit the active `current-feature.md`, every committed feature-branch
+- `current`: audit the active `devflow/context/{xxx-slug}/spec.md`, every committed feature-branch
   change from its merge base through `HEAD`, staged and unstaged changes,
   untracked source files, and nearby code affected by the feature
 - `changed`: audit staged, unstaged, and untracked source files plus nearby code
@@ -65,8 +65,8 @@ Read:
 - `AGENTS.md`
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
-- `devflow/context/current-feature.md`
-- `devflow/context/findings.md`, for existing IDs and statuses
+- `devflow/context/{xxx-slug}/spec.md` (when a task is active)
+- `devflow/context/{xxx-slug}/findings.md` (or existing ledger), for existing IDs and statuses
 - `devflow/context/ai-interaction.md`
 - `devflow/build-plan.md`, when feature order matters
 - git branch and working tree status
@@ -145,9 +145,9 @@ audit evidence before responding.
 
 ## Step 4 - update the findings ledger
 
-`devflow/context/findings.md` is the durable record of findings. Chat reports
+`devflow/context/{xxx-slug}/findings.md` is the durable record of findings for the active task. Chat reports
 do not survive a context clear; the ledger does. It is the only file this skill
-writes. If it is missing (an older install), create it with a `# Findings`
+writes. If it is missing, create it with a `# Findings`
 heading first.
 
 **The ledger never scopes the review.** Review the code fresh in Step 3, then

package/template/.claude/skills/autopilot/SKILL.md

@@ -38,11 +38,11 @@ Common forms:
 - `resume`: continue the current feature on its existing branch.
 
 If the requested target conflicts with a feature already in progress, stop and
-ask which one should win. Do not overwrite `devflow/context/current-feature.md`
+ask which one should win. Do not overwrite task workspaces
 silently.
 
 Rollback is intentionally excluded from Autopilot. If the request is a rollback
-or `current-feature.md` is marked `Type: Rollback`, stop and direct the user to
+or active spec is marked `Type: Rollback`, stop and direct the user to
 the reviewed `/implement` path. Reversing completed work requires the explicit
 dependency and conflict gates in `/rollback` and `/implement`.
 
@@ -54,8 +54,8 @@ Read the same state `/status` reads:
 - `devflow/project-plan.md`
 - `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/current-feature.md`
-- `devflow/context/findings.md`
+- `devflow/context/{xxx-slug}/spec.md` (when present)
+- `devflow/context/{xxx-slug}/findings.md` (when present)
 - `devflow/context/coding-standards.md`
 - `devflow/context/ai-interaction.md`
 - git branch, status, and recent log
@@ -67,7 +67,7 @@ Stop before changing files when:
 - The repo is not a git repo.
 - The working tree is dirty and there is no current feature tying those changes
   to this run.
-- `current-feature.md` has real work and the user requested a different target.
+- Active task spec has real work and the user requested a different target.
 - `project-overview.md` is missing or stale and the planning docs are not clear
   enough to regenerate it.
 - The next feature is visual or replication-heavy and no design reference exists.
@@ -80,14 +80,14 @@ final packet.
 
 ## Step 2 - choose or write the spec
 
-If `devflow/context/current-feature.md` already contains an active spec,
+If `devflow/context/{xxx-slug}/spec.md` already contains an active spec,
 resume it. Read checked steps and continue from the first unchecked step.
 
 If there is no active spec:
 
 1. Use the `/feature` behavior for a planned feature, or `/fix` behavior for a
    requested fix.
-2. Write `devflow/context/current-feature.md`.
+2. Create workspace and write `devflow/context/{xxx-slug}/spec.md`.
 3. Red-team the spec before building:
    - missing unhappy paths
    - oversized steps
@@ -101,32 +101,22 @@ If there is no active spec:
 Autopilot may continue past this spec gate because the user explicitly invoked
 Autopilot. Still report what the critique changed in the final packet.
 
-## Step 3 - create or reuse the branch
+## Step 3 - branch
 
-Use the same branch rules as `/implement`:
+Create or check out the branch for the work:
 
-- Feature: `feature/<name>`
-- Fix: `fix/<name>`
+- `feature/{xxx-slug}` for a planned feature
+- `fix/{xxx-slug}` for an ad-hoc fix
 
-If the branch already exists, switch to it only if it matches the active spec.
-If switching branches would strand unrelated dirty work, stop and report the
-problem.
+If the branch already exists, check it out and verify it matches the spec.
 
-## Step 4 - implement in small steps
+## Step 4 - build in small steps with review gates
 
-Work through the spec's build steps in order. Each step must remain reviewable.
-Unlike `/implement`, do not pause for user approval after each passing step. The
-review happens at the final packet unless a hard stop is hit.
+Work through the spec's steps in order:
 
-For every step:
-
-1. Implement only that step.
-2. Run the relevant verification:
-   - the exact `Verify` command from `AGENTS.md`, when declared
-   - otherwise the build, relevant test, lint, and typecheck commands already
-     documented by the project
-   - browser, CLI, API, or app-level evidence for behavioral done-whens
-3. If UI is involved, inspect the running app when possible. Prefer Playwright if
+1. Keep each change small and focused on the current step.
+2. Run the declared `test` command when logic changed.
+3. If the step has visual or browser-visible behavior, drive the browser when
    it is already installed or declared. Capture screenshots when they add useful
    evidence. Check for console errors and failed requests.
 4. Self-review the diff for the step:
@@ -136,15 +126,15 @@ For every step:
    - did it follow `coding-standards.md`?
    - are tests present for new in-scope logic when the test gate is on?
 5. Fix obvious issues and rerun the failed checks.
-6. Mark the step checked in `current-feature.md` only after the step passes.
+6. Mark the step checked in `devflow/context/{xxx-slug}/spec.md` only after the step passes.
 7. Create a checkpoint commit on the feature or fix branch for the passing step.
-   Include the code, tests, and the updated `current-feature.md` checkbox. Use a
+   Include the code, tests, and the updated `spec.md` checkbox. Use a
    conventional message such as `feat: checkpoint mock snapshot route` or
    `fix: checkpoint stale service filter`. Keep the message about the step, not
    about Autopilot.
 
 Do not batch the whole feature into one large diff. If a step gets too large,
-split the step in `current-feature.md` and continue with the first smaller step.
+split the step in `devflow/context/{xxx-slug}/spec.md` and continue with the first smaller step.
 
 ## Step 5 - acceptance check
 
@@ -159,7 +149,7 @@ may be enough. Be explicit about the evidence used.
 After the acceptance check, apply the `/audit current` behavior to the active
 feature, its diff, and the nearby code affected by the change. This is a targeted
 feature audit, not a repository-wide cleanup pass. Findings are recorded in
-`devflow/context/findings.md` with durable IDs and statuses, as `/audit`
+`devflow/context/{xxx-slug}/findings.md` with durable IDs and statuses, as `/audit`
 defines; the ledger reports status and never scopes what the audit examines.
 
 For every finding:
@@ -173,35 +163,21 @@ For every finding:
 3. Report P2 and P3 findings in the final packet. Fix them only when the change
    is small, directly caused by the current feature, and clearly required by the
    project standards.
-4. If a confirmed P0 or P1 finding cannot be repaired safely within scope, stop
-   and report it. Do not present the feature as ready for `/complete`.
-
-After any audit repair:
-
-1. Rerun the documented `Verify` command when present; otherwise rerun the
-   affected build, lint, typecheck, and test commands.
-2. Rerun the acceptance evidence affected by the repair.
-3. Recheck the repaired area using the same targeted audit criteria. When that
-   recheck confirms the original defect is gone and the repair introduced no
-   new one, move the `fixed` finding to `closed` under the `/audit` close
-   conditions and name it in the packet. An unrelated new finding gets its own
-   ledger entry and does not keep the repaired one open.
-4. Create a checkpoint commit only after the repair and its checks pass.
+4. If a finding cannot be resolved safely in-scope, leave it `open` and describe
+   it in the final packet. A finding that is wrong goes back to `/audit` to
+   invalidate with recorded evidence; Autopilot never marks findings `invalid`
+   or `accepted`.
 
-Use the existing two-attempt hard stop for repeated repair failures. Do not widen
-the feature into a general refactor, silently suppress a finding, or turn this
-step into a full-project hardening pass. A broader cleanup remains a separate
-`/audit` followed by planned `/fix` work.
+Re-run the build, tests, and any affected checks after repairs. If a repair fails
+twice, stop and report the blocker.
 
-## Step 7 - final review packet
+## Step 7 - compile the review packet
 
-Stop with a concise review packet. Keep it useful enough for `/complete` but not
-a full audit report:
+Stop and produce a concise review packet:
 
-- branch name
 - target feature or fix
-- whether the spec was created or resumed
-- what the spec critique changed
+- branch name
+- what was built
 - changed files and why each changed
 - build/test/check commands run, with pass or fail
 - screenshots or output paths, when relevant
@@ -210,7 +186,7 @@ a full audit report:
 - self-review findings
 - targeted audit scope and findings
 - audit repairs made and checks rerun
-- P0/P1 findings still `open` or `fixed` in `devflow/context/findings.md`,
+- P0/P1 findings still `open` or `fixed` in `devflow/context/{xxx-slug}/findings.md`,
   which block `/complete`
 - unresolved risks or skipped checks
 - exact next action
@@ -240,11 +216,11 @@ Stop immediately and report instead of continuing when Autopilot would need to:
 - Autopilot creates checkpoint commits on the feature or fix branch after passing
   steps.
 - Autopilot audits the active feature and affected code, not the entire project.
-- A P0 or P1 finding left `open` or `fixed` in `devflow/context/findings.md`
+- A P0 or P1 finding left `open` or `fixed` in `devflow/context/{xxx-slug}/findings.md`
   blocks readiness for `/complete`. The ledger is what makes this enforceable.
 - Autopilot stops before `/complete`. It never merges.
 - The Blueprint files remain the state machine. Keep
-  `current-feature.md` accurate as steps complete.
+  `devflow/context/{xxx-slug}/spec.md` accurate as steps complete.
 - Follow `coding-standards.md`, `ai-interaction.md`, and `AGENTS.md`.
 - Prefer fewer, higher-quality changes over broad coverage.
 - Report uncertainty plainly. A blocked run is useful if it tells the truth.

package/template/.claude/skills/brief/SKILL.md

@@ -82,7 +82,7 @@ plans aren't ready, `/prototype` if it's UI-facing and the look isn't locked, or
 ## Rules
 
 - **Read-only, always.** Never write a file, never edit `build-plan.md` or
-  `current-feature.md`, never branch, commit, install, or build. To act on the
+  specs in `devflow/context/`, never branch, commit, install, or build. To act on the
   briefing, the user runs `/feature` next.
 - **Explain, don't spec.** Size, dependencies, and a likely sub-split are the
   value here; the actual build steps are `/feature`'s job. Don't write step lists.

package/template/.claude/skills/check/SKILL.md

@@ -28,7 +28,7 @@ It changes no source and commits nothing — it executes, inspects, and reports
 
 ## Step 1 - Build the Dual-Axis Review Matrix
 
-Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`) and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
+Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
 
 1. **Axis 1 (Standards & Architecture Criteria)**:
    - Coding conventions in `coding-standards.md`
@@ -36,7 +36,7 @@ Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/cont
    - Baseline 12 Fowler Code Smells (Primitive obsession, Feature envy, Shotgun surgery, Speculative generality, etc.)
    - Multi-lane technical gates (Typecheck, test suites, zero secrets, zero P0/P1 findings)
 2. **Axis 2 (Spec Fidelity & Behavioral Observables)**:
-   - Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `current-feature.md`
+   - Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `devflow/context/{xxx-slug}/spec.md`
    - Scope Creep detection (Unrequested behavior in the diff)
    - Missing Requirements detection (Unimplemented edge cases)
 
@@ -69,7 +69,7 @@ Format the report into two distinct, un-merged review axes:
   - [pass] Type Safety: `tsc --noEmit` (0 errors)
   - [pass] Automated Tests: `npm test` (All tests green)
   - [pass] Security & Hygiene: Zero secrets, sanitized inputs
-  - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/findings.md`
+  - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/{xxx-slug}/findings.md`
 - **Deep Modules & Architecture**:
   - [pass] Seam Integrity: Public interfaces remain small, implementation details hidden.
   - [pass] The Deletion Test: Complexity is concentrated inside the module, not scattered across callers.
@@ -78,7 +78,7 @@ Format the report into two distinct, un-merged review axes:
 
 ## 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
 
-Line-by-line verification against `current-feature.md`:
+Line-by-line verification against `devflow/context/{xxx-slug}/spec.md`:
 - [pass] **AC-1 (<title>)**: <Observed empirical evidence / screenshot path>
 - [pass] **AC-2 (<title>)**: <Observed empirical evidence / terminal output>
 - [fail] **AC-3 (<title>)**: <Exact observed failure with reproduction command>