@jakkrichm/create-nexus-devflow 2.0.25 → 2.1.0

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

@@ -1,6 +1,6 @@
 ---
 name: autopilot
-description: "[Devflow] Optional explicit mode for one bounded spec/plan/implement/verify/report pass with checkpoint commits and review packet."
+description: "[Devflow] Optional explicit mode for one bounded Fast-Track or Deep-Track delivery pass with checkpoint commits and review packet."
 ---
 
 # autopilot - Autonomous Bounded DevFlow Loop
@@ -8,27 +8,31 @@ description: "[Devflow] Optional explicit mode for one bounded spec/plan/impleme
 Where this sits in the workflow:
 
 ```text
-devflow  ->  [autopilot]  ->  review packet  ->  70-release
-(where        (spec, plan,     (human review,     (package, PR,
- are we?)      build, verify,   walkthrough)       merge with approval)
-               report)
+devflow  ->  [autopilot]  ->  review packet  ->  /complete (fast) / 70-deliver (deep)
+(where        (fast or deep      (human review,        (package, PR,
+ are we?)      track loop)        walkthrough)           merge with approval)
 ```
 
-Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs a single bounded loop across the delivery lifecycle (**`20-spec` -> `30-plan` -> `40-execute` -> `50-verify` -> `60-report`**) without requiring human confirmation between every sub-step.
+Autopilot is an explicit opt-in execution skill for Nexus-DevFlow 2.0. It runs one bounded loop without requiring human confirmation between every sub-step, in either track:
 
-It does **not** replace the normal step-by-step workflow. Mainline commands (`20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`) remain the conservative default.
+- Fast-Track: `feature` / `fix` -> `implement` -> `check`.
+- Deep-Track: `20-spec` -> `30-plan` -> `40-execute` -> `50-verify` -> `60-report`.
+
+It does **not** replace the normal step-by-step workflow. Mainline commands (`feature`, `fix`, `implement`, `check`, `complete`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-deliver`) remain the conservative default.
 
 Do not suggest Autopilot as the default next action. Use it only when the user explicitly asks for it.
 
-The explicit Autopilot request is permission to create checkpoint commits on the feature or fix branch after passing implementation steps. It is **not** permission to merge into `main`, push to remote, deploy, publish, delete data, or run destructive actions.
+The explicit Autopilot request is permission to create checkpoint commits on the feature/fix branch after passing implementation steps. It is **not** permission to merge into `main`, push to remote, deploy, publish, delete data, or run destructive actions.
 
 ## Input
 
 Common forms:
 
 - **No argument**: resume the active run in `devflow/context/current-stage.md`, or target the next planned run/feature in `devflow/context/project-overview.md`.
-- **Running ID or feature name**: target that run, e.g. `autopilot RUN-004` or `autopilot "add user authentication"`.
-- **`fix "<issue>"`**: write and execute an ad-hoc fix run.
+- **`fast`**: force Fast-Track mode. Example: `autopilot fast "add auth header"`
+- **`deep`**: force Deep-Track mode. Example: `autopilot deep "data migration"`
+- **Running ID or feature name**: target that run, e.g. `autopilot RUN-004` or `autopilot "add user authentication"` (mode auto-selected from context).
+- **`fix "<issue>"`**: write and execute an ad-hoc fast-mode fix run.
 - **`resume`**: continue the current active run on its existing branch.
 
 If the requested target conflicts with a run already in progress, stop and ask which one should win. Do not overwrite active stage artifacts silently.
@@ -36,8 +40,6 @@ If the requested target conflicts with a run already in progress, stop and ask w
 > [!IMPORTANT]
 > Rollback is intentionally excluded from Autopilot. If the request is a rollback or the stage is marked Rollback, stop and direct the user to `rollback` and reviewed `40-execute`. Reversing completed work requires explicit dependency and human review gates.
 
----
-
 ## Step 1 - Preflight & Safety Check
 
 Read the project state:
@@ -45,11 +47,20 @@ Read the project state:
 - `AGENTS.md` & `CLAUDE.md`
 - `devflow/context/project-overview.md`
 - `devflow/context/current-stage.md`
+- `devflow/context/current-feature.md`
+- `devflow/context/current-run/` artifacts
 - `devflow/context/coding-standards.md`
 - `devflow/context/ai-interaction.md`
 - `devflow/context/findings.md`
 - git branch, status, and recent log
 
+Track mode selection:
+
+1. Use explicit `fast` or `deep` if provided.
+2. If `devflow/context/current-feature.md` is active and `current-run/` has no deep stage files, default to **fast**.
+3. If `devflow/context/current-run/` has deep stage files (`10-define.md`, `20-spec.md`, `30-plan.md`, etc.), default to **deep**.
+4. If both tracks are active, stop and ask which track should win.
+
 Stop before changing files when:
 
 1. The repo is not a git repository.
@@ -57,18 +68,24 @@ Stop before changing files when:
 3. `current-stage.md` has an active run and the user requested a different target without resolving conflict.
 4. The task requires architectural, financial, auth, billing, or destructive decisions not documented in the context.
 
----
+## Step 2 - Choose or Write Specification
 
-## Step 2 - Choose or Write Specification (`20-spec`)
+### Fast-Track
 
-1. If `devflow/runs/{running-id}-{slug}20-spec.md` already exists, resume it.
+1. If `devflow/context/current-feature.md` already exists and is active, resume it.
+2. If no spec exists:
+   - Write or refresh the spec in `devflow/context/current-feature.md`.
+   - Lock scope, acceptance criteria, and implementation checklist.
+   - Add feasibility checks and test hooks.
+3. Critique and red-team the spec (edge cases, unhappy paths, testable criteria), then apply fixes.
+
+### Deep-Track
+
+1. If `devflow/context/current-run/20-spec.md` already exists, resume it.
 2. If no spec exists:
    - Ensure `10-define.md` exists with locked scope and allocated Running ID.
    - Write `20-spec.md` following the DevFlow specification schema.
-   - Critique and red-team the spec (edge cases, unhappy paths, testable criteria).
-   - Apply fixes to the spec.
-
----
+   - Critique and red-team the spec (edge cases, unhappy paths, testable criteria), then apply fixes.
 
 ## Step 3 - Branch Setup & Implementation Plan (`30-plan`)
 
@@ -77,10 +94,8 @@ Stop before changing files when:
    - Fix: `fix/{slug}-{running-id}`
    - Switch to or create the working branch. Never run Autopilot directly on `main` or `master`.
 2. **Planning**:
-   - Write `devflow/runs/{running-id}-{slug}30-plan.md`.
-   - Seed `checklists/implementation-checklist.md` and `checklists/verification-checklist.md`.
-
----
+   - **Fast-Track**: maintain the implementation and verification checklist sections in `devflow/context/current-feature.md`.
+   - **Deep-Track**: write `devflow/context/current-run/30-plan.md` and seed `checklists/implementation-checklist.md` and `checklists/verification-checklist.md`.
 
 ## Step 4 - Implement in Small Increments (`40-execute`)
 
@@ -93,15 +108,19 @@ For every subtask:
 3. If UI is involved, inspect behavior, verify console errors and network calls.
 4. Self-review diff against `coding-standards.md`.
 5. Fix issues and rerun failed checks.
-6. Mark the task checked `[x]` in `checklists/implementation-checklist.md`.
+6. Mark the task checked `[x]`.
 7. **Create a Checkpoint Commit** on the feature/fix branch for the passing step:
    ```bash
-   git add <modified-files> devflow/runs/{running-id}-{slug}/checklists/implementation-checklist.md
+   # Fast-Track
+   git add <modified-files> devflow/context/current-feature.md
    git commit -m "feat({running-id}): checkpoint <concise step description>"
-   ```
-8. Write `devflow/runs/{running-id}-{slug}40-execute.md`.
 
----
+   # Deep-Track
+   git add <modified-files> devflow/context/current-run/{running-id}-{slug}/checklists/implementation-checklist.md
+   git commit -m "feat({running-id}): checkpoint <concise step description>"
+   ```
+8. **Fast-Track**: write implementation status to `devflow/context/current-feature.md`.
+9. **Deep-Track**: write `devflow/context/current-run/{running-id}-{slug}40-execute.md`.
 
 ## Step 5 - Senior QA Verification (`50-verify`)
 
@@ -110,10 +129,11 @@ For every subtask:
    - Static contracts (`npm run check:static` when applicable)
    - Project test suite (Unit tests, integration tests)
    - Build / Package smoke tests
-2. Update `checklists/verification-checklist.md` with concrete evidence.
-3. Write `devflow/runs/{running-id}-{slug}50-verify.md` with QA verdict (`PASS` / `FAIL`).
-
----
+2. Update verification evidence with concrete evidence in the active track artifact:
+   - **Fast-Track**: `devflow/context/current-feature.md`
+   - **Deep-Track**: `checklists/verification-checklist.md`
+3. **Deep-Track**: write `devflow/context/current-run/{running-id}-{slug}50-verify.md` with QA verdict (`PASS` / `FAIL`).
+4. **Fast-Track**: confirm check stage transition and verification state in `devflow/context/current-feature.md`.
 
 ## Step 6 - Targeted Quality Audit & Repair
 
@@ -125,16 +145,15 @@ Review diffs and inspect `devflow/context/findings.md`:
 4. Create a checkpoint commit for the fix.
 5. If a P0/P1 finding cannot be repaired within scope or fails twice consecutively, stop immediately and report.
 
----
-
-## Step 7 - Delivery Digest & Review Packet (`60-report`)
-
-1. Write `devflow/runs/{running-id}-{slug}60-report.md`.
-2. Render standalone HTML dashboard `devflow/runs/{running-id}-{slug}60-report.html` (via `md2html` or report generator).
-3. Update `devflow/context/current-stage.md` to indicate ready for `70-release`.
-4. Stop with a concise **Review Packet Dashboard** for human approval.
+## Step 7 - Review Packet & Track Handoff
 
----
+1. **Deep-Track**: write `devflow/context/current-run/{running-id}-{slug}60-report.md`, render standalone HTML dashboard `devflow/context/current-run/{running-id}-{slug}60-report.html` (via `md2html` or report generator), and set `devflow/context/current-stage.md` to ready for `70-deliver`.
+2. **Fast-Track**: keep final checkpoint and evidence in `devflow/context/current-feature.md`.
+3. Stop with a concise **Review Packet Dashboard** for human approval, including:
+   - Track used (`fast` or `deep`)
+   - Evidence summary
+   - Commit count
+   - Manual next action (`/complete` for fast, `/70-deliver` for deep)
 
 ## 🛑 Strict Hard Stops (Never Exceed)
 
@@ -147,29 +166,32 @@ Stop immediately and report to the user instead of continuing when Autopilot wou
 - Make product, business, or architecture decisions not specified in the context.
 - Continue after two failed attempts to fix the same issue (Two-attempt hard stop).
 
----
-
 ## Output Review Packet Format
 
 When Autopilot finishes successfully, output a scannable review packet:
 
 ```markdown
-### 🛸 Autopilot Execution Summary: [{running-id}]
+### 🛸 Autopilot Execution Summary: [{running-id}] ({track})
 
 - **Branch**: `{branch-name}`
 - **Target Run**: `{running-id} - {title}`
 - **Artifacts Generated**:
-  - Spec: `devflow/runs/{id}20-spec.md`
-  - Plan: `devflow/runs/{id}30-plan.md`
-  - Implement Evidence: `devflow/runs/{id}40-execute.md`
-  - QA Verify Report: `devflow/runs/{id}50-verify.md`
-  - Digest Report: `devflow/runs/{id}60-report.md`
-  - HTML Dashboard: `devflow/runs/{id}60-report.html`
-- **Validation & Tests**: `All Passed (Green)`
+  - **Fast-Track**:
+    - Spec/Build/Verify evidence: `devflow/context/current-feature.md`
+  - **Deep-Track**:
+    - Spec: `devflow/context/current-run/{id}20-spec.md`
+    - Plan: `devflow/context/current-run/{id}30-plan.md`
+    - Implement Evidence: `devflow/context/current-run/{id}40-execute.md`
+    - QA Verify Report: `devflow/context/current-run/{id}50-verify.md`
+    - Digest Report: `devflow/context/current-run/{id}60-report.md`
+    - HTML Dashboard: `devflow/context/current-run/{id}60-report.html`
+- **Validation & Tests**: track-aware PASS/FAIL evidence
 - **Checkpoint Commits**: `{count} commits created on {branch-name}`
 - **Manual QA Walkthrough**: Run `try {running-id}` for human review guide
 
 ---
 👉 **Next Recommended Action**:
-Inspect diffs and `try` walkthrough, then run `70-release {running-id}` to package, merge, or create PR.
+Inspect diffs and `try` walkthrough.
+- Fast-Track: run `/complete {running-id}` for final safety and merge flow.
+- Deep-Track: run `70-deliver {running-id}` to package, merge, or create PR.
 ```

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

@@ -1,77 +1,99 @@
 ---
 name: brief
-description: "[Devflow] Read-only scope, dependency, and risk pre-briefing before speccing a run."
+description: "[Devflow] Deep read-only scope, codebase impact, dependency, and sub-feature split briefing before speccing a run (reads build-plan.md or ideas.md)."
+argument-hint: "[feature-number | 'feature-name' | IDEA-xxx]"
 ---
 
-# brief - Scope, Dependency & Risk Pre-Check
+# brief - Deep Scope, Dependency & Codebase Impact Briefing
 
 Where this sits in the workflow:
 
 ```text
-10-define or project-overview.md  ->  [brief]  ->  20-spec  ->  30-plan  ->  40-execute
-(proposed scope & context)            (read-only   (write        (break down)  (build it)
-                                      explainer)    contract)
+devflow/build-plan.md (or ideas.md)  ──▶  [brief]  ──▶  feature / 20-spec  ──▶  implement / 40-execute
+(feature queue & context)                 (deep read-only  (write spec)          (build it)
+                                           explainer)
 ```
 
-This skill answers one essential question: ***"What does this upcoming feature or run actually involve before I commit to writing a full specification?"***
+This skill answers one essential question: ***"What does this upcoming feature actually touch and involve in the real codebase before I commit to writing a full specification?"***
 
-It inspects the relevant context files and provides a concise briefing so the team can decide whether to spec it now, split it into smaller runs, reorder priorities, or clear an architectural blocker first.
+It inspects `devflow/build-plan.md` (or `devflow/ideas.md` / `project-overview.md`) and conducts a **Deep Static Codebase Analysis** to provide a concise briefing — calculating files touched, dependency chains, estimated size (`XS`..`XL`), and actionable sub-feature split proposals before any work begins.
 
 It is **strictly read-only 100%**. It never writes specs, creates directories, branches, or commits code.
 
-## Input
+---
 
-- **no argument**: briefs the active run in `devflow/context/current-stage.md` (or the first planned feature in `devflow/context/project-overview.md`).
-- **running ID or feature name**: e.g. `brief RUN-003`, `brief "OAuth Login"`.
-- **topic / concern**: e.g. `brief "database migration"`.
+## Usage & Invocations
 
-If there is no active run and the overview does not list planned features, plainly report that context is needed and recommend `00-discover` or `10-define`.
+```text
+brief                     # Briefs the next unchecked feature in build-plan.md
+brief 2                   # Briefs feature #2 in build-plan.md
+brief "OAuth Login"       # Briefs a specific feature by name
+brief IDEA-003            # Briefs a pending idea from ideas.md
+```
 
-## Step 1 - Read Context (Read-Only)
+If there is no build plan or pending idea, plainly report that context is needed and recommend `/discovery` or `/overview`.
 
-Gather and synthesize:
+---
 
-1. **Active/Target Scope**: Target Running ID, `10-define.md`, or roadmap feature item.
-2. **Project Context**: `devflow/context/project-overview.md` (Data models, architecture layout, primary stack, existing shipped capabilities).
-3. **Existing Codebase State**: Inspect existing directory structures, schemas, and routes touching this feature.
-4. **Dependencies**: What previously completed runs (`devflow/runs/`) or modules must be in place first.
+## 3-Step Briefing Protocol
 
-## Step 2 - Analyze & Assess
+### Step 1 - Read Context & Target Resolution (Read-Only)
 
-Evaluate:
+1. **Target Item Resolution**:
+   - If argument provided (`2`, `"OAuth Login"`, `IDEA-003`): find matching item in `devflow/build-plan.md` or `devflow/ideas.md`.
+   - If no argument: locate the first unchecked item (`- [ ]`) in `devflow/build-plan.md`. If build plan is empty, locate the first pending item in `devflow/ideas.md`.
+2. **Project Architecture**: Read `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`.
+3. **Deep Codebase Inspection**:
+   - Inspect existing directory structures, routing files, data models/schemas, database migrations, API handlers, and UI component trees.
+   - Trace existing modules related to the target feature.
 
-- **What It Is**: Core capability and user-visible or system-visible outcome.
-- **Depends On**: Required upstream models, tables, APIs, environment variables, or sibling runs.
-- **Unblocks**: Downstream features or workflows that this run enables.
-- **Touches**: Files, modules, API routes, database tables, or UI components likely to change.
-- **Estimated Size**: Small (S), Medium (M), Large (L), or Extra-Large (XL - recommend splitting in `10-define`).
-- **Open Questions & Risks**: Ambiguous requirements, missing external APIs, or complex migrations.
+---
 
-## Step 3 - Output Structured Briefing
+### Step 2 - Analyze Scope, Dependencies & Sizing
 
-Produce a short, scannable briefing:
+Evaluate with concrete facts:
 
-```markdown
-### 📋 Feature Briefing: [Feature / Run Name]
+1. **What It Is**: Core capability and user-visible or system-visible outcome.
+2. **Dependencies & Prerequisites**: Upstream database models, authentication layers, environment variables, or sibling features that must be complete first.
+3. **Unblocks**: Downstream features or workflows enabled once this item ships.
+4. **Files & Modules Touched**: List predicted files and folders likely to be created or modified (e.g. `lib/`, `routes/`, `components/`, `test/`).
+5. **Estimated Size**:
+   - `XS`: Small tweak / config (~15-30 mins, 1-2 files)
+   - `S`: Single component or route (~1-2 hours, 2-4 files)
+   - `M`: Full CRUD feature or service integration (~half day, 4-7 files)
+   - `L`: Complex multi-component subsystem (~1 day, 7-12 files)
+   - `XL`: Major epic (>12 files or heavy cross-cutting concerns)
+6. **Sub-Feature Split Engine (for L and XL)**:
+   - If the feature is `L` or `XL`, draft a concrete 2-3 sub-feature breakdown (e.g. `4a: Backend Schema & Core APIs`, `4b: Frontend UI & Client State`) with individual sizing and sequential dependencies.
+7. **Key Risks & Open Questions**: Unsettled API contracts, performance bottlenecks, migration risks, or design decisions.
 
-- **What**: Brief summary of the core outcome.
-- **Depends On**: Prerequisite modules, runs, or infrastructure.
-- **Unblocks**: Downstream capabilities enabled by this feature.
-- **Touches**: Anticipated files, schemas, endpoints, and UI views.
-- **Estimated Scope & Size**: `[S / M / L / XL]` (and split recommendation if XL).
-- **Key Risks & Open Questions**: Technical or product unknowns that must be settled in `20-spec`.
+---
+
+### Step 3 - Output Structured Briefing Card
+
+Produce a clean, scannable briefing directly in the chat in **Thai (`th`)**:
+
+```markdown
+### 📋 Feature Briefing: [หมายเลขหรือรหัส - ชื่อฟีเจอร์]
+
+- **🎯 What**: [สรุปเป้าหมายและความสามารถหลักสั้นๆ]
+- **🔗 Dependencies**: [ฟีเจอร์หรือโมดูลก่อนหน้าที่ต้องมี หรือ 'None']
+- **🔓 Unlocks**: [ฟีเจอร์ถัดไปในแผนงานที่จะถูกปลดล็อก]
+- **📁 Files Touched**: [รายชื่อไฟล์และโมดูลที่คาดว่าจะต้องแก้ไขหรือสร้างใหม่]
+- **⚖️ Estimated Scope & Size**: `[XS | S | M | L | XL]`
+- **✂️ Sub-Feature Split Proposal** *(กรณีขนาด L หรือ XL)*:
+  - `[ID]a: [ขอบเขตย่อยส่วนที่ 1]` (Size: M, Dependencies: None)
+  - `[ID]b: [ขอบเขตย่อยส่วนที่ 2]` (Size: M, Dependencies: [ID]a)
+- **⚠️ Key Risks & Open Questions**: [ความเสี่ยงทางเทคนิคหรือคำถามที่ต้องตอบใน Spec]
 
 ---
-👉 **Next Recommended Action**: `20-spec {running-id}` (or resolve prerequisite blocker first).
+👉 **Next Recommended Action**: `/feature {target}` (หรือเริ่มทำ sub-feature แรก เช่น `/feature 4a`)
 ```
 
-## Rules
-
-- **Always Read-Only**: Never edit any workspace file, never allocate running IDs, never commit or execute scripts.
-- **Explain, Don't Spec**: Focus on scope, architectural dependencies, and size estimation. The formal delivery contract is the responsibility of `20-spec`.
-- **Ground In Reality**: Trace all assertions back to `project-overview.md` or actual codebase facts. Do not invent non-existent packages or fictional architecture.
-- **Highlight Blockers Early**: Flagging a missing prerequisite before speccing is the primary value of this command.
+---
 
-## Output Formatting
+## Strict Rules & Guardrails
 
-Follow the project conventions in `devflow/context/ai-interaction.md`: concise, scannable markdown with bold labels and actionable bullet points.
+1. **Always Read-Only**: Never edit workspace files, allocate running IDs, switch branches, or commit code during `/brief`.
+2. **Explain, Don't Spec**: Focus on scope, architectural dependencies, and size estimation. The formal delivery contract belongs to `/feature` or `20-spec`.
+3. **Ground In Reality**: Trace all assertions back to `project-overview.md` and active codebase inspection. Do not hallucinate non-existent files or packages.

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

@@ -75,4 +75,4 @@ jobs:
 
 - **Classification**: Companion command & Automated testing infrastructure
 - **Mainline integration**: Invoked via `/ci` during `onboard` or `adopt`.
-- **Handoff**: `50-verify`, `70-release`
+- **Handoff**: `50-verify`, `70-deliver`

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

@@ -91,7 +91,7 @@ When invoked:
 Update `devflow/context/current-stage.md`:
 - `Active Discovery ID`: `None`
 - `Active Running ID`: `None (Idle)`
-- `Current Stage`: `Idle (Ready for new /feature, /fix, or /00-discover)`
+- `Current Stage`: `Idle (Ready for new /feature, /fix, or /00-explore)`
 - `Living Spec`: `None`
 - `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
 - `Last Updated`: `{YYYY-MM-DD}`

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

@@ -64,7 +64,7 @@ Structure:
 
 - **Classification**: Companion command & Investigation lane
 - **Mainline integration**:
-  - During `00-discover`: Unclear failure intake before allocation
+  - During `00-explore`: Unclear failure intake before allocation
   - During `40-execute`: Hard test failure or unexpected runtime exception
   - During `50-verify`: Defect found during QA inspection
 - **Handoff**: `test` (write repro test), `40-execute` (execute fix), `50-verify` (re-check)

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

@@ -17,7 +17,7 @@ Use this skill to guide the user on what to do next, inspect current workspace s
 Nexus-DevFlow supports two seamless workflow tracks:
 1. **🏎️ Fast-Track (Blueprint Mode - 4 Steps)**: `/spec` ➔ `/implement` ➔ `/check` ➔ `/complete`  
    *Driven by a **Single Living Spec (`current-feature.md`)** for fast, high-velocity daily development and bugfixes (85% of tasks).*
-2. **🏗️ Deep-Track (Architect Mode - 8 Steps)**: `00-discover` ➔ `10-define` ➔ `20-spec` ➔ `30-plan` ➔ `40-execute` ➔ `50-verify` ➔ `60-report` ➔ `70-release`  
+2. **🏗️ Deep-Track (Architect Mode - 8 Steps)**: `00-explore` ➔ `10-define` ➔ `20-spec` ➔ `30-plan` ➔ `40-execute` ➔ `50-verify` ➔ `60-report` ➔ `70-deliver`  
    *Driven by modular separate stage files for large, high-stakes architectural epics and multi-agent coordination.*
 
 ---
@@ -37,7 +37,7 @@ When invoked without an argument (or when determining the next step), inspect:
      - If at `20-spec.md` -> Recommend `30-plan {RUNNING_ID}`.
      - If at `30-plan.md` -> Recommend `40-execute {RUNNING_ID}`.
      - If at `40-execute.md` with all tasks done -> Recommend `50-verify {RUNNING_ID}`.
-     - If passed `50-verify.md` -> Recommend `60-report {RUNNING_ID}` then `70-release {RUNNING_ID}`.
+     - If passed `50-verify.md` -> Recommend `60-report {RUNNING_ID}` then `70-deliver {RUNNING_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 `/spec IDEA-xxx`.
 5. **Audit Findings Ledger**: Check `devflow/context/findings.md` for open high-severity findings.
@@ -46,7 +46,7 @@ When invoked without an argument (or when determining the next step), inspect:
 - If no run is active and user wants to start a feature -> Recommend `/spec <name>` (or `/feature <name>`).
 - If no run is active and user wants to fix a bug -> Recommend `/fix <bug>`.
 - If no run is active and user has pending ideas in `devflow/ideas.md` -> Highlight `/spec IDEA-xxx`.
-- If no run is active and user wants deep architectural exploration -> Recommend `00-discover`.
+- If no run is active and user wants deep architectural exploration -> Recommend `00-explore`.
 - If user asks to check system health -> Recommend `doctor`.
 
 ---
@@ -65,13 +65,13 @@ When invoked without an argument (or when determining the next step), inspect:
 | "Setup DevFlow on fresh/new project" | `onboard` | `onboard` / `setup` | `onboard` -> `/spec` or `10-define` |
 | "Adopt DevFlow on existing codebase" | `adopt` | `adopt` / `bootstrap` | `adopt` -> `/spec` or `10-define` |
 | "Check setup health & diagnostics" | `doctor` | `doctor` / `health` | `doctor` |
-| "Explore a new request / deep idea" | `00-discover` | `discover` | **Deep-Track**: `00` -> `10` -> `20` -> ... |
+| "Explore a new request / deep idea" | `00-explore` | `discover` | **Deep-Track**: `00` -> `10` -> `20` -> ... |
 | "Define delivery boundaries and ID" | `10-define` | `define` | **Deep-Track**: `10` -> `20` -> `30` |
 | "Break down spec into plan (Deep)" | `30-plan` | `plan` | **Deep-Track**: `30` -> `40` -> `50` |
 | "Deep code implementation" | `40-execute` | `implement` | **Deep-Track**: `40` -> `50` |
 | "Deep QA verification" | `50-verify` | `verify` | **Deep-Track**: `50` -> `60` -> `70` |
 | "Deep markdown digest report" | `60-report` | `report` | **Deep-Track**: `60` -> `70` |
-| "Deep release packaging & merge" | `70-release` | `release` | **Deep-Track**: `70-release` |
+| "Deep release packaging & merge" | `70-deliver` | `release` | **Deep-Track**: `70-deliver` |
 | "Human manual QA walkthrough guide" | `try` | `try` | Companion (after implement or check) |
 | "Safely plan feature or run reversal" | `rollback` | `rollback` | Companion |
 | "Set up automatic GitHub Actions CI" | `ci` | `ci` | Companion |
@@ -91,14 +91,14 @@ When invoked without an argument (or when determining the next step), inspect:
 - `complete` (`/complete`, `$complete`) - Safety pass, release digest, git merge, close run
 
 ### 2. Deep-Track (Architect Mode - 8 Steps)
-- `00-discover` - Explore request and decide Proceed/Defer/Reject
+- `00-explore` - Explore request and decide Proceed/Defer/Reject
 - `10-define` - Lock delivery boundaries and allocate Running ID
 - `20-spec` - Formalize markdown delivery contract
 - `30-plan` - Breakdown spec into phased tasks with test decisions
 - `40-execute` - Incremental task implementation
 - `50-verify` - Senior QA review and multi-lane validation
 - `60-report` - Generate standardized markdown digest report
-- `70-release` - Release packaging, release notes, and merge
+- `70-deliver` - Release packaging, release notes, and merge
 
 ### 3. Public Companion Commands
 - `devflow` (`status`, `/devflow`) - Interactive guide, state inspector, and router

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

@@ -0,0 +1,145 @@
+---
+name: discovery
+description: "[Devflow] Deep multi-turn guided project discovery interview that develops detailed project-plan.md and build-plan.md files through an adaptive conversation, drafting only after user approval."
+argument-hint: "[optional product idea or context]"
+---
+
+# discovery - Guided Multi-Turn Project Discovery & Architecture Interview
+
+Where this sits in the workflow:
+
+```text
+[Product Idea / Concept]  ->  [discovery]  ->  devflow/project-plan.md  ->  /overview  ->  project-overview.md
+(rough thoughts from user)    (deep adaptive    devflow/build-plan.md      (distill)     (living source of truth)
+                               interview)      (user-owned plans)
+```
+
+`discovery` is an optional, high-depth conversational planning assistant. It guides the user through an adaptive, multi-turn interview to think through product vision, technical architecture, constraints, and phased delivery roadmap — drafting the two user-owned planning documents (`devflow/project-plan.md` and `devflow/build-plan.md`) only after explicit user review and approval.
+
+It is **never mandatory**: users who already have clear requirements can write both planning files directly or run `/overview` straight away.
+
+---
+
+## Usage & Invocations
+
+```text
+/discovery                          # Start interactive discovery interview
+/discovery "AI-powered CRM for SMB" # Start discovery seeded with an initial product concept
+$discovery                          # Codex CLI invocation
+```
+
+---
+
+## The Adaptive Interview Protocol
+
+Run discovery as an **engaging pair-programming conversation**:
+- 🚫 **Do NOT dump 10-20 questions at once.**
+- ✅ **Ask 1-2 focused questions at a time.**
+- ✅ **Adapt follow-up questions based on previous answers.**
+- ✅ **Offer proactive suggestions, sensible defaults, and architectural trade-offs.**
+
+---
+
+### Step 1 - Check Existing Planning State
+
+1. Inspect `devflow/project-plan.md` and `devflow/build-plan.md` (or `blueprint/` equivalents).
+2. If detailed plans already exist:
+   - Ask the user whether they want to **deepen/refine** the existing plan or **start fresh**.
+   - Never overwrite existing user-authored content without confirmation.
+
+---
+
+### Step 2 - Conduct Multi-Turn Discovery Interview
+
+Guide the user through 4 core discovery pillars:
+
+#### Pillar 1: Product Vision & User Persona
+- **Problem Statement**: What core problem does this application solve?
+- **Target Audience**: Who is the primary user persona?
+- **Core Value & Success Metric**: What is the single most important workflow that delivers value?
+
+#### Pillar 2: Technical Architecture & Stack
+- **Frontend & UI**: Framework (Next.js, Vite, React, Svelte, Vue), Styling (Tailwind, CSS Modules, Vanilla CSS).
+- **Backend & APIs**: REST, GraphQL, tRPC, Server Actions, Node.js, Go, Python.
+- **Data Layer**: Database (PostgreSQL, SQLite, MongoDB), ORM/Query Builder (Prisma, Drizzle, Kysely), Migrations.
+- **Authentication & Security**: Auth provider (NextAuth, Supabase Auth, Clerk, JWT, Session cookies).
+- **Integrations & Third-party Services**: Payments (Stripe), Emails (Resend), Cloud storage (S3/R2).
+
+#### Pillar 3: Constraints & Non-Goals (Scope Boundaries)
+- **Non-Goals (Out of Scope)**: What features are explicitly postponed for later phases?
+- **Technical & Operational Constraints**: Budget, latency targets, deployment platform (Vercel, Render, AWS, VPS).
+
+#### Pillar 4: Phased Roadmap & Feature Sizing
+- Break down the delivery into sequential phases:
+  - **Phase 1: MVP Baseline** (Core database models, auth, primary happy path)
+  - **Phase 2: Core Experience** (Main features, workflows, dashboard, notifications)
+  - **Phase 3: Polish & Scale** (Edge cases, performance optimizations, exports, settings)
+- Assign a **Size** to every feature:
+  - `XS`: Small tweak / config (~10-30 mins)
+  - `S`: Single component or route (~1-2 hours)
+  - `M`: Full CRUD feature or API integration (~ครึ่งวัน)
+  - `L`: Complex multi-component subsystem (1 วัน)
+  - `XL`: Major epic (ควรแบ่งย่อยเป็น L หรือ M)
+- Define **Dependencies** for sequential execution.
+
+---
+
+### Step 3 - Draft Plan Preview & Confirmation Gate
+
+Once all pillars are sufficiently explored:
+
+1. Synthesize the findings into Markdown drafts for both files.
+2. Present the draft summary directly in the chat to the user in **Thai (`th`)**:
+   - High-level Architectural Summary
+   - Proposed Feature List by Phase with Sizing and Dependencies
+3. **STOP and ask for user confirmation**:
+   > *"นี่คือร่างแผนงาน Project Plan และ Build Plan ทั้งหมด คุณต้องการปรับแก้ส่วนไหนเพิ่มเติม หรือยืนยันให้บันทึกลงไฟล์เลยครับ?"*
+
+---
+
+### Step 4 - Write User-Owned Planning Documents
+
+Upon user approval, write to:
+
+1. **`devflow/project-plan.md`**:
+   ```markdown
+   # 🗺️ Project Plan (User-Owned Architectural Vision)
+
+   ## 1. Product Vision & Problem Statement
+   ...
+
+   ## 2. Target Users & Core Personas
+   ...
+
+   ## 3. Technical Architecture & Tech Stack
+   ...
+
+   ## 4. Key Constraints & Non-Goals
+   ...
+   ```
+
+2. **`devflow/build-plan.md`**:
+   ```markdown
+   # 🏗️ Build Plan (Phased Sequential Feature Queue)
+
+   ## Phase 1: MVP Baseline
+   - [ ] 1. Project Initialization & Base Tooling (Size: S)
+   - [ ] 2. Database Schema & Auth Setup (Size: M, Depends on: 1)
+
+   ## Phase 2: Core Workflows
+   - [ ] 3. Main Dashboard & Data Grid (Size: M, Depends on: 2)
+   ```
+
+---
+
+### Step 5 - Handoff to `/overview`
+
+After writing the planning files, prompt the user with the next recommended action:
+
+```markdown
+✅ **บันทึกแผนงานลง `devflow/project-plan.md` และ `devflow/build-plan.md` เรียบร้อยแล้ว!**
+
+👉 **ขั้นตอนถัดไป**: เรียกคำสั่ง:
+`/overview`
+เพื่อกลั่นกรองแผนงานทั้งหมดลงสู่ `devflow/context/project-overview.md` ซึ่งจะเป็น Living Source of Truth สำหรับ AI Agent ในทุกๆ Session ครับ
+```

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

@@ -36,7 +36,7 @@ Run through these 5 health checks:
   - `findings.md` (Check if ledger exists)
 
 ### Check 2: Tool Adapters Parity
-- Check if `.agents/skills/` exists and contains core lifecycle skills (`00-discover` through `70-release`, `devflow`, `onboard`, `adopt`, `doctor`).
+- Check if `.agents/skills/` exists and contains core lifecycle skills (`00-explore` through `70-deliver`, `devflow`, `onboard`, `adopt`, `doctor`).
 - Check if `.claude/skills/` is in sync with `.agents/skills/`.
 
 ### Check 3: Commands & Script Verification