@jakkrichm/create-nexus-devflow 2.17.3 → 2.17.4

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jakkrichm/create-nexus-devflow",
-  "version": "2.17.3",
+  "version": "2.17.4",
   "description": "Installer and workflow manager for Nexus-DevFlow agentic workflow layer.",
   "license": "MIT",
   "author": "Jakkrich",

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

@@ -1,6 +1,6 @@
 ---
 name: bughunter
-description: "[devflow] Offensive security orchestrator & bug hunting guide. Indexes 83 vulnerability classes, 5-phase methodology (Think, Hunt, Perimeter, Ship), 681 disclosed HackerOne patterns, and JIT reference guides in devflow/.vendor/bughunter/. Use when running /bughunter, performing security reviews, verifying auth/injection risks in /check or /audit, or testing API endpoints for vulnerabilities."
+description: "[devflow] Investigate security vulnerabilities with evidence. Use for /bughunter or an authorized security review of code or endpoints."
 argument-hint: "[{target, vuln-class, or topic}]"
 ---
 

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

@@ -36,7 +36,8 @@ When invoked without an argument (or when determining the next step), inspect:
 
 ### Default State Recommendations
 - If no run is active and user wants to start a feature -> Recommend `/feature <name>`.
-- If no run is active and user wants to fix a bug -> Recommend `/fix <bug>`.
+- If the user requests a bugfix plan -> Recommend `/fix <bug>`.
+- If the user requests a completed fix -> preserve the implementation and verification scope; draft the required spec internally and continue to `/implement` using existing authorization.
 - If no run is active and user has pending ideas in `devflow/ideas.md` -> Highlight `/feature IDEA-xxx` or `/discovery IDEA-xxx`.
 - If no run is active and user wants deep architectural exploration -> Recommend `/discovery`.
 - If user asks to check system health -> Recommend `doctor`.
@@ -48,7 +49,7 @@ When invoked without an argument (or when determining the next step), inspect:
 | User Intent / Request Type | Recommended Skill | Normal Name / Alias | Lifecycle Path |
 | :--- | :--- | :--- | :--- |
 | **"Spec new feature / living spec"** | `feature` | `/feature` / `/spec` | **Unified**: `/feature` -> `/implement` -> `/check` -> `/complete` |
-| **"Quick bugfix / ad-hoc change"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
+| **"Draft a bugfix / small-change plan"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
 | **"Capture quick idea / thought"** | `idea` | `/idea` | **Companion**: Enriches & saves to `devflow/ideas.md` |
 | **"Pre-delivery exploration / research"**| `discovery`| `/discovery` | **Pre-Flight**: `discovery` -> `/feature` |
 | **"Socratic alignment / ADR / glossary"**| `grill` | `/grill` / `/align` | **Pre-Flight**: `grill` -> `/feature` |

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

@@ -1,6 +1,6 @@
 ---
 name: fix
-description: "[devflow] Write a task-isolated spec (devflow/context/{xxx-slug}/spec.md) for an ad-hoc bug fix or small unplanned change, then stop before implementation. Use for /fix, confirmed bugs, or small changes outside the build plan."
+description: "[devflow] Draft a task-isolated spec for a bug or small change. Use when invoking /fix or requesting a fix plan."
 argument-hint: "[{title or issue-description}]"
 ---
 
@@ -23,7 +23,7 @@ it creates a dedicated run folder at `devflow/context/{xxx-slug}/` (e.g. `059-fi
 ## Input
 
 A description of the bug or change, for example `/fix "password reset email never
-sends"`. If the user just reported the problem in chat, use that.
+sends"`. Use the reported problem as input when the user asks for a fix plan. A request to diagnose a problem belongs to `/debug`; a request to fix and verify it retains its full delivery scope.
 
 The input may also be a finding ID from `devflow/context/{xxx-slug}/findings.md` (or previous findings), alone
 or with a description, for example `/fix F-03`.
@@ -46,7 +46,7 @@ then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize
   big to read. Each ends with an observable "done when".
 - **Verify** - how to confirm it's fixed (what to click or test).
 
-Then stop. Tell the user to review the fix spec, then run `/implement` to build it.
+For an explicit `/fix` or a planning-only request, present the spec as the completed deliverable and identify `/implement` as the next command. For an existing request to implement and verify the fix, preserve that authorization: use this spec as the internal handoff and continue through `/implement` without an extra approval pause. Ask only for unresolved material scope, design, or permission decisions.
 
 ## Rules
 

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

@@ -1,10 +1,10 @@
 ---
 name: implement
-description: "[devflow] Implement or start coding the active task-isolated spec on its branch in small steps, running tests after each step and presenting the configured review handoff. Use for /implement or requests to build or resume an approved spec."
+description: "[devflow] Build and verify a task-isolated spec. Use for /implement or requests to implement an approved plan."
 argument-hint: "[{run-id, number, or name}] [--ticket <NN | path>]"
 ---
 
-# implement - build the target spec, one reviewed step at a time
+# implement - build and verify the target spec
 
 **Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
 
@@ -20,17 +20,23 @@ Where this sits in the workflow:
 
 `/feature`, `/fix`, or `/rollback` wrote the spec to
 `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
-behind your approval. It builds on a branch and offers an optional commit
-checkpoint after each step; the work-level commit, merging, and logging are
-`/complete`'s job.
+Build the selected spec through its acceptance criteria and required verification, then present the configured review handoff. Preserve authorization already given for this work. Read only relevant conventions and reuse loaded context.
+
+## Review cadence and checkpoints
+
+Read `workflow.stepReview` and `workflow.checkpointCommits` from `devflow/config.json` independently; defaults are `feature` and `disabled`.
+
+- `stepReview: "feature"`: continue through all authorized steps without asking Continue after each step. Record evidence as work proceeds and present one final review packet.
+- `stepReview: "every"`: after a working step, show its diff and evidence, then wait for approval before the next step. A walkthrough is available on request.
+- `checkpointCommits: "disabled"`: omit ordinary checkpoint offers.
+- `checkpointCommits: "enabled"`: offer an optional checkpoint at the configured review boundary (per-step for `every`, final packet for `feature`). Show the exact candidate and obtain commit authorization before committing. The setting itself is not authorization.
+
+Independent-review checkpoints follow their separate contract below. Review cadence never authorizes commit, merge, push, or deployment.
 
 ## Multi-Run Target & Ticket-Driven 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 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.
+- **Given an ID or name** (e.g. `/implement 12`, `/implement 012`, `/implement kanban`) -> locates the matching run folder `devflow/context/{xxx-slug}/`, selects the branch matching the run type and configured prefix, and loads only that run's `spec.md`.
+- **With no argument** (`/implement`) -> checks the current feature, fix, or rollback branch against the configured prefixes, or auto-picks if only 1 spec is active in `devflow/context/`, or prompts the user if multiple specs are queued.
 - **Ticket Input (`--ticket <NN | path>`)**: Targets a specific tracer-bullet ticket directly (e.g. `/implement 12 --ticket 01`, `/implement --ticket 02`, `/implement --ticket issues/01-auth.md`, or `/implement 01` when run-id is not ambiguous).
 
 ### Ticket Discovery Hierarchy
@@ -80,11 +86,7 @@ receipt. After the final Verify pass, an active gate routes to
 `current` freshness may proceed toward `/complete`. This skill never approves
 its own work or rewrites receipt evidence.
 
-For a browser-facing step, run `npm run test:browser` when the script exists and
-record the result in the step evidence. Use `browseros-neo` for the interactive
-handoff when it is available and the done-when is visual or behavioral. When the
-script or MCP is absent, report that exact limitation; do not silently install a
-runner or claim browser evidence.
+For browser-facing changes, run focused browser tests during iteration when available. Run the required `npm run test:browser` gate once before handoff if the spec or project requires it. Use `browseros-neo` for visual or behavioral evidence when available and relevant. Record missing tooling accurately; install a runner only when setup is in the authorized scope.
 
 **Resuming?** If the spec already has some build steps checked off (`- [x]`), this
 feature was started earlier and interrupted (often a cleared context). The spec and
@@ -95,8 +97,7 @@ starting over.
 
 ## Step 1 - branch
 
-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
+Create or select the branch for the spec using `git.featureBranchPrefix`, `git.fixBranchPrefix`, or `git.rollbackBranchPrefix` from config (defaults: `feature/`, `fix/`, `rollback/`). Preserve unrelated working-tree changes before switching. 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.
@@ -105,99 +106,20 @@ instead of creating a new one.
 
 When implementing a rollback task, follow the exact safety procedure in `reference/rollback-implementation.md`.
 
-## Step 2 - build one step, review, iterate, checkpoint (Strict TDD)
-
-Work through the spec's build steps in order, one at a time. For each step:
-
-1. **Strict TDD Cycle (for logic & behavior changes)**:
-   - **🔴 RED**: Write the unit test first in the relevant test file. Execute the test command and show the failing assertion output.
-   - **🟢 GREEN**: Implement only the minimal code in the source file necessary to make the test pass. Re-run test and show passing output.
-   - **🔵 REFACTOR**: Refactor and format cleanly, verifying that 100% of tests remain green.
-   - *Code Reversion Rule*: If production code is written without a prior test for behavior changes, revert it and write the test first.
-
-   **⚖️ The Iron Law**: `NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST` — Apply to behavior changes according to the spec's test decision. If code came first, revert only your own work for that step and restart from the test, preserving the user's existing work.
-
-   **Red-Phase Verification (confirm all three before GREEN):**
-   - The test actually fails, rather than encountering a syntax error
-   - The error message identifies missing behavior, rather than invalid configuration
-   - The failure reflects the behavior under test, rather than a bug in the test itself
-
-   **Green-Phase Discipline**: Write the minimum code needed to pass the test; add only the options/features it requires (YAGNI constraint).
-
-   > 📖 For anti-patterns and Bad vs Good examples, read [`tdd-anti-patterns.md`](tdd-anti-patterns.md).
-
-2. Implement just that step: the smallest change that satisfies its "done when."
-3. Show the **diff**, not whole files.
-4. **Explain it, and prove it.** Give a short summary: what the step delivered,
-   one line per changed file on what it does and why, then confirm the step's
-   "done when" is met with empirical evidence (test pass output, build output, or screenshot). This summary is the comprehension gate, so keep it concrete, not
-   vague. Include a short **How to try it** note when the step has a manual
-   path: the command, URL, click, endpoint, or output the user can check.
-5. **Verify the step.** If `AGENTS.md` declares a `Verify` command, run that exact
-   command as the automated gate. It is only an umbrella for checks the project
-   actually has, so do not invent tests or other checks to satisfy it. If no
-   `Verify` command exists, run the documented build command and the test command
-   when the project declares one. A step that adds logic must ship a passing test
-   in the same diff when the test gate is on, and the suite must be green before
-   the step is approved (see the Testing gate in `coding-standards.md`). UI and
-   integration-only steps ride on screenshot plus build evidence. Run a focused
-   test separately when it gives faster feedback, then use `Verify` as the final
-   automated gate. For UI or integration done-whens, prefer Playwright when it is
-   already installed or declared in `AGENTS.md`; do not add it silently for an
-   unrelated feature. Create focused test files next to the source they cover,
-   per `coding-standards.md`. Never install a runner mid-step unless the current
-   spec is explicitly the unit-testing setup itself (for example `/fix "add unit
-   testing"`). If a step surfaces non-trivial logic the spec did not foresee, add
-   a focused test then, or note why not. When a step's done-when is behavioral (a
-   click, a download, or a flow across screens), run `/check` to prove it against
-   the running app rather than eyeballing it.
-5. **Iterate until it works.** If it fails or the user wants changes, revise the
-   step (re-prompt or hand-edit the code), show the updated diff, and re-test.
-   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/{xxx-slug}/spec.md` so progress survives a context
-   clear. If the step repaired a finding tracked in
-   `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
-   `/complete` makes the real feature-level commit. Use the current tool's short
-   user-input prompt when available; when you've just produced a long block to
-   read (a deep explanation, a big
-   walk-through), ask in plain text instead, so the prompt doesn't cover what the
-   user is still reading:
-   - **Continue** (default) - roll into the next step without committing.
-   - **Commit checkpoint** - commit just this step on the branch with a
-     conventional message (a cheap rollback point).
-   - **Walk me through it** - give a deeper, line-level explanation of the new or
-     changed code (why this approach, what each part does, any gotchas), then
-     re-ask this checkpoint prompt. A loop-back, not a terminal choice.
-   - **Stop here** - pause the loop so the user can review or come back later.
-
-   On **Continue** or after **Commit checkpoint**, go to the next step. On **Walk
-   me through it**, explain in depth and then re-ask this prompt in plain text (the
-   explanation is long, so a modal would cover it). On **Stop here**, stop and say
-   where things stand: the branch is intact; run `/implement` again to resume, or
-   `/complete` to wrap up what's built so far.
-
-### Ticket-Driven TDD Execution (when working from a Ticket)
-
-When executing a tracer-bullet ticket (via `--ticket` or auto-frontier):
-1. **Extract Scope**: Read *What to build* and *Acceptance criteria* checklist (`- [ ]`) from the active ticket file.
-2. **Strict TDD Cycle per Criterion**:
-   - **🔴 RED**: Write the unit/integration test for the criterion first at the agreed seam. Execute the test command and verify the expected failing assertion.
-   - **🟢 GREEN**: Implement only the minimal code in the source file necessary to make the test pass. Re-run test and show passing output.
-   - **🔵 REFACTOR**: Refactor and format cleanly, verifying that 100% of tests remain green.
-3. **Verify Gate**: Run the project's Verify command (`npm run check` or documented test suite) to ensure whole-system health before concluding the ticket.
-4. **Bidirectional State Sync**:
-   - Mark each completed criterion `- [x]` in the ticket file.
-   - Once all criteria in the ticket pass, update the ticket status to `**Status:** done` (or `Status: done`).
-   - Mirror the completed work, status, and diff evidence into `devflow/context/{xxx-slug}/spec.md` (under `## 📋 3. Execution Plan & TDD Checklist` and `## ⚡ 4. Implementation Log & Evidence`) so the Living Spec remains the authoritative single source of truth for `/check`, `/audit`, and `/complete`.
-
-Never batch the whole thing into one diff. If a step's diff is too big to read,
-split it. The documented `Verify` command, or the fallback build and tests, must
-pass before any commit.
+## Step 2 - implement and verify
+
+Work in small reviewable diffs, keeping progress in the selected spec.
+
+1. For logic or behavior changes with the test gate on, use Red-Green-Refactor: write a focused failing test, confirm the assertion fails for the missing behavior, implement the smallest change, then refactor with affected tests green. Preserve the user's existing work. Consult [TDD anti-patterns](tdd-anti-patterns.md) when test design needs it.
+2. Match the step's done-when and run focused checks. Documentation or formatting-only edits use structural checks and review; they do not require artificial unit tests. Capture relevant runtime or browser proof for behavioral criteria, following the selected Check policy.
+3. Fix failures caused by the change and rerun affected checks without requesting authorization again. Broaden verification when dependencies, failures, or risk justify it.
+4. Record the diff summary and evidence. Mark a step complete once its done-when passes and any configured per-step review has been approved. A repaired finding becomes `fixed` with resolution evidence; only a subsequent audit can close it. Apply the review cadence above before proceeding.
+
+At the final handoff, run the exact documented Verify command and all required gates. If there is no Verify command, use the project's declared build and test commands. Reuse a passing result for unchanged inputs within this pass; rerun affected gates after subsequent edits. Do not add tests or tools just to inflate the verification matrix.
+
+### Ticket execution
+
+When a ticket is selected, use its acceptance criteria as the steps above. Mark completed criteria in the ticket, mark it `done` after its criteria and required verification pass, and mirror status and evidence into the run's spec. A ticket handoff runs required gates once; criteria within the ticket use focused checks. A request to finish the whole run continues through the dependency frontier until the authorized scope is verified.
 
 After final Verify and required Check pass, set the active spec to `verified`
 with every completed box checked. Then resolve independent review before the
@@ -270,23 +192,19 @@ named area. If the feature spans too many distinct areas for one useful pass,
 name the sections first and let the user choose where to begin. Remain read-only
 unless the user separately requests changes.
 
-Never create an ordinary step, product, or work-level commit from this skill.
-The sole exception is exactly one immutable independent-review checkpoint after
-showing its exact candidate and receiving current explicit commit approval.
-Configuration never supplies that approval. Never merge, push, deploy, publish,
+Ordinary checkpoint commits are available only through the configured review boundary and explicit candidate approval above. The immutable independent-review checkpoint also requires explicit candidate approval. Work-level completion commits belong to `/complete`. Configuration never supplies commit approval. Never merge, push, deploy, publish,
 or start unrelated work from this skill.
 
 ## Rules
 
-- One small step per diff; the user reviews and approves each before any commit.
+- Keep diffs small and apply the configured review cadence.
 - Explain every change in plain English. Understanding the code is the point.
 - Iterate on the branch until each step works; never commit code the user hasn't
   approved.
 - Follow `devflow/context/coding-standards.md` (server vs client, scope user-owned queries
   by the authenticated user id, validate inputs, and so on).
-- Build only what the spec says. If the spec is wrong or thin, stop and fix the
-  spec first, do not improvise.
-- Per-step commits are optional checkpoints. The work-level commit, the merge,
+- Keep the spec aligned with the authorized scope. Correct routine omissions with evidence; ask only when a material scope or design decision is unresolved.
+- Configured checkpoint offers are optional. The work-level commit, the merge,
   and any push are `/complete`'s job.
 - For Type: Rollback, reverse only the approved product diff and preserve all
   protected Blueprint paths.

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

@@ -1,6 +1,6 @@
 ---
 name: bughunter
-description: "[devflow] Offensive security orchestrator & bug hunting guide. Indexes 83 vulnerability classes, 5-phase methodology (Think, Hunt, Perimeter, Ship), 681 disclosed HackerOne patterns, and JIT reference guides in devflow/.vendor/bughunter/. Use when running /bughunter, performing security reviews, verifying auth/injection risks in /check or /audit, or testing API endpoints for vulnerabilities."
+description: "[devflow] Investigate security vulnerabilities with evidence. Use for /bughunter or an authorized security review of code or endpoints."
 argument-hint: "[{target, vuln-class, or topic}]"
 ---
 

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

@@ -36,7 +36,8 @@ When invoked without an argument (or when determining the next step), inspect:
 
 ### Default State Recommendations
 - If no run is active and user wants to start a feature -> Recommend `/feature <name>`.
-- If no run is active and user wants to fix a bug -> Recommend `/fix <bug>`.
+- If the user requests a bugfix plan -> Recommend `/fix <bug>`.
+- If the user requests a completed fix -> preserve the implementation and verification scope; draft the required spec internally and continue to `/implement` using existing authorization.
 - If no run is active and user has pending ideas in `devflow/ideas.md` -> Highlight `/feature IDEA-xxx` or `/discovery IDEA-xxx`.
 - If no run is active and user wants deep architectural exploration -> Recommend `/discovery`.
 - If user asks to check system health -> Recommend `doctor`.
@@ -48,7 +49,7 @@ When invoked without an argument (or when determining the next step), inspect:
 | User Intent / Request Type | Recommended Skill | Normal Name / Alias | Lifecycle Path |
 | :--- | :--- | :--- | :--- |
 | **"Spec new feature / living spec"** | `feature` | `/feature` / `/spec` | **Unified**: `/feature` -> `/implement` -> `/check` -> `/complete` |
-| **"Quick bugfix / ad-hoc change"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
+| **"Draft a bugfix / small-change plan"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
 | **"Capture quick idea / thought"** | `idea` | `/idea` | **Companion**: Enriches & saves to `devflow/ideas.md` |
 | **"Pre-delivery exploration / research"**| `discovery`| `/discovery` | **Pre-Flight**: `discovery` -> `/feature` |
 | **"Socratic alignment / ADR / glossary"**| `grill` | `/grill` / `/align` | **Pre-Flight**: `grill` -> `/feature` |

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

@@ -1,6 +1,6 @@
 ---
 name: fix
-description: "[devflow] Write a task-isolated spec (devflow/context/{xxx-slug}/spec.md) for an ad-hoc bug fix or small unplanned change, then stop before implementation. Use for /fix, confirmed bugs, or small changes outside the build plan."
+description: "[devflow] Draft a task-isolated spec for a bug or small change. Use when invoking /fix or requesting a fix plan."
 argument-hint: "[{title or issue-description}]"
 ---
 
@@ -23,7 +23,7 @@ it creates a dedicated run folder at `devflow/context/{xxx-slug}/` (e.g. `059-fi
 ## Input
 
 A description of the bug or change, for example `/fix "password reset email never
-sends"`. If the user just reported the problem in chat, use that.
+sends"`. Use the reported problem as input when the user asks for a fix plan. A request to diagnose a problem belongs to `/debug`; a request to fix and verify it retains its full delivery scope.
 
 The input may also be a finding ID from `devflow/context/{xxx-slug}/findings.md` (or previous findings), alone
 or with a description, for example `/fix F-03`.
@@ -46,7 +46,7 @@ then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize
   big to read. Each ends with an observable "done when".
 - **Verify** - how to confirm it's fixed (what to click or test).
 
-Then stop. Tell the user to review the fix spec, then run `/implement` to build it.
+For an explicit `/fix` or a planning-only request, present the spec as the completed deliverable and identify `/implement` as the next command. For an existing request to implement and verify the fix, preserve that authorization: use this spec as the internal handoff and continue through `/implement` without an extra approval pause. Ask only for unresolved material scope, design, or permission decisions.
 
 ## Rules
 

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

@@ -1,10 +1,10 @@
 ---
 name: implement
-description: "[devflow] Implement or start coding the active task-isolated spec on its branch in small steps, running tests after each step and presenting the configured review handoff. Use for /implement or requests to build or resume an approved spec."
+description: "[devflow] Build and verify a task-isolated spec. Use for /implement or requests to implement an approved plan."
 argument-hint: "[{run-id, number, or name}] [--ticket <NN | path>]"
 ---
 
-# implement - build the target spec, one reviewed step at a time
+# implement - build and verify the target spec
 
 **Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
 
@@ -20,17 +20,23 @@ Where this sits in the workflow:
 
 `/feature`, `/fix`, or `/rollback` wrote the spec to
 `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
-behind your approval. It builds on a branch and offers an optional commit
-checkpoint after each step; the work-level commit, merging, and logging are
-`/complete`'s job.
+Build the selected spec through its acceptance criteria and required verification, then present the configured review handoff. Preserve authorization already given for this work. Read only relevant conventions and reuse loaded context.
+
+## Review cadence and checkpoints
+
+Read `workflow.stepReview` and `workflow.checkpointCommits` from `devflow/config.json` independently; defaults are `feature` and `disabled`.
+
+- `stepReview: "feature"`: continue through all authorized steps without asking Continue after each step. Record evidence as work proceeds and present one final review packet.
+- `stepReview: "every"`: after a working step, show its diff and evidence, then wait for approval before the next step. A walkthrough is available on request.
+- `checkpointCommits: "disabled"`: omit ordinary checkpoint offers.
+- `checkpointCommits: "enabled"`: offer an optional checkpoint at the configured review boundary (per-step for `every`, final packet for `feature`). Show the exact candidate and obtain commit authorization before committing. The setting itself is not authorization.
+
+Independent-review checkpoints follow their separate contract below. Review cadence never authorizes commit, merge, push, or deployment.
 
 ## Multi-Run Target & Ticket-Driven 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 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.
+- **Given an ID or name** (e.g. `/implement 12`, `/implement 012`, `/implement kanban`) -> locates the matching run folder `devflow/context/{xxx-slug}/`, selects the branch matching the run type and configured prefix, and loads only that run's `spec.md`.
+- **With no argument** (`/implement`) -> checks the current feature, fix, or rollback branch against the configured prefixes, or auto-picks if only 1 spec is active in `devflow/context/`, or prompts the user if multiple specs are queued.
 - **Ticket Input (`--ticket <NN | path>`)**: Targets a specific tracer-bullet ticket directly (e.g. `/implement 12 --ticket 01`, `/implement --ticket 02`, `/implement --ticket issues/01-auth.md`, or `/implement 01` when run-id is not ambiguous).
 
 ### Ticket Discovery Hierarchy
@@ -80,11 +86,7 @@ receipt. After the final Verify pass, an active gate routes to
 `current` freshness may proceed toward `/complete`. This skill never approves
 its own work or rewrites receipt evidence.
 
-For a browser-facing step, run `npm run test:browser` when the script exists and
-record the result in the step evidence. Use `browseros-neo` for the interactive
-handoff when it is available and the done-when is visual or behavioral. When the
-script or MCP is absent, report that exact limitation; do not silently install a
-runner or claim browser evidence.
+For browser-facing changes, run focused browser tests during iteration when available. Run the required `npm run test:browser` gate once before handoff if the spec or project requires it. Use `browseros-neo` for visual or behavioral evidence when available and relevant. Record missing tooling accurately; install a runner only when setup is in the authorized scope.
 
 **Resuming?** If the spec already has some build steps checked off (`- [x]`), this
 feature was started earlier and interrupted (often a cleared context). The spec and
@@ -95,8 +97,7 @@ starting over.
 
 ## Step 1 - branch
 
-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
+Create or select the branch for the spec using `git.featureBranchPrefix`, `git.fixBranchPrefix`, or `git.rollbackBranchPrefix` from config (defaults: `feature/`, `fix/`, `rollback/`). Preserve unrelated working-tree changes before switching. 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.
@@ -105,99 +106,20 @@ instead of creating a new one.
 
 When implementing a rollback task, follow the exact safety procedure in `reference/rollback-implementation.md`.
 
-## Step 2 - build one step, review, iterate, checkpoint (Strict TDD)
-
-Work through the spec's build steps in order, one at a time. For each step:
-
-1. **Strict TDD Cycle (for logic & behavior changes)**:
-   - **🔴 RED**: Write the unit test first in the relevant test file. Execute the test command and show the failing assertion output.
-   - **🟢 GREEN**: Implement only the minimal code in the source file necessary to make the test pass. Re-run test and show passing output.
-   - **🔵 REFACTOR**: Refactor and format cleanly, verifying that 100% of tests remain green.
-   - *Code Reversion Rule*: If production code is written without a prior test for behavior changes, revert it and write the test first.
-
-   **⚖️ The Iron Law**: `NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST` — Apply to behavior changes according to the spec's test decision. If code came first, revert only your own work for that step and restart from the test, preserving the user's existing work.
-
-   **Red-Phase Verification (confirm all three before GREEN):**
-   - The test actually fails, rather than encountering a syntax error
-   - The error message identifies missing behavior, rather than invalid configuration
-   - The failure reflects the behavior under test, rather than a bug in the test itself
-
-   **Green-Phase Discipline**: Write the minimum code needed to pass the test; add only the options/features it requires (YAGNI constraint).
-
-   > 📖 For anti-patterns and Bad vs Good examples, read [`tdd-anti-patterns.md`](tdd-anti-patterns.md).
-
-2. Implement just that step: the smallest change that satisfies its "done when."
-3. Show the **diff**, not whole files.
-4. **Explain it, and prove it.** Give a short summary: what the step delivered,
-   one line per changed file on what it does and why, then confirm the step's
-   "done when" is met with empirical evidence (test pass output, build output, or screenshot). This summary is the comprehension gate, so keep it concrete, not
-   vague. Include a short **How to try it** note when the step has a manual
-   path: the command, URL, click, endpoint, or output the user can check.
-5. **Verify the step.** If `AGENTS.md` declares a `Verify` command, run that exact
-   command as the automated gate. It is only an umbrella for checks the project
-   actually has, so do not invent tests or other checks to satisfy it. If no
-   `Verify` command exists, run the documented build command and the test command
-   when the project declares one. A step that adds logic must ship a passing test
-   in the same diff when the test gate is on, and the suite must be green before
-   the step is approved (see the Testing gate in `coding-standards.md`). UI and
-   integration-only steps ride on screenshot plus build evidence. Run a focused
-   test separately when it gives faster feedback, then use `Verify` as the final
-   automated gate. For UI or integration done-whens, prefer Playwright when it is
-   already installed or declared in `AGENTS.md`; do not add it silently for an
-   unrelated feature. Create focused test files next to the source they cover,
-   per `coding-standards.md`. Never install a runner mid-step unless the current
-   spec is explicitly the unit-testing setup itself (for example `/fix "add unit
-   testing"`). If a step surfaces non-trivial logic the spec did not foresee, add
-   a focused test then, or note why not. When a step's done-when is behavioral (a
-   click, a download, or a flow across screens), run `/check` to prove it against
-   the running app rather than eyeballing it.
-5. **Iterate until it works.** If it fails or the user wants changes, revise the
-   step (re-prompt or hand-edit the code), show the updated diff, and re-test.
-   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/{xxx-slug}/spec.md` so progress survives a context
-   clear. If the step repaired a finding tracked in
-   `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
-   `/complete` makes the real feature-level commit. Use the current tool's short
-   user-input prompt when available; when you've just produced a long block to
-   read (a deep explanation, a big
-   walk-through), ask in plain text instead, so the prompt doesn't cover what the
-   user is still reading:
-   - **Continue** (default) - roll into the next step without committing.
-   - **Commit checkpoint** - commit just this step on the branch with a
-     conventional message (a cheap rollback point).
-   - **Walk me through it** - give a deeper, line-level explanation of the new or
-     changed code (why this approach, what each part does, any gotchas), then
-     re-ask this checkpoint prompt. A loop-back, not a terminal choice.
-   - **Stop here** - pause the loop so the user can review or come back later.
-
-   On **Continue** or after **Commit checkpoint**, go to the next step. On **Walk
-   me through it**, explain in depth and then re-ask this prompt in plain text (the
-   explanation is long, so a modal would cover it). On **Stop here**, stop and say
-   where things stand: the branch is intact; run `/implement` again to resume, or
-   `/complete` to wrap up what's built so far.
-
-### Ticket-Driven TDD Execution (when working from a Ticket)
-
-When executing a tracer-bullet ticket (via `--ticket` or auto-frontier):
-1. **Extract Scope**: Read *What to build* and *Acceptance criteria* checklist (`- [ ]`) from the active ticket file.
-2. **Strict TDD Cycle per Criterion**:
-   - **🔴 RED**: Write the unit/integration test for the criterion first at the agreed seam. Execute the test command and verify the expected failing assertion.
-   - **🟢 GREEN**: Implement only the minimal code in the source file necessary to make the test pass. Re-run test and show passing output.
-   - **🔵 REFACTOR**: Refactor and format cleanly, verifying that 100% of tests remain green.
-3. **Verify Gate**: Run the project's Verify command (`npm run check` or documented test suite) to ensure whole-system health before concluding the ticket.
-4. **Bidirectional State Sync**:
-   - Mark each completed criterion `- [x]` in the ticket file.
-   - Once all criteria in the ticket pass, update the ticket status to `**Status:** done` (or `Status: done`).
-   - Mirror the completed work, status, and diff evidence into `devflow/context/{xxx-slug}/spec.md` (under `## 📋 3. Execution Plan & TDD Checklist` and `## ⚡ 4. Implementation Log & Evidence`) so the Living Spec remains the authoritative single source of truth for `/check`, `/audit`, and `/complete`.
-
-Never batch the whole thing into one diff. If a step's diff is too big to read,
-split it. The documented `Verify` command, or the fallback build and tests, must
-pass before any commit.
+## Step 2 - implement and verify
+
+Work in small reviewable diffs, keeping progress in the selected spec.
+
+1. For logic or behavior changes with the test gate on, use Red-Green-Refactor: write a focused failing test, confirm the assertion fails for the missing behavior, implement the smallest change, then refactor with affected tests green. Preserve the user's existing work. Consult [TDD anti-patterns](tdd-anti-patterns.md) when test design needs it.
+2. Match the step's done-when and run focused checks. Documentation or formatting-only edits use structural checks and review; they do not require artificial unit tests. Capture relevant runtime or browser proof for behavioral criteria, following the selected Check policy.
+3. Fix failures caused by the change and rerun affected checks without requesting authorization again. Broaden verification when dependencies, failures, or risk justify it.
+4. Record the diff summary and evidence. Mark a step complete once its done-when passes and any configured per-step review has been approved. A repaired finding becomes `fixed` with resolution evidence; only a subsequent audit can close it. Apply the review cadence above before proceeding.
+
+At the final handoff, run the exact documented Verify command and all required gates. If there is no Verify command, use the project's declared build and test commands. Reuse a passing result for unchanged inputs within this pass; rerun affected gates after subsequent edits. Do not add tests or tools just to inflate the verification matrix.
+
+### Ticket execution
+
+When a ticket is selected, use its acceptance criteria as the steps above. Mark completed criteria in the ticket, mark it `done` after its criteria and required verification pass, and mirror status and evidence into the run's spec. A ticket handoff runs required gates once; criteria within the ticket use focused checks. A request to finish the whole run continues through the dependency frontier until the authorized scope is verified.
 
 After final Verify and required Check pass, set the active spec to `verified`
 with every completed box checked. Then resolve independent review before the
@@ -270,23 +192,19 @@ named area. If the feature spans too many distinct areas for one useful pass,
 name the sections first and let the user choose where to begin. Remain read-only
 unless the user separately requests changes.
 
-Never create an ordinary step, product, or work-level commit from this skill.
-The sole exception is exactly one immutable independent-review checkpoint after
-showing its exact candidate and receiving current explicit commit approval.
-Configuration never supplies that approval. Never merge, push, deploy, publish,
+Ordinary checkpoint commits are available only through the configured review boundary and explicit candidate approval above. The immutable independent-review checkpoint also requires explicit candidate approval. Work-level completion commits belong to `/complete`. Configuration never supplies commit approval. Never merge, push, deploy, publish,
 or start unrelated work from this skill.
 
 ## Rules
 
-- One small step per diff; the user reviews and approves each before any commit.
+- Keep diffs small and apply the configured review cadence.
 - Explain every change in plain English. Understanding the code is the point.
 - Iterate on the branch until each step works; never commit code the user hasn't
   approved.
 - Follow `devflow/context/coding-standards.md` (server vs client, scope user-owned queries
   by the authenticated user id, validate inputs, and so on).
-- Build only what the spec says. If the spec is wrong or thin, stop and fix the
-  spec first, do not improvise.
-- Per-step commits are optional checkpoints. The work-level commit, the merge,
+- Keep the spec aligned with the authorized scope. Correct routine omissions with evidence; ask only when a material scope or design decision is unresolved.
+- Configured checkpoint offers are optional. The work-level commit, the merge,
   and any push are `/complete`'s job.
 - For Type: Rollback, reverse only the approved product diff and preserve all
   protected Blueprint paths.

package/template/AGENTS.md

@@ -11,14 +11,22 @@ This project uses **Nexus-DevFlow**, an agentic workflow layer supporting **The
 
 To start a new project, scaffold the application first in an empty folder, then run `npx nexus-devflow` (or `npm create @jakkrichm/nexus-devflow`) to overlay DevFlow onto your codebase.
 
-## Read these for full context
+## Load context for the task
 
-- `devflow/config.json` - deterministic project workflow settings
-- `devflow/context/project-overview.md` - the project's source of truth
-- `devflow/context/coding-standards.md` - engineering conventions & rules to follow
-- `devflow/context/ai-interaction.md` - how to interact with the user on this project
-- `devflow/context/glossary.md` - domain terms & architecture definitions
-- `devflow/context/{xxx-slug}/` - active task living spec, stage, findings ledger, and independent review receipt
+Reuse instructions already loaded. Read relevant sections, rather than every document before every edit:
+
+- `devflow/config.json` for workflow policy and quality-gate decisions.
+- `devflow/context/project-overview.md` for project purpose, architecture, and cross-module boundaries.
+- `devflow/context/coding-standards.md` for conventions affecting changed code.
+- `devflow/context/ai-interaction.md` for workflow interaction and review cadence.
+- `devflow/context/glossary.md` when domain terminology matters.
+- `devflow/context/{xxx-slug}/` for the selected run's spec, stage, findings, and review receipt.
+
+## Task intent and authorization
+
+Explicit user scope takes precedence over skill guidance, within runtime permissions and safety constraints. A request to draft a spec ends at the spec; a request to implement and verify continues through those authorized steps. A skill transition is not a new approval requirement. Ask when a material decision or authorization is missing, reuse existing authorization, and identify the exact instruction if it requires a pause. Preserve separate authorization for commit, merge, push, and deployment.
+
+Use focused checks during edits, and run the documented required gates before handoff. Repeat passing checks only after relevant changes, failures, or unresolved concerns. Apply TDD to logic and behavior changes; documentation-only edits need appropriate structural or review evidence.
 
 ## Project configuration
 
@@ -50,37 +58,7 @@ Unused adapter families can be removed. Codex, Antigravity, GitHub Copilot, and
 3. **Google Antigravity & Claude Code**: Native skill engines automatically discover and surface `.agents/skills/` and `.claude/skills/`.
 4. **State-Aware Inspection**: When unsure what to do next, invoke `devflow` to automatically inspect active task directories in `devflow/context/{xxx-slug}/`, `devflow/discoveries/`, and `devflow/ideas.md`.
 5. **Default Artifact & Communication Language (Thai)**: All generated markdown stage artifacts (`spec.md`, `discovery.md`, etc.) and user communication MUST default to **Thai (`th`)**, while code, technical terms, file paths, and identifiers remain in English.
-6. **Universal Contextual Help & Playbook Protocol (`help`, `--help`, `-h`, `?`)**:
-   Whenever any skill or command is invoked with a help keyword or flag (e.g., `/bughunter help`, `bughunter --help`, `/archify -h`, `/check ?`, `/feature help`):
-   - **Execution Safety Gate**: DO NOT execute the skill's primary or mutating actions (do not launch scans/attacks, do not modify source code, and do not initialize new task runs).
-   - **Dynamic Workspace Inspection**: Read the target skill definition (`.agents/skills/<skill>/SKILL.md`, `.claude/skills/<skill>/SKILL.md`, and any vendored resources such as `devflow/.vendor/<skill>/`), then scan the active workspace (`devflow/context/project-overview.md`, `package.json`, tech stack, active tasks, endpoints, and file hierarchy).
-   - **Persistent HTML Playbook & Token-Saving Cache**:
-     - **Output Location & Light Theme Mandate**: Compile and persist the tailored playbook as a standalone, styled HTML report at `devflow/docs/playbooks/{skill}.html` adhering to the **Paper/Ink Light Theme Standard** (`data-theme="light"`, teal accent, ruler corner, terminal mockup UI, and diagram slot per `devflow/docs/playbooks/template.html`). Never generate dark-mode-first documentation.
-     - **First Run**: Render the comprehensive 5W1H playbook in chat and write the complete HTML report to `devflow/docs/playbooks/{skill}.html`.
-     - **Subsequent Invocations (Delta Updates & Zero Token Bloat)**: If `devflow/docs/playbooks/{skill}.html` already exists:
-       - Inspect the existing HTML file and compute the diff/delta against the current repository state (e.g., new file paths, modified endpoints, or newly installed vendor assets).
-       - DO NOT repeat unchanged boilerplate or full static content in chat.
-       - Provide a concise **Delta Summary** in chat (highlighting what changed, new recommendations, or newly available commands).
-       - In-place update `devflow/docs/playbooks/{skill}.html` with the fresh timestamp and state.
-       - Provide a direct clickable link to [devflow/docs/playbooks/{skill}.html](file:///d:/devtools/nexus-devflow/devflow/docs/playbooks/{skill}.html) for browser viewing.
-   - **Render the User-Friendly 5W1H Playbook**: Emit an easy-to-read, practical guide organized around the **5W 1H Framework** (rendered on initial run or updated in the HTML playbook):
-      1. **What (Concept & Capabilities)**: Clear, jargon-free summary of what this skill does, its core concept, and its bundled tools/capabilities.
-      2. **Why (Problems Solved & Key Benefits)**: The problems it solves, key advantages, and why you should use it instead of ad-hoc manual work.
-      3. **Who (Target Roles & Personas)**: Target audience or engineering role (e.g., Feature Developer, Senior QA, Security Auditor, Solo Dev, or Tech Lead).
-      4. **Where (Boundaries & Artifact Locations)**: Target workspace boundaries, affected directories, and generated artifact locations (e.g., `devflow/context/`, `devflow/discoveries/`, `findings.md`).
-      5. **When (Timing & Prerequisites/Next Steps)**:
-         - **Timing & Triggers**: Practical situations or milestones when this skill should be invoked.
-         - **Run Before (Prerequisites)**: What to check, prepare, or run beforehand to get the best result.
-         - **Run After (Next Steps)**: What DevFlow command or lifecycle stage should follow next (e.g., handing off to `/fix`, `/feature`, or `/complete`).
-      6. **How (Execution Lifecycle & Real Command Examples)**:
-         - **How It Works (Lifecycle)**: Simple, plain-language breakdown of the execution steps or phases.
-         - **Available Commands & Options**: Common sub-commands, arguments, and flags with brief explanations.
-         - **Safety, Guardrails & Precautions**: Operational boundaries, credential hygiene, read-only vs. mutating constraints, and explicit special safety constraints / precautions.
-      7. **Diagram Slot & Architecture Flow**:
-         - **Real Diagram Mandate**: MUST embed a real, verified vector SVG or interactive diagram reflecting actual skill lifecycle, state transitions, or threat models in Light Theme (`data-theme="light"`).
-         - **Thai Language & Legible Typography**: Architecture and flow diagrams must describe workflows and nodes in Thai language while preserving technical identifiers, paths, and commands in English. Typography must be sufficiently sized and legible for Thai script (Headers 13–14px, box content/descriptions 11–12px, line spacing 18–22px) to prevent tone marks and vowels from clipping or overlapping.
-         - **Strictly No Placeholders**: NEVER output empty placeholder cards, generic instruction text, or phrases like *"when invoking archify..."*. Every playbook must ship with a real visual architectural diagram.
-   - Always conclude the response with: `"Help menu displayed successfully"`.
+6. **Contextual Help**: When a DevFlow command is invoked with `help`, `--help`, `-h`, or `?`, read [the playbook protocol](devflow/reference/help-playbook-protocol.md). Produce its help deliverable without running the command's primary action or creating a task run.
 
 ---
 

package/template/devflow/context/ai-interaction.md

@@ -8,7 +8,7 @@
 
 - **Be Concise and Direct**: State conclusions, status, and findings first; provide supporting context afterward.
 - **Explain Non-Obvious Decisions Briefly**: Highlight architectural trade-offs, edge-case rationale, or safety considerations in 1–2 sentences.
-- **Ask Before Destructive or Architectural Changes**: Always obtain explicit confirmation before deleting files, executing major refactors, or altering public interfaces.
+- **Authorization**: Reuse explicit authorization already given for the requested work. Ask before destructive actions or material architectural changes outside that scope. Identify the instruction requiring a pause; routine implementation choices do not require renewed approval.
 - **Don't Add Unplanned Scope**: Stick strictly to the Acceptance Criteria defined in the spec. Avoid adding "nice-to-have" features that were not requested.
 - **Preserve Existing Codebase Patterns**: Respect existing file structure, typing patterns, naming conventions, and deep module boundaries.
 
@@ -21,8 +21,8 @@ Format every response for fast scanning and readability:
 - **Real Markdown, Not Prose Walls**: Use bold labels, concise bullet points, and blank lines between blocks.
 - **Enumerations Are Lists**: Numbered or bulleted lists for sequential steps or findings, never inline runs crammed into paragraphs.
 - **Tables for Comparative Matrices**: Use markdown tables when comparing status, options, test results, or trade-offs.
-- **Backticks for Code References**: Wrap file paths, variable names, functions, CLI flags, and commands in backticks (e.g. `current-feature.md`, `npm run check`).
-- **Clickable File Links**: Use GitHub-style markdown links with `file://` scheme (e.g. `[current-feature.md](file:///d:/path/to/current-feature.md)`).
+- **Backticks for Code References**: Wrap file paths, variable names, functions, CLI flags, and commands in backticks (e.g. `devflow/context/{xxx-slug}/spec.md`, `npm run check`).
+- **Clickable File Links**: Use the active client's supported local-file link format with the actual resolved path.
 - **Lead With the Result**: State pass/fail status or completed action before presenting logs.
 
 ---
@@ -97,7 +97,7 @@ After the first successful `/overview`, DevFlow offers a reviewed local commit f
 ## 4. Strict TDD & Two-Stage Review Interaction Rules
 
 ### 🔴🟢 Strict TDD Execution Discipline
-During implementation in `/implement`:
+For logic and behavior changes during `/implement`, follow the spec's test decision:
 - **Show Red Phase**: First execute tests to demonstrate expected failure *before* adding production code.
 - **Show Green Phase**: Add minimal production code, re-run tests, and report pass rate.
 - **Show Refactor Phase**: Polish and clean up with zero test regression.
@@ -111,10 +111,10 @@ During `/check`:
 
 ### ⚡ Review Cadence & Implementation Loop
 - **Efficient Default (`stepReview: "feature"`)**: Presents one comprehensive review packet after all implementation steps of the feature complete, with step checkpoint commits disabled (`checkpointCommits: "disabled"`). This minimizes review fatigue and saves context window tokens.
-- **Guided Review (`stepReview: "every"`)**: Available for high-risk changes, pair programming, or instructional sessions. Pauses for user approval after each small step and offers checkpoint commits (`checkpointCommits: "enabled"`).
+- **Guided Review (`stepReview: "every"`)**: Available for high-risk changes, pair programming, or instructional sessions. Pauses for user approval after each small step. Offer optional checkpoints only if `checkpointCommits: "enabled"`.
 - **Post-Implementation Walkthrough**: After the final review packet, `/implement` always offers an optional read-only walkthrough of the finished code, regardless of review cadence or checkpoint settings.
 - **Independent Review Execution**: Regular and Continuous independent review default to `when-sensitive`, while `review.independentExecution` defaults to `automatic` (spawning an isolated reviewer child when the active adapter supports it). Setting `review.independentExecution: "manual"` produces the fresh-session handoff.
-- **Configuration**: Managed directly in `devflow/config.json`.
+- **Configuration**: Managed directly in `devflow/config.json`. The two workflow keys are independent: `every` does not imply checkpoints are enabled, and `enabled` never grants commit authorization. Use the implementation skill's cadence contract for all four combinations.
 
 ---
 
@@ -131,16 +131,17 @@ During `/check`:
 
 Progress lives in persistent files, not in transient chat history:
 
-- In Fast-Track: `devflow/context/current-feature.md` maintains ticked checklist boxes `- [x]`.
+- In the selected run: `devflow/context/{xxx-slug}/spec.md` maintains ticked checklist boxes `- [x]`.
 - In Git: Commits, branches, and working tree maintain the code history.
-- When starting a fresh session after a context clear, run `devflow` or inspect `current-stage.md` to pick up immediately from the next pending step.
+- When starting a fresh session after a context clear, resolve the run from an explicit ID or current branch, then inspect `devflow/context/{xxx-slug}/stage.md` and its spec to pick up immediately from the next pending step.
 
 ---
 
-## 6. Single Active Run Guardrail (One Thing at a Time)
+## 6. Multi-Run Isolation
 
-- Only one active Single Living Spec run is allowed at a time.
-- The AI will actively block opening a new feature or fix until the current one is completed with `/complete` (or explicitly rolled back/cancelled).
+- Multiple specs may be queued in `devflow/context/{xxx-slug}/` without blocking new drafts.
+- Select a run by explicit ID, matching branch, or the sole active candidate. Ask only when the target remains ambiguous.
+- Keep each run's spec, stage, findings, and branch separate. Protect unrelated working-tree changes before switching; use an isolated worktree when concurrent implementation requires it.
 
 ---
 
@@ -177,14 +178,14 @@ Progress lives in persistent files, not in transient chat history:
 Nexus-DevFlow natively supports extending workflow capabilities with **Third-Party Skills** (installed via `nexus-devflow skill add <repo-or-path>`):
 
 ### 🧩 1. Discovery & Inventory
-- Core workflow commands and AI agents automatically inspect `.agents/skills/` (and `.claude/skills/`) or run `nexus-devflow skill list` to discover installed third-party capabilities.
+- Reuse the available skill catalog. Inspect the active adapter or run `nexus-devflow skill list` only when a required capability is not already known.
 - Installed third-party skills maintain their exact original directory structure, references, assets, scripts, and `SKILL.md`.
 
 ### 🎯 2. Cross-Command Delegation & Genuine Execution
-- **Verbatim & Original Prompt Fidelity**: When a DevFlow stage requires specialized domain expertise (e.g., editorial diagramming, system mapping, domain modeling, cloud provisioning, UI benchmarking), the AI agent must read the third-party skill's `SKILL.md` (e.g. `.agents/skills/archify/SKILL.md` or `.agents/skills/diagram-design/SKILL.md`) and strictly follow its original instructions, philosophy, style guide gates, and complexity constraints.
+- **Verbatim & Original Prompt Fidelity**: When a DevFlow stage requires specialized domain expertise (e.g., editorial diagramming, system mapping, domain modeling, cloud provisioning, UI benchmarking), the AI agent must read the third-party skill's `SKILL.md` (e.g. `.agents/skills/archify/SKILL.md` or `.agents/skills/diagram-design/SKILL.md`) and apply the relevant workflow within the user's requested scope. Explicit user instructions take precedence over skill guidance; reuse existing authorization rather than adding approval gates.
 - **Workflow Command Integration Map**:
   - **`/discovery`**: When macro roadmap planning or micro pre-flight exploration involves system architecture, IT landscape, data pipelines, sequence flows, or user journeys, check for `archify` (for interactive system maps, data flows, and sequence traces) or `diagram-design` (for editorial and business layouts).
-  - **`/feature` & `/fix`**: In Section 2 (`## 📐 2. Technical Spec & Contracts`), invoke `archify` for interactive component diagrams, state machines, and sequence traces, or `diagram-design` for database ER models.
+  - **`/feature` & `/fix`**: When a diagram materially clarifies Section 2 (`## 📐 2. Technical Spec & Contracts`), use `archify` for interactive component diagrams, state machines, and sequence traces, or `diagram-design` for database ER models.
   - **`/implement`**: Seamlessly consumes Tracer-Bullet Tickets generated by Matt Pocock's `/to-tickets` (`.scratch/<feature>/issues/`, `devflow/context/{xxx-slug}/tickets/`), resolving the unblocked Frontier and executing with Strict TDD.
   - **`/brainstorm` & `/grill`**: Leverage visual trade-off matrices (Quadrant, Radar spider) or domain models (UML class, ER).
   - **`/prototype` & `/report-html`**: Embed standalone HTML/SVG assets seamlessly.

package/template/devflow/context/coding-standards.md

@@ -119,12 +119,13 @@ nexus-devflow/
 
 Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
-- **Unit Test Mandate**: Any new feature, modified logic, parser improvement, or bug fix **MUST ship with automated unit tests** in the same diff.
+- **Unit Test Mandate**: Logic or behavior changes must include meaningful automated coverage when the spec's test gate is enabled. Documentation, prompt wording, or formatting-only changes use structural checks and review instead of artificial unit tests.
 - **Strict TDD (Red-Green-Refactor) Protocol**:
   1. **🔴 RED (Test First)**: Always write automated tests *before* writing or modifying functional logic. Run the test command and verify that it fails for the expected reason.
   2. **🟢 GREEN (Minimal Code)**: Write only the minimal production code necessary to make the failing test pass. Run the test command and verify 100% green pass.
   3. **🔵 REFACTOR (Clean & Robust)**: Refactor code for readability, performance, and DRY/YAGNI discipline while ensuring all tests stay green.
   - *Code Deletion / Reversion Rule*: If functional code is created without a prior failing test for behavior changes, it must be reverted or immediately backed by tests before continuing.
+- **Verification Scope**: Run focused checks during edits and required project gates before handoff. Repeat passing checks only after relevant changes, new failures, or unresolved risk.
 - **Test Framework**: Use Node.js native test runner executed via `tsx --test test/*.test.ts` under `packages/create-nexus-devflow/`.
 - **Test Design (AAA Pattern)**:
   - Structure each test case cleanly: **Arrange** (setup fixtures/mock directories), **Act** (execute function), **Assert** (verify invariants).
@@ -137,7 +138,7 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
     2. *Interactive AI Visual QA (MCP)*: Live DOM and styling inspection via MCP `browseros-neo` (`http://127.0.0.1:9010/mcp`) during `/check` and `/try`.
 - **Two-Stage Review Pattern (Verification Gate)**:
   - **Stage 1: Spec Fidelity & Acceptance Gate**:
-    - Verify 100% conformance against the Single Living Spec (`current-feature.md`).
+    - Verify 100% conformance against the Single Living Spec (`devflow/context/{xxx-slug}/spec.md`).
     - Validate all Acceptance Criteria (ACs) and "Done When" observables without missing requirements or scope creep.
     - Test edge cases and boundary conditions defined in the specification.
   - **Stage 2: Code Quality, Security & Architecture Gate**:
@@ -145,13 +146,13 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
     - **Lane 2 (Automated Test Suites & Evals)**: `npm test` (Unit tests 100% pass) + `npm run test:routing` (Skill routing accuracy).
     - **Lane 3 (Scrutinize & Security Audit)**: Edge cases, null-safety, 0 secrets, safe inputs.
     - **Lane 4 (Manual / Scenario Proof)**: Concrete walkthrough steps ("Where to go", "What to run", "What to expect").
-    - **Findings Ledger State**: 0 blockers (P0/P1) in `devflow/context/findings.md`.
+    - **Findings Ledger State**: 0 blockers (P0/P1) in `devflow/context/{xxx-slug}/findings.md`.
 
 ---
 
 ## 8. Findings Ledger & Quality Gates (`findings.md`, `review.md`)
 
-- All quality defects, security findings, or regression issues identified during review must be logged in `devflow/context/findings.md`.
+- All quality defects, security findings, or regression issues identified during review must be logged in `devflow/context/{xxx-slug}/findings.md`.
 - **Finding State Machine**:
   - `open`: Confirmed issue waiting to be fixed.
   - `fixed`: Repaired in code, pending QA re-verification.

package/template/devflow/context/glossary.md

@@ -4,15 +4,15 @@
 
 ---
 
-### Single Living Spec (`current-feature.md`)
-- **Definition**: เอกสาร Markdown กลางเพียงฉบับเดียวที่ใช้ขับเคลื่อนและบันทึกวงจรชีวิตของงานพัฒนาตั้งแต่ต้นจนจบ (Single Source of Truth during active delivery)
-- **Constraints**: มีได้เพียง 1 งานที่ active ในช่วงเวลาหนึ่งตามหลักการ Single Active Run Guardrail
+### Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)
+- **Definition**: เอกสาร Markdown หลักหนึ่งฉบับต่อ runที่ใช้ขับเคลื่อนและบันทึกวงจรชีวิตของงานพัฒนาตั้งแต่ต้นจนจบ (Single Source of Truth during active delivery)
+- **Constraints**: ร่างหลาย run ได้พร้อมกัน แต่แต่ละ run แยก spec, stage, findings และ branch; เลือกเป้าหมายก่อน implement
 - **Structure**: ครอบคลุม 6 ส่วนหลัก: (1) Define & Boundaries, (2) Technical Spec & Contracts, (3) Execution Plan & TDD Tasks, (4) Implementation Log & Evidence, (5) Multi-Lane Verification Matrix, (6) Release Digest & Retrospective
-- **Aliases / Related**: `current-feature.md`, Living Spec, Feature Spec
+- **Aliases / Related**: `devflow/context/{xxx-slug}/spec.md`, Living Spec, Feature Spec
 
 ### Unified Fast-Track
 - **Definition**: รูปแบบการพัฒนาหลักแบบ Single-Track ของ Nexus-DevFlow ที่รวมความสามารถเชิงสถาปัตยกรรมระดับลึก (Deep) และความคล่องตัว (Fast) เข้าด้วยกันผ่าน 4 คำสั่งหลัก: `/feature` (หรือ `/fix`), `/implement`, `/check`, และ `/complete`
-- **Constraints**: ขับเคลื่อนผ่านไฟล์ `current-feature.md` และเมื่อเสร็จสิ้นจะถูก Archive เป็นไฟล์ Markdown เดี่ยวใน `devflow/history/`
+- **Constraints**: ขับเคลื่อนผ่านไฟล์ `devflow/context/{xxx-slug}/spec.md` และเมื่อเสร็จสิ้นจะถูก Archive เป็นไฟล์ Markdown เดี่ยวใน `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`
 - **Aliases / Related**: Fast-Track, Unified Track
 
 ### Pre-Flight Discovery
@@ -22,7 +22,7 @@
 
 ### Multi-Lane Verification Matrix
 - **Definition**: ตารางตรวจสอบคุณภาพแบบหลายมิติที่ครอบคลุม Typecheck, Linter, Automated Unit/Integration Tests, และ Manual Proof Evidence ในคำสั่ง `/check`
-- **Constraints**: ต้องมีผลลัพธ์ผ่าน (PASS) ครบทุก Lane และไม่มี P0/P1 Finding ที่ยังค้างอยู่ก่อนที่จะส่งต่อไปยัง `/complete`
+- **Constraints**: ต้องมีหลักฐานผ่านสำหรับทุก Lane ที่ใช้กับงาน ส่วนที่ไม่เกี่ยวข้องให้บันทึก N/A พร้อมเหตุผล และไม่มี P0/P1 Finding ที่ยังค้างอยู่ก่อนที่จะส่งต่อไปยัง `/complete`
 - **Aliases / Related**: QA Matrix, Lane Verification
 
 ### Release Digest & Retrospective

package/template/devflow/reference/help-playbook-protocol.md

@@ -0,0 +1,33 @@
+# Contextual Help Playbook
+
+**Universal Contextual Help & Playbook Protocol (`help`, `--help`, `-h`, `?`)**:
+   Whenever any skill or command is invoked with a help keyword or flag (e.g., `/bughunter help`, `bughunter --help`, `/archify -h`, `/check ?`, `/feature help`):
+   - **Execution Safety Gate**: DO NOT execute the skill's primary or mutating actions (do not launch scans/attacks, do not modify source code, and do not initialize new task runs).
+   - **Dynamic Workspace Inspection**: Read the target skill in the active adapter. Inspect only workspace files and selected references needed to tailor its examples; reuse current context.
+   - **Persistent HTML Playbook & Token-Saving Cache**:
+     - **Output Location & Light Theme Mandate**: Compile and persist the tailored playbook as a standalone, styled HTML report at `devflow/docs/playbooks/{skill}.html` adhering to the **Paper/Ink Light Theme Standard** (`data-theme="light"`, teal accent, ruler corner, terminal mockup UI, and a real diagram). Reuse `devflow/docs/playbooks/template.html` when present; otherwise build the standalone page using these conventions.
+     - **First Run**: Render the comprehensive 5W1H playbook in chat and write the complete HTML report to `devflow/docs/playbooks/{skill}.html`.
+     - **Subsequent Invocations (Delta Updates & Zero Token Bloat)**: If `devflow/docs/playbooks/{skill}.html` already exists:
+       - Inspect the existing HTML file and compute the diff/delta against the current repository state (e.g., new file paths, modified endpoints, or newly installed vendor assets).
+       - DO NOT repeat unchanged boilerplate or full static content in chat.
+       - Provide a concise **Delta Summary** in chat (highlighting what changed, new recommendations, or newly available commands).
+       - In-place update `devflow/docs/playbooks/{skill}.html` with the fresh timestamp and state.
+       - Provide a clickable link to the actual resolved output file using the active client's supported local-file link format.
+   - **Render the User-Friendly 5W1H Playbook**: Emit an easy-to-read, practical guide organized around the **5W 1H Framework** (rendered on initial run or updated in the HTML playbook):
+      1. **What (Concept & Capabilities)**: Clear, jargon-free summary of what this skill does, its core concept, and its bundled tools/capabilities.
+      2. **Why (Problems Solved & Key Benefits)**: The problems it solves, key advantages, and why you should use it instead of ad-hoc manual work.
+      3. **Who (Target Roles & Personas)**: Target audience or engineering role (e.g., Feature Developer, Senior QA, Security Auditor, Solo Dev, or Tech Lead).
+      4. **Where (Boundaries & Artifact Locations)**: Target workspace boundaries, affected directories, and generated artifact locations (e.g., `devflow/context/`, `devflow/discoveries/`, `findings.md`).
+      5. **When (Timing & Prerequisites/Next Steps)**:
+         - **Timing & Triggers**: Practical situations or milestones when this skill should be invoked.
+         - **Run Before (Prerequisites)**: What to check, prepare, or run beforehand to get the best result.
+         - **Run After (Next Steps)**: What DevFlow command or lifecycle stage should follow next (e.g., handing off to `/fix`, `/feature`, or `/complete`).
+      6. **How (Execution Lifecycle & Real Command Examples)**:
+         - **How It Works (Lifecycle)**: Simple, plain-language breakdown of the execution steps or phases.
+         - **Available Commands & Options**: Common sub-commands, arguments, and flags with brief explanations.
+         - **Safety, Guardrails & Precautions**: Operational boundaries, credential hygiene, read-only vs. mutating constraints, and explicit special safety constraints / precautions.
+      7. **Diagram Slot & Architecture Flow**:
+         - **Real Diagram Mandate**: MUST embed a real, verified vector SVG or interactive diagram reflecting actual skill lifecycle, state transitions, or threat models in Light Theme (`data-theme="light"`).
+         - **Thai Language & Legible Typography**: Architecture and flow diagrams must describe workflows and nodes in Thai language while preserving technical identifiers, paths, and commands in English. Typography must be sufficiently sized and legible for Thai script (Headers 13–14px, box content/descriptions 11–12px, line spacing 18–22px) to prevent tone marks and vowels from clipping or overlapping.
+         - **Strictly No Placeholders**: NEVER output empty placeholder cards, generic instruction text, or phrases like *"when invoking archify..."*. Every playbook must ship with a real visual architectural diagram.
+   - Always conclude the response with: `"Help menu displayed successfully"`.