@jakkrichm/create-nexus-devflow 2.17.8 → 2.18.0

package/template/AGENTS.md

@@ -11,26 +11,18 @@ This project uses **Nexus-DevFlow**, an agentic workflow layer supporting **The
 
 To start a new project, scaffold the application first in an empty folder, then run `npx nexus-devflow` (or `npm create @jakkrichm/nexus-devflow`) to overlay DevFlow onto your codebase.
 
-## Load context for the task
+## Read these for full context
 
-Reuse instructions already loaded. Read relevant sections, rather than every document before every edit:
-
-- `devflow/config.json` for workflow policy and quality-gate decisions.
-- `devflow/context/project-overview.md` for project purpose, architecture, and cross-module boundaries.
-- `devflow/context/coding-standards.md` for conventions affecting changed code.
-- `devflow/context/ai-interaction.md` for workflow interaction and review cadence.
-- `devflow/context/glossary.md` when domain terminology matters.
-- `devflow/context/{xxx-slug}/` for the selected run's spec, stage, findings, and review receipt.
-
-## Task intent and authorization
-
-Explicit user scope takes precedence over skill guidance, within runtime permissions and safety constraints. A request to draft a spec ends at the spec; a request to implement and verify continues through those authorized steps. A skill transition is not a new approval requirement. Ask when a material decision or authorization is missing, reuse existing authorization, and identify the exact instruction if it requires a pause. Preserve separate authorization for commit, merge, push, and deployment.
-
-Use focused checks during edits, and run the documented required gates before handoff. Repeat passing checks only after relevant changes, failures, or unresolved concerns. Apply TDD to logic and behavior changes; documentation-only edits need appropriate structural or review evidence.
+- `devflow/config.json` - deterministic project workflow settings
+- `devflow/context/project-overview.md` - the project's source of truth
+- `devflow/context/coding-standards.md` - engineering conventions & rules to follow
+- `devflow/context/ai-interaction.md` - how to interact with the user on this project
+- `devflow/context/glossary.md` - domain terms & architecture definitions
+- `devflow/context/{xxx-slug}/` - active task living spec, stage, findings ledger, and independent review receipt
 
 ## Proportional engineering
 
-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.
+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.
 
 - Unknown scale or extensibility defaults to the smaller reversible design. Do not infer enterprise, multi-tenant, hostile-user, or compliance requirements.
 - Derive trust and data-integrity boundaries from actual reachability: untrusted input, auth/session/ownership, shared persisted data, destructive operations, payments, secrets, and sensitive data.
@@ -69,7 +61,37 @@ Unused adapter families can be removed. Codex, Antigravity, GitHub Copilot, and
 3. **Google Antigravity & Claude Code**: Native skill engines automatically discover and surface `.agents/skills/` and `.claude/skills/`.
 4. **State-Aware Inspection**: When unsure what to do next, invoke `devflow` to automatically inspect active task directories in `devflow/context/{xxx-slug}/`, `devflow/discoveries/`, and `devflow/ideas.md`.
 5. **Default Artifact & Communication Language (Thai)**: All generated markdown stage artifacts (`spec.md`, `discovery.md`, etc.) and user communication MUST default to **Thai (`th`)**, while code, technical terms, file paths, and identifiers remain in English.
-6. **Contextual Help**: When a DevFlow command is invoked with `help`, `--help`, `-h`, or `?`, read [the playbook protocol](devflow/reference/help-playbook-protocol.md). Produce its help deliverable without running the command's primary action or creating a task run.
+6. **Universal Contextual Help & Playbook Protocol (`help`, `--help`, `-h`, `?`)**:
+   Whenever any skill or command is invoked with a help keyword or flag (e.g., `/bughunter help`, `bughunter --help`, `/archify -h`, `/check ?`, `/feature help`):
+   - **Execution Safety Gate**: DO NOT execute the skill's primary or mutating actions (do not launch scans/attacks, do not modify source code, and do not initialize new task runs).
+   - **Dynamic Workspace Inspection**: Read the target skill definition (`.agents/skills/<skill>/SKILL.md`, `.claude/skills/<skill>/SKILL.md`, and any vendored resources such as `devflow/.vendor/<skill>/`), then scan the active workspace (`devflow/context/project-overview.md`, `package.json`, tech stack, active tasks, endpoints, and file hierarchy).
+   - **Persistent HTML Playbook & Token-Saving Cache**:
+     - **Output Location & Light Theme Mandate**: Compile and persist the tailored playbook as a standalone, styled HTML report at `devflow/docs/playbooks/{skill}.html` adhering to the **Paper/Ink Light Theme Standard** (`data-theme="light"`, teal accent, ruler corner, terminal mockup UI, and diagram slot per `devflow/docs/playbooks/template.html`). Never generate dark-mode-first documentation.
+     - **First Run**: Render the comprehensive 5W1H playbook in chat and write the complete HTML report to `devflow/docs/playbooks/{skill}.html`.
+     - **Subsequent Invocations (Delta Updates & Zero Token Bloat)**: If `devflow/docs/playbooks/{skill}.html` already exists:
+       - Inspect the existing HTML file and compute the diff/delta against the current repository state (e.g., new file paths, modified endpoints, or newly installed vendor assets).
+       - DO NOT repeat unchanged boilerplate or full static content in chat.
+       - Provide a concise **Delta Summary** in chat (highlighting what changed, new recommendations, or newly available commands).
+       - In-place update `devflow/docs/playbooks/{skill}.html` with the fresh timestamp and state.
+       - Provide a direct clickable link to [devflow/docs/playbooks/{skill}.html](file:///d:/devtools/nexus-devflow/devflow/docs/playbooks/{skill}.html) for browser viewing.
+   - **Render the User-Friendly 5W1H Playbook**: Emit an easy-to-read, practical guide organized around the **5W 1H Framework** (rendered on initial run or updated in the HTML playbook):
+      1. **What (Concept & Capabilities)**: Clear, jargon-free summary of what this skill does, its core concept, and its bundled tools/capabilities.
+      2. **Why (Problems Solved & Key Benefits)**: The problems it solves, key advantages, and why you should use it instead of ad-hoc manual work.
+      3. **Who (Target Roles & Personas)**: Target audience or engineering role (e.g., Feature Developer, Senior QA, Security Auditor, Solo Dev, or Tech Lead).
+      4. **Where (Boundaries & Artifact Locations)**: Target workspace boundaries, affected directories, and generated artifact locations (e.g., `devflow/context/`, `devflow/discoveries/`, `findings.md`).
+      5. **When (Timing & Prerequisites/Next Steps)**:
+         - **Timing & Triggers**: Practical situations or milestones when this skill should be invoked.
+         - **Run Before (Prerequisites)**: What to check, prepare, or run beforehand to get the best result.
+         - **Run After (Next Steps)**: What DevFlow command or lifecycle stage should follow next (e.g., handing off to `/fix`, `/feature`, or `/complete`).
+      6. **How (Execution Lifecycle & Real Command Examples)**:
+         - **How It Works (Lifecycle)**: Simple, plain-language breakdown of the execution steps or phases.
+         - **Available Commands & Options**: Common sub-commands, arguments, and flags with brief explanations.
+         - **Safety, Guardrails & Precautions**: Operational boundaries, credential hygiene, read-only vs. mutating constraints, and explicit special safety constraints / precautions.
+      7. **Diagram Slot & Architecture Flow**:
+         - **Real Diagram Mandate**: MUST embed a real, verified vector SVG or interactive diagram reflecting actual skill lifecycle, state transitions, or threat models in Light Theme (`data-theme="light"`).
+         - **Thai Language & Legible Typography**: Architecture and flow diagrams must describe workflows and nodes in Thai language while preserving technical identifiers, paths, and commands in English. Typography must be sufficiently sized and legible for Thai script (Headers 13–14px, box content/descriptions 11–12px, line spacing 18–22px) to prevent tone marks and vowels from clipping or overlapping.
+         - **Strictly No Placeholders**: NEVER output empty placeholder cards, generic instruction text, or phrases like *"when invoking archify..."*. Every playbook must ship with a real visual architectural diagram.
+   - Always conclude the response with: `"Help menu displayed successfully"`.
 
 ---
 

package/template/devflow/build-plan.md

@@ -8,7 +8,7 @@
 
 ## 🚀 Phase 1: Core Foundation & Data Layer
 
-- [ ] 1. **Core Schema & Data Models** - สร้าง Data Models, Schemas (Zod) และ Database Migrations เบื้องต้น
+- [x] 1. **Upstream AI Blueprint Synchronization & Zero-Regression Fusion** - ผสานฟีเจอร์เด่นจาก Upstream (explore skill, proportional engineering, update adapter switcher, CI pre-push hook) ตัด dark mode ออก และปกป้องสถาปัตยกรรมของ DevFlow (Ref: DISC-20260929-001)
 - [ ] 2. **Base Layout & Main UI Shell** - วางโครงสร้างหน้าจอหลัก, Navigation Shell และ Design Tokens
 - [ ] 3. **Primary Feature Flow** - พัฒนาฟังก์ชันการทำงานหลัก พร้อม Input Form และ Validation
 

package/template/devflow/context/ai-interaction.md

@@ -8,7 +8,7 @@
 
 - **Be Concise and Direct**: State conclusions, status, and findings first; provide supporting context afterward.
 - **Explain Non-Obvious Decisions Briefly**: Highlight architectural trade-offs, edge-case rationale, or safety considerations in 1–2 sentences.
-- **Authorization**: Reuse explicit authorization already given for the requested work. Ask before destructive actions or material architectural changes outside that scope. Identify the instruction requiring a pause; routine implementation choices do not require renewed approval.
+- **Ask Before Destructive or Architectural Changes**: Always obtain explicit confirmation before deleting files, executing major refactors, or altering public interfaces.
 - **Don't Add Unplanned Scope**: Stick strictly to the Acceptance Criteria defined in the spec. Avoid adding "nice-to-have" features that were not requested.
 - **Preserve Existing Codebase Patterns**: Respect existing file structure, typing patterns, naming conventions, and deep module boundaries.
 
@@ -21,8 +21,8 @@ Format every response for fast scanning and readability:
 - **Real Markdown, Not Prose Walls**: Use bold labels, concise bullet points, and blank lines between blocks.
 - **Enumerations Are Lists**: Numbered or bulleted lists for sequential steps or findings, never inline runs crammed into paragraphs.
 - **Tables for Comparative Matrices**: Use markdown tables when comparing status, options, test results, or trade-offs.
-- **Backticks for Code References**: Wrap file paths, variable names, functions, CLI flags, and commands in backticks (e.g. `devflow/context/{xxx-slug}/spec.md`, `npm run check`).
-- **Clickable File Links**: Use the active client's supported local-file link format with the actual resolved path.
+- **Backticks for Code References**: Wrap file paths, variable names, functions, CLI flags, and commands in backticks (e.g. `current-feature.md`, `npm run check`).
+- **Clickable File Links**: Use GitHub-style markdown links with `file://` scheme (e.g. `[current-feature.md](file:///d:/path/to/current-feature.md)`).
 - **Lead With the Result**: State pass/fail status or completed action before presenting logs.
 
 ---
@@ -97,7 +97,7 @@ After the first successful `/overview`, DevFlow offers a reviewed local commit f
 ## 4. Strict TDD & Two-Stage Review Interaction Rules
 
 ### 🔴🟢 Strict TDD Execution Discipline
-For logic and behavior changes during `/implement`, follow the spec's test decision:
+During implementation in `/implement`:
 - **Show Red Phase**: First execute tests to demonstrate expected failure *before* adding production code.
 - **Show Green Phase**: Add minimal production code, re-run tests, and report pass rate.
 - **Show Refactor Phase**: Polish and clean up with zero test regression.
@@ -111,10 +111,10 @@ During `/check`:
 
 ### ⚡ Review Cadence & Implementation Loop
 - **Efficient Default (`stepReview: "feature"`)**: Presents one comprehensive review packet after all implementation steps of the feature complete, with step checkpoint commits disabled (`checkpointCommits: "disabled"`). This minimizes review fatigue and saves context window tokens.
-- **Guided Review (`stepReview: "every"`)**: Available for high-risk changes, pair programming, or instructional sessions. Pauses for user approval after each small step. Offer optional checkpoints only if `checkpointCommits: "enabled"`.
+- **Guided Review (`stepReview: "every"`)**: Available for high-risk changes, pair programming, or instructional sessions. Pauses for user approval after each small step and offers checkpoint commits (`checkpointCommits: "enabled"`).
 - **Post-Implementation Walkthrough**: After the final review packet, `/implement` always offers an optional read-only walkthrough of the finished code, regardless of review cadence or checkpoint settings.
 - **Independent Review Execution**: Regular and Continuous independent review default to `when-sensitive`, while `review.independentExecution` defaults to `automatic` (spawning an isolated reviewer child when the active adapter supports it). Setting `review.independentExecution: "manual"` produces the fresh-session handoff.
-- **Configuration**: Managed directly in `devflow/config.json`. The two workflow keys are independent: `every` does not imply checkpoints are enabled, and `enabled` never grants commit authorization. Use the implementation skill's cadence contract for all four combinations.
+- **Configuration**: Managed directly in `devflow/config.json`.
 
 ---
 
@@ -131,17 +131,16 @@ During `/check`:
 
 Progress lives in persistent files, not in transient chat history:
 
-- In the selected run: `devflow/context/{xxx-slug}/spec.md` maintains ticked checklist boxes `- [x]`.
+- In Fast-Track: `devflow/context/current-feature.md` maintains ticked checklist boxes `- [x]`.
 - In Git: Commits, branches, and working tree maintain the code history.
-- When starting a fresh session after a context clear, resolve the run from an explicit ID or current branch, then inspect `devflow/context/{xxx-slug}/stage.md` and its spec to pick up immediately from the next pending step.
+- When starting a fresh session after a context clear, run `devflow` or inspect `current-stage.md` to pick up immediately from the next pending step.
 
 ---
 
-## 6. Multi-Run Isolation
+## 6. Single Active Run Guardrail (One Thing at a Time)
 
-- Multiple specs may be queued in `devflow/context/{xxx-slug}/` without blocking new drafts.
-- Select a run by explicit ID, matching branch, or the sole active candidate. Ask only when the target remains ambiguous.
-- Keep each run's spec, stage, findings, and branch separate. Protect unrelated working-tree changes before switching; use an isolated worktree when concurrent implementation requires it.
+- Only one active Single Living Spec run is allowed at a time.
+- The AI will actively block opening a new feature or fix until the current one is completed with `/complete` (or explicitly rolled back/cancelled).
 
 ---
 
@@ -178,14 +177,14 @@ Progress lives in persistent files, not in transient chat history:
 Nexus-DevFlow natively supports extending workflow capabilities with **Third-Party Skills** (installed via `nexus-devflow skill add <repo-or-path>`):
 
 ### 🧩 1. Discovery & Inventory
-- Reuse the available skill catalog. Inspect the active adapter or run `nexus-devflow skill list` only when a required capability is not already known.
+- Core workflow commands and AI agents automatically inspect `.agents/skills/` (and `.claude/skills/`) or run `nexus-devflow skill list` to discover installed third-party capabilities.
 - Installed third-party skills maintain their exact original directory structure, references, assets, scripts, and `SKILL.md`.
 
 ### 🎯 2. Cross-Command Delegation & Genuine Execution
-- **Verbatim & Original Prompt Fidelity**: When a DevFlow stage requires specialized domain expertise (e.g., editorial diagramming, system mapping, domain modeling, cloud provisioning, UI benchmarking), the AI agent must read the third-party skill's `SKILL.md` (e.g. `.agents/skills/archify/SKILL.md` or `.agents/skills/diagram-design/SKILL.md`) and apply the relevant workflow within the user's requested scope. Explicit user instructions take precedence over skill guidance; reuse existing authorization rather than adding approval gates.
+- **Verbatim & Original Prompt Fidelity**: When a DevFlow stage requires specialized domain expertise (e.g., editorial diagramming, system mapping, domain modeling, cloud provisioning, UI benchmarking), the AI agent must read the third-party skill's `SKILL.md` (e.g. `.agents/skills/archify/SKILL.md` or `.agents/skills/diagram-design/SKILL.md`) and strictly follow its original instructions, philosophy, style guide gates, and complexity constraints.
 - **Workflow Command Integration Map**:
   - **`/discovery`**: When macro roadmap planning or micro pre-flight exploration involves system architecture, IT landscape, data pipelines, sequence flows, or user journeys, check for `archify` (for interactive system maps, data flows, and sequence traces) or `diagram-design` (for editorial and business layouts).
-  - **`/feature` & `/fix`**: When a diagram materially clarifies Section 2 (`## 📐 2. Technical Spec & Contracts`), use `archify` for interactive component diagrams, state machines, and sequence traces, or `diagram-design` for database ER models.
+  - **`/feature` & `/fix`**: In Section 2 (`## 📐 2. Technical Spec & Contracts`), invoke `archify` for interactive component diagrams, state machines, and sequence traces, or `diagram-design` for database ER models.
   - **`/implement`**: Seamlessly consumes Tracer-Bullet Tickets generated by Matt Pocock's `/to-tickets` (`.scratch/<feature>/issues/`, `devflow/context/{xxx-slug}/tickets/`), resolving the unblocked Frontier and executing with Strict TDD.
   - **`/brainstorm` & `/grill`**: Leverage visual trade-off matrices (Quadrant, Radar spider) or domain models (UML class, ER).
   - **`/prototype` & `/report-html`**: Embed standalone HTML/SVG assets seamlessly.

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,194 @@
+# 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 (32 Skills)
+
+DevFlow ships **32 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 (5 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/`).
+- `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
+```