@jakkrichm/create-nexus-devflow 2.6.2 → 2.8.0

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

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

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

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

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

@@ -9,14 +9,14 @@ Use this skill to guide the user on what to do next, inspect current workspace s
 
 ## Input
 
-- **No argument (`devflow`, `/devflow`, `$devflow`, or `status`)**: Inspect current workspace state (active run in `devflow/context/current-stage.md`, active living spec in `devflow/context/current-feature.md`, active discovery in `devflow/discoveries/`, pending ideas in `devflow/ideas.md`, open findings in `devflow/context/findings.md`, and project overview in `devflow/context/project-overview.md`) and recommend the exact next action.
+- **No argument (`devflow`, `/devflow`, `$devflow`, or `status`)**: Inspect current workspace state (active tasks in `devflow/context/{xxx-slug}/`, active discovery in `devflow/discoveries/`, pending ideas in `devflow/ideas.md`, and project overview in `devflow/context/project-overview.md`) and recommend the exact next action.
 - **With user request (`devflow "<request>"`)**: Classify the user's intent and guide them to the matching DevFlow workflow stage or companion command path.
 
-## The Unified Living Spec Architecture (DevFlow 2.5.0)
+## The Task-Isolated Living Spec Architecture
 
-Nexus-DevFlow uses a **Single Unified Living Spec Model**:
+Nexus-DevFlow uses a **Task-Isolated Living Spec Model**:
 - **The 4-Stage Lifecycle**: `/feature` (or `/fix`) ➔ `/implement` ➔ `/check` ➔ `/complete`
-- Driven by a **Single Living Spec (`devflow/context/current-feature.md`)** that integrates architectural depth (Define, Spec, Plan, Execution Log, Multi-Lane QA, and Release Digest) into one clear living document.
+- Driven by a **Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)** that integrates architectural depth (Define, Spec, Plan, Execution Log, Multi-Lane QA, and Release Digest) into dedicated task workspaces without root bottleneck.
 - **Pre-Flight Inception Engine**: Companion skills (`/discovery`, `/idea`, `/grill`, `/brainstorm`) feed directly into `/feature`.
 
 ---
@@ -26,13 +26,13 @@ Nexus-DevFlow uses a **Single Unified Living Spec Model**:
 When invoked without an argument (or when determining the next step), inspect:
 
 1. **Project Setup Baseline**: Read `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`. If empty or default placeholders, recommend `onboard` (for fresh projects) or `adopt` (for existing codebases).
-2. **Active Delivery Run**: Read `devflow/context/current-stage.md` and `devflow/context/current-feature.md`.
-   - If `current-feature.md` has incomplete checklist tasks (`- [ ]`) -> Recommend `/implement`.
-   - If all tasks are completed (`- [x]`) but no passing verification evidence in Section 5 -> Recommend `/check`.
-   - If verification evidence passed in Section 5 -> Recommend `/complete`.
+2. **Active Delivery Runs**: Scan `devflow/context/{xxx-slug}/` subdirectories.
+   - If active `spec.md` has incomplete checklist tasks (`- [ ]`) -> Recommend `/implement [id]`.
+   - If all tasks are completed (`- [x]`) but no passing verification evidence in Section 5 -> Recommend `/check [id]`.
+   - If verification evidence passed in Section 5 -> Recommend `/complete [id]`.
 3. **Active Discovery**: Check `devflow/discoveries/` for open discovery notes.
 4. **Pending Ideas Inbox**: Check `devflow/ideas.md`. If items exist under `## 📌 Pending Ideas`, summarize them in a **💡 Pending Ideas (Inbox)** list with their IDs (`[IDEA-xxx]`), feasibility, and mention that they can be started with `/feature IDEA-xxx` or `/discovery IDEA-xxx`.
-5. **Audit Findings Ledger**: Check `devflow/context/findings.md` for open high-severity findings.
+5. **Audit Findings Ledger**: Check `devflow/context/{xxx-slug}/findings.md` for open high-severity findings.
 
 ### Default State Recommendations
 - If no run is active and user wants to start a feature -> Recommend `/feature <name>`.
@@ -55,7 +55,7 @@ When invoked without an argument (or when determining the next step), inspect:
 | **"Execute implementation tasks"** | `implement` | `/implement` | **Core Loop**: `/implement` -> `/check` |
 | **"Run QA verification & check"** | `check` | `/check` | **Core Loop**: `/check` -> `/complete` |
 | **"Complete run & git merge"** | `complete` | `/complete` | **Core Loop**: `/complete` |
-| **"Generate HTML dashboard report"**| `report-html` | `/report:html` | **Standalone**: Converts `current-feature.md` or archive to HTML |
+| **"Generate HTML dashboard report"**| `report-html` | `/report:html` | **Standalone**: Converts living spec or archive to HTML |
 | "Setup DevFlow on fresh/new project" | `onboard` | `onboard` / `setup` | `onboard` -> `/feature` |
 | "Adopt DevFlow on existing codebase" | `adopt` | `adopt` / `bootstrap` | `adopt` -> `/feature` |
 | "Check setup health & diagnostics" | `doctor` | `doctor` / `health` | `doctor` |
@@ -72,8 +72,8 @@ When invoked without an argument (or when determining the next step), inspect:
 ## Available Skills Sitemap
 
 ### 1. Mainline Living Spec Loop (4 Steps)
-- `feature` (`/feature`, `/spec`) - Define, spec, and plan in `current-feature.md`
-- `fix` (`/fix`) - Document an ad-hoc bug or change in `current-feature.md`
+- `feature` (`/feature`, `/spec`) - Define, spec, and plan in `devflow/context/{xxx-slug}/spec.md`
+- `fix` (`/fix`) - Document an ad-hoc bug or change in `devflow/context/{xxx-slug}/spec.md`
 - `implement` (`/implement`) - Execute planned checklist tasks with TDD
 - `check` (`/check`) - Senior QA review, multi-lane verification, record evidence
 - `complete` (`/complete`) - Safety pass, release digest, git merge, close run

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

@@ -76,7 +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:
-  - Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` to create the Single Living Spec in `devflow/context/current-feature.md`.
+  - Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` to create the Task-Isolated Living Spec in `devflow/context/{xxx-slug}/spec.md`.
 - `Defer`: The idea remains relevant but timing or evidence is not ready.
 - `Reject`: The idea should not proceed under current framing.
 
@@ -85,5 +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 Pre-Flight (Approved Proceed)**: Run `/feature {discovery_id}` or `/fix {discovery_id}` to start the Single Living Spec lifecycle.
+- **From Micro Pre-Flight (Approved Proceed)**: Run `/feature {discovery_id}` or `/fix {discovery_id}` to start the Task-Isolated Living Spec lifecycle.
 - **From Micro Pre-Flight (Defer / Reject)**: No next command needed.

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

@@ -30,10 +30,10 @@ Gather these, then summarize. Do not dump file contents.
 1. **Required DevFlow files**
    - Confirm `AGENTS.md`, `devflow/project-plan.md`,
      `devflow/build-plan.md`, and `devflow/context/` exist.
-   - Confirm `devflow/context/coding-standards.md`,
-     `devflow/context/ai-interaction.md`,
-     `devflow/context/current-feature.md`, and
-     `devflow/context/project-overview.md` exist.
+   - Confirm `devflow/context/project-overview.md`,
+     `devflow/context/coding-standards.md`,
+     `devflow/context/ai-interaction.md`, and
+     `devflow/context/glossary.md` exist.
    - Confirm `devflow/history/features/` and `devflow/history/fixes/` exist.
      When the rollback skill is installed, also check
      `devflow/history/rollbacks/`. A missing rollback folder on a legacy
@@ -48,6 +48,14 @@ Gather these, then summarize. Do not dump file contents.
    - If `.gitignore` marks DevFlow workflow files as local-only, still require
      the files to exist on disk. Ignored but present is healthy; ignored and
      missing means the local workflow needs to be restored.
+   - Read `devflow/config.json` when present. Missing is healthy and means
+     built-in defaults. When present, require a regular non-symbolic-link JSON
+     file with `schemaVersion: 1`. Reject unknown keys and unsupported values.
+     Report the effective workflow, git, verification, regular quality-gate,
+     Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
+     check, and try-guide gate uses its supported values and defaults to `manual`.
+     An invalid config is a setup blocker for mutating workflow skills because
+     they must not guess which policy to follow.
 2. **Tool adapters**
    - Read `.nexus/nexus-devflow.json` when present and report its exact
      logical adapters: Codex, Claude Code, GitHub Copilot, Antigravity, and OpenCode.
@@ -121,16 +129,12 @@ Gather these, then summarize. Do not dump file contents.
    - If either planning file appears newer than the overview by filesystem time,
      call the overview possibly stale and suggest `/overview` before feature work.
 7. **Current workflow state**
-   - Check whether `devflow/context/current-feature.md` is the reset stub or an
-     active feature, fix, or rollback spec.
+   - Scan `devflow/context/{xxx-slug}/` for active task directories and specs.
    - If a spec is active, report checked and unchecked implementation steps.
-   - If `current-feature.md` is the reset stub but git has source or workflow
+   - If no active task directory exists in `devflow/context/` but git has source or workflow
      changes, warn that work is happening without an active spec.
    - Flag active spec on `main`, all spec steps checked but no completion, or a
-     branch that does not match `feature/`, `fix/`, or `rollback/` for the spec
-     type. For a feature, also flag a mismatch with the next unchecked
-     build-plan item. For a rollback, confirm its target is a checked item and do
-     not compare it to the next unchecked item.
+     branch that does not match `feature/{xxx-slug}`, `fix/{xxx-slug}`, or `rollback/{xxx-slug}`.
 8. **Git**
    - Report current branch, clean vs dirty working tree, rough changed-file count,
      last commit subject, and whether the branch is ahead of upstream.

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

@@ -116,9 +116,8 @@ build plan starts high-level.
 
 ## Step 3 - write the spec
 
-For the one (sub-)feature being built now, write a full spec to
-`devflow/context/current-feature.md` (create `devflow/context/` if needed), following
-`reference/feature-spec-template.md`. Fill every section:
+For the one (sub-)feature being built now, allocate sequential ID (`xxx-slug`) and create a dedicated workspace at `devflow/context/{xxx-slug}/`. Write the full living spec to
+`devflow/context/{xxx-slug}/spec.md`, following `reference/feature-spec-template.md`. Also initialize `stage.md` and `findings.md` in that folder. Fill every section:
 - Goal, Problem Statement, and In/Out of scope
 - Acceptance Criteria (AC-1, AC-2, ...)
 - Small build steps as atomic 2-5 min checklist items (`- [ ]`, supporting `[TDD-Red]`, `[TDD-Green]`, `[TDD-Refactor]` triplets for functional logic)
@@ -178,7 +177,7 @@ code exists. Run the draft against these questions:
   test when a `test` command is declared in `AGENTS.md`, UI/integration rides on
   screenshot + build?
 
-Apply the fixes to `current-feature.md`. Then stop and present the spec, leading
+Apply the fixes to `devflow/context/{xxx-slug}/spec.md`. Then stop and present the spec, leading
 with a short **"what the critique changed"** note - the splits, gaps, or scope
 cuts you made (or "nothing - the draft held up"). That note is the point: it shows
 the gate working before a line of code is written.
@@ -201,8 +200,8 @@ Tell the user to review and adjust. This skill plans; it never starts building.
 ## When a (sub-)feature is done
 
 Check its box in `build-plan.md` (and the parent item once all its sub-items are
-checked), archive the finished `devflow/context/current-feature.md` to
-`devflow/history/features/NN-name.md`, then run `/feature` again for the next one.
+checked), archive the finished `devflow/context/{xxx-slug}/spec.md` to
+`devflow/history/features/{xxx-slug}.md`, delete the run workspace `devflow/context/{xxx-slug}/`, then run `/feature` again for the next one.
 
 ## Formatting
 

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

@@ -21,14 +21,14 @@ it creates a dedicated run folder at `devflow/context/{xxx-slug}/` (e.g. `059-fi
 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.
 
-The input may also be a finding ID from `devflow/context/findings.md`, alone
+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`.
 
 ## Step 1 - write the fix spec
 
 Pull context from `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`,
 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:
+then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize `stage.md` and `findings.md` in that folder. 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/.agents/skills/implement/SKILL.md

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

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

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

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

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

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

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