@jakkrichm/create-nexus-devflow 2.7.0 → 2.9.0

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

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

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

@@ -1,6 +1,6 @@
 ---
 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, Single Living Spec (current-feature.md), branch isolation, TDD verification, quality gates, and local squash-merges into main. Use when running /continuous, $continuous, or executing Continuous Mode."
+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}]"
 ---
 
@@ -15,7 +15,7 @@ Where this sits in the workflow:
                Gates ➔ Merge)
 ```
 
-`/continuous` (หรือ `$continuous`) คือโหมดการทำงานแบบ Autonomous Multi-Feature Delivery Loop สำหรับจัดส่งฟีเจอร์ที่อยู่ใน `devflow/build-plan.md` ต่อเนื่องทีละฟีเจอร์ในเครื่อง Local โดยไม่ต้องหยุดรอ Manual Review Prompts ในแต่ละขั้นตอนย่อย แต่ยังคงรักษาความเข้มงวดของ **The 3-Pillars Model & Single Living Spec (`current-feature.md`)**, การทำ TDD, การตรวจ Quality Gates, การบันทึก Findings Ledger, และการ Squash-merge ลง Local Main Commit ทีละฟีเจอร์อย่างปลอดภัย 100%
+`/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
@@ -36,7 +36,7 @@ Where this sits in the workflow:
 ## Input & Target Selection
 
 - **ไม่ระบุ Argument (`/continuous`)**:
-  1. หากมีฟีเจอร์ค้างอยู่ใน `devflow/context/current-feature.md` ให้ทำต่อจากขั้นตอนย่อยแรกที่ยังไม่ได้เช็ค (`- [ ]`)
+  1. หากมีฟีเจอร์ค้างอยู่ใน `devflow/context/{xxx-slug}/` ให้ทำต่อจากขั้นตอนย่อยแรกที่ยังไม่ได้เช็ค (`- [ ]`)
   2. หากไม่มี ให้เลือกฟีเจอร์แรกที่ยังไม่ได้เช็ค (`- [ ]`) ใน `devflow/build-plan.md`
   3. วนลูปทำต่อเนื่องตามลำดับใน `build-plan.md` จนกว่าจะหมด หรือครบตามจำนวน `continuous.maxFeatures` ใน `devflow/config.json`
 - **ระบุ `resume` (`/continuous resume`)**: ทำงานต่อจากฟีเจอร์และขั้นตอนย่อยที่ค้างอยู่ทันที
@@ -51,8 +51,7 @@ Where this sits in the workflow:
 - `devflow/config.json` (หากไม่มี ให้ใช้ค่า Defaults อย่างปลอดภัย; หาก Invalid ให้หยุดและชี้ไปที่ `/doctor`)
 - `devflow/project-plan.md` และ `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/current-feature.md` และ `devflow/context/current-stage.md`
-- `devflow/context/findings.md`
+- `devflow/context/{xxx-slug}/` (ถ้ามีงานค้างอยู่)
 - `devflow/context/coding-standards.md` และ `devflow/context/ai-interaction.md`
 - สถานะ Git (`git status`, `git branch`, recent log)
 
@@ -69,11 +68,11 @@ Where this sits in the workflow:
 ดำเนินงานวนลูปทีละ 1 ฟีเจอร์ตามลำดับ:
 
 ### 2.1 Select & Spec (เลือกและร่างสเปก)
-- หาก Resuming: ใช้ Spec เดิมใน `current-feature.md`
-- หากเป็นฟีเจอร์ใหม่: ถอดความต้องการจาก `build-plan.md` และสร้าง Single Living Spec ลงใน `devflow/context/current-feature.md` พร้อมวิเคราะห์ Red-team ก่อนเริ่มโค้ด
+- หาก 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/060-slug`) จาก Default Branch
+- สร้าง Branch ตาม Prefix ใน Config (เช่น `feature/061-slug`) จาก Default Branch
 
 ### 2.3 Implement Small Steps with Strict TDD
 - ดำเนินการสร้างฟังก์ชันทีละ Task ตาม Checklist ใน Spec:
@@ -96,7 +95,7 @@ Where this sits in the workflow:
 - รัน Verification ขั้นสุดท้าย
 - ย้ายและ Archive เอกสารไปที่ `devflow/history/features/{xxx-slug}.md`
 - อัปเดตเช็คบ็อกซ์ใน `devflow/build-plan.md`
-- รีเซ็ต `devflow/context/current-feature.md` กลับสู่ Stub
+- ลบโฟลเดอร์รัน `devflow/context/{xxx-slug}/`
 - Squash-merge Feature Branch เข้าสู่ Local Main และลบ Feature Branch ใน Local
 - นับจำนวนฟีเจอร์ที่สำเร็จเพิ่มขึ้น 1
 

package/template/.claude/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,8 @@ 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 |
+| **"Create editorial diagram / flowchart"**| `diagram-design`| `/diagram-design` | **Third-Party**: 39 visual diagrams (HTML/SVG) |
 | "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 +73,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
@@ -94,4 +95,8 @@ When invoked without an argument (or when determining the next step), inspect:
 - `report-html` - Standalone interactive HTML report dashboard
 - `debug` - Root-cause investigation without editing code
 - `rollback` - Safe reversal of completed features
-- `release` - Deployment readiness check
+- `release` - Deployment readiness check
+
+### 4. Installed Third-Party Skills & Extensions
+- `diagram-design` (`/diagram-design`) - 39 editorial visual diagram types (HTML/SVG) for system architecture, sequence flows, ER models, data platform pipelines, and journeys.
+- *Use `nexus-devflow skill add <url>` to install more third-party skills.*

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

@@ -57,7 +57,7 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
 ```
 *(A Discovery ID uses the namespace `DISC-YYYYMMDD-NNN`. It is not a Running ID and does not reserve a numeric delivery run.)*
 
-### 5 Supporting Routes & Built-in Lenses:
+### 6 Supporting Routes & Built-in Lenses:
 
 1. **Brainstorming Lens (Divergent & Convergent)**:
    - Formulate 2-3 viable options with trade-offs.
@@ -72,11 +72,16 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
 5. **Socratic Grilling & Domain Alignment Lens (`grill`)**:
    - Codebase-grounded interactive inquiry to clarify entity boundaries, data flows, and edge cases.
    - Record agreed terminology in `devflow/context/glossary.md` and major architecture decisions in `devflow/decisions/ADR-xxx-{slug}.md`.
+6. **🎨 Visual Architecture & Diagram Design Lens (`diagram-design`)**:
+   - When exploring system topologies, legacy IT modernizations, sequence flows, data platform pipelines, or user journeys, check if the third-party skill `diagram-design` is installed in `.agents/skills/diagram-design/`.
+   - If available: Read `.agents/skills/diagram-design/SKILL.md` and load the matching type reference (e.g. `references/type-architecture.md`, `references/type-data-flow.md`, `references/type-sequence.md`, `references/type-journey.md`).
+   - Strictly follow the genuine design rules: editorial palette, style guide gate, target density 4/10, and self-contained HTML/SVG output.
+   - Save diagram artifacts to `devflow/discoveries/{DISCOVERY_ID}-{slug}/diagrams/{name}.html` and reference them directly in `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 +90,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/.claude/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
@@ -129,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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/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/.claude/skills/rollback/SKILL.md

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

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

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

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

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