@jakkrichm/create-nexus-devflow 2.17.9 → 2.18.1

package/template/devflow/context/coding-standards.md

@@ -62,7 +62,19 @@
 
 ---
 
-## 3. Stable API & Interface Design Standards
+## 3. Proportional Engineering & YAGNI Standards
+
+Build for established requirements, not hypothetical scale, threats, or future flexibility. Reuse existing code, the standard library, native platform features, and installed dependencies before adding machinery. Harmonize with DevFlow's `ponytail` skill for operational bloat reduction and YAGNI discipline.
+
+- **Proportional Scope**: Build for the immediate task. Unknown scale or extensibility defaults to the smaller reversible design. Do not infer enterprise, multi-tenant, hostile-user, or compliance requirements.
+- **Reachability-Derived Boundaries**: Derive trust and data-integrity boundaries from actual reachability: untrusted input, auth/session/ownership, shared persisted data, destructive operations, payments, secrets, and sensitive data.
+- **Material Unknowns Only**: Ask questions only when an unknown materially changes behavior, architecture, persisted data, interoperability, a real security boundary, or cost. Otherwise choose the simplest repository-native implementation.
+- **Just-In-Time Abstractions**: Add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only for a current requirement.
+- **Non-Negotiable Boundaries**: Simplicity never removes real trust-boundary validation, data-loss prevention, accessibility, explicit security requirements, configured tests, or project rules.
+
+---
+
+## 4. Stable API & Interface Design Standards
 
 - **Contract Stability**: Public exports, CLI options, and stage artifact schemas form immutable delivery contracts. Never break contracts without a major version bump.
 - **Explicit Parameter Objects**: For functions with more than 2 arguments, use an options object interface with descriptive property names.
@@ -119,13 +131,12 @@ nexus-devflow/
 
 Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
-- **Unit Test Mandate**: Logic or behavior changes must include meaningful automated coverage when the spec's test gate is enabled. Documentation, prompt wording, or formatting-only changes use structural checks and review instead of artificial unit tests.
+- **Unit Test Mandate**: Any new feature, modified logic, parser improvement, or bug fix **MUST ship with automated unit tests** in the same diff.
 - **Strict TDD (Red-Green-Refactor) Protocol**:
   1. **🔴 RED (Test First)**: Always write automated tests *before* writing or modifying functional logic. Run the test command and verify that it fails for the expected reason.
   2. **🟢 GREEN (Minimal Code)**: Write only the minimal production code necessary to make the failing test pass. Run the test command and verify 100% green pass.
   3. **🔵 REFACTOR (Clean & Robust)**: Refactor code for readability, performance, and DRY/YAGNI discipline while ensuring all tests stay green.
   - *Code Deletion / Reversion Rule*: If functional code is created without a prior failing test for behavior changes, it must be reverted or immediately backed by tests before continuing.
-- **Verification Scope**: Run focused checks during edits and required project gates before handoff. Repeat passing checks only after relevant changes, new failures, or unresolved risk.
 - **Test Framework**: Use Node.js native test runner executed via `tsx --test test/*.test.ts` under `packages/create-nexus-devflow/`.
 - **Test Design (AAA Pattern)**:
   - Structure each test case cleanly: **Arrange** (setup fixtures/mock directories), **Act** (execute function), **Assert** (verify invariants).
@@ -138,7 +149,7 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
     2. *Interactive AI Visual QA (MCP)*: Live DOM and styling inspection via MCP `browseros-neo` (`http://127.0.0.1:9010/mcp`) during `/check` and `/try`.
 - **Two-Stage Review Pattern (Verification Gate)**:
   - **Stage 1: Spec Fidelity & Acceptance Gate**:
-    - Verify 100% conformance against the Single Living Spec (`devflow/context/{xxx-slug}/spec.md`).
+    - Verify 100% conformance against the Single Living Spec (`current-feature.md`).
     - Validate all Acceptance Criteria (ACs) and "Done When" observables without missing requirements or scope creep.
     - Test edge cases and boundary conditions defined in the specification.
   - **Stage 2: Code Quality, Security & Architecture Gate**:
@@ -146,13 +157,13 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
     - **Lane 2 (Automated Test Suites & Evals)**: `npm test` (Unit tests 100% pass) + `npm run test:routing` (Skill routing accuracy).
     - **Lane 3 (Scrutinize & Security Audit)**: Edge cases, null-safety, 0 secrets, safe inputs.
     - **Lane 4 (Manual / Scenario Proof)**: Concrete walkthrough steps ("Where to go", "What to run", "What to expect").
-    - **Findings Ledger State**: 0 blockers (P0/P1) in `devflow/context/{xxx-slug}/findings.md`.
+    - **Findings Ledger State**: 0 blockers (P0/P1) in `devflow/context/findings.md`.
 
 ---
 
 ## 8. Findings Ledger & Quality Gates (`findings.md`, `review.md`)
 
-- All quality defects, security findings, or regression issues identified during review must be logged in `devflow/context/{xxx-slug}/findings.md`.
+- All quality defects, security findings, or regression issues identified during review must be logged in `devflow/context/findings.md`.
 - **Finding State Machine**:
   - `open`: Confirmed issue waiting to be fixed.
   - `fixed`: Repaired in code, pending QA re-verification.
@@ -203,7 +214,7 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
 ## 12. HTML Documentation & Theming Standards (Light Theme Mandate)
 
-All generated HTML artifacts across the framework (Contextual Help Playbooks `devflow/reference/playbooks/{skill}.html`, Standalone Reports `report-html`, Architecture & Workflow Diagrams `archify` / `diagram-design`, and UI Prototypes/Mockups) MUST strictly adhere to the **Paper/Ink Light Theme Design System**:
+All generated HTML artifacts across the framework (Contextual Help Playbooks `devflow/docs/playbooks/{skill}.html`, Standalone Reports `report-html`, Architecture & Workflow Diagrams `archify` / `diagram-design`, and UI Prototypes/Mockups) MUST strictly adhere to the **Paper/Ink Light Theme Design System**:
 
 - **Mandatory Default `data-theme="light"`**:
   - All HTML documents must start with `<html lang="th" data-theme="light">`.
@@ -245,66 +256,6 @@ All generated HTML artifacts across the framework (Contextual Help Playbooks `de
   - Fonts: Google Sans (`'Google Sans'`, `'Google Sans Text'`) for display headers and body text, `'JetBrains Mono'` for code and monospaced data.
   - Full support for `prefers-reduced-motion: reduce` and clear `:focus-visible` outlines.
 - **Master Reference Template**:
-  - Refer to `devflow/reference/playbooks/template.html` as the authoritative, reusable component reference for all playbook and HTML documentation generation.
+  - Refer to `devflow/docs/playbooks/template.html` as the authoritative, reusable component reference for all playbook and HTML documentation generation.
 
----
-
-## 13. Prompt Token Economy & Mechanical Input Coverage Standards
-
-- **Skill Byte Budgets & Prompt Hygiene**:
-  - **Size Ceilings**: `SKILL.md` must not exceed **32 KB**, support/reference markdown files must not exceed **24 KB**, and frontmatter `description` must not exceed **400 characters**.
-  - **Every Line Must Earn Its Keep**: If an agent naturally behaves correctly by default, avoid adding redundant prose. Instruct directly without philosophical justification.
-  - **Completion Summaries (Lead with Essentials)**:
-    - **Headline**: One-line summary of what was accomplished.
-    - **Next**: Exactly one next recommended command or action.
-    - **Heads up**: Active blockers, decision debt, or critical items needing user attention (omitted when empty).
-    - **Pointer**: Link to the detailed artifact rather than repeating large text blocks.
-    - **No Checklist Spam**: Avoid dumping lists of obvious successes (`Semantic HTML: OK`, `Keyboard: OK`).
-- **Mechanical Input Coverage Principle (Anti-Hallucination Gate)**:
-  - Before implementation, enumerate all values and states that the code must produce or display.
-  - Each value must have an explicitly named source (Database column, Input argument, Calculated derivation, or Settled architectural decision).
-  - Any required value lacking a named source represents an **Owed Decision**; agents are prohibited from making unrecorded architectural choices or guessing implementations under the guise of "just wiring". Stop and route to `/grill` or request user clarification.
-
----
-
-## 14. Architectural Slicing & Assumed Decision Governance
-
-- **4 Slicing Archetypes Framework (`devflow/reference/slicing-archetypes.md`)**:
-  - When decomposing large roadmaps or splitting oversized features, select from the 4 standard archetypes:
-    - **Skateboard**: Minimal functional loop (prove core logic end-to-end with minimal UI).
-    - **Facade**: Rich UI/DX with mock backend (validate user flow & interaction first).
-    - **Tracer Bullet**: Deep vertical slice across all layers (DB -> API -> UI) for 1 happy path.
-    - **Journey**: Slice along natural user workflow milestones.
-  - Avoid purely technical layer slicing (e.g. DB only or backend only) that leaves work unverifiable in a single delivery run.
-- **Assumed Decision Debt Lifecycle (`Status: Assumed`)**:
-  - For fast-tracking development when user confirmation is pending, record decisions in ADRs (`devflow/decisions/`) with `Status: Assumed`.
-  - Every assumed decision MUST specify `Assumption`, `Risk Level & Blast Radius`, and `Ratification Plan`.
-  - Untracked architectural assumptions are strictly prohibited.
-
----
-
-## 15. Test File Classification & AC Traceability Standards
-
-- **5-Tier Test Classification**:
-  - **Tier 1: Pure Logic & Algorithms** (`src/utils/`, `services/`, `lib/`): Fast in-memory Unit Tests, 100% boundary & edge cases coverage. Use TDD.
-  - **Tier 2: UI Components** (`src/components/`, `src/pages/`): Component mounting & event interaction, visual verification via Playwright / BrowserOS Neo. Prohibit trivial unit tests for static HTML markup.
-  - **Tier 3: API & Data Integration** (`src/api/`, route handlers, DB models): Contract tests, schema validation (Zod), status codes, payload shapes.
-  - **Tier 4: Config & Build Tooling** (`*.json`, `*.yaml`, `scripts/`): Static contract validation (`npm run check:static`), budget linters (`npm run check:budgets`), smoke tests.
-  - **Tier 5: Documentation & Prose** (`*.md`, `docs/`, `scripts/data/`): Structural checks, markdown contract scans, link integrity verification.
-- **Acceptance Criteria (`AC-N`) Traceability**:
-  - All automated test suites and assertion descriptions must explicitly include the target Acceptance Criterion tag (e.g. `it('AC-1: ...')`).
-  - During `/check`, verify that 100% of defined acceptance criteria in the active living spec have matching passing empirical proof.
-
----
 
-## 16. Token Economy & Cost Optimization Standards
-
-- **Token Economics Visibility**:
-  - Leverage `npm run analyze:tokens` (or `scripts/analyze-token-usage.ts`) to audit session token usage across Main Thread vs Subagents.
-  - Track the 4 token dimensions: **Fresh Input Tokens**, **Prompt Cache Write Tokens**, **Prompt Cache Read Tokens (Hits)**, and **Output Tokens**.
-- **Prompt Caching Optimization**:
-  - Structure documentation and context files with immutable headers first so LLM providers can achieve high prompt cache hit rates (>60%).
-  - Ensure living specs and references stay compact (under byte budgets) to prevent prompt cache misses and unnecessary token churn.
-- **Cost Metrics & Savings**:
-  - Track estimated model costs (USD) against model pricing catalogs (Claude 3.7/3.5 Sonnet, Gemini 2.5 Pro/Flash, GPT-4o).
-  - Aim for >50% cost savings through effective prompt caching reuse.

package/template/devflow/context/glossary.md

@@ -4,15 +4,15 @@
 
 ---
 
-### Task-Isolated Living Spec (`devflow/context/{xxx-slug}/spec.md`)
-- **Definition**: เอกสาร Markdown หลักหนึ่งฉบับต่อ runที่ใช้ขับเคลื่อนและบันทึกวงจรชีวิตของงานพัฒนาตั้งแต่ต้นจนจบ (Single Source of Truth during active delivery)
-- **Constraints**: ร่างหลาย run ได้พร้อมกัน แต่แต่ละ run แยก spec, stage, findings และ branch; เลือกเป้าหมายก่อน implement
+### Single Living Spec (`current-feature.md`)
+- **Definition**: เอกสาร Markdown กลางเพียงฉบับเดียวที่ใช้ขับเคลื่อนและบันทึกวงจรชีวิตของงานพัฒนาตั้งแต่ต้นจนจบ (Single Source of Truth during active delivery)
+- **Constraints**: มีได้เพียง 1 งานที่ active ในช่วงเวลาหนึ่งตามหลักการ Single Active Run Guardrail
 - **Structure**: ครอบคลุม 6 ส่วนหลัก: (1) Define & Boundaries, (2) Technical Spec & Contracts, (3) Execution Plan & TDD Tasks, (4) Implementation Log & Evidence, (5) Multi-Lane Verification Matrix, (6) Release Digest & Retrospective
-- **Aliases / Related**: `devflow/context/{xxx-slug}/spec.md`, Living Spec, Feature Spec
+- **Aliases / Related**: `current-feature.md`, Living Spec, Feature Spec
 
 ### Unified Fast-Track
 - **Definition**: รูปแบบการพัฒนาหลักแบบ Single-Track ของ Nexus-DevFlow ที่รวมความสามารถเชิงสถาปัตยกรรมระดับลึก (Deep) และความคล่องตัว (Fast) เข้าด้วยกันผ่าน 4 คำสั่งหลัก: `/feature` (หรือ `/fix`), `/implement`, `/check`, และ `/complete`
-- **Constraints**: ขับเคลื่อนผ่านไฟล์ `devflow/context/{xxx-slug}/spec.md` และเมื่อเสร็จสิ้นจะถูก Archive เป็นไฟล์ Markdown เดี่ยวใน `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`
+- **Constraints**: ขับเคลื่อนผ่านไฟล์ `current-feature.md` และเมื่อเสร็จสิ้นจะถูก Archive เป็นไฟล์ Markdown เดี่ยวใน `devflow/history/`
 - **Aliases / Related**: Fast-Track, Unified Track
 
 ### Pre-Flight Discovery
@@ -22,30 +22,10 @@
 
 ### Multi-Lane Verification Matrix
 - **Definition**: ตารางตรวจสอบคุณภาพแบบหลายมิติที่ครอบคลุม Typecheck, Linter, Automated Unit/Integration Tests, และ Manual Proof Evidence ในคำสั่ง `/check`
-- **Constraints**: ต้องมีหลักฐานผ่านสำหรับทุก Lane ที่ใช้กับงาน ส่วนที่ไม่เกี่ยวข้องให้บันทึก N/A พร้อมเหตุผล และไม่มี P0/P1 Finding ที่ยังค้างอยู่ก่อนที่จะส่งต่อไปยัง `/complete`
+- **Constraints**: ต้องมีผลลัพธ์ผ่าน (PASS) ครบทุก Lane และไม่มี P0/P1 Finding ที่ยังค้างอยู่ก่อนที่จะส่งต่อไปยัง `/complete`
 - **Aliases / Related**: QA Matrix, Lane Verification
 
 ### Release Digest & Retrospective
 - **Definition**: สรุปผลการเปลี่ยนแปลง, บทเรียนที่ได้รับ (Lessons Learned), และการตัดสินใจสำคัญที่บันทึกไว้ในตอนปิดรอบการพัฒนา
 - **Constraints**: บันทึกอัตโนมัติใน Living Spec ก่อนที่จะทำการ Squash Merge และ Archive
 - **Aliases / Related**: Delivery Digest, Retrospective Log
-
-### 4 Slicing Archetypes
-- **Definition**: รูปแบบมาตรฐาน 4 ประการในการแบ่งย่อยฟีเจอร์ (Skateboard, Facade, Tracer Bullet, Journey) เพื่อให้ได้รอบการส่งมอบที่เล็ก ทดสอบได้จริง และไม่ติดขัด Technical Layer Dependency
-- **Constraints**: ใช้งานใน `/discovery`, `/brainstorm`, และ `/feature` (Step 2)
-- **Aliases / Related**: `slicing-archetypes.md`, Feature Decomposition, Slicing Strategy
-
-### Assumed Decision Debt
-- **Definition**: หนี้การตัดสินใจที่เกิดขึ้นจากการตั้งสมมติฐานทางสถาปัตยกรรมชั่วคราว (`Status: Assumed` ใน ADR) เพื่อให้การพัฒนาเดินหน้าได้อย่างรวดเร็ว (Fast-track) โดยไม่สะดุด
-- **Constraints**: ต้องระบุ Assumption, Risk Level, และ Ratification Plan กำกับเสมอ และต้องได้รับการตรวจทาน/ยืนยัน (Ratified) ก่อนปล่อยสู่ Production
-- **Aliases / Related**: Assumed ADR, Decision Debt, Fast-track Assumption
-
-### AC-to-Test Traceability Matrix
-- **Definition**: ตารางเชื่อมโยงระหว่างข้อกำหนด Acceptance Criteria (`AC-N`) ใน Living Spec กับ Automated Test Cases และหลักฐานเชิงประจักษ์ เพื่อให้มั่นใจว่าทุกข้อกำหนดได้รับการทดสอบและพิสูจน์จริงแบบ 1-to-1
-- **Constraints**: ใช้ระบุใน Living Spec (`spec.md`), ตรวจทานใน `/check`, และกำกับด้วย `AC-N` Tag ในโค้ดทดสอบ
-- **Aliases / Related**: Traceability Matrix, AC Mapping, Spec Verification Trace
-
-### Prompt Caching Rate & Billed-Equivalent Cost
-- **Definition**: ดัชนีวัดประสิทธิภาพการใช้ Token ของ AI Coding Agent โดยแยกแยะระหว่าง Fresh Input Tokens, Cache Creation (Write), Cache Read (Prompt Caching Hits), และ Output Tokens เพื่อคำนวณต้นทุนจริง (USD) และ % ส่วนลดที่ประหยัดได้จาก Prompt Caching
-- **Constraints**: วิเคราะห์ผ่าน `scripts/analyze-token-usage.ts` และคำสั่ง `npm run analyze:tokens`
-- **Aliases / Related**: Token Economics, Cost Units, Cache Hit Rate

package/template/devflow/decisions/README.md

@@ -11,14 +11,10 @@ Each ADR is named `ADR-xxx-{slug}.md` (e.g. `ADR-001-database-schema-migration.m
 ```markdown
 # ADR-xxx: {Title}
 
-- **Status**: `Accepted` | `Proposed` | `Assumed` (Fast-tracked Assumption) | `Deprecated` | `Superseded by ADR-yyy`
+- **Status**: Accepted | Proposed | Deprecated | Superseded by ADR-yyy
 - **Date**: YYYY-MM-DD
 - **Context**: Problem statement, background, and why this decision was needed.
 - **Decision**: The selected architectural approach or invariant.
-- **Assumption Metadata** *(Mandatory when Status is `Assumed`)*:
-  - **Assumption**: ข้อสมมติฐานทางเทคนิคที่ตั้งขึ้นเพื่อปลดบล็อกการทำงานชั่วคราว
-  - **Risk Level & Blast Radius**: ระดับความเสี่ยงและขอบเขตผลกระทบหากข้อสมมติไม่ถูกต้อง
-  - **Ratification Plan**: เงื่อนไข, วันที่ หรือเหตุการณ์ที่จะทำการทวนสอบ (Ratify) เพื่อเปลี่ยนสถานะเป็น `Accepted` หรือ `Rejected`
 - **Alternatives Considered**:
   - *Option 1*: Pros / Cons
   - *Option 2*: Pros / Cons
@@ -26,13 +22,3 @@ Each ADR is named `ADR-xxx-{slug}.md` (e.g. `ADR-001-database-schema-migration.m
   - *Positive*: Benefits and capabilities unlocked
   - *Trade-offs / Risks*: Costs, complexity, or constraints
 ```
-
----
-
-## ⚡ Assumed Decision Debt Policy
-
-เมื่อทีมหรือ Agent จำเป็นต้องเดินหน้าพัฒนาอย่างรวดเร็ว (Fast-track) โดยที่ข้อสรุปทางสถาปัตยกรรมยังไม่ได้รับการยืนยัน 100% จากผู้ใช้ ให้บันทึก ADR ด้วย `Status: Assumed` พร้อมกรอก **Assumption Metadata** ให้ครบถ้วน
-
-> [!WARNING]
-> **Zero Untracked Decision Debt**: ทุก ADR ที่มีสถานะ `Assumed` จะถูกตรวจสอบโดย `/audit` และ `/complete` เพื่อแจ้งเตือนให้ทีมยืนยัน (Ratify) หรือปรับแก้ก่อนส่งมอบขึ้น Production เสมอ
-

package/template/devflow/docs/USAGE.md

@@ -0,0 +1,195 @@
+# Nexus-DevFlow 2.13.0 Comprehensive Usage Guide
+
+This guide provides full operating instructions for **Nexus-DevFlow 2.13.0 (The 3-Pillars Workspace Architecture & Pure Task-Isolated Living Spec Model)** across Google Antigravity, OpenAI Codex, Claude Code, Cursor, GitHub Copilot, and related AI development environments.
+
+---
+
+## 1. Core Architecture: The 3-Pillars Model
+
+Nexus-DevFlow structures development history and active context into three distinct temporal pillars:
+
+1. **🔮 Future (Backlog)**: [`devflow/ideas.md`](../ideas.md), [`devflow/project-plan.md`](../project-plan.md), [`devflow/build-plan.md`](../build-plan.md)
+   - Centralized Idea Inbox with AI feasibility, value scoring, and priority tagging (`[IDEA-xxx]`).
+   - Product vision and master build-plan sequencing.
+   - Quick idea capture via `/idea {description}`.
+2. **⚡ Present (Active Context)**: `devflow/context/`
+   - Global Shared Source of Truth: `project-overview.md`, `coding-standards.md`, `ai-interaction.md`, `glossary.md`.
+   - **Task-Isolated Workspaces**: `devflow/context/{xxx-slug}/`
+     - `spec.md`: The Living Spec, task checklist, and empirical proof.
+     - `stage.md`: Stage pointer and transition state.
+     - `findings.md`: Dedicated quality, security, and Fowler smell findings ledger.
+3. **📦 Past (History Archive)**: `devflow/history/`
+   - Categorized delivery archives: `features/`, `fixes/`, `rollbacks/`.
+   - Master Release Ledger: `HISTORY.md`.
+
+---
+
+## 2. The Unified 4-Stage Living Spec Lifecycle
+
+All development tasks execute through the progressive 4-stage task-isolated living spec lifecycle:
+
+```text
+/feature (or /fix) ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+| Step | Command | Artifact | Description |
+| :--- | :--- | :--- | :--- |
+| **1. Spec** | `/feature {title}`<br>`/fix {bug}` | `context/{xxx-slug}/spec.md` | Allocates sequential ID (`xxx-slug`), initializes task workspace, writes living spec behind review gate. |
+| **2. Build** | `/implement [id]` | `context/{xxx-slug}/spec.md` | Executes tasks incrementally with strict TDD discipline (Red-Green-Refactor) and evidence recording. |
+| **3. Verify**| `/check [id]` | `context/{xxx-slug}/spec.md` | Dual-Axis review: empirical spec fidelity plus independent standards, architecture, and quality gates. |
+| **4. Deliver** | `/complete [id]` | `history/{cat}/{xxx-slug}.md` | Final safety audit, records Release Digest, archives living spec, cleans active task folder, squash-merges branch. |
+
+---
+
+## 3. Pre-Flight Discovery, SA & Architectural Alignment Suite
+
+Before committing to delivery, use specialized companion skills:
+
+```text
+/analyze ──▶ /idea (Inbox) ──▶ /grill (Socratic ADR) ──▶ /discovery (Explore) ──▶ /feature (Deliver)
+```
+
+- **`/analyze`**: Multi-format requirement ingestion (PDF, Word, Excel, Images), Codebase Impact scan & Socratic Gap checklist.
+- **`/idea`**: Capture raw ideas in `devflow/ideas.md` with instant AI feasibility scoring.
+- **`/grill`** (or **`/align`**): Socratic alignment & domain modeling; records Architecture Decision Records (`devflow/decisions/ADR-xxx.md`).
+- **`/brainstorm`**: Structured ideation with trade-off analysis.
+- **`/discovery`**: Deep inception and exploratory discovery (`devflow/discoveries/DISC-xxx.md`).
+
+---
+
+## 4. Core Skills Inventory (33 Skills)
+
+DevFlow ships **33 bundled Core Skills** from the ordered `core_skills` inventory
+in `agent-bundle.manifest.json`, synchronized 1:1 across `.agents/skills/`
+(Codex / Antigravity / Copilot) and `.claude/skills/` (Claude Code). Local or
+Personal Skills may coexist in a workspace, but are excluded from the Core count
+and package template until explicitly promoted.
+
+### A. Lifecycle Delivery Skills (8 Skills)
+- `feature`: Turn a build-plan item or new idea into a task-isolated living spec (`devflow/context/{xxx-slug}/spec.md`).
+- `fix`: Document and spec an ad-hoc bug or issue into `devflow/context/{xxx-slug}/spec.md`.
+- `implement`: Step-by-step TDD implementation behind review gates.
+- `check`: Dual-Axis verification of observable spec behavior and independent architecture/standards quality.
+- `complete`: Final safety audit, Conventional Commit, archiving, and branch delivery gate.
+- `autopilot`: Bounded single-pass delivery loop with self-review and safe repair.
+- `continuous`: Autonomous serial multi-feature delivery loop completing build-plan items with quality gates.
+- `rollback`: Plan a safe reversal of a completed feature preserving history.
+
+### B. Pre-Flight Discovery, SA & Alignment Skills (6 Skills)
+- `analyze`: Multi-format requirement ingestion (PDF, Word, Excel, Images), Codebase Impact scan & Socratic Gap checklist.
+- `discovery`: Inception exploration and deep multi-turn planning (`devflow/discoveries/`).
+- `explore`: Read-only codebase exploration to investigate an idea and compare options without changing files or writing a spec.
+- `idea`: Quick idea capture and AI feasibility scoring (`devflow/ideas.md`).
+- `grill` / `align`: Socratic alignment, domain modeling, and ADR recording (`devflow/decisions/`).
+- `brainstorm`: Structured divergent & convergent ideation with trade-off matrices.
+
+### C. Workspace & Governance Skills (19 Skills)
+- `devflow`: Interactive workspace inspector and intent router.
+- `doctor`: Read-only health check for setup, adapters, and workflow drift.
+- `onboard`: Configure freshly scaffolded projects.
+- `adopt`: Bootstrap DevFlow into existing brownfield codebases.
+- `overview`: Compile living source of truth from planning docs.
+- `brief`: Feature scope and dependency briefing before speccing.
+- `audit`: Branch-aware or full-project code and security audit.
+- `bughunter`: Offensive security orchestrator, 83 vulnerability patterns & CVE payloads.
+- `ci`: Set up single Verify command and GitHub Actions.
+- `test`: Test suite runner and coverage analyzer.
+- `setup-tests`: Add or normalize unit test suite.
+- `browser-tests`: Add or normalize Playwright browser test harness & connect with MCP browseros-neo.
+- `release`: Cloud deployment readiness check (Render / Vercel).
+- `prototype`: Static HTML/CSS prototype mockups.
+- `status`: Progress summary and next action inspector.
+- `try`: Manual review testing guide.
+- `debug`: Scientific six-phase diagnosis built around a deterministic red-capable feedback loop.
+- `report-html`: Generate interactive standalone HTML report dashboard.
+- `convert-any-to-md`: Document conversion utility into markdown.
+
+---
+
+## 5. Quality, Governance & Authoring Contracts
+
+- [Workflow surface map](workflow-surface-map.md): canonical command taxonomy and artifacts.
+- [Skill selection policy](skill-selection-policy.md): choose the smallest suitable workflow surface.
+- [Governance rules](governance-rules.md): public-surface and documentation placement rules.
+- [Markdown metadata contract](markdown-metadata-contract.md): frontmatter and semantic heading requirements.
+- [Manual review workflow](manual-review-workflow-spec.md): review gates from spec through delivery.
+- [Living Spec examples](examples/living-spec/): reference specs, discoveries, ADRs, and ideas.
+
+`/check` applies the Deep Modules standard independently from spec fidelity:
+small public interfaces, hidden complexity, stable seams, and no speculative
+abstraction. `/debug` diagnoses first and hands confirmed repairs to `/fix` or
+`/implement`; it does not edit source during diagnosis.
+
+---
+
+### Debugging, TDD & Review Reference Guides
+
+The `debug`, `implement`, and `audit` skills include five English reference guides.
+They are supporting files read when needed, not additional commands. Both
+`.agents/skills/` and `.claude/skills/` contain matching copies; no separate
+Superpowers plugin installation is required.
+
+| Situation | Entry point | Reference guide |
+| :--- | :--- | :--- |
+| Error deep in a call stack or unclear input origin | `/debug` Phase 4 | [Root-cause tracing](../../.agents/skills/debug/root-cause-tracing.md) |
+| Confirmed root cause needs protective checks | `/debug` repair planning → `/fix` → `/implement` | [Defense-in-depth](../../.agents/skills/debug/defense-in-depth.md) |
+| Flaky async tests or guessed sleep delays | `/debug` Phase 4 | [Condition-based waiting](../../.agents/skills/debug/condition-based-waiting.md) |
+| Planning RED/GREEN or inspecting test quality | `/implement [id]` | [TDD anti-patterns](../../.agents/skills/implement/tdd-anti-patterns.md) |
+| Preparing an independent review | `/audit independent current` | [Two-stage review template](../../.agents/skills/audit/two-stage-review-template.md) |
+
+**Debugging:** Trace the trigger before planning a repair. Use validation layers
+according to actual invariants and risks, and keep diagnostic output redacted.
+The waiting example accepts synchronous predicates only; async I/O needs an
+appropriate async helper with cancellation or timeout. `/debug` remains a
+diagnostic stage. After three unsuccessful repair attempts in the supplied
+history, stop and discuss the architecture before attempting another fix.
+
+**Implementation:** Apply the Iron Law to behavior changes according to the
+spec's test decision: observe the intended failing test before production code.
+Confirm that RED reflects missing behavior rather than broken setup, implement
+the minimum change for GREEN, then refactor with tests passing. Preserve existing
+user work; verify documentation or configuration without logic as the spec directs.
+
+**Review:** Check spec compliance first, then code quality only after Stage 1
+passes. Use the template alongside the canonical
+[independent-review contract](../../.agents/skills/audit/reference/independent-review.md).
+The configured gate still determines whether review runs, and its request,
+immutable checkpoint, reviewer identity, and receipt requirements remain in force.
+Open or fixed P0/P1 findings continue to block completion.
+
+Example prompts (use `$debug` and `$implement` in Codex where appropriate):
+
+```text
+/debug "This async test passes locally but times out in CI; inspect its waiting conditions"
+/implement 085
+/audit independent current
+```
+
+Replace `085` with your active task ID. For the review prompt, ask the reviewer
+to use `audit/two-stage-review-template.md` with the canonical receipt contract;
+the template does not launch a reviewer or authorize a checkpoint commit itself.
+
+---
+
+## 6. Web Dashboard & CLI Management
+
+```bash
+# Launch interactive Local Dashboard (0ms SSR Hydration & Git Cache)
+npx @jakkrichm/create-nexus-devflow dashboard
+
+# Check active project status across 3-Pillars
+npx @jakkrichm/create-nexus-devflow status
+
+# Automated Quality Gatekeeper
+npx @jakkrichm/create-nexus-devflow gate [--strict]
+
+# Model Context Protocol (MCP) Server Hub
+npx @jakkrichm/create-nexus-devflow mcp
+
+# Just-In-Time (JIT) Dynamic Context Slicing
+npx @jakkrichm/create-nexus-devflow slice --stage implement
+
+# Multi-Agent Swarm & Code Graph RAG
+npx @jakkrichm/create-nexus-devflow swarm
+npx @jakkrichm/create-nexus-devflow graph --file src/index.ts
+```