@jakkrichm/create-nexus-devflow 2.2.2 → 2.6.0

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

@@ -1,9 +1,9 @@
 ---
 name: debug
-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."
+description: "[devflow][B] Diagnose a failing test, broken build, crash, error, regression, or unexpected behavior without editing source or DevFlow state. Follows a strict 6-Phase Scientific Debugging Loop: builds a red-capable tight feedback loop, reproduces & minimises, tests 3-5 falsifiable hypotheses, localizes the failure to a root cause, 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 - find the cause before changing the code
+# debug - 6-Phase Scientific Debugging Protocol
 
 Where this sits in the workflow:
 
@@ -12,130 +12,112 @@ Where this sits in the workflow:
      crash, behavior)       isolate,       repair active work)
                             explain)
 
-`/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.
+`/debug` separates diagnosis from repair. It gathers empirical evidence, narrows the failure to a specific root cause using scientific method, and stops with an actionable repair handoff. It does not guess, assume, or perform ad-hoc "vibe debugging".
+
+---
 
 ## Input
 
 Accept a symptom, failing command, error message, or unexpected behavior. Examples:
 
-    /debug npm test fails in cart-total.test.js
+    /debug npm test fails in cart-total.test.ts
     /debug the upload route returns 500 for PNG files
-    /debug why does the production build fail?
+    /debug why does the build fail on Windows?
 
-With no useful symptom, ask for the expected behavior, actual behavior, and
-smallest known reproduction. Do not guess which problem the user means.
+With no useful symptom, ask for expected behavior, actual behavior, and smallest known reproduction. Do not guess.
 
-## Step 1 - establish the boundary
+---
 
-Read the project instructions and the context relevant to the failure:
+## 🔬 The 6-Phase Scientific Debugging Loop
 
-- `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
+### Phase 1: Build a Red-Capable Feedback Loop (Golden Rule)
 
-State the symptom and what would count as reproducing it. Note whether the
-failure belongs to an active feature or is an unplanned bug.
+**This is the core discipline.** If you have a **tight** pass/fail command that actively goes RED on this bug, you will find the root cause. If you do not have one, staring at code will not save you.
 
-Do not treat a dirty working tree as permission to discard or rewrite anything.
-Use the diff as evidence and preserve it.
+**Spend disproportionate effort here. Ways to construct one (in order):**
+1. **Failing Unit / Integration Test** at the responsible module seam.
+2. **Curl / HTTP script** against the running local dev server.
+3. **CLI invocation** diffing stdout/stderr against expected output.
+4. **Headless browser script** (Playwright) asserting on DOM/network/console.
+5. **Replay captured trace**: Replay isolated payload/event log through the code path.
 
-## Step 2 - reproduce safely
+**Completion Criterion for Phase 1**:
+You must name **one single command** (a test invocation, a script, or curl) that you have **already run at least once** and proven:
+- [ ] **Red-capable**: It exercises the actual code path and catches the user's exact symptom (fails red now, will pass green once fixed).
+- [ ] **Deterministic**: Returns the same verdict every run.
+- [ ] **Fast & Agent-runnable**: Completes in seconds, executable without manual intervention.
 
-Run the smallest existing command or interaction that can reproduce the symptom.
+> [!CAUTION]
+> **No Red-Capable Command = No Phase 2.** If you catch yourself reading code to form theories before this command exists, **STOP**. Jumping straight to a hypothesis is the exact failure this protocol prevents.
 
-- 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.
+### Phase 2: Reproduce & Minimise
 
-## Step 3 - localize the failure
+Run the feedback loop and watch it go RED.
 
-Trace from the observed failure toward the smallest responsible area.
+1. **Confirm Symptom**: Ensure the failure mode matches what the user reported (not a nearby unrelated error).
+2. **Minimise the Repro**: Cut inputs, configs, dependencies, and steps **one at a time**, re-running the command after each cut. Keep only what is load-bearing for the failure.
+3. **Done when**: Every remaining parameter is load-bearing (removing any one makes the loop go green).
 
-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
+### Phase 3: Form 3–5 Ranked Falsifiable Hypotheses
 
-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.
+Generate **3 to 5 ranked hypotheses** before testing or inspecting deeply. Never anchor on the first plausible idea.
 
-## Step 4 - confirm or narrow
+Every hypothesis MUST be **falsifiable** using this exact format:
+> *"If `<X>` is the cause, then `<changing Y>` will make the bug disappear / `<changing Z>` will make it worse."*
 
-A root cause is confirmed only when the evidence connects all three:
+If you cannot state the prediction, it is a vibe: sharpen or discard it.
 
-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.
+### Phase 4: Targeted Instrumentation & Isolation
 
-Use one of these verdicts:
+Test hypotheses by changing **one variable at a time**:
+1. **Tool preference**: Read-only inspection > REPL/debugger > Targeted probe logs.
+2. **Debug Tag Rule**: If temporary diagnostic logs are necessary, tag every log line with a unique prefix, e.g. `[DEBUG-a4f2]`. This guarantees a single `grep` can find and remove all probes.
+3. **Redaction**: Redact all secrets, tokens, and credentials in terminal outputs (`<REDACTED>`).
 
-- **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
+### Phase 5: Confirm Root Cause at Real Seam
 
-Give a concise debug report:
+A root cause is **Confirmed** only when empirical evidence connects all three:
+1. The triggering input or state
+2. The responsible code / configuration boundary
+3. The observed failure
 
-- 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
+**Seam Identification**: Identify the exact architectural seam (per `devflow/context/coding-standards.md` Deep Modules) where the regression test must live. If no clean seam exists, note that as an architectural finding.
 
-Choose the next action without writing files:
+---
+
+### Phase 6: Report & Hand-off
+
+Give a structured, concise debug report:
 
-- Active feature or fix caused the failure -> return the diagnosis to `/implement` with instructions to write a failing reproduction test ([TDD-Red]) first.
-- No active work item and the bug is confirmed -> recommend `/fix "<concise bug and confirmed cause>"` (which will write a failing test first before fixing).
-- 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`.
+```markdown
+### 🐞 Debug Report: <Concise Title>
+
+- **Symptom**: <Exact user symptom observed>
+- **Reproduction Command**: `<Single red-capable command>`
+- **Verdict**: Confirmed | Likely | Blocked
+- **Root Cause**: <Precise technical explanation of why it failed>
+- **Responsible Seam**: `<path/to/file.ts#line>`
+- **Evidence**:
+  - Test/Curl output confirming the red signal
+  - Trace connecting triggering state to failure
+- **Next Action**:
+  - For active feature -> Hand back to `/implement` with instructions to write failing test first.
+  - For standalone bug -> Recommend `/fix "<concise description>"` to create spec and implement regression test.
+```
+
+---
 
 ## 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.
-
-## 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.
+- **Diagnose, do not repair**: Never edit production source, package lockfiles, or DevFlow state inside `/debug`.
+- **Evidence outranks confidence**: Label uncertainty honestly (`Likely` vs `Confirmed`).
+- **Preserve git state**: Never switch branches, commit, reset, or clean the working tree.
+- **Clean up probes**: Ensure any temporary test scripts in scratch/ are cleanly referenced.

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

@@ -5,26 +5,19 @@ description: "[devflow][B] Flagship interactive guide, state inspector, and inte
 
 # 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.
+Use this skill to guide the user on what to do next, inspect current workspace state, map their natural language intent to the matching Nexus-DevFlow stage or companion command, or display a sitemap of available DevFlow skills.
 
 ## Input
 
-- **No argument (`devflow`, `devflow`, `$devflow`, or `status`)**: Inspect current workspace state (active run in `devflow/runs/` or `devflow/context/current-stage.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.
-- **With user request (`devflow "<request>"`)**: Classify the user's intent and guide them to the matching DevFlow workflow track or companion command path.
+- **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.
+- **With user request (`devflow "<request>"`)**: Classify the user's intent and guide them to the matching DevFlow workflow stage or companion command path.
 
-## Dual-Track Architecture
+## The Unified Living Spec Architecture (DevFlow 2.5.0)
 
-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)**: `discovery` ➔ `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.*
+Nexus-DevFlow uses a **Single Unified 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.
+- **Pre-Flight Inception Engine**: Companion skills (`/discovery`, `/idea`, `/grill`, `/brainstorm`) feed directly into `/feature`.
 
 ---
 
@@ -33,93 +26,72 @@ Nexus-DevFlow supports two seamless workflow tracks:
 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 check `devflow/runs/{RUNNING_ID}/`.
-   - **If Fast-Track (`current-feature.md`, `spec.md`, or `blueprint.md` present)**:
-     - If `current-feature.md` (or `spec.md`) has incomplete checklist items -> Recommend `/implement` (or `implement {RUNNING_ID}`).
-     - If all tasks done but no passing verification evidence -> Recommend `/check` (or `check {RUNNING_ID}`).
-     - If verification evidence passed -> Recommend `/complete` (or `complete {RUNNING_ID}`).
-   - **If Deep-Track (numbered stage files present)**:
-     - If at `10-define.md` -> Recommend `20-spec {RUNNING_ID}`.
-     - 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-deliver {RUNNING_ID}`.
+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`.
 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` or `/discovery IDEA-xxx`.
+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.
 
 ### Default State Recommendations
-- if no run is active and user wants to start a feature -> Recommend `/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` or `/discovery IDEA-xxx`.
-- If no run is active and user wants deep architectural exploration -> Recommend `discovery`.
+- If no run is active and user has pending ideas in `devflow/ideas.md` -> Highlight `/feature IDEA-xxx` or `/discovery IDEA-xxx`.
+- If no run is active and user wants deep architectural exploration -> Recommend `/discovery`.
 - If user asks to check system health -> Recommend `doctor`.
 
 ---
 
 ## Intent Classification & Skill Routing
 
-| User Intent / Request Type | Recommended Skill | Normal Name / Alias | Track / Lifecycle Path |
+| User Intent / Request Type | Recommended Skill | Normal Name / Alias | Lifecycle Path |
 | :--- | :--- | :--- | :--- |
-| **"Spec new feature / lean workflow"** | `spec` | `/spec` / `/feature` | **Fast-Track**: `/spec` -> `/implement` -> `/check` -> `/complete` |
-| **"Quick bugfix / ad-hoc change"** | `spec` | `/fix` | **Fast-Track**: `/fix` -> `/implement` -> `/check` -> `/complete` |
+| **"Spec new feature / living spec"** | `feature` | `/feature` / `/spec` | **Unified**: `/feature` -> `/implement` -> `/check` -> `/complete` |
+| **"Quick bugfix / ad-hoc change"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
 | **"Capture quick idea / thought"** | `idea` | `/idea` | **Companion**: Enriches & saves to `devflow/ideas.md` |
-| **"Execute implementation tasks"** | `implement` | `/implement` | **Fast-Track**: `/implement` -> `/check` |
-| **"Run QA verification & check"** | `check` | `/check` | **Fast-Track**: `/check` -> `/complete` |
-| **"Complete run & git merge"** | `complete` | `/complete` | **Fast-Track**: `/complete` |
-| **"Generate HTML dashboard report"**| `report-html` | `/report:html` | **Standalone**: Converts `current-feature.md` / `60-report.md` to HTML |
-| "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` |
+| **"Pre-delivery exploration / research"**| `discovery`| `/discovery` | **Pre-Flight**: `discovery` -> `/feature` |
+| **"Socratic alignment / ADR / glossary"**| `grill` | `/grill` / `/align` | **Pre-Flight**: `grill` -> `/feature` |
+| **"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 |
+| "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` |
-| "Explore a new request / deep idea" | `discovery` | `discovery` / `/discovery` | **Deep-Track**: `discovery` -> `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-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 |
+| "Safely plan feature or run reversal"| `rollback` | `rollback` | Companion |
 | "Set up automatic GitHub Actions CI" | `ci` | `ci` | Companion |
-| "Pre-check scope & risks before spec" | `brief` | `brief` | Companion |
+| "Pre-check scope & risks before spec"| `brief` | `brief` | Companion |
 | "Run autonomous bounded delivery loop"| `autopilot` | `autopilot` | Companion |
 | "Brainstorm ideas without ID" | `brainstorm` | `brainstorm` | Companion |
-| "Socratic alignment / ADR / glossary" | `grill` | `/grill` / `align` | Companion (pre-spec / domain modeling) |
 | "Investigate failure or root cause" | `debug` | `debug` | Companion |
 
 ---
 
 ## Available Skills Sitemap
 
-### 1. Fast-Track (Blueprint Mode - 4 Steps)
-- `spec` (`/spec`, `/feature`, `/fix`, `$spec`) - Define, spec, plan, and create `current-feature.md`
-- `implement` (`/implement`, `$implement`) - Execute planned checklist tasks with TDD
-- `check` (`/check`, `$check`) - Senior QA review, multi-lane verification, record evidence
-- `complete` (`/complete`, `$complete`) - Safety pass, release digest, git merge, close run
+### 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`
+- `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
 
-### 2. Deep-Track (Architect Mode - 8 Steps)
+### 2. Pre-Flight Discovery Engine
 - `discovery` - Project roadmap planning or feature exploration before delivery commitment
-- `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-deliver` - Release packaging, release notes, and merge
-
-### 3. Public Companion Commands
-- `devflow` (`status`, `/devflow`) - Interactive guide, state inspector, and router
-- `idea` (`/idea`) - Quick idea capture and AI feasibility enrichment into `devflow/ideas.md`
-- `grill` (`/grill`, `align`) - Codebase-grounded Socratic alignment, domain glossary, and ADR recorder
-- `brainstorm` - Ideate and compare trade-off options without allocating running IDs
-- `report-html` (`/report:html`) - Standalone interactive HTML report dashboard generator
-- `onboard` - Baseline stack setup for freshly scaffolded projects
-- `adopt` - Bootstrap DevFlow into existing brownfield projects
-- `doctor` - Read-only health check for setup and drift
-- `try` - Step-by-step human manual QA review guide
-- `rollback` - Safe feature/run reversal planner
-- `ci` - Automatic GitHub Actions workflow setup
-- `brief` - Read-only scope and risk pre-briefing
-- `autopilot` - Autonomous bounded delivery loop
-- `debug` - Root cause investigation before or during implementation
-- `overview` - Living context synchronization into project-overview.md
+- `idea` - Quick idea capture with AI feasibility scoring
+- `grill` (or `align`) - Socratic alignment, domain modeling, and ADR recording
+- `brainstorm` - Multi-option ideation with trade-off analysis
+
+### 3. Verification & Diagnostic Companions
+- `doctor` - Health check for setup, adapters, and workspace state
+- `audit` - Branch-aware or full-project code, security, and quality review
+- `test` / `tests` - Test suite runner and unit test scaffolding
+- `ci` - Set up or normalize GitHub Actions checks
+- `status` - Read-only progress summary and next action suggestion
+- `try` - Human manual QA walkthrough guide
+- `report-html` - Standalone interactive HTML report dashboard
+- `debug` - Root-cause investigation without editing code
+- `rollback` - Safe reversal of completed features
+- `release` - Deployment readiness check

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

@@ -1,6 +1,6 @@
 ---
 name: discovery
-description: "[devflow][D] Unified discovery and exploration stage in DevFlow 2.0 - conducts project-level roadmap discovery (project-plan.md/build-plan.md) or feature-level exploration (Stage 00) before delivery commitment."
+description: "[devflow][D] Unified discovery and exploration stage in DevFlow 2.5.0 - conducts project-level roadmap discovery (project-plan.md/build-plan.md) or feature-level pre-delivery exploration before the Single Living Spec lifecycle."
 argument-hint: "[{title, request, IDEA-xxx, or discovery-id}]"
 ---
 
@@ -10,7 +10,7 @@ $ARGUMENTS
 
 `/discovery` is the central discovery entry point in Nexus-DevFlow. It operates in two adaptive modes based on input scope:
 1. **🗺️ Macro Project Discovery**: Develops high-level product and build roadmap plans (`devflow/project-plan.md` & `devflow/build-plan.md`) through an adaptive conversation before `/overview`.
-2. **🔍 Micro Feature Exploration (Stage 00)**: Explores a specific feature, request, or idea before committing to delivery, routes through supporting lenses, and finishes with a visible `Proceed`, `Defer`, or `Reject` decision before `10-define`.
+2. **🔍 Micro Feature Exploration (Pre-Flight)**: Explores a specific feature, request, or idea before committing to delivery, routes through supporting lenses, and finishes with a visible `Proceed`, `Defer`, or `Reject` decision before `/feature` or `/fix`.
 
 ---
 
@@ -21,7 +21,7 @@ $ARGUMENTS
 /discovery
 /discovery --project
 
-# 2. Micro Feature Exploration Mode (Stage 00 of Deep-Track)
+# 2. Micro Feature Exploration Mode (Pre-Flight)
 /discovery {title or request}
 /discovery IDEA-xxx
 /discovery {discovery-id}
@@ -44,7 +44,7 @@ Use when:
 
 ---
 
-## Mode 2: Micro Feature Exploration (Stage 00 of Deep-Track)
+## Mode 2: Micro Feature Exploration (Pre-Flight)
 
 Use when:
 - Exploring a specific feature, complex architectural change, or pending idea (`/discovery IDEA-xxx`).
@@ -76,8 +76,7 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
 ### Decision & Approval Gate:
 Set one visible decision:
 - `Proceed`: Enough value and evidence exist to define delivery work:
-  - **🏎️ Fast-Track (Recommended for 85% of standard features/fixes)**: Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` (writes `devflow/context/current-feature.md`).
-  - **🏗️ Deep-Track (For large architectural epics/migrations)**: Handoff to `10-define {discovery_id}` (writes `devflow/context/current-run/10-define.md`).
+  - Handoff to `/feature {discovery_id}` or `/fix {discovery_id}` to create the Single Living Spec in `devflow/context/current-feature.md`.
 - `Defer`: The idea remains relevant but timing or evidence is not ready.
 - `Reject`: The idea should not proceed under current framing.
 
@@ -86,6 +85,5 @@ Set one visible decision:
 ## Next Workflow Recommendations
 
 - **From Macro Project Mode**: Run `/overview` to compile context into `devflow/context/project-overview.md`.
-- **From Micro Stage 00 (Approved Proceed ➔ Fast-Track)**: Run `/feature {discovery_id}` to start lean living spec.
-- **From Micro Stage 00 (Approved Proceed ➔ Deep-Track)**: Run `10-define {discovery_id}` to allocate a Running ID.
-- **From Micro Stage 00 (Defer / Reject)**: No next command needed.
+- **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 (Defer / Reject)**: No next command needed.