@jakkrichm/create-nexus-devflow 2.6.2 → 2.8.0

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>

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

@@ -24,7 +24,7 @@ passes.
 
 ## Before you start
 
-Confirm the target work is actually finished: `devflow/context/{xxx-slug}/spec.md` (or `current-feature.md`)
+Confirm the target work is actually finished: `devflow/context/{xxx-slug}/spec.md`
 holds a real spec, its steps are built on a branch, and `Verify`, or the fallback
 build and tests, passes. If any of the
 spec's done-whens are behavioral, `/check` should have proven them against the
@@ -36,9 +36,8 @@ the steps to be pre-committed.
 
 Before logging or committing, run a short safety pass and report blockers only:
 
-- active spec exists and the work is not being completed directly from `main` or `master`
-- changed files are tied to the active spec, with no unrelated dirty work mixed
-  in (a dirty `devflow/context/findings.md` is expected, since `/audit` writes it)
+- active spec exists in `devflow/context/{xxx-slug}/spec.md` and the work is not being completed directly from `main` or `master`
+- changed files are tied to the active spec, with no unrelated dirty work mixed in
 - the exact `Verify` command from `AGENTS.md` passed in this session, when one is
   declared; otherwise the build passed, and tests passed when the project has a
   declared test command and the change touched logic
@@ -46,7 +45,7 @@ Before logging or committing, run a short safety pass and report blockers only:
   a clear manual try path
 - if workflow files changed, `.agents` and `.claude` stayed in sync where both
   adapters exist
-- no P0 or P1 finding in `devflow/context/findings.md` is `open` or `fixed`.
+- no P0 or P1 finding in `devflow/context/{xxx-slug}/findings.md` is `open` or `fixed`.
   `fixed` still blocks on purpose: the repair exists but no review has looked at
   it - run `/audit` to close it. The only waivers are `accepted` (the user's
   explicit decision in the current chat, reason recorded; never set it for
@@ -64,48 +63,16 @@ Check whether the spec is a feature, fix, or rollback. A fix is marked
 `Type: Fix` and has no build-plan number. A rollback is marked `Type: Rollback`
 and records the exact target feature, archive, commit, and parent.
 
-- **Feature** - archive `devflow/context/current-feature.md` to `devflow/history/features/NN-name.md`
-  (NN is the build-plan number), and check it off in `devflow/build-plan.md`
-  (and its parent item once all sub-items are checked).
-- **Fix** - archive it to `devflow/history/fixes/name.md`. A fix isn't a build-plan item, so
-  there's nothing to check off.
-- **Rollback** - archive it to
-  `devflow/history/rollbacks/YYYY-MM-DD-NN-name.md`, preserving the original
-  completed feature archive. Create `devflow/history/rollbacks/` first if an
-  older Blueprint installation does not have it yet. Uncheck the exact target item in
-  `devflow/build-plan.md` and its parent when applicable, then append a concise
-  note to the target line with the rollback date and archive path. Keep the
-  feature number stable. If the user later decides the feature is permanently
-  abandoned rather than pending rebuild, that roadmap decision is a separate
-  plan edit.
-
-**Archive resolved findings.** If `devflow/context/findings.md` holds any
+- **Feature** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/features/{xxx-slug}.md`, check it off in `devflow/build-plan.md` (and its parent item once all sub-items are checked), and record an entry into `devflow/history/HISTORY.md`.
+- **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
+- **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
+
+**Archive resolved findings.** If `devflow/context/{xxx-slug}/findings.md` holds any
 findings, append a `## Findings` section to the archive file just written with
 every `closed`, `accepted`, or `invalid` entry at its final status (`accepted`
-entries keep their recorded reason). Prefix each ID with the archive name for
-global uniqueness: feature 12's `F-03` becomes `12/F-03`; fixes and rollbacks
-use their archive filename as the prefix. An entry carried forward from earlier
-work archives with the item that resolved it; its **Found** line preserves
-where it came from. Then remove the archived entries from the ledger. Unresolved entries (`open` or `fixed` P2/P3, and `unverified`
-leads) stay in the ledger with their IDs so they are never silently dropped.
-When nothing remains, reset the ledger to exactly this stub, and create it the
-same way if the file is missing (an older install):
-
-    # Findings
-
-    > **Generated file.** The findings ledger: review findings raised by `/audit`
-    > against the work in progress, each with a durable ID, severity (P0-P3), and
-    > status. `/implement` marks repaired findings `fixed`, a later `/audit` pass
-    > moves them to `closed`, and `/complete` refuses to merge while any P0 or P1
-    > finding is `open` or `fixed`, then archives resolved findings with the work
-    > and resets this file.
-
-    _No findings recorded. `/audit` appends findings here when it finds them._
-
-Then reset `devflow/context/current-feature.md` to its current stub ("nothing
-in progress"), including `/rollback` alongside `/feature` and `/fix`. Don't
-commit yet; the next step makes one work commit covering the code and these doc
-changes. The archive is the build history.
+entries keep their recorded reason).
+
+**Clean up run workspace.** Delete the task directory `devflow/context/{xxx-slug}/`. In Pure Multi-Run architecture, completed work leaves zero residual stubs in `devflow/context/`.
 
 **Discard consumed prototypes.** If this feature built the look from `prototypes/`
 - its Design reference pointed there and an early step ported `prototypes/theme.css`
@@ -159,7 +126,7 @@ Finish with a concise **How to try it** note for the completed work. For a
 rollback, explain how to confirm the removed behavior is gone and name one
 unaffected regression path. If the
 manual path is more than a couple of steps, tell the user to run `/try latest`;
-that command can read the archived feature after `current-feature.md` is reset.
+that command can read the archived feature from history.
 
 ## Rules
 

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

@@ -0,0 +1,117 @@
+---
+name: continuous
+description: "[devflow] Autonomous multi-feature delivery loop in Nexus-DevFlow: completes planned features serially from devflow/build-plan.md without review pauses. Maintains safety boundaries, Task-Isolated Living Spec, branch isolation, TDD verification, quality gates, and local squash-merges into main. Use when running /continuous, $continuous, or executing Continuous Mode."
+argument-hint: "[{resume, max-features, or start-feature}]"
+---
+
+# continuous - Complete the Build Plan One Local Feature at a Time
+
+Where this sits in the workflow:
+
+```text
+/status  ──▶  [continuous]  ──▶  Final Review Packet
+(ready)       (Serial Loop:      (Local main only,
+               Spec ➔ TDD ➔       never pushed)
+               Gates ➔ Merge)
+```
+
+`/continuous` (หรือ `$continuous`) คือโหมดการทำงานแบบ Autonomous Multi-Feature Delivery Loop สำหรับจัดส่งฟีเจอร์ที่อยู่ใน `devflow/build-plan.md` ต่อเนื่องทีละฟีเจอร์ในเครื่อง Local โดยไม่ต้องหยุดรอ Manual Review Prompts ในแต่ละขั้นตอนย่อย แต่ยังคงรักษาความเข้มงวดของ **The 3-Pillars Model & Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)**, การทำ TDD, การตรวจ Quality Gates, การบันทึก Findings Ledger, และการ Squash-merge ลง Local Main Commit ทีละฟีเจอร์อย่างปลอดภัย 100%
+
+### ขอบเขตสิทธิ์ที่ได้รับอนุญาตเฉพาะในเครื่อง Local:
+- สร้างและสลับ Feature Branch ในเครื่อง Local
+- บันทึก Checkpoint Commits ย่อยบน Branch
+- บันทึก Feature Commit สุดท้าย
+- Squash-merge ฟีเจอร์ที่เสร็จสมบูรณ์ลง Default Branch ของ Local
+- ลบ Feature Branch เฉพาะใน Local หลังรวมโค้ดสำเร็จ
+- วนลูปเริ่มทำฟีเจอร์ที่ยังไม่ได้เช็ค (`- [ ]`) รายการถัดไปใน `build-plan.md`
+
+### ข้อจำกัดความปลอดภัยเด็ดขาด (Strict Safety Boundaries):
+- **ห้าม** Push ขึ้น Remote Repository
+- **ห้าม** Deploy หรือเผยแพร่ (Publish) สู่ภายนอก
+- **ห้าม** ลบข้อมูลจริง, ทำลาย Database, หรือรัน Destructive Migration
+- **ห้าม** กด Accept Finding หรือเพิกเฉยต่อ Failing Quality Gate แทนมนุษย์
+
+---
+
+## Input & Target Selection
+
+- **ไม่ระบุ Argument (`/continuous`)**:
+  1. หากมีฟีเจอร์ค้างอยู่ใน `devflow/context/{xxx-slug}/` ให้ทำต่อจากขั้นตอนย่อยแรกที่ยังไม่ได้เช็ค (`- [ ]`)
+  2. หากไม่มี ให้เลือกฟีเจอร์แรกที่ยังไม่ได้เช็ค (`- [ ]`) ใน `devflow/build-plan.md`
+  3. วนลูปทำต่อเนื่องตามลำดับใน `build-plan.md` จนกว่าจะหมด หรือครบตามจำนวน `continuous.maxFeatures` ใน `devflow/config.json`
+- **ระบุ `resume` (`/continuous resume`)**: ทำงานต่อจากฟีเจอร์และขั้นตอนย่อยที่ค้างอยู่ทันที
+- **ระบุชื่อหรือหมายเลขฟีเจอร์ (`/continuous 13`)**: เริ่มต้นจากฟีเจอร์ที่ระบุ แล้ววนลูปต่อไปยังฟีเจอร์ถัดไป
+
+---
+
+## Step 1: Preflight Safety Check (ตรวจสอบความพร้อมก่อนเริ่ม)
+
+อ่านบริบทตั้งต้น:
+- `AGENTS.md`
+- `devflow/config.json` (หากไม่มี ให้ใช้ค่า Defaults อย่างปลอดภัย; หาก Invalid ให้หยุดและชี้ไปที่ `/doctor`)
+- `devflow/project-plan.md` และ `devflow/build-plan.md`
+- `devflow/context/project-overview.md`
+- `devflow/context/{xxx-slug}/` (ถ้ามีงานค้างอยู่)
+- `devflow/context/coding-standards.md` และ `devflow/context/ai-interaction.md`
+- สถานะ Git (`git status`, `git branch`, recent log)
+
+### กฎการเริ่มงาน (Start Conditions):
+1. สถานะ Git Working Tree สะอาด (Clean) บน Default Branch หรือมีเฉพาะ Diff ของฟีเจอร์ปัจจุบัน
+2. `devflow/build-plan.md` มีฟีเจอร์ที่ยังไม่ได้ทำเหลืออยู่
+3. ไม่มี Finding ระดับ P0 หรือ P1 ค้างในสถานะ `open` หรือ `fixed`
+4. บันทึก Commit SHA ตั้งต้นของ Default Branch ไว้สำหรับสรุปผลในรายงานสุดท้าย
+
+---
+
+## Step 2: Serial Feature Lifecycle (วงจรการส่งมอบทีละฟีเจอร์)
+
+ดำเนินงานวนลูปทีละ 1 ฟีเจอร์ตามลำดับ:
+
+### 2.1 Select & Spec (เลือกและร่างสเปก)
+- หาก Resuming: ใช้ Spec เดิมใน `devflow/context/{xxx-slug}/spec.md`
+- หากเป็นฟีเจอร์ใหม่: ถอดความต้องการจาก `build-plan.md` และสร้าง Task Workspace ที่ `devflow/context/{xxx-slug}/` พร้อมเขียน `spec.md`, `stage.md`, `findings.md` และวิเคราะห์ Red-team ก่อนเริ่มโค้ด
+
+### 2.2 Create / Resume Feature Branch
+- สร้าง Branch ตาม Prefix ใน Config (เช่น `feature/061-slug`) จาก Default Branch
+
+### 2.3 Implement Small Steps with Strict TDD
+- ดำเนินการสร้างฟังก์ชันทีละ Task ตาม Checklist ใน Spec:
+  1. `[TDD-Red]`: เขียน Unit Test ก่อน
+  2. `[TDD-Green]`: เขียนโค้ดขั้นต่ำให้ Test ผ่าน
+  3. `[TDD-Refactor]`: ปรับแต่งโค้ดให้สะอาดและรัน Verification ผ่าน
+  4. ทำเครื่องหมาย `- [x]` ใน Spec และบันทึก Checkpoint Commit บน Branch (หาก `workflow.checkpointCommits: "enabled"`)
+
+### 2.4 Apply Continuous Quality Gates
+ตรวจสอบตามการตั้งค่า `qualityGates.continuous` ใน `devflow/config.json`:
+- **Audit**: `manual` (ข้ามอัตโนมัติ), `when-sensitive` (รันเมื่อแตะ Auth/Security/Database/Secrets), `always` (รันทุกฟีเจอร์)
+- **Check**: `manual` (ข้ามอัตโนมัติ), `when-behavioral` (รันเมื่อมี Runtime Behavior เช่น UI/CLI/API), `always` (รันทุกฟีเจอร์)
+- **Try Guide**: `manual` (ข้ามอัตโนมัติ), `when-user-facing` (สร้าง Try Guide เมื่อเป็น UI/CLI), `always` (สร้างทุกฟีเจอร์)
+
+### 2.5 Repair Findings
+- ซ่อมแซม Finding ระดับ P0/P1 ที่เกิดขึ้นจากฟีเจอร์นี้โดยอัตโนมัติ (ไม่เกิน `continuous.maxRepairAttempts` ครั้ง)
+- หากไม่สามารถซ่อมแซมได้ หรือมี P0/P1 ค้างอยู่ ให้หยุดการทำงานทันที
+
+### 2.6 Complete Locally Like a Human
+- รัน Verification ขั้นสุดท้าย
+- ย้ายและ Archive เอกสารไปที่ `devflow/history/features/{xxx-slug}.md`
+- อัปเดตเช็คบ็อกซ์ใน `devflow/build-plan.md`
+- ลบโฟลเดอร์รัน `devflow/context/{xxx-slug}/`
+- Squash-merge Feature Branch เข้าสู่ Local Main และลบ Feature Branch ใน Local
+- นับจำนวนฟีเจอร์ที่สำเร็จเพิ่มขึ้น 1
+
+---
+
+## Step 3: Optional Final Integration Audit
+
+เมื่อครบกำหนดจำนวนฟีเจอร์หรือหมด `build-plan.md` หาก `continuous.finalIntegrationAudit: true` ให้รันการตรวจสอบความเข้ากันได้แบบบูรณาการ (Cross-Feature Contracts & Seams) จากจุดเริ่มต้นถึง HEAD ปัจจุบัน
+
+---
+
+## Step 4: Stop & Report (สรุปรายงานผลลัพธ์)
+
+เมื่อการทำงานสิ้นสุด (ไม่ว่าจะสำเร็จครบถ้วน หรือหยุดเนื่องจากติดเงื่อนไขความปลอดภัย) ให้รายงานสรุปเป็นภาษาไทย:
+- Commit เริ่มต้น และ Commit สุดท้ายของ Default Branch
+- รายชื่อฟีเจอร์ที่จัดส่งสำเร็จในรอบนี้ พร้อม Commit Hash
+- ผลการรัน Quality Gates และการซ่อมแซม Findings (ถ้ามี)
+- ความคืบหน้าภาพรวมของ `build-plan.md` และฟีเจอร์ถัดไป
+- ย้ำเตือนชัดเจนว่า **ไม่มีการ Push ใดๆ ขึ้น Remote Repository**