@jakkrichm/create-nexus-devflow 2.5.0 → 2.6.1

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

@@ -1,9 +1,9 @@
 ---
 name: debug
-description: "[devflow][B] Diagnose a failing test, broken build, crash, error, regression, or unexpected behavior without editing source or Blueprint state. Reproduces the symptom with the smallest safe command, localizes the failing path, tests competing hypotheses, identifies the root cause when evidence supports one, and reports a repair handoff to /fix or /implement. Use when the user runs /debug, invokes $debug, asks why something is failing or broken, wants a root-cause investigation, or asks to diagnose before fixing."
+description: "[devflow] Diagnose a failing test, broken build, crash, error, regression, or unexpected behavior without editing source or DevFlow state. Follows a strict 6-Phase Scientific Debugging Loop: builds a red-capable tight feedback loop, reproduces & minimises, tests 3-5 falsifiable hypotheses, localizes the failure to a root cause, and reports a repair handoff to /fix or /implement. Use when the user runs /debug, invokes $debug, asks why something is failing or broken, wants a root-cause investigation, or asks to diagnose before fixing."
 ---
 
-# debug - find the cause before changing the code
+# debug - 6-Phase Scientific Debugging Protocol
 
 Where this sits in the workflow:
 
@@ -12,130 +12,112 @@ Where this sits in the workflow:
      crash, behavior)       isolate,       repair active work)
                             explain)
 
-`/debug` separates diagnosis from repair. It gathers evidence, narrows the
-failure to a specific cause when possible, and stops with a useful handoff. It
-does not make the code "temporarily work" while investigating.
+`/debug` separates diagnosis from repair. It gathers empirical evidence, narrows the failure to a specific root cause using scientific method, and stops with an actionable repair handoff. It does not guess, assume, or perform ad-hoc "vibe debugging".
+
+---
 
 ## Input
 
 Accept a symptom, failing command, error message, or unexpected behavior. Examples:
 
-    /debug npm test fails in cart-total.test.js
+    /debug npm test fails in cart-total.test.ts
     /debug the upload route returns 500 for PNG files
-    /debug why does the production build fail?
+    /debug why does the build fail on Windows?
 
-With no useful symptom, ask for the expected behavior, actual behavior, and
-smallest known reproduction. Do not guess which problem the user means.
+With no useful symptom, ask for expected behavior, actual behavior, and smallest known reproduction. Do not guess.
 
-## Step 1 - establish the boundary
+---
 
-Read the project instructions and the context relevant to the failure:
+## 🔬 The 6-Phase Scientific Debugging Loop
 
-- `AGENTS.md` and its real commands
-- `devflow/context/project-overview.md`
-- `devflow/context/coding-standards.md`
-- `devflow/context/current-feature.md`
-- the reported error, failing output, and affected files
-- git status, diff, and recent log when a regression is possible
+### Phase 1: Build a Red-Capable Feedback Loop (Golden Rule)
 
-State the symptom and what would count as reproducing it. Note whether the
-failure belongs to an active feature or is an unplanned bug.
+**This is the core discipline.** If you have a **tight** pass/fail command that actively goes RED on this bug, you will find the root cause. If you do not have one, staring at code will not save you.
 
-Do not treat a dirty working tree as permission to discard or rewrite anything.
-Use the diff as evidence and preserve it.
+**Spend disproportionate effort here. Ways to construct one (in order):**
+1. **Failing Unit / Integration Test** at the responsible module seam.
+2. **Curl / HTTP script** against the running local dev server.
+3. **CLI invocation** diffing stdout/stderr against expected output.
+4. **Headless browser script** (Playwright) asserting on DOM/network/console.
+5. **Replay captured trace**: Replay isolated payload/event log through the code path.
 
-## Step 2 - reproduce safely
+**Completion Criterion for Phase 1**:
+You must name **one single command** (a test invocation, a script, or curl) that you have **already run at least once** and proven:
+- [ ] **Red-capable**: It exercises the actual code path and catches the user's exact symptom (fails red now, will pass green once fixed).
+- [ ] **Deterministic**: Returns the same verdict every run.
+- [ ] **Fast & Agent-runnable**: Completes in seconds, executable without manual intervention.
 
-Run the smallest existing command or interaction that can reproduce the symptom.
+> [!CAUTION]
+> **No Red-Capable Command = No Phase 2.** If you catch yourself reading code to form theories before this command exists, **STOP**. Jumping straight to a hypothesis is the exact failure this protocol prevents.
 
-- Prefer one focused test, request, CLI command, or input over the entire suite.
-- Capture the exact exit code, error, stack trace, output, response, console
-  error, or failed request.
-- Reuse an already-running local app when available. If reproduction requires a
-  long-running server that is not running, ask the user to start it and provide
-  the documented command.
-- Do not install dependencies, change configuration, run migrations, mutate
-  production data, contact external users, or use destructive commands to force
-  a reproduction.
-- Do not edit code to add logs or probes. Use existing logs, debuggers,
-  read-only inspection, or one-off commands that do not change project files.
-- Compare git status after diagnostic commands. If one changes tracked or
-  untracked project files, stop and report those paths. Do not clean, restore,
-  or hide the changes.
+---
 
-If the symptom cannot be reproduced, say what was attempted and what evidence is
-missing. Continue with static investigation only when it can produce a clearly
-labeled hypothesis, not a claimed root cause.
+### Phase 2: Reproduce & Minimise
 
-## Step 3 - localize the failure
+Run the feedback loop and watch it go RED.
 
-Trace from the observed failure toward the smallest responsible area.
+1. **Confirm Symptom**: Ensure the failure mode matches what the user reported (not a nearby unrelated error).
+2. **Minimise the Repro**: Cut inputs, configs, dependencies, and steps **one at a time**, re-running the command after each cut. Keep only what is load-bearing for the failure.
+3. **Done when**: Every remaining parameter is load-bearing (removing any one makes the loop go green).
 
-Use the evidence that fits the project:
+---
 
-- the first relevant application frame in a stack trace
-- the smallest failing test and its inputs
-- request and response data at the failing boundary
-- console and network errors
-- callers, imports, data flow, and configuration reads
-- `git diff`, `git log`, and `git blame` for a suspected regression
-- comparison with a nearby working path or input
+### Phase 3: Form 3–5 Ranked Falsifiable Hypotheses
 
-Separate facts from hypotheses. Test the cheapest safe competing explanations
-first. Do not stop at the first plausible line, blame a dependency without
-evidence, or confuse the place an error surfaced with the place it originated.
+Generate **3 to 5 ranked hypotheses** before testing or inspecting deeply. Never anchor on the first plausible idea.
 
-## Step 4 - confirm or narrow
+Every hypothesis MUST be **falsifiable** using this exact format:
+> *"If `<X>` is the cause, then `<changing Y>` will make the bug disappear / `<changing Z>` will make it worse."*
 
-A root cause is confirmed only when the evidence connects all three:
+If you cannot state the prediction, it is a vibe: sharpen or discard it.
 
-1. the triggering input or state
-2. the responsible code, configuration, or contract
-3. the observed failure
+---
 
-When safe and read-only, vary one input or run a smaller focused command to
-confirm the connection. Do not change implementation or tests to prove the fix.
+### Phase 4: Targeted Instrumentation & Isolation
 
-Use one of these verdicts:
+Test hypotheses by changing **one variable at a time**:
+1. **Tool preference**: Read-only inspection > REPL/debugger > Targeted probe logs.
+2. **Debug Tag Rule**: If temporary diagnostic logs are necessary, tag every log line with a unique prefix, e.g. `[DEBUG-a4f2]`. This guarantees a single `grep` can find and remove all probes.
+3. **Redaction**: Redact all secrets, tokens, and credentials in terminal outputs (`<REDACTED>`).
 
-- **Confirmed** - evidence identifies the cause and explains the failure.
-- **Likely** - evidence narrows the cause, but one specific proof is unavailable.
-- **Blocked** - the failure cannot be reproduced or required evidence is
-  inaccessible.
+---
 
-## Step 5 - report and hand off
+### Phase 5: Confirm Root Cause at Real Seam
 
-Give a concise debug report:
+A root cause is **Confirmed** only when empirical evidence connects all three:
+1. The triggering input or state
+2. The responsible code / configuration boundary
+3. The observed failure
 
-- symptom and reproduction
-- verdict
-- root cause or leading hypothesis
-- evidence, including commands and relevant paths
-- affected behavior and likely repair boundary
-- what was not verified
-- exact next action
+**Seam Identification**: Identify the exact architectural seam (per `devflow/context/coding-standards.md` Deep Modules) where the regression test must live. If no clean seam exists, note that as an architectural finding.
 
-Choose the next action without writing files:
+---
+
+### Phase 6: Report & Hand-off
+
+Give a structured, concise debug report:
 
-- Active feature or fix caused the failure -> return the diagnosis to `/implement` with instructions to write a failing reproduction test ([TDD-Red]) first.
-- No active work item and the bug is confirmed -> recommend `/fix "<concise bug and confirmed cause>"` (which will write a failing test first before fixing).
-- Cause is only likely or blocked -> recommend the next diagnostic evidence, not a speculative repair.
-- The issue is planned product work rather than a defect -> point to `/feature`.
+```markdown
+### 🐞 Debug Report: <Concise Title>
+
+- **Symptom**: <Exact user symptom observed>
+- **Reproduction Command**: `<Single red-capable command>`
+- **Verdict**: Confirmed | Likely | Blocked
+- **Root Cause**: <Precise technical explanation of why it failed>
+- **Responsible Seam**: `<path/to/file.ts#line>`
+- **Evidence**:
+  - Test/Curl output confirming the red signal
+  - Trace connecting triggering state to failure
+- **Next Action**:
+  - For active feature -> Hand back to `/implement` with instructions to write failing test first.
+  - For standalone bug -> Recommend `/fix "<concise description>"` to create spec and implement regression test.
+```
+
+---
 
 ## Rules
 
-- Diagnose, do not repair. Never edit source, tests, configuration, lockfiles, or
-  Blueprint files.
-- Never create, switch, merge, or delete branches. Never commit or push.
-- Do not update the findings ledger. `/audit` owns recorded code-quality
-  findings; `/debug` reports one investigated failure in chat.
-- Evidence outranks confidence. Label uncertainty and failed reproduction
-  honestly.
-- Preserve the user's working tree and running processes.
-- Do not broaden one failure into a general audit or refactor.
-
-## Formatting
-
-Format the output to match the project's conventions in
-`devflow/context/ai-interaction.md`: concise, scannable markdown with a short
-evidence list and a clear next action.
+- **Diagnose, do not repair**: Never edit production source, package lockfiles, or DevFlow state inside `/debug`.
+- **Evidence outranks confidence**: Label uncertainty honestly (`Likely` vs `Confirmed`).
+- **Preserve git state**: Never switch branches, commit, reset, or clean the working tree.
+- **Clean up probes**: Ensure any temporary test scripts in scratch/ are cleanly referenced.

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

@@ -1,6 +1,6 @@
 ---
 name: devflow
-description: "[devflow][B] Flagship interactive guide, state inspector, and intent router for DevFlow workflows."
+description: "[devflow] Flagship interactive guide, state inspector, and intent router for DevFlow workflows."
 ---
 
 # devflow - Interactive Workflow Guide & Intent Router for Nexus-DevFlow

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

@@ -1,6 +1,6 @@
 ---
 name: discovery
-description: "[devflow][D] Unified discovery and exploration stage in DevFlow 2.0 - conducts project-level roadmap discovery (project-plan.md/build-plan.md) or feature-level exploration (Stage 00) before delivery commitment."
+description: "[devflow] Unified discovery and exploration stage in DevFlow 2.5.0 - conducts project-level roadmap discovery (project-plan.md/build-plan.md) or feature-level pre-delivery exploration before the Single Living Spec lifecycle."
 argument-hint: "[{title, request, IDEA-xxx, or discovery-id}]"
 ---
 
@@ -10,7 +10,7 @@ $ARGUMENTS
 
 `/discovery` is the central discovery entry point in Nexus-DevFlow. It operates in two adaptive modes based on input scope:
 1. **🗺️ Macro Project Discovery**: Develops high-level product and build roadmap plans (`devflow/project-plan.md` & `devflow/build-plan.md`) through an adaptive conversation before `/overview`.
-2. **🔍 Micro Feature Exploration (Stage 00)**: Explores a specific feature, request, or idea before committing to delivery, routes through supporting lenses, and finishes with a visible `Proceed`, `Defer`, or `Reject` decision before `10-define`.
+2. **🔍 Micro Feature Exploration (Pre-Flight)**: Explores a specific feature, request, or idea before committing to delivery, routes through supporting lenses, and finishes with a visible `Proceed`, `Defer`, or `Reject` decision before `/feature` or `/fix`.
 
 ---
 
@@ -21,7 +21,7 @@ $ARGUMENTS
 /discovery
 /discovery --project
 
-# 2. Micro Feature Exploration Mode (Stage 00 of Deep-Track)
+# 2. Micro Feature Exploration Mode (Pre-Flight)
 /discovery {title or request}
 /discovery IDEA-xxx
 /discovery {discovery-id}
@@ -44,7 +44,7 @@ Use when:
 
 ---
 
-## Mode 2: Micro Feature Exploration (Stage 00 of Deep-Track)
+## Mode 2: Micro Feature Exploration (Pre-Flight)
 
 Use when:
 - Exploring a specific feature, complex architectural change, or pending idea (`/discovery IDEA-xxx`).
@@ -76,8 +76,7 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
 ### Decision & Approval Gate:
 Set one visible decision:
 - `Proceed`: Enough value and evidence exist to define delivery work:
-  - **🏎️ Fast-Track (Recommended for 85% of standard features/fixes)**: Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` (writes `devflow/context/current-feature.md`).
-  - **🏗️ Deep-Track (For large architectural epics/migrations)**: Handoff to `10-define {discovery_id}` (writes `devflow/context/current-run/10-define.md`).
+  - Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` to create the Single Living Spec in `devflow/context/current-feature.md`.
 - `Defer`: The idea remains relevant but timing or evidence is not ready.
 - `Reject`: The idea should not proceed under current framing.
 
@@ -86,6 +85,5 @@ Set one visible decision:
 ## Next Workflow Recommendations
 
 - **From Macro Project Mode**: Run `/overview` to compile context into `devflow/context/project-overview.md`.
-- **From Micro Stage 00 (Approved Proceed ➔ Fast-Track)**: Run `/feature {discovery_id}` to start lean living spec.
-- **From Micro Stage 00 (Approved Proceed ➔ Deep-Track)**: Run `10-define {discovery_id}` to allocate a Running ID.
-- **From Micro Stage 00 (Defer / Reject)**: No next command needed.
+- **From Micro Pre-Flight (Approved Proceed)**: Run `/feature {discovery_id}` or `/fix {discovery_id}` to start the Single Living Spec lifecycle.
+- **From Micro Pre-Flight (Defer / Reject)**: No next command needed.

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

@@ -1,6 +1,6 @@
 ---
 name: doctor
-description: "[devflow][B] Run a read-only Blueprint health check for setup, onboarding, required files, tool adapters, commands, optional verification and CI, Blueprint visibility, ignore rules, planning readiness, overview freshness, and workflow drift. Use when the user runs /doctor, asks whether the Blueprint is installed correctly, wants a health check, setup check, doctor pass, or says something feels off before starting or resuming work."
+description: "[devflow] Run a read-only Blueprint health check for setup, onboarding, required files, tool adapters, commands, optional verification and CI, Blueprint visibility, ignore rules, planning readiness, overview freshness, and workflow drift. Use when the user runs /doctor, asks whether the Blueprint is installed correctly, wants a health check, setup check, doctor pass, or says something feels off before starting or resuming work."
 ---
 
 # doctor - Blueprint health check

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

@@ -1,6 +1,7 @@
 ---
 name: feature
-description: "[devflow][F] Turn a feature from build-plan.md into a buildable spec. With no argument, specs the next unchecked item in the build plan; given a number or name, specs that one. If a clearly new feature does not match the plan, proposes a reviewed plan addition, refreshes the overview after approval, then specs it. Sizes the feature and splits anything too big into smaller sub-features (4a, 4b, ...), writes small, reviewable build steps to devflow/context/current-feature.md, then red-teams its own draft for gaps, oversized steps, and scope creep before stopping at a review gate. Use when the user runs /feature, names or numbers a feature, asks to add and start a new feature, or asks to spec out, break down, or start the next feature."
+description: "[devflow] Turn a feature from build-plan.md into a buildable living spec. Supports Multi-Run Spec Queue: drafts dedicated context in devflow/context/{xxx-slug}/ without blocking additional specs. With no argument, specs the next unchecked item; given a number or name, specs that one. Sizes and splits large items (4a, 4b), generates TDD checklist steps, red-teams the draft, and stops at review gate. Use when running /feature, naming a feature, or drafting the next living spec."
+argument-hint: "[{number, name, DISC-id, or IDEA-id}]"
 ---
 
 # feature - turn a build-plan feature into a buildable spec
@@ -8,18 +9,22 @@ description: "[devflow][F] Turn a feature from build-plan.md into a buildable sp
 Where this sits in the workflow:
 
     project-overview.md  +  build-plan.md  ->  [this skill]  ->  build
-    (source of truth,        (which feature       (the spec for      (code,
-     from /overview)          to build)            one feature)        reviewed)
+    (source of truth,        (which feature       (the spec in       (code,
+     from /overview)          to build)            contexts/xxx/)      reviewed)
 
 `build-plan.md` is intentionally high-level - one line per feature, no detail,
 no ordering ceremony. All of that is this skill's job: take one listed feature,
 read the full context from `project-overview.md`, and turn it into something
-buildable.
+buildable in `devflow/context/{xxx-slug}/spec.md`.
+
+## Multi-Run Spec-Ahead Support
+
+`/feature` supports drafting multiple specs ahead of time. Creating a spec creates a dedicated workspace directory at `devflow/context/{xxx-slug}/` and does **not block** drafting subsequent features.
 
 ## Input
 
 A feature from `build-plan.md`, by number or name - e.g. `/feature 3` or
-`/feature "typing engine"`.
+`/feature "typing engine"` or `/feature DISC-20260826-001`.
 
 The request may also describe a genuinely new feature that is not in the build
 plan yet. That goes through the new-feature intake in Step 1. Never silently add

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

@@ -1,6 +1,7 @@
 ---
 name: fix
-description: "[devflow][F] Document an ad-hoc bug fix or small change (one not in the build plan) into devflow/context/current-feature.md so it runs through the same build loop. Writes a short fix spec and stops; then /implement builds it and /complete logs it to devflow/history/fixes/ and merges. Use when the user runs /fix, reports a bug, or asks to fix or change something that isn't a planned build-plan feature."
+description: "[devflow] Document an ad-hoc bug fix or small change (one not in the build plan) into devflow/context/{xxx-slug}/spec.md so it runs through the same build loop. Supports Multi-Run: drafts dedicated fix context and allows selective /implement [id]. Writes a short fix spec and stops; then /implement builds it and /complete logs it to devflow/history/fixes/ and merges. Use when running /fix, reporting a bug, or fixing an ad-hoc issue."
+argument-hint: "[{title or issue-description}]"
 ---
 
 # fix - document an ad-hoc fix, then build it like anything else
@@ -13,7 +14,7 @@ Where this sits in the workflow:
 
 A fix is a bug or small change that isn't a planned build-plan feature. It runs
 through the same loop as a feature (build with review gates, iterate, then merge);
-it just starts here instead of `/feature`, and is logged separately.
+it creates a dedicated run folder at `devflow/context/{xxx-slug}/` (e.g. `059-fix-login-error`).
 
 ## Input
 
@@ -21,16 +22,13 @@ A description of the bug or change, for example `/fix "password reset email neve
 sends"`. If the user just reported the problem in chat, use that.
 
 The input may also be a finding ID from `devflow/context/findings.md`, alone
-or with a description, for example `/fix F-03`. Pull the problem statement from
-that ledger entry. Use this form only between work items, when
-`current-feature.md` is the reset stub: this skill overwrites that file, so
-while a spec is active, repair its findings through `/implement` instead.
+or with a description, for example `/fix F-03`.
 
 ## Step 1 - write the fix spec
 
 Pull context from `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`,
-then write a short spec to `devflow/context/current-feature.md` (this file holds whatever
-is being built now, feature or fix). Keep it lighter than a feature spec:
+calculate the next sequential running ID (e.g. `059-fix-slug`),
+then write a short spec to `devflow/context/{xxx-slug}/spec.md` (and update `devflow/context/current-feature.md`). Keep it lighter than a feature spec:
 
 - **Title** - the bug or change in a few words.
 - **Type:** Fix  (so `/complete` logs it to `devflow/history/fixes/`, not `devflow/history/features/`).

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

@@ -1,6 +1,6 @@
 ---
 name: grill
-description: "[devflow][B] Interactive Socratic alignment & domain modeling - stress-test plans, extract domain glossary, and record architecture decision records (ADRs) before delivery."
+description: "[devflow] Interactive Socratic alignment & domain modeling - stress-test plans, extract domain glossary, and record architecture decision records (ADRs) before delivery."
 argument-hint: "{topic, plan, or question}"
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: idea
-description: "[devflow][B] Quick idea capture and AI enrichment - analyze feasibility, value, key points, and record into devflow/ideas.md inbox."
+description: "[devflow] Quick idea capture and AI enrichment - analyze feasibility, value, key points, and record into devflow/ideas.md inbox."
 argument-hint: "\"<idea text or description>\""
 ---
 

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

@@ -1,9 +1,10 @@
 ---
 name: implement
-description: "[devflow][F] Build the feature, fix, or rollback spec'd in devflow/context/current-feature.md, one small reviewable step at a time. Creates the matching branch, implements each step, shows the diff and explains it in plain English, tests, and iterates until it works. Type: Rollback specs use a guarded reverse patch that preserves Blueprint history. After each approved step it offers an optional commit checkpoint on the branch; the work-level commit, merge, and logging are /complete's job. Use when the user runs /implement, or asks to build, implement, or start the current feature, fix, or rollback once its spec is ready."
+description: "[devflow] Build the feature, fix, or rollback spec, one small reviewable step at a time with Strict TDD. Supports Multi-Run: given an optional ID or name (/implement 12, /implement 012), targets that spec from devflow/context/{xxx-slug}/. Checks out matching branch, runs pre-flight drift revalidation, executes TDD steps with diffs, and offers commit checkpoints. Use when running /implement, or starting work on a spec."
+argument-hint: "[{run-id, number, or name}]"
 ---
 
-# implement - build the current spec, one reviewed step at a time
+# implement - build the target spec, one reviewed step at a time
 
 Where this sits in the workflow:
 
@@ -12,7 +13,7 @@ Where this sits in the workflow:
                                         reviewed)        merge + log)
 
 `/feature`, `/fix`, or `/rollback` wrote the spec to
-`devflow/context/current-feature.md` and stopped.
+`devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.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
@@ -20,9 +21,14 @@ 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.
 
+## Multi-Run Target Resolution
+
+- **Given an ID or name** (e.g. `/implement 12`, `/implement 012`, `/implement kanban`) -> locates the matching run folder `devflow/context/{xxx-slug}/`, checks out `feature/{xxx-slug}`, and loads only that run's `spec.md`.
+- **With no argument** (`/implement`) -> checks current git branch, or auto-picks if only 1 spec is active, or prompts the user if multiple specs are queued.
+
 ## Before you start
 
-Read `devflow/context/current-feature.md`. If it has no real spec (still the stub, or its
+Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`). If it has no real spec (still the stub, or its
 status is already complete), stop and tell the user to run `/feature` (for a
 planned feature), `/fix` (for an ad-hoc bug or change), or `/rollback` (for a
 completed feature reversal) first. Pull the

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

@@ -1,6 +1,6 @@
 ---
 name: onboard
-description: "[devflow][B] Set up the Blueprint after overlaying it onto a freshly scaffolded or early project. Detects the stack, tunes project files and adapters, documents real commands and existing checks, points to the optional standalone CI setup, and tells the user what to fill in before /overview or $overview. Use when the user runs /onboard, invokes $onboard, just copied the Blueprint into a new project, or asks what to do after overlaying the Blueprint. For an existing app with meaningful shipped features, use adopt instead."
+description: "[devflow] Set up the Blueprint after overlaying it onto a freshly scaffolded or early project. Detects the stack, tunes project files and adapters, documents real commands and existing checks, points to the optional standalone CI setup, and tells the user what to fill in before /overview or $overview. Use when the user runs /onboard, invokes $onboard, just copied the Blueprint into a new project, or asks what to do after overlaying the Blueprint. For an existing app with meaningful shipped features, use adopt instead."
 ---
 
 # onboard - finish the Blueprint overlay setup

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

@@ -1,6 +1,6 @@
 ---
 name: overview
-description: "[devflow][B] Distill user-owned planning docs into `devflow/context/project-overview.md` using a deterministic compiler. The overview is the living source of truth that agents read every session."
+description: "[devflow] Distill user-owned planning docs into `devflow/context/project-overview.md` using a deterministic compiler. The overview is the living source of truth that agents read every session."
 ---
 
 # overview - dynamic project overview compiler

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

@@ -1,6 +1,6 @@
 ---
 name: prototype
-description: "[devflow][B] Interactively prototype the look of a project. Asks about the desired look and feel and which pages to draft, proposes a plan, and only then writes throwaway static HTML/CSS mockups to prototypes/ that share one theme (a set of CSS theme variables). A plan-first, pre-build helper that sits outside the spec-driven feature loop, like scaffolding. Use when the user runs /prototype, names screens to mock up, or asks to prototype the layout, theme, or look and feel."
+description: "[devflow] Interactively prototype the look of a project. Asks about the desired look and feel and which pages to draft, proposes a plan, and only then writes throwaway static HTML/CSS mockups to prototypes/ that share one theme (a set of CSS theme variables). A plan-first, pre-build helper that sits outside the spec-driven feature loop, like scaffolding. Use when the user runs /prototype, names screens to mock up, or asks to prototype the layout, theme, or look and feel."
 ---
 
 # prototype - lock the look before you build

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

@@ -1,6 +1,6 @@
 ---
 name: release
-description: "[devflow][B] Prepare a Blueprint project for deployment to Render or Vercel. Reads the plans, project commands, app config, and current repo state; verifies build, start, output, env, health checks, and provider config; can create or update render.yaml or vercel.json when requested; and stops before any external deploy, service creation, remote env change, push, publish, or destructive action unless the user explicitly approves. Use when the user runs /release, invokes $release, asks for Render setup, Vercel setup, deploy readiness, deployment config, render.yaml, or vercel.json."
+description: "[devflow] Prepare a Blueprint project for deployment to Render or Vercel. Reads the plans, project commands, app config, and current repo state; verifies build, start, output, env, health checks, and provider config; can create or update render.yaml or vercel.json when requested; and stops before any external deploy, service creation, remote env change, push, publish, or destructive action unless the user explicitly approves. Use when the user runs /release, invokes $release, asks for Render setup, Vercel setup, deploy readiness, deployment config, render.yaml, or vercel.json."
 ---
 
 # release - deployment readiness for Render and Vercel

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

@@ -1,6 +1,6 @@
 ---
 name: report-html
-description: "[devflow][B] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from current-feature.md or 60-report.md on demand."
+description: "[devflow] Standalone HTML Report Generator - render an interactive standalone HTML dashboard from current-feature.md or 60-report.md on demand."
 argument-hint: "{running-id or workspace path}"
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: rollback
-description: "[devflow][B] Plan a safe reversal of a completed Blueprint feature using its archived spec and squashed git commit. Finds the exact feature commit, reviews later commits for dependency risk, writes a Type: Rollback spec to devflow/context/current-feature.md, and stops for review before /implement applies any code change. Use when the user runs /rollback, asks to remove or undo a completed feature, or wants to return the app to its pre-feature behavior without erasing Blueprint history."
+description: "[devflow] Plan a safe reversal of a completed Blueprint feature using its archived spec and squashed git commit. Finds the exact feature commit, reviews later commits for dependency risk, writes a Type: Rollback spec to devflow/context/current-feature.md, and stops for review before /implement applies any code change. Use when the user runs /rollback, asks to remove or undo a completed feature, or wants to return the app to its pre-feature behavior without erasing Blueprint history."
 ---
 
 # rollback - safely reverse a completed feature

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

@@ -1,6 +1,6 @@
 ---
 name: status
-description: "[devflow][B] Show where the project stands: build-plan progress, the current feature's checked and unchecked steps, git state, drift warnings, and the exact next action. Read-only. Use when the user runs /status, asks where things stand, what's next, what's in progress, or is picking work back up after a break or a context clear."
+description: "[devflow] Show where the project stands: build-plan progress, the current feature's checked and unchecked steps, git state, drift warnings, and the exact next action. Read-only. Use when the user runs /status, asks where things stand, what's next, what's in progress, or is picking work back up after a break or a context clear."
 ---
 
 # status - where the project stands right now

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

@@ -1,6 +1,6 @@
 ---
 name: test
-description: "[devflow][B] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
+description: "[devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
 ---
 
 # Test-Driven Development, Generation & Execution

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

@@ -1,6 +1,6 @@
 ---
 name: tests
-description: "[devflow][B] Add or normalize unit testing for a Blueprint project. Detects the stack, reuses an existing test runner when present, or installs the stack-native unit test runner when missing, then adds one small example test, updates AGENTS.md commands, runs build and tests, and reports the diff. Use when the user runs /tests, invokes $tests, asks to add unit tests, set up unit testing, configure tests, or make tests part of the Blueprint workflow."
+description: "[devflow] Add or normalize unit testing for a Blueprint project. Detects the stack, reuses an existing test runner when present, or installs the stack-native unit test runner when missing, then adds one small example test, updates AGENTS.md commands, runs build and tests, and reports the diff. Use when the user runs /tests, invokes $tests, asks to add unit tests, set up unit testing, configure tests, or make tests part of the Blueprint workflow."
 ---
 
 # tests - add unit testing to the project

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

@@ -1,6 +1,6 @@
 ---
 name: try
-description: "[devflow][B] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
+description: "[devflow] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
 ---
 
 # try - manual review guide

package/template/AGENTS.md

@@ -1,4 +1,4 @@
-# Nexus-DevFlow 2.5.0 (The 3-Pillars & Single Living Spec Model)
+# Nexus-DevFlow 2.6.1 (The 3-Pillars & Single Living Spec Model)
 
 Instructions for AI coding agents working in this project. This is the cross-tool entry point: Codex, Google Antigravity, Cursor, GitHub Copilot, Gemini CLI, Aider, Zed, Windsurf, and others read `AGENTS.md`. Claude Code reads `CLAUDE.md`, which imports this file (`@AGENTS.md`), so there is a single source of truth.
 

package/template/devflow/build-plan.md

@@ -84,6 +84,16 @@
   - *Dependencies*: ADR-001
   - *Scope*: รวมความสามารถเชิงสถาปัตยกรรมระดับลึกของ Deep-Track เข้าสู่ 4 ขั้นตอนหลักของ Fast-Track บนเอกสาร Single Living Spec (`current-feature.md`) จัดเก็บประวัติแบบ Single Archive (`.md`), ปลดระวาง stage skills 10-70 ที่ซ้ำซ้อน, และปรับปรุงเอกสาร & Schemas ทั้งหมด
 
+---
+
+## 🚀 Phase 11: Multi-Run Context Architecture & Spec Queue Engine
+
+- [x] **11. Multi-Run Context Architecture & Spec Queue Engine (`IDEA-026`, `DISC-20260826-001`)** `[Size: M]`
+  - *Dependencies*: Feature 10, Feature 3
+  - *Scope*: แยกจัดเก็บ Task-Specific Context เป็นโฟลเดอร์ย่อยใน `devflow/context/{xxx-slug}/`, พัฒนา Context Resolver สำหรับสลับและเรียกใช้งาน `/implement <id>`, `/check <id>`, `/complete <id>` แบบระบุ Running ID หรือ Fuzzy Match, และอัปเกรด CLI/Dashboard/Skills ให้รองรับ Spec Queue หลายรันพร้อมกัน
+
+
+
 
 
 

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

@@ -81,14 +81,14 @@ devflow/
 ## 4. Strict TDD & Two-Stage Review Interaction Rules
 
 ### 🔴🟢 Strict TDD Execution Discipline
-During implementation in `/implement` and `40-execute`:
+During implementation in `/implement`:
 - **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.
 - **Forbidden**: Never present functional code changes without matching test execution evidence.
 
 ### 🛡️ Two-Stage Verification Reporting
-During `/check` and `50-verify`:
+During `/check`:
 - **Stage 1 (Spec Fidelity Gate)**: Report each Acceptance Criterion and "Done When" status.
 - **Stage 2 (Code Quality & Security Gate)**: Report Typecheck, Lint, Test Suites, Security checks, and Findings Ledger (0 blockers).
 
@@ -97,7 +97,7 @@ During `/check` and `50-verify`:
 ## 5. Standalone HTML Reporting Policy
 
 > [!IMPORTANT]
-> **No Auto-Generated HTML**: Mainline stages (`/complete` and `60-report`) strictly output Markdown only.
+> **No Auto-Generated HTML**: The mainline `/complete` stage strictly outputs Markdown only.
 > When an interactive web dashboard is desired for presentation or sharing, invoke the standalone companion command:
 > `/report:html` (or `npm run report:html -- {ID}`).
 
@@ -108,7 +108,6 @@ During `/check` and `50-verify`:
 Progress lives in persistent files, not in transient chat history:
 
 - In Fast-Track: `devflow/context/current-feature.md` maintains ticked checklist boxes `- [x]`.
-- In Deep-Track: `devflow/context/current-run/` maintains stage markdown files.
 - 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.
 
@@ -116,8 +115,8 @@ Progress lives in persistent files, not in transient chat history:
 
 ## 6. Single Active Run Guardrail (One Thing at a Time)
 
-- Only one active run is allowed at a time across both Fast-Track and Deep-Track.
-- The AI will actively block opening a new feature or fix until the current one is completed with `/complete` or `70-deliver` (or explicitly rolled back/cancelled).
+- 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).
 
 ---