@jakkrichm/create-nexus-devflow 2.1.0 → 2.2.1

package/template/.claude/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-explore` ➔ `10-define` ➔ `20-spec` ➔ `30-plan` ➔ `40-execute` ➔ `50-verify` ➔ `60-report` ➔ `70-deliver`  
+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.*
 
 ---
@@ -39,14 +45,14 @@ When invoked without an argument (or when determining the next step), inspect:
      - 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}`.
 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`.
+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`.
 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-explore`.
+- 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 user asks to check system health -> Recommend `doctor`.
 
 ---
@@ -65,7 +71,7 @@ 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-explore` | `discover` | **Deep-Track**: `00` -> `10` -> `20` -> ... |
+| "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` |
@@ -78,6 +84,7 @@ When invoked without an argument (or when determining the next step), inspect:
 | "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 |
 
 ---
@@ -91,7 +98,7 @@ 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-explore` - Explore request and decide Proceed/Defer/Reject
+- `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
@@ -103,6 +110,8 @@ When invoked without an argument (or when determining the next step), inspect:
 ### 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
@@ -112,6 +121,5 @@ When invoked without an argument (or when determining the next step), inspect:
 - `ci` - Automatic GitHub Actions workflow setup
 - `brief` - Read-only scope and risk pre-briefing
 - `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

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

@@ -1,145 +1,91 @@
 ---
 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]"
+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."
+argument-hint: "[{title, request, IDEA-xxx, or discovery-id}]"
 ---
 
-# discovery - Guided Multi-Turn Project Discovery & Architecture Interview
+# discovery - Unified Discovery & Pre-Delivery Exploration
 
-Where this sits in the workflow:
+$ARGUMENTS
 
-```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.
+`/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`.
 
 ---
 
-## Usage & Invocations
+## Invocations & Usage
 
 ```text
-/discovery                          # Start interactive discovery interview
-/discovery "AI-powered CRM for SMB" # Start discovery seeded with an initial product concept
-$discovery                          # Codex CLI invocation
+# 1. Macro Project Planning Mode (No arguments or project scope)
+/discovery
+/discovery --project
+
+# 2. Micro Feature Exploration Mode (Stage 00 of Deep-Track)
+/discovery {title or request}
+/discovery IDEA-xxx
+/discovery {discovery-id}
 ```
 
 ---
 
-## 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.
+## Mode 1: Macro Project Discovery (Roadmap & System Planning)
 
----
+Use when:
+- Starting a new product or shaping high-level architecture across the entire repository.
+- Revisiting the overall project vision, major milestones, or tech stack before generating `/overview`.
 
-### 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.
+### Process:
+1. **Establish Baseline**: Read `devflow/project-plan.md` and `devflow/build-plan.md` (if present).
+2. **Adaptive Conversation**: Ask 1-2 focused questions at a time covering problem space, user workflows, MVP boundaries, non-goals, data models, and stack constraints.
+3. **Periodic Snapshots**: Provide compact summaries of confirmed decisions, working assumptions, and open TODOs.
+4. **Draft Plans Behind Approval Gate**: Draft proposed `project-plan.md` and `build-plan.md` only when the user explicitly requests drafts.
+5. **Write on Approval**: Write approved files and recommend `/overview` as the next step.
 
 ---
 
-### 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 ทั้งหมด คุณต้องการปรับแก้ส่วนไหนเพิ่มเติม หรือยืนยันให้บันทึกลงไฟล์เลยครับ?"*
-
----
+## Mode 2: Micro Feature Exploration (Stage 00 of Deep-Track)
 
-### Step 4 - Write User-Owned Planning Documents
+Use when:
+- Exploring a specific feature, complex architectural change, or pending idea (`/discovery IDEA-xxx`).
+- The team needs to evaluate feasibility, options, domain glossary, or root causes before locking delivery scope.
 
-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)
-   ```
+### Markdown-First Contract:
+Write the primary discovery artifact to:
+```text
+devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
+```
+*(A Discovery ID uses the namespace `DISC-YYYYMMDD-NNN`. It is not a Running ID and does not reserve a numeric delivery run.)*
+
+### 5 Supporting Routes & Built-in Lenses:
+
+1. **Brainstorming Lens (Divergent & Convergent)**:
+   - Formulate 2-3 viable options with trade-offs.
+   - Construct a **Trade-off Comparison Table** (Pros, Cons, Recommendation).
+2. **Research & Empirical Proof Lens**:
+   - Inspect existing codebase patterns with search tools (`grep_search`, `rg`).
+   - Conduct external web search if library feasibility or API contracts are uncertain.
+3. **PRD & Scoping Lens**:
+   - Problem Statement, Target Persona, Core User Stories, and In-Scope vs. Out-of-Scope boundaries.
+4. **Issue & Bug Triage Lens**:
+   - Classify severity (`Critical/Blocker`, `Major`, `Minor`) and determine whether root-cause analysis (`debug`) is required.
+5. **Socratic Grilling & Domain Alignment Lens (`grill`)**:
+   - Codebase-grounded interactive inquiry to clarify entity boundaries, data flows, and edge cases.
+   - Record agreed terminology in `devflow/context/glossary.md` and major architecture decisions in `devflow/decisions/ADR-xxx-{slug}.md`.
+
+### 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`).
+- `Defer`: The idea remains relevant but timing or evidence is not ready.
+- `Reject`: The idea should not proceed under current framing.
 
 ---
 
-### Step 5 - Handoff to `/overview`
+## Next Workflow Recommendations
 
-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 ครับ
-```
+- **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.

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

@@ -1,84 +1,207 @@
 ---
 name: doctor
-description: "[Devflow] Read-only DevFlow health check and diagnostics for context files, adapters, commands, and workflow drift."
+description: "[devflow][B] Run a read-only Blueprint health check for setup, onboarding, required files, tool adapters, commands, optional verification and CI, Blueprint visibility, ignore rules, planning readiness, overview freshness, and workflow drift. Use when the user runs /doctor, asks whether the Blueprint is installed correctly, wants a health check, setup check, doctor pass, or says something feels off before starting or resuming work."
 ---
 
-# doctor - Read-Only DevFlow Health Check & Diagnostics
+# doctor - Blueprint health check
 
 Where this sits in the workflow:
 
-```text
-Any time during development -> [doctor] -> Health Report & Actionable Fixes
-(read-only inspection)          (diagnostics)    (remediation recommendations)
-```
+    any time  ->  [doctor]  ->  reads setup + plans + workflow state + git
+                  (read-only)   prints health, warnings, and repair order
 
-`doctor` is a safe, read-only diagnostic skill that verifies whether your repository's Nexus-DevFlow configuration, context files, tool adapters, commands, and active runs are healthy and aligned.
+This skill answers one question: *is this Blueprint project ready to use?* It is
+the diagnostic pass for setup drift, incomplete onboarding, missing files,
+placeholder plans, stale generated context, Blueprint visibility, and confusing
+workflow state. It never changes anything: no edits, no commits, no installs, no
+builds, no branch changes.
 
----
+Use `/status` when the user mainly wants progress and the next build action. Use
+`/doctor` when the user wants to know whether the workflow itself is healthy.
 
 ## Input
 
-No argument is required.
-
----
-
-## Diagnostics Checklist
-
-Run through these 5 health checks:
-
-### Check 1: Core Framework & Context Files Integrity
-- Check if [AGENTS.md](AGENTS.md) and [CLAUDE.md](CLAUDE.md) exist and are populated.
-- Check required context files under `devflow/context/`:
-  - `project-overview.md` (Check if still empty/placeholder -> recommend `onboard` or `adopt`)
-  - `coding-standards.md` (Check if customized for stack)
-  - `ai-interaction.md` (Check if rules are configured)
-  - `current-stage.md` (Check if active run matches filesystem)
-  - `findings.md` (Check if ledger exists)
-
-### Check 2: Tool Adapters Parity
-- 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
-- Inspect the Commands section in `AGENTS.md`.
-- Cross-reference with project manifest (`package.json`, `pyproject.toml`, `Cargo.toml`, etc.):
-  - Does the `Dev` command exist in scripts?
-  - Does the `Build` command exist in scripts?
-  - Does the `Test` command exist in scripts?
-  - Does the `Verify` command exist in scripts?
-
-### Check 4: Active Runs & Workflow Drift Detection
-- Inspect `devflow/runs/`:
-  - Are there active runs?
-  - Is `current-stage.md` consistent with the latest stage artifact in the active run?
-  - Are checklists (`checklists/implementation-checklist.md`, `checklists/verification-checklist.md`) properly tracked?
-  - Detect stage skips or workflow drift (e.g. jumping from `10-define` directly to `40-execute` without `20-spec` and `30-plan`).
-
-### Check 5: Findings Ledger Inspection
-- Inspect `devflow/context/findings.md`:
-  - Are there open P0 or P1 findings that block release?
-  - Are resolved findings properly closed?
-
----
-
-## Output Format
-
-Present a clean, scannable diagnostic report:
-
-```markdown
-# 🩺 Nexus-DevFlow Health Report
-
-## Overall Status: [HEALTHY | WARNING | ACTION REQUIRED]
-
-| Component | Status | Details |
-| :--- | :--- | :--- |
-| **Context Files** | [PASS / WARN] | project-overview.md, coding-standards.md status |
-| **Tool Adapters** | [PASS / WARN] | .agents and .claude parity |
-| **Configured Commands**| [PASS / WARN] | dev, build, test, verify alignment |
-| **Active Runs & Drift**| [PASS / WARN] | active run status, stage progression |
-| **Findings Ledger** | [PASS / WARN] | open P0/P1 issues count |
-
-### Recommended Remediation Actions:
-1. [Action item if any warning or failure detected]
-2. [Suggested next command, e.g. devflow, onboard, adopt, etc.]
-```
+None. `/doctor` takes no argument.
+
+## What it checks
+
+Gather these, then summarize. Do not dump file contents.
+
+1. **Required DevFlow files**
+   - Confirm `AGENTS.md`, `devflow/project-plan.md`,
+     `devflow/build-plan.md`, and `devflow/context/` exist.
+   - Confirm `devflow/context/coding-standards.md`,
+     `devflow/context/ai-interaction.md`,
+     `devflow/context/current-feature.md`, and
+     `devflow/context/project-overview.md` exist.
+   - Confirm `devflow/history/features/` and `devflow/history/fixes/` exist.
+     When the rollback skill is installed, also check
+     `devflow/history/rollbacks/`. A missing rollback folder on a legacy
+     installation is a warning, not a blocker; `/complete` creates it on the
+     first rollback.
+   - Check `devflow/context/findings.md`. Missing on a legacy installation is
+     a warning, not a blocker; `/audit` and `/complete` create it on first use.
+     When present, confirm its entry headers still match
+     `### <id> [<severity>] <status> - <title>` and warn on a malformed ledger.
+     Report any P0 or P1 finding still `open` or `fixed` by ID, since it will
+     block `/complete`. Never block on the ledger yourself.
+   - If `.gitignore` marks DevFlow workflow files as local-only, still require
+     the files to exist on disk. Ignored but present is healthy; ignored and
+     missing means the local workflow needs to be restored.
+2. **Tool adapters**
+   - Read `.nexus/nexus-devflow.json` when present and report its exact
+     logical adapters: Codex, Claude Code, GitHub Copilot, Antigravity, and OpenCode.
+   - Confirm at least one compatible skill tree exists. Codex, Antigravity, and
+     GitHub Copilot use `.agents/skills/`. Claude Code uses `.claude/skills/`.
+     OpenCode can use either tree.
+   - If both skill trees are present, say that is healthy when the selected
+     tools require both. Compare their skill folder names and warn about missing
+     skills on either side.
+   - If OpenCode is selected, do not require `.opencode/skills/`. If it contains
+     duplicate DevFlow skills alongside `.agents/skills/` or `.claude/skills/`,
+     warn that OpenCode discovers all of those locations and the duplicate tree
+     should be reviewed.
+   - If git shows changes under `.agents/skills/` or `.claude/skills/`, check
+     the matching adapter file too. Warn when workflow behavior was updated in
+     one adapter but not the other.
+   - If only one tool is used, mention the unused adapter can be deleted. Do not
+     treat extra adapters as an error.
+   - If `CLAUDE.md` exists and still starts with `# Project Name`, flag that
+     `/onboard` probably has not finished.
+3. **Commands and project setup**
+   - Check whether root `README.md` is still the copied DevFlow workflow doc
+     by looking for `# AI Coding Blueprint` or opening text that describes the
+     workflow instead of the app. If so, warn that `/onboard` should
+     replace it with a project README before publishing.
+   - If `devflow/README.md` clearly contains copied workflow docs,
+     report it as an obsolete installer artifact. Its absence is healthy. An
+     unchanged managed copy can be removed by the updater; a modified copy needs
+     user review.
+   - Check whether `AGENTS.md` has a `## Commands` section with dev and build
+     commands.
+   - Report missing lint or test commands as informational unless the project has
+     real lint or test scripts elsewhere that are not reflected in `AGENTS.md`.
+   - If `package.json` exists, compare its scripts against `AGENTS.md` at a high
+     level. Do not require every script to be documented.
+   - If `AGENTS.md` declares a `Verify` command, confirm it resolves to real
+     project commands in the expected order: typecheck, tests when configured,
+     then build. Do not require checks the project does not have.
+   - If `.github/workflows/verify.yml` exists, confirm it runs the exact documented
+     `Verify` command for pull requests and pushes to the default branch, uses the
+     detected runtime and package manager, and starts with read-only contents
+     permission. Preserve other workflows and report overlap for review.
+   - A missing `Verify` command or GitHub workflow is informational. It means the
+     optional automatic-check setup was not selected, not that DevFlow is
+     unhealthy.
+4. **Ignore rules**
+   - Check obvious ignore patterns for the detected stack. For Node or Astro,
+     look for `node_modules`, `.env`, `dist`, and framework cache folders such as
+     `.astro` or `.next` when relevant.
+   - Detect local-only DevFlow mode if `.gitignore` ignores `.agents/`,
+     `.claude/`, `devflow/`, or `CLAUDE.md`. Report it as a visibility choice,
+     not a failure, when the local files exist.
+   - In local-only mode, check whether tracked `AGENTS.md` still describes the
+     Blueprint workflow, lists hidden adapter paths, or exposes the core skill
+     list. If so, warn that `/onboard` should make `AGENTS.md` public-safe.
+   - If local-only mode is active but those paths are already tracked by git,
+     warn that `.gitignore` does not hide tracked files and the user must approve
+     any `git rm --cached` cleanup separately.
+   - Keep this conservative. If uncertain, report "review" instead of failure.
+5. **Planning readiness**
+   - Check whether `devflow/project-plan.md` and `devflow/build-plan.md` look
+     filled in or still template-like. Treat obvious TODO, TBD, example-only text,
+     or empty required sections as not ready.
+   - Check whether `devflow/build-plan.md` is a numbered checkbox list. Raw
+     bullets are allowed as a first draft, but they should be normalized by
+     `/overview` before the build loop starts.
+   - Count checked and unchecked leaf items in `devflow/build-plan.md`.
+6. **Overview freshness**
+   - Check whether `devflow/context/project-overview.md` exists and looks
+     generated from the current plans.
+   - If either planning file appears newer than the overview by filesystem time,
+     call the overview possibly stale and suggest `/overview` before feature work.
+7. **Current workflow state**
+   - Check whether `devflow/context/current-feature.md` is the reset stub or an
+     active feature, fix, or rollback spec.
+   - If a spec is active, report checked and unchecked implementation steps.
+   - If `current-feature.md` is the reset stub but git has source or workflow
+     changes, warn that work is happening without an active spec.
+   - Flag active spec on `main`, all spec steps checked but no completion, or a
+     branch that does not match `feature/`, `fix/`, or `rollback/` for the spec
+     type. For a feature, also flag a mismatch with the next unchecked
+     build-plan item. For a rollback, confirm its target is a checked item and do
+     not compare it to the next unchecked item.
+8. **Git**
+   - Report current branch, clean vs dirty working tree, rough changed-file count,
+     last commit subject, and whether the branch is ahead of upstream.
+   - If the directory is not a git repo, report that as a setup issue and keep
+     going.
+
+## Output
+
+Print a compact health report with these labels:
+
+    Health: Pass | Needs attention | Blocked
+    Setup: ...
+    Verification: ...
+    Adapters: ...
+    Visibility: ...
+    Plans: ...
+    Workflow: ...
+    Git: ...
+    Watch: ...
+    Repair order: ...
+
+Use `Watch:` only when there are warnings. Use `Repair order:` for the exact next
+steps, in order. Keep it short and practical.
+
+Choose the repair order in this priority:
+
+- Required Blueprint files missing -> overlay the Blueprint again, or use
+  `/adopt` for a brownfield app.
+- No git repo -> initialize git before using the build loop.
+- No tool adapter -> restore `.agents/skills/` or `.claude/skills/` for the
+  selected tool. OpenCode can use either compatible tree.
+- Onboarding incomplete -> run `/onboard`.
+- Root README is still the Blueprint workflow doc -> run `/onboard` to replace
+  it with a project README before publishing.
+- Local-only visibility selected but ignored Blueprint files are missing ->
+  reinstall or restore the Blueprint files locally.
+- Local-only visibility selected but Blueprint paths are tracked -> ask whether
+  to untrack them with `git rm --cached` while keeping local files.
+- Local-only visibility selected but `AGENTS.md` still exposes the workflow ->
+  run `/onboard` to make `AGENTS.md` a lightweight public project guide.
+- A documented `Verify` command, project script, and GitHub workflow disagree ->
+  run `/ci` to review and align them. Missing optional CI alone does not need
+  repair.
+- Commands or ignore rules need review -> update the files or run `/onboard` if
+  this is an early project.
+- Plans are placeholders -> fill `devflow/project-plan.md` and
+  `devflow/build-plan.md`.
+- Overview missing or stale -> run `/overview`.
+- Active spec has unchecked steps -> run `/status` or `/implement`, depending on
+  whether the user wants orientation or action.
+- A P0 or P1 finding is `open` -> repair it through `/implement` while a spec
+  is active, or `/fix <finding id>` between work items. One that is `fixed` ->
+  `/audit` to re-review and close it. Both come before suggesting `/complete`.
+- Active spec is done but not closed -> run `/check`, then `/complete`.
+- Everything is healthy -> say so, then suggest `/status` for progress or
+  `/feature` for the next planned feature.
+
+## Rules
+
+- **Read-only, always.** This skill never writes files, never commits, never runs
+  installs, never runs builds or tests, and never switches branches.
+- **Diagnose, then order repairs.** Do not just list problems. End with the
+  smallest ordered sequence that gets the project back to a healthy state.
+- **Do not over-police adapters.** Extra adapters are optional clutter, not a
+  failure.
+- **Be conservative with stack-specific checks.** If a command or ignore pattern
+  is uncertain, mark it for review instead of inventing a hard failure.
+- **Stay concise.** A doctor pass should feel like a checklist, not an audit.
+
+## 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.