@jakkrichm/create-nexus-devflow 2.7.0 → 2.9.0

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

@@ -38,11 +38,11 @@ Common forms:
 - `resume`: continue the current feature on its existing branch.
 
 If the requested target conflicts with a feature already in progress, stop and
-ask which one should win. Do not overwrite `devflow/context/current-feature.md`
+ask which one should win. Do not overwrite task workspaces
 silently.
 
 Rollback is intentionally excluded from Autopilot. If the request is a rollback
-or `current-feature.md` is marked `Type: Rollback`, stop and direct the user to
+or active spec is marked `Type: Rollback`, stop and direct the user to
 the reviewed `/implement` path. Reversing completed work requires the explicit
 dependency and conflict gates in `/rollback` and `/implement`.
 
@@ -54,8 +54,8 @@ Read the same state `/status` reads:
 - `devflow/project-plan.md`
 - `devflow/build-plan.md`
 - `devflow/context/project-overview.md`
-- `devflow/context/current-feature.md`
-- `devflow/context/findings.md`
+- `devflow/context/{xxx-slug}/spec.md` (when present)
+- `devflow/context/{xxx-slug}/findings.md` (when present)
 - `devflow/context/coding-standards.md`
 - `devflow/context/ai-interaction.md`
 - git branch, status, and recent log
@@ -67,7 +67,7 @@ Stop before changing files when:
 - The repo is not a git repo.
 - The working tree is dirty and there is no current feature tying those changes
   to this run.
-- `current-feature.md` has real work and the user requested a different target.
+- Active task spec has real work and the user requested a different target.
 - `project-overview.md` is missing or stale and the planning docs are not clear
   enough to regenerate it.
 - The next feature is visual or replication-heavy and no design reference exists.
@@ -80,14 +80,14 @@ final packet.
 
 ## Step 2 - choose or write the spec
 
-If `devflow/context/current-feature.md` already contains an active spec,
+If `devflow/context/{xxx-slug}/spec.md` already contains an active spec,
 resume it. Read checked steps and continue from the first unchecked step.
 
 If there is no active spec:
 
 1. Use the `/feature` behavior for a planned feature, or `/fix` behavior for a
    requested fix.
-2. Write `devflow/context/current-feature.md`.
+2. Create workspace and write `devflow/context/{xxx-slug}/spec.md`.
 3. Red-team the spec before building:
    - missing unhappy paths
    - oversized steps
@@ -101,32 +101,22 @@ If there is no active spec:
 Autopilot may continue past this spec gate because the user explicitly invoked
 Autopilot. Still report what the critique changed in the final packet.
 
-## Step 3 - create or reuse the branch
+## Step 3 - branch
 
-Use the same branch rules as `/implement`:
+Create or check out the branch for the work:
 
-- Feature: `feature/<name>`
-- Fix: `fix/<name>`
+- `feature/{xxx-slug}` for a planned feature
+- `fix/{xxx-slug}` for an ad-hoc fix
 
-If the branch already exists, switch to it only if it matches the active spec.
-If switching branches would strand unrelated dirty work, stop and report the
-problem.
+If the branch already exists, check it out and verify it matches the spec.
 
-## Step 4 - implement in small steps
+## Step 4 - build in small steps with review gates
 
-Work through the spec's build steps in order. Each step must remain reviewable.
-Unlike `/implement`, do not pause for user approval after each passing step. The
-review happens at the final packet unless a hard stop is hit.
+Work through the spec's steps in order:
 
-For every step:
-
-1. Implement only that step.
-2. Run the relevant verification:
-   - the exact `Verify` command from `AGENTS.md`, when declared
-   - otherwise the build, relevant test, lint, and typecheck commands already
-     documented by the project
-   - browser, CLI, API, or app-level evidence for behavioral done-whens
-3. If UI is involved, inspect the running app when possible. Prefer Playwright if
+1. Keep each change small and focused on the current step.
+2. Run the declared `test` command when logic changed.
+3. If the step has visual or browser-visible behavior, drive the browser when
    it is already installed or declared. Capture screenshots when they add useful
    evidence. Check for console errors and failed requests.
 4. Self-review the diff for the step:
@@ -136,15 +126,15 @@ For every step:
    - did it follow `coding-standards.md`?
    - are tests present for new in-scope logic when the test gate is on?
 5. Fix obvious issues and rerun the failed checks.
-6. Mark the step checked in `current-feature.md` only after the step passes.
+6. Mark the step checked in `devflow/context/{xxx-slug}/spec.md` only after the step passes.
 7. Create a checkpoint commit on the feature or fix branch for the passing step.
-   Include the code, tests, and the updated `current-feature.md` checkbox. Use a
+   Include the code, tests, and the updated `spec.md` checkbox. Use a
    conventional message such as `feat: checkpoint mock snapshot route` or
    `fix: checkpoint stale service filter`. Keep the message about the step, not
    about Autopilot.
 
 Do not batch the whole feature into one large diff. If a step gets too large,
-split the step in `current-feature.md` and continue with the first smaller step.
+split the step in `devflow/context/{xxx-slug}/spec.md` and continue with the first smaller step.
 
 ## Step 5 - acceptance check
 
@@ -159,7 +149,7 @@ may be enough. Be explicit about the evidence used.
 After the acceptance check, apply the `/audit current` behavior to the active
 feature, its diff, and the nearby code affected by the change. This is a targeted
 feature audit, not a repository-wide cleanup pass. Findings are recorded in
-`devflow/context/findings.md` with durable IDs and statuses, as `/audit`
+`devflow/context/{xxx-slug}/findings.md` with durable IDs and statuses, as `/audit`
 defines; the ledger reports status and never scopes what the audit examines.
 
 For every finding:
@@ -173,35 +163,21 @@ For every finding:
 3. Report P2 and P3 findings in the final packet. Fix them only when the change
    is small, directly caused by the current feature, and clearly required by the
    project standards.
-4. If a confirmed P0 or P1 finding cannot be repaired safely within scope, stop
-   and report it. Do not present the feature as ready for `/complete`.
-
-After any audit repair:
-
-1. Rerun the documented `Verify` command when present; otherwise rerun the
-   affected build, lint, typecheck, and test commands.
-2. Rerun the acceptance evidence affected by the repair.
-3. Recheck the repaired area using the same targeted audit criteria. When that
-   recheck confirms the original defect is gone and the repair introduced no
-   new one, move the `fixed` finding to `closed` under the `/audit` close
-   conditions and name it in the packet. An unrelated new finding gets its own
-   ledger entry and does not keep the repaired one open.
-4. Create a checkpoint commit only after the repair and its checks pass.
+4. If a finding cannot be resolved safely in-scope, leave it `open` and describe
+   it in the final packet. A finding that is wrong goes back to `/audit` to
+   invalidate with recorded evidence; Autopilot never marks findings `invalid`
+   or `accepted`.
 
-Use the existing two-attempt hard stop for repeated repair failures. Do not widen
-the feature into a general refactor, silently suppress a finding, or turn this
-step into a full-project hardening pass. A broader cleanup remains a separate
-`/audit` followed by planned `/fix` work.
+Re-run the build, tests, and any affected checks after repairs. If a repair fails
+twice, stop and report the blocker.
 
-## Step 7 - final review packet
+## Step 7 - compile the review packet
 
-Stop with a concise review packet. Keep it useful enough for `/complete` but not
-a full audit report:
+Stop and produce a concise review packet:
 
-- branch name
 - target feature or fix
-- whether the spec was created or resumed
-- what the spec critique changed
+- branch name
+- what was built
 - changed files and why each changed
 - build/test/check commands run, with pass or fail
 - screenshots or output paths, when relevant
@@ -210,7 +186,7 @@ a full audit report:
 - self-review findings
 - targeted audit scope and findings
 - audit repairs made and checks rerun
-- P0/P1 findings still `open` or `fixed` in `devflow/context/findings.md`,
+- P0/P1 findings still `open` or `fixed` in `devflow/context/{xxx-slug}/findings.md`,
   which block `/complete`
 - unresolved risks or skipped checks
 - exact next action
@@ -240,11 +216,11 @@ Stop immediately and report instead of continuing when Autopilot would need to:
 - Autopilot creates checkpoint commits on the feature or fix branch after passing
   steps.
 - Autopilot audits the active feature and affected code, not the entire project.
-- A P0 or P1 finding left `open` or `fixed` in `devflow/context/findings.md`
+- A P0 or P1 finding left `open` or `fixed` in `devflow/context/{xxx-slug}/findings.md`
   blocks readiness for `/complete`. The ledger is what makes this enforceable.
 - Autopilot stops before `/complete`. It never merges.
 - The Blueprint files remain the state machine. Keep
-  `current-feature.md` accurate as steps complete.
+  `devflow/context/{xxx-slug}/spec.md` accurate as steps complete.
 - Follow `coding-standards.md`, `ai-interaction.md`, and `AGENTS.md`.
 - Prefer fewer, higher-quality changes over broad coverage.
 - Report uncertainty plainly. A blocked run is useful if it tells the truth.

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

@@ -82,7 +82,7 @@ plans aren't ready, `/prototype` if it's UI-facing and the look isn't locked, or
 ## Rules
 
 - **Read-only, always.** Never write a file, never edit `build-plan.md` or
-  `current-feature.md`, never branch, commit, install, or build. To act on the
+  specs in `devflow/context/`, never branch, commit, install, or build. To act on the
   briefing, the user runs `/feature` next.
 - **Explain, don't spec.** Size, dependencies, and a likely sub-split are the
   value here; the actual build steps are `/feature`'s job. Don't write step lists.

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

@@ -28,7 +28,7 @@ It changes no source and commits nothing — it executes, inspects, and reports
 
 ## Step 1 - Build the Dual-Axis Review Matrix
 
-Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/context/current-feature.md`) and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
+Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
 
 1. **Axis 1 (Standards & Architecture Criteria)**:
    - Coding conventions in `coding-standards.md`
@@ -36,7 +36,7 @@ Read the target spec from `devflow/context/{xxx-slug}/spec.md` (or `devflow/cont
    - Baseline 12 Fowler Code Smells (Primitive obsession, Feature envy, Shotgun surgery, Speculative generality, etc.)
    - Multi-lane technical gates (Typecheck, test suites, zero secrets, zero P0/P1 findings)
 2. **Axis 2 (Spec Fidelity & Behavioral Observables)**:
-   - Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `current-feature.md`
+   - Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `devflow/context/{xxx-slug}/spec.md`
    - Scope Creep detection (Unrequested behavior in the diff)
    - Missing Requirements detection (Unimplemented edge cases)
 
@@ -69,7 +69,7 @@ Format the report into two distinct, un-merged review axes:
   - [pass] Type Safety: `tsc --noEmit` (0 errors)
   - [pass] Automated Tests: `npm test` (All tests green)
   - [pass] Security & Hygiene: Zero secrets, sanitized inputs
-  - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/findings.md`
+  - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/{xxx-slug}/findings.md`
 - **Deep Modules & Architecture**:
   - [pass] Seam Integrity: Public interfaces remain small, implementation details hidden.
   - [pass] The Deletion Test: Complexity is concentrated inside the module, not scattered across callers.
@@ -78,7 +78,7 @@ Format the report into two distinct, un-merged review axes:
 
 ## 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
 
-Line-by-line verification against `current-feature.md`:
+Line-by-line verification against `devflow/context/{xxx-slug}/spec.md`:
 - [pass] **AC-1 (<title>)**: <Observed empirical evidence / screenshot path>
 - [pass] **AC-2 (<title>)**: <Observed empirical evidence / terminal output>
 - [fail] **AC-3 (<title>)**: <Exact observed failure with reproduction command>

package/template/.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

@@ -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/.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,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/.agents/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/.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
@@ -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/.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/`).