@jakkrichm/create-nexus-devflow 2.0.25 → 2.1.0

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

@@ -1,105 +1,160 @@
 ---
 name: complete
-description: "[Devflow] Fast-Track Complete stage in DevFlow (Blueprint Mode) - final safety pass, archive living spec into categorized history, reset stub, git merge, and close run."
-argument-hint: "{running-id or workspace path}"
+description: "[devflow][F] Wrap up a finished feature, fix, or rollback. Runs a final safety pass, archives its spec to devflow/history/features/, devflow/history/fixes/, or devflow/history/rollbacks/, updates the build plan for features and rollbacks, resets devflow/context/current-feature.md to its stub, makes one work-level commit, then squash-merges the branch to main and deletes it. Merges only with explicit approval, then asks separately before pushing main. Use when the user runs /complete, or asks to finish, wrap up, merge, or close out the current feature, fix, or rollback after it is built and reviewed."
 ---
 
-# Fast-Track: Complete (Blueprint Mode)
-
-$ARGUMENTS
-
-Final delivery, safety pass, archive, and run closure stage in Fast-Track. Validates verification status, archives `devflow/context/current-feature.md` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`, resets the stub, updates changelog, performs conventional commit & git merge, and closes the run **without auto-generating HTML reports**.
-
-## Invocations & Aliases
-
-- `/complete`: Complete current active run
-- `/complete {id}`: Complete specified ID
-- `$complete`: Codex CLI invocation
-
-## Fast-Track Mainline Workflow
-
-```text
-/feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
-```
-
-## Behavior & Contract
-
-When invoked:
-
-### 1. Validate Delivery Pre-conditions
-1. Identify active Running ID from `devflow/context/current-stage.md` or `devflow/context/current-feature.md`.
-2. Read `devflow/context/current-feature.md`.
-3. Confirm:
-   - File contains an active spec (not the idle stub `_Nothing in progress._`).
-   - All checklist items in `## 3. Implementation Checklist` are marked `- [x]`.
-   - `## 5. Verification Evidence` contains passing verification results and empirical command outputs.
-
-### 2. Final Safety Pass & Findings Check
-1. Verify working directory hygiene (no accidental leftover test files or debug statements).
-2. Inspect `devflow/context/findings.md`:
-   - No `P0` or `P1` finding is in `open` or `fixed` status (`fixed` requires re-audit).
-   - Only `closed`, `accepted` (user waived), or `invalid` findings are permitted for completion.
-
-### 3. Update Living Spec & Archive to Categorized History
-1. Append `## 6. Release & Handoff` in `current-feature.md` in **Thai (`th`)**:
-   ```markdown
-   ## 6. Release & Handoff
-   - **Release Digest**: สรุปสิ่งที่ส่งมอบในรอบนี้
-   - **Git Branch**: `{branch_name}`
-   - **Merge Status**: Merged into `main` (Commit `{commit_hash}`)
-   - **Archive Date**: {YYYY-MM-DD}
-   ```
-2. Determine Category:
-   - If spec has `Category: Fix` or `Type: Fix` ➔ `fixes`
-   - If spec has `Category: Rollback` or `Type: Rollback` ➔ `rollbacks`
-   - Otherwise ➔ `features`
-3. Archive `devflow/context/current-feature.md` ➔ `devflow/history/{category}/{xxx-slug}.md`.
-4. If `findings.md` contains resolved entries (`closed`, `accepted`, `invalid`), append a `## Resolved Findings` section to the archive file and clean those resolved entries from `findings.md`.
-5. **Reset Living Spec Stub**: Reset `devflow/context/current-feature.md` to:
-   ```markdown
-   # Current Feature
-
-   _Nothing in progress. Run /feature, /fix, or /rollback to start._
-   ```
-
-### 4. Update Master Ledger (`HISTORY.md`) & CHANGELOG.md
-1. Append a new row to `devflow/history/HISTORY.md` under `## 📜 Master Release Log`:
-   ```markdown
-   | {YYYY-MM-DD} | `{ID}` | {Category} | {Title} | `{commit_hash}` | `Released` | [`{xxx-slug}.md`]({category}/{xxx-slug}.md) |
-   ```
-2. **Keep a Changelog & SemVer**:
-   - If `CHANGELOG.md` exists, append a new version block following SemVer principles:
-     - `Major (+1.0.0)`: Breaking architectural changes or API removal
-     - `Minor (0.+1.0)`: New user-facing feature additions (`Added`)
-     - `Patch (0.0.+1)`: Bug fixes (`Fixed`), documentation (`Docs`), or tweaks (`Changed`)
-
-### 5. Policy on HTML Reports (Strict Rule)
-> [!IMPORTANT]
-> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `report.html` หรือ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้โดยเด็ดขาด!
-> หากผู้ใช้ต้องการดู HTML Dashboard สวยงาม ให้แจ้งผู้ใช้ว่าสามารถเรียกคำสั่งแยกได้: `/report:html`
-
-### 6. Conventional Commits, Git Merge & Branch Cleanup
-1. **Conventional Commits Format**:
-   - Stage relevant files explicitly.
-   - Use imperative mood: `<type>(<scope>): <short imperative summary>` (e.g. `feat(auth): add password reset flow`, `fix(cli): handle missing config gracefully`).
-   - Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`.
-2. **Squash-Merge**:
-   - Squash-merge feature branch into target base branch (`main` / `master`) with explicit user approval.
-   - Clean up short-lived feature branch.
-
-### 7. Close Active Run
-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)`
-- `Living Spec`: `None`
-- `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
-- `Last Updated`: `{YYYY-MM-DD}`
-
-### 8. Output Completion Report & PR Template
-Report to the user:
-- Run successfully completed and merged
-- Archived path: `devflow/history/{category}/{xxx-slug}.md`
-- Standalone HTML command tip: `/report:html` (if HTML view is desired)
-- Pull Request summary block (if PR creation is needed)
-- Workspace is now Idle and ready for the next task.
+# complete - log the finished work, make the work commit, and merge
+
+Where this sits in the workflow:
+
+    /feature, /fix, or /rollback  ->  /implement  ->  [complete]  ->  next
+    (the spec)                         (build it)      (commit + merge + log)
+
+`/implement` built the feature, fix, or rollback on its branch, with optional per-step commit
+checkpoints. This skill closes it out: it logs the work, makes the single
+work-level commit, and squash-merges. Run it only when the work is done,
+reviewed, and the documented `Verify` command, or the fallback build and tests,
+passes.
+
+## Before you start
+
+Confirm the work is actually finished: `devflow/context/current-feature.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
+running app first - don't merge on an unverified claim. Uncommitted step work is
+expected (per-step checkpoints are optional); this skill commits it. Don't require
+the steps to be pre-committed.
+
+## Step 0 - final safety pass
+
+Before logging or committing, run a short safety pass and report blockers only:
+
+- active spec exists and the work is not being completed 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)
+- 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
+- behavioral done-whens have `/check` evidence or equivalent proof, and there is
+  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`.
+  `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
+  them) or `invalid` (an `/audit` re-examination verdict with recorded
+  evidence, or the user's explicit call). A missing ledger file means no
+  findings.
+
+Do not claim "passed", "verified", or "working" without naming the command,
+route, screenshot, or output that proves it. Stop before Step 1 if required
+evidence is missing.
+
+## Step 1 - log the work
+
+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
+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.
+
+**Discard consumed prototypes.** If this feature built the look from `prototypes/`
+- its Design reference pointed there and an early step ported `prototypes/theme.css`
+into the app - delete the `prototypes/` folder now. The tokens live in the real
+stylesheet and the HTML mockups were always throwaway; fold the deletion into this
+feature's commit. Skip this if the feature didn't consume prototypes.
+
+## Step 2 - make the work commit
+
+Stage everything on the branch (any uncommitted step work plus the Step 1 logging
+changes) and make one conventional work commit (for example `feat: <feature>`,
+`fix: <name>`, or `revert: roll back <feature>`). `Verify`, or the fallback build
+and tests, must pass first.
+
+## Step 3 - merge
+
+1. Squash-merge the branch into main, only with the user's explicit go-ahead, so
+   the feature lands as one clean commit regardless of how many checkpoints the
+   branch carried.
+2. Delete the branch after a clean merge.
+3. Stop and ask whether to push local `main` to its upstream. The merge approval
+   does not count as push approval.
+4. Push main only after a separate explicit yes to push main in the current chat.
+   If the repo has no remote or upstream, say so instead of guessing.
+
+Then point the user at `/feature`, `/fix`, or `/rollback` for the next thing.
+
+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.
+
+## Rules
+
+- The work item is the unit of history: one squashed feature, fix, or rollback
+  commit on main, even if the branch carried several checkpoint commits.
+- A rollback preserves the original feature archive and adds a separate rollback
+  archive. Never rewrite history to make the feature look as if it never existed.
+- Don't merge unfinished or failing work. The documented `Verify` command, or
+  the fallback build and tests, must pass first.
+- Never merge while a P0 or P1 finding is `open` or `fixed` in the ledger. The
+  recorded ways past the gate without code are `accepted` (only by the user's
+  explicit decision, with their reason) or `invalid` (only from re-examination
+  evidence or the user's explicit call); both travel into the archive, never a
+  silent drop.
+- Merging and pushing are the user's calls: get an explicit yes for the merge,
+  then ask whether to push main. Do not treat merge approval, `/complete`, or
+  "looks good" as permission to push.
+- Push main only after a separate explicit yes to push main in the current chat.
+- One item per completion. If a parent feature still has unchecked sub-features,
+  leave the parent unchecked.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

package/template/.agents/skills/convert-any-to-md/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: convert-any-to-md
-description: '[Devflow] Converts any document (.xlsx, .pdf, .docx, .txt, .csv, .log, .json, .yaml, etc.) or mixed folders into clean Markdown in devflow/reference. Use whenever documents need to be analyzed, summarized, searched, or extracted from.'
+description: "[devflow][B] Converts any document (.xlsx, .pdf, .docx, .txt, .csv, .log, .json, .yaml, etc.) or mixed folders into clean Markdown in devflow/reference. Use whenever documents need to be analyzed, summarized, searched, or extracted from."
 ---
 
 # Convert Any Document to Markdown
@@ -77,4 +77,4 @@ python .agents/skills/convert-any-to-md/scripts/convert_any_to_md.py "C:\path\to
 | `.txt`, `.csv`, `.json`, `.yaml`, `.log` | Plaintext Formatter | N/A | `<name>/<name>.md` |
 
 > [!NOTE]
-> Legacy binary formats (`.xls`, `.doc`) are not supported directly. Ask the user to re-save them as `.xlsx` / `.docx` first.
+> Legacy binary formats (`.xls`, `.doc`) are not supported directly. Ask the user to re-save them as `.xlsx` / `.docx` first.

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

@@ -1,70 +1,145 @@
 ---
 name: debug
-description: "[Devflow] Root cause investigation and diagnostic loop before or during implementation without editing code. Use when encountering broken behavior, test failures, or bugs."
+description: "[devflow][B] Diagnose a failing test, broken build, crash, error, regression, or unexpected behavior without editing source or Blueprint state. Reproduces the symptom with the smallest safe command, localizes the failing path, tests competing hypotheses, identifies the root cause when evidence supports one, and reports a repair handoff to /fix or /implement. Use when the user runs /debug, invokes $debug, asks why something is failing or broken, wants a root-cause investigation, or asks to diagnose before fixing."
 ---
 
-# Debug & Root Cause Analysis (RCA)
+# debug - find the cause before changing the code
 
-## Overview
+Where this sits in the workflow:
 
-This is the comprehensive debugging master skill for Nexus-DevFlow. It guides systematic root-cause investigation without blindly editing code. The goal is to find the actual origin of an issue, not merely suppress visible symptoms.
+    reported failure  ->  [debug]  ->  /fix or /implement
+    (test, build,          (reproduce,    (spec a new fix, or
+     crash, behavior)       isolate,       repair active work)
+                            explain)
 
-**The Debug Mantra (9arm Pattern)**:
-```text
-Reproduce ➔ Trace Fail Path ➔ Falsify Hypotheses ➔ Cross-reference Breadcrumbs ➔ RCA Proof
-```
+`/debug` separates diagnosis from repair. It gathers evidence, narrows the
+failure to a specific cause when possible, and stops with a useful handoff. It
+does not make the code "temporarily work" while investigating.
 
----
+## Input
 
-## 1. The 4-Phase Diagnostic Loop
+Accept a symptom, failing command, error message, or unexpected behavior. Examples:
 
-### Phase 1: Reproduce & Classify
-- Restate the observed symptom vs. expected behavior with exact steps.
-- Create a minimal reproduction script, test case, or curl command.
-- Rule: **Do not propose a code fix before the reproduction story is verified.**
+    /debug npm test fails in cart-total.test.js
+    /debug the upload route returns 500 for PNG files
+    /debug why does the production build fail?
 
-### Phase 2: Isolate & Hypothesize
-- Generate 2–4 distinct hypotheses ranked by probability.
-- Formulate specific criteria and evidence that would *falsify* each hypothesis.
+With no useful symptom, ask for the expected behavior, actual behavior, and
+smallest known reproduction. Do not guess which problem the user means.
 
-### Phase 3: Non-Destructive Investigation
-- Trace code execution paths end-to-end (stack traces, logs, variable states, async boundaries).
-- Inspect recent commits or configuration changes that touch the affected boundary.
-- Test hypotheses methodically using tests and logging without altering business logic.
+## Step 1 - establish the boundary
 
-### Phase 4: Root Cause Conclusion (RCA)
-- State precisely *why* the bug occurred (underlying invariant violation).
-- Define the minimal, robust architectural fix direction.
-- Propose regression prevention measures (unit test, type guard, linter rule).
+Read the project instructions and the context relevant to the failure:
 
----
+- `AGENTS.md` and its real commands
+- `devflow/context/project-overview.md`
+- `devflow/context/coding-standards.md`
+- `devflow/context/current-feature.md`
+- the reported error, failing output, and affected files
+- git status, diff, and recent log when a regression is possible
 
-## 2. Output Format (RCA Report)
+State the symptom and what would count as reproducing it. Note whether the
+failure belongs to an active feature or is an unplanned bug.
 
-Save substantial RCA investigations under:
-```text
-devflow/debug/rca-{slug}.md
-```
+Do not treat a dirty working tree as permission to discard or rewrite anything.
+Use the diff as evidence and preserve it.
 
-Structure:
-```markdown
-## Debug Summary
+## Step 2 - reproduce safely
 
-1. **Symptom**: [What is happening vs expected]
-2. **Evidence**: [Error logs, stack trace, file:line references]
-3. **Investigation Path**: [Hypotheses tested and falsification proof]
-4. **Root Cause**: [The exact mechanism causing the failure]
-5. **Fix Direction**: [Recommended scoped change]
-6. **Regression Guard**: [Reproduction test to add before fixing]
-```
+Run the smallest existing command or interaction that can reproduce the symptom.
 
----
+- Prefer one focused test, request, CLI command, or input over the entire suite.
+- Capture the exact exit code, error, stack trace, output, response, console
+  error, or failed request.
+- Reuse an already-running local app when available. If reproduction requires a
+  long-running server that is not running, ask the user to start it and provide
+  the documented command.
+- Do not install dependencies, change configuration, run migrations, mutate
+  production data, contact external users, or use destructive commands to force
+  a reproduction.
+- Do not edit code to add logs or probes. Use existing logs, debuggers,
+  read-only inspection, or one-off commands that do not change project files.
+- Compare git status after diagnostic commands. If one changes tracked or
+  untracked project files, stop and report those paths. Do not clean, restore,
+  or hide the changes.
+
+If the symptom cannot be reproduced, say what was attempted and what evidence is
+missing. Continue with static investigation only when it can produce a clearly
+labeled hypothesis, not a claimed root cause.
+
+## Step 3 - localize the failure
+
+Trace from the observed failure toward the smallest responsible area.
+
+Use the evidence that fits the project:
+
+- the first relevant application frame in a stack trace
+- the smallest failing test and its inputs
+- request and response data at the failing boundary
+- console and network errors
+- callers, imports, data flow, and configuration reads
+- `git diff`, `git log`, and `git blame` for a suspected regression
+- comparison with a nearby working path or input
+
+Separate facts from hypotheses. Test the cheapest safe competing explanations
+first. Do not stop at the first plausible line, blame a dependency without
+evidence, or confuse the place an error surfaced with the place it originated.
+
+## Step 4 - confirm or narrow
+
+A root cause is confirmed only when the evidence connects all three:
+
+1. the triggering input or state
+2. the responsible code, configuration, or contract
+3. the observed failure
+
+When safe and read-only, vary one input or run a smaller focused command to
+confirm the connection. Do not change implementation or tests to prove the fix.
+
+Use one of these verdicts:
+
+- **Confirmed** - evidence identifies the cause and explains the failure.
+- **Likely** - evidence narrows the cause, but one specific proof is unavailable.
+- **Blocked** - the failure cannot be reproduced or required evidence is
+  inaccessible.
+
+## Step 5 - report and hand off
+
+Give a concise debug report:
+
+- symptom and reproduction
+- verdict
+- root cause or leading hypothesis
+- evidence, including commands and relevant paths
+- affected behavior and likely repair boundary
+- what was not verified
+- exact next action
+
+Choose the next action without writing files:
+
+- Active feature or fix caused the failure -> return the diagnosis to
+  `/implement`.
+- No active work item and the bug is confirmed -> recommend
+  `/fix "<concise bug and confirmed cause>"`.
+- Cause is only likely or blocked -> recommend the next diagnostic evidence, not
+  a speculative repair.
+- The issue is planned product work rather than a defect -> point to
+  `/feature`.
 
-## Relationship To DevFlow 2.0
+## Rules
+
+- Diagnose, do not repair. Never edit source, tests, configuration, lockfiles, or
+  Blueprint files.
+- Never create, switch, merge, or delete branches. Never commit or push.
+- Do not update the findings ledger. `/audit` owns recorded code-quality
+  findings; `/debug` reports one investigated failure in chat.
+- Evidence outranks confidence. Label uncertainty and failed reproduction
+  honestly.
+- Preserve the user's working tree and running processes.
+- Do not broaden one failure into a general audit or refactor.
 
-- **Classification**: Companion command & Investigation lane
-- **Mainline integration**:
-  - During `00-discover`: 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)
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown with a short
+evidence list and a clear next action.

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

@@ -1,10 +1,16 @@
 ---
 name: devflow
-description: "[Devflow] Flagship interactive guide, state inspector, and intent router for DevFlow workflows."
+description: "[devflow][B] Flagship interactive guide, state inspector, and intent router for DevFlow workflows."
 ---
 
 # devflow - Interactive Workflow Guide & Intent Router for Nexus-DevFlow
 
+## Command Track Policy
+- [F] Fast-Track only
+- [D] Deep-Track only
+- [B] Available in both tracks (Track-agnostic)
+
+
 Use this skill to guide the user on what to do next, inspect current workspace state, map their natural language intent to the right Nexus-DevFlow track (Fast-Track or Deep-Track) or companion command, or display a sitemap of available DevFlow skills.
 
 ## Input
@@ -17,7 +23,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,16 +43,16 @@ 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.
 
 ### Default State Recommendations
-- 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 start a feature -> Recommend `/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 +71,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 +97,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
@@ -114,4 +120,4 @@ When invoked without an argument (or when determining the next step), inspect:
 - `autopilot` - Autonomous bounded delivery loop
 - `brainstorm` - Ideate without allocating running IDs
 - `debug` - Root cause investigation before or during implementation
-- `overview` - Living context synchronization into project-overview.md
+- `overview` - Living context synchronization into project-overview.md