@jakkrichm/create-nexus-devflow 2.0.25 → 2.1.0

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

@@ -1,27 +1,37 @@
 ---
 name: feature
-description: "[Devflow] Fast-Track Feature stage in DevFlow (Blueprint Mode) - define, spec, plan, and create the living current-feature.md contract in context for new features."
-argument-hint: "{feature title, IDEA-xxx, or feature description}"
+description: "[Devflow] Fast-Track Feature stage in DevFlow (Blueprint Mode) - turn a build-plan item, sub-feature (4a, 4b), idea, or requirement into the living current-feature.md contract with automatic sizing & splitting."
+argument-hint: "{feature title, number, 4a, IDEA-xxx, or empty for next item}"
 ---
 
 # Fast-Track: Feature (Blueprint Mode)
 
 $ARGUMENTS
 
-Fast-Track entry point combining Discovery, Definition, Specification, and Implementation Planning into one streamlined, review-gated step for **new features or enhancements**. Creates and maintains the **Single Living Spec (`devflow/context/current-feature.md`)** for the feature run. Supports intake from Idea Inbox (`IDEA-xxx`).
+Fast-Track entry point combining Discovery, Definition, Specification, and Implementation Planning into one streamlined, review-gated step for **new features or enhancements**. Creates and maintains the **Single Living Spec (`devflow/context/current-feature.md`)** for the feature run. Supports intake from Build Plan (`devflow/build-plan.md`), Sub-features (`4a`, `4b`), or Idea Inbox (`IDEA-xxx`).
+
+Includes built-in **Multi-Factor Sizing Heuristic & Interactive Split Gate** to prevent context overflow on oversized tasks (`L`/`XL`).
+
+---
 
 ## Invocations & Aliases
 
-- `/feature <title>` or `feature <title>`: Fast-Track feature specification
+- `/feature`: Specs the next unchecked feature from `devflow/build-plan.md`
+- `/feature <number | title>`: Specs a specific feature from the build plan or a new requirement
+- `/feature <number[a-z]>` (e.g. `/feature 4a`): Specs a specific sub-feature
 - `/feature IDEA-xxx`: Intake and promote a pending idea from `devflow/ideas.md`
 - `$feature`: Codex CLI invocation
 
+---
+
 ## Fast-Track Mainline Workflow
 
 ```text
 /feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
 ```
 
+---
+
 ## Behavior & Contract
 
 When invoked:
@@ -31,18 +41,53 @@ When invoked:
 2. If `Active Running ID` is not `None` and `Current Stage` is not `Idle`, or if `current-feature.md` contains an active uncompleted spec:
    - **HALT and reject opening a new feature**.
    - Explain to the user that an active run is currently in progress:
-     > ⚠️ *"มีงาน `{active_id}` กำลังดำเนินการอยู่ กรุณาปิดงานเดิมด้วย `/complete` หรือ `70-release` (หรือสั่ง `/rollback`) ก่อนเริ่มงานใหม่"*
+     > ⚠️ *"มีงาน `{active_id}` กำลังดำเนินการอยู่ กรุณาปิดงานเดิมด้วย `/complete` หรือ `70-deliver` (หรือสั่ง `/rollback`) ก่อนเริ่มงานใหม่"*
+
+---
+
+### 2. Sizing Heuristic & Sub-Feature Splitting Engine
+
+Before locking the spec, evaluate the target scope:
 
-### 2. Work Identity & Idea Intake
-1. **Idea Inbox Intake**: If the argument is an idea identifier (e.g. `IDEA-001`):
+1. **Multi-Factor Sizing Heuristic**:
+   - **Files Touched**: $\ge 6$ files predicted to be created or modified.
+   - **Architectural Layers**: $\ge 3$ distinct layers (e.g. DB Schema/Migration + Backend API + Frontend UI + State Store).
+   - **Task Complexity**: $\ge 6$ checklist tasks or heavy multi-service integrations.
+2. **Interactive Split Gate**:
+   - If the feature is assessed as `L` or `XL` and no explicit sub-feature notation (`4a`) was requested:
+     - **Draft Sub-Feature Proposals**: Break into 2-3 focused sub-features (e.g. `4a: Backend Schema & Core APIs (Size: M)`, `4b: Frontend UI & Client State (Size: M)`).
+     - **Prompt User in Thai**:
+       > ⚠️ *"ฟีเจอร์นี้มีขนาดใหญ่ (`L`/`XL`) เพื่อรักษาคุณภาพและป้องกัน Context Overflow แนะนำให้แบ่งเป็น sub-features ดังนี้:*  
+       > *- `4a: [ขอบเขตย่อยส่วนที่ 1]` (Size: M)*  
+       > *- `4b: [ขอบเขตย่อยส่วนที่ 2]` (Size: M)*  
+       > *คุณต้องการให้เปิด Spec เริ่มทำ `4a` ทันทีเลยไหมครับ?"*
+     - If the user confirms or provides a sub-feature argument (e.g. `4a`), proceed with the sub-feature spec.
+
+---
+
+### 3. Work Identity & Source Resolution
+
+1. **No Argument**:
+   - Inspect `devflow/build-plan.md` (or `devflow/ideas.md`).
+   - Pick the first unchecked feature (`- [ ]`) or sub-feature (`- [ ] 4a.`) in sequence.
+2. **Sub-Feature Notation** (e.g. `4a`, `038b-slug`):
+   - Allocate sub-feature running ID with alpha suffix: `xxx[a-z]-slug` (e.g. `038a-auth-schema-and-api`).
+   - Set Git branch: `feature/xxx[a-z]-slug`.
+3. **Idea Inbox Intake** (e.g. `IDEA-001`):
    - Read `devflow/ideas.md` and extract the idea's title, raw problem statement, AI Feasibility notes, and Quick Seed points.
-   - Use these details as the primary input for Specification & Scope.
    - In `devflow/ideas.md`, update the item's status to `[x] Claimed ({ID})` and move it under `## 📦 Archived / Shipped Ideas`.
-2. Inspect `devflow/history/HISTORY.md` and determine the next sequential ID without prefix (e.g. `022-{slug}`).
-3. Identify Git branch naming:
-   - `feature/{xxx-slug}`
+4. **Number or Title**:
+   - Match item in `devflow/build-plan.md` or treat as a new planned addition.
+5. Determine next sequential ID:
+   - For standard feature: `xxx-slug` (e.g. `038-payment-gateway`).
+   - For sub-feature: `xxx[a-z]-slug` (e.g. `038a-payment-api`, `038b-payment-ui`).
+6. Identify Git branch naming:
+   - `feature/{ID}`
+
+---
+
+### 4. Generate the Living Spec (`devflow/context/current-feature.md`)
 
-### 3. Generate the Living Spec (`devflow/context/current-feature.md`)
 Write `devflow/context/current-feature.md` using the structured template below in **Thai (`th`)**:
 
 ```markdown
@@ -93,7 +138,9 @@ Write `devflow/context/current-feature.md` using the structured template below i
 - *(จะถูกบันทึกเมื่อรัน /complete)*
 ```
 
-### 4. Update Workspace Status
+---
+
+### 5. Update Workspace Status
 Update `devflow/context/current-stage.md`:
 - `Active Discovery ID`: `None`
 - `Active Running ID`: `{ID}`
@@ -101,8 +148,10 @@ Update `devflow/context/current-stage.md`:
 - `Living Spec`: `devflow/context/current-feature.md`
 - `Last Updated`: `{YYYY-MM-DD}`
 
-### 5. Output Summary & Next Step
-Report to the user:
-- Running ID and allocated branch
-- Summary of Scope and Acceptance Criteria
-- Explicit next step: `/implement`
+---
+
+### 6. Output Summary & Next Step
+Report to the user in **Thai (`th`)**:
+- Running ID and allocated branch (`feature/{ID}`)
+- Summary of Scope, Acceptance Criteria, and Sizing evaluation
+- Explicit next step: `/implement` (หรือ `$implement`)

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

@@ -31,7 +31,7 @@ When invoked:
 2. If `Active Running ID` is not `None` and `Current Stage` is not `Idle`, or if `current-feature.md` contains an active uncompleted spec:
    - **HALT and reject opening a new fix**.
    - Explain to the user that an active run is currently in progress:
-     > ⚠️ *"มีงาน `{active_id}` กำลังดำเนินการอยู่ กรุณาปิดงานเดิมด้วย `/complete` หรือ `70-release` (หรือสั่ง `/rollback`) ก่อนเริ่มงานใหม่"*
+     > ⚠️ *"มีงาน `{active_id}` กำลังดำเนินการอยู่ กรุณาปิดงานเดิมด้วย `/complete` หรือ `70-deliver` (หรือสั่ง `/rollback`) ก่อนเริ่มงานใหม่"*
 
 ### 2. Work Identity & Issue Intake
 1. **Idea / Issue Inbox Intake**: If the argument is an identifier (e.g. `IDEA-001`):

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

@@ -44,7 +44,7 @@ Insert the new idea block directly under `## 📌 Pending Ideas` in `devflow/ide
 - **Quick Seed (กันลืม)**:
   1. {ประเด็นสำคัญที่ 1}
   2. {ประเด็นสำคัญที่ 2}
-- **สถานะ**: `Pending` (หยิบไปทำได้ด้วย `/spec IDEA-001` หรือ `/00-discover IDEA-001`)
+- **สถานะ**: `Pending` (หยิบไปทำได้ด้วย `/spec IDEA-001` หรือ `/00-explore IDEA-001`)
 ```
 
 *(หากมีข้อความ `*(ยังไม่มีไอเดียค้างอยู่...)*` ให้ลบออกเมื่อมีไอเดียแรก)*
@@ -54,4 +54,4 @@ Report to the user:
 - Allocated Idea ID: `[IDEA-xxx]`
 - Summary of Feasibility & Value analysis
 - Seed points saved
-- Instructions for promotion: "เมื่อพร้อมลงมือทำ สามารถพิมพ์ `/spec IDEA-xxx` หรือ `/00-discover IDEA-xxx` ได้ทันที"
+- Instructions for promotion: "เมื่อพร้อมลงมือทำ สามารถพิมพ์ `/spec IDEA-xxx` หรือ `/00-explore IDEA-xxx` ได้ทันที"

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

@@ -8,8 +8,8 @@ description: "[Devflow] Set up Nexus-DevFlow after overlaying it onto a freshly
 Where this sits in the workflow:
 
 ```text
-scaffold app  ->  overlay DevFlow  ->  [onboard]  ->  00-discover or 10-define  ->  Mainline Loop
-(user/tool)       (create-nexus)       (tune setup)   (discovery / run scoping)      (20-spec -> 70-release)
+scaffold app  ->  overlay DevFlow  ->  [onboard]  ->  00-explore or 10-define  ->  Mainline Loop
+(user/tool)       (create-nexus)       (tune setup)   (discovery / run scoping)      (20-spec -> 70-deliver)
 ```
 
 `onboard` is the fresh-project on-ramp for Nexus-DevFlow. It assumes the application was scaffolded first (e.g. via `create-next-app`, `create-vite`, `cargo new`, etc.) and DevFlow was overlaid after.
@@ -125,5 +125,5 @@ Present a concise onboarding summary report:
 - Files tuned during onboarding
 - Adapter status (`.agents/`, `.claude/`)
 - Recommended next step:
-  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the first feature or product direction
+  - Run `00-explore` (or `00-explore`, `$00-explore`) to explore the first feature or product direction
   - Run `10-define` (or `10-define`, `$10-define`) if the initial delivery slice is already clear and ready for execution

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

@@ -1,114 +1,65 @@
 ---
 name: overview
-description: "[Devflow] Scan codebase architecture, data models, and shipped history to synthesize or refresh devflow/context/project-overview.md as the living source of truth."
+description: "[Devflow] Distill user-owned planning docs into `devflow/context/project-overview.md` using a deterministic compiler so the workspace context stays live and generated, not hand-authored."
 ---
 
-# overview - Living Context Synthesis & Sync
+# overview - dynamic project overview compiler
 
-Where this sits in the workflow:
+## Position in workflow
 
 ```text
-codebase + devflow/history/HISTORY.md  ->  [overview]  ->  devflow/context/project-overview.md  ->  00-discover / 10-define / 20-spec
-(reality & shipped runs)                    (sync &         (living source of truth)             (informed planning)
-                                             synthesize)
+project-plan.md + build-plan.md + history + codebase signals
+            -> scripts/overview.ts
+            -> devflow/context/project-overview.md
+            -> /feature / fix / check / complete
 ```
 
-`overview` is the context synchronization and synthesis engine for Nexus-DevFlow. It inspects the actual codebase (manifest, dependencies, directory layout, models/schemas, entry points) along with the completed delivery history (`devflow/history/HISTORY.md` and `devflow/history/`) to build or refresh `devflow/context/project-overview.md`.
+`/overview` turns planning and delivery context into one generated
+`devflow/context/project-overview.md` artifact.
 
-It ensures that `project-overview.md` remains a **Living Source of Truth** that evolves alongside your software, rather than a stale artifact left behind after onboarding.
+## Input
 
-## Usage
-
-```text
-/overview
-$overview
-overview
-```
-
-Use this when:
-- Multiple delivery runs (`xxx-slug`) have shipped and `project-overview.md` needs to reflect newly added capabilities.
-- New database schemas, ORM models, or API boundaries were introduced.
-- Major dependencies or architectural patterns were added or modified.
-- After completing `70-release` to keep project context perfectly aligned.
-- Preparing for a new initiative or discovery pass.
-
----
+- `devflow/project-plan.md` - product vision, users, stack, constraints
+- `devflow/build-plan.md` - ordered checkbox feature queue
+- `devflow/history/HISTORY.md` - shipped capability context
+- `devflow/ideas.md` - backlog pulse
+- `package.json` (if available) - command/tooling signal
 
 ## Process
 
-### Step 1 - Scan Reality (Codebase Survey)
+### Step 1: Read and validate plans
 
-Inspect the actual codebase to establish hard facts:
+1. Read `project-plan.md` and `build-plan.md`.
+2. Validate plan shape:
+   - checkbox list in `build-plan.md`
+   - feature-sized items
+   - no pre-build setup or unclear one-liners
 
-1. **Manifest & Tooling**:
-   - Read `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `pom.xml`, or `Gemfile`.
-   - Identify language versions, primary framework, state management, and build tools.
-2. **Directory Architecture**:
-   - Map high-level directory layout (`src/`, `app/`, `api/`, `lib/`, `components/`, etc.).
-   - Identify major modules, entry points, and routing conventions.
-3. **Concrete Data Models & Schemas**:
-   - Search for ORM schemas (`schema.prisma`, Drizzle schemas, TypeORM entities, SQLAlchemy models, Zod schemas, or core TypeScript types).
-   - Extract entity names, core fields, relationships, and invariants.
-4. **Verified Commands**:
-   - Inspect package scripts (`dev`, `build`, `test`, `lint`, `check`, `verify`).
+If `build-plan.md` is still placeholder-only while planning is real in `project-plan.md`,
+pause for user approval before normalizing and writing.
 
----
-
-### Step 2 - Scan History (Delivered Capabilities)
-
-Inspect DevFlow history records:
-
-1. Read `devflow/history/HISTORY.md` for completed and released milestones.
-2. Scan completed delivery runs in `devflow/history/features/`, `devflow/history/fixes/`, and `devflow/history/rollbacks/` to extract shipped user-visible capabilities and core system features.
-
----
+### Step 2: Compile overview
 
-### Step 3 - Synthesize `project-overview.md`
+Run:
 
-Write or update `devflow/context/project-overview.md` following standard structure:
-
-```markdown
-# Project Overview & Source of Truth
-
-> Living context artifact automatically synchronized with codebase reality and DevFlow delivery history.
-
-## 1. Project Purpose & Target Users
-- High-level summary of what the system does, who it serves, and the core problem it solves.
-
-## 2. Architecture & Directory Layout
-- Visual directory layout tree with short descriptions for major modules and boundaries.
-
-## 3. Technology Stack & Key Tooling
-- Frontend, Backend, Database, ORM, Testing frameworks, CI/CD, and Package Manager.
-
-## 4. Concrete Data Models & Entities
-- Field-level definitions of major entities, types, and relationships.
-
-## 5. Shipped Capabilities & Key Modules
-- Consolidated list of active features and subsystems verified in the codebase.
-
-## 6. Verified Commands & Developer Workflow
-- Exact commands for Dev, Build, Test, Lint, and Verify.
-
-## 7. Known Architectural Focus Areas
-- Known technical debt, active migrations, or upcoming architectural focus points.
+```bash
+npm run overview
 ```
 
----
+The script uses `devflow/reference/project-overview-template.md` and writes the output
+to `devflow/context/project-overview.md`.
 
-### Step 4 - Review & Report
+### Step 3: Report
 
-Present a concise summary of the sync:
-- Models or entities detected and added
-- Shipped capabilities refreshed from history
-- Stack and tooling updates
-- Any inconsistencies or gaps found between code and documentation
+Summarize what changed and list:
 
----
+- sections marked `TODO`
+- any plan conflicts / unresolved scope gaps
+- next recommended action (`/feature` when queue is clean)
 
-## Rules & Guardrails
+## Rules
 
-1. **Grounded in Reality**: Never invent non-existent packages, fictional data models, or unverified endpoints. Everything in `project-overview.md` must be traceable to real code or recorded history.
-2. **Preserve User Intent**: Do not erase custom business rules or user-written notes. Integrate new facts smoothly around existing intent.
-3. **Concrete Over Vague**: Provide actual model names, field types, and route paths rather than vague one-line summaries.
-4. **Non-Destructive**: `overview` only writes to `devflow/context/project-overview.md`. It never modifies source code, runs migrations, or touches git history.
+- Keep overview generation deterministic and input-sourced.
+- Do not invent scope.
+- Never rewrite user-owned plan files unless explicitly requested.
+- Re-run whenever plans or history materially change.

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

@@ -8,7 +8,7 @@ disable-model-invocation: true
 
 A prototype is throwaway code that answers one question.
 
-Use this support skill behind `Research`, `Brainstorm`, `00-discover`, `10-define`, `20-spec`, or `30-plan` when conversation alone cannot settle the uncertainty.
+Use this support skill behind `Research`, `Brainstorm`, `00-explore`, `10-define`, `20-spec`, or `30-plan` when conversation alone cannot settle the uncertainty.
 
 ## Branches
 

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

@@ -0,0 +1,171 @@
+---
+name: release
+description: "Prepare a DevFlow project for deployment to Render or Vercel. Inspects project stack, package manager, commands, and environment variables; verifies local build, start, output, and health endpoints; creates or updates render.yaml or vercel.json; and enforces strict safety gates before any remote action. Use when the user runs /release, invokes $release, asks for Render setup, Vercel setup, deploy readiness, deployment config, render.yaml, or vercel.json."
+argument-hint: "[render | vercel | check | config]"
+---
+
+# release - deployment readiness for Render and Vercel
+
+Where this sits in the workflow:
+
+```text
+/complete (or 70-deliver)  ->  [release]  ->  deploy with explicit approval
+(feature / run finished)        (config,       (human confirms external action)
+                                 readiness)
+```
+
+`/release` is an optional deployment preparation step. It gets the application ready to ship, but it is **not** an auto-deploy button. It can inspect, recommend, create local config files (`render.yaml`, `vercel.json`), and run local readiness checks. It **must stop** before any external provider action unless the user gives an explicit confirmation in the current chat.
+
+Supported initial targets:
+
+- **Render** - static sites, web services, background workers, cron jobs, databases, and `render.yaml`.
+- **Vercel** - frontend apps, full-stack framework apps, serverless functions, and `vercel.json`.
+
+---
+
+## Usage
+
+```text
+release
+release render
+release vercel
+release check
+release config
+```
+
+### Scopes & Arguments
+
+- **no argument**: inspect the project and recommend Render or Vercel if the target is obvious; otherwise ask which target to prepare.
+- `render`: prepare Render readiness and local configuration (`render.yaml`).
+- `vercel`: prepare Vercel readiness and local configuration (`vercel.json`).
+- `check`: read-only deployment readiness report (runs local checks without changing files).
+- `config`: focus on creating or updating local provider configuration files.
+
+> [!CAUTION]
+> **Strict Safety Gate**: If the user asks to deploy, connect a cloud provider, create a remote service, set remote env vars, push, publish, or run CLI commands that affect a remote infrastructure, pause and request explicit user confirmation before executing.
+
+---
+
+## 5-Step Deployment Readiness Protocol
+
+### Step 1 - Read & Inspect the Project
+
+Read:
+- `AGENTS.md` and `devflow/context/project-overview.md`
+- `devflow/project-plan.md` and `devflow/build-plan.md` (if present)
+- `devflow/context/current-feature.md` or recent history
+- Package and build manifests: `package.json`, lockfiles, framework configs, Dockerfile, `render.yaml`, `vercel.json`, `.env.example`, README
+- Git working tree status
+
+Identify:
+- **App Type**: static frontend, SSR/hybrid app, API service, background worker, CLI, monorepo
+- **Commands & Output**: build command, start command, dev command, test command, output directory (`dist/`, `build/`, `.next/`, `out/`), package manager
+- **Runtime Needs**: Node version, Python version, Docker, database, cache, object storage, background jobs, cron, migrations
+- **Environment Variables**: identify required variables **by name only**; never print, request, or record secret values
+- **Health / Smoke Path**: health endpoint (e.g. `/api/health`, `/healthz`, `/`) or smoke test command
+
+---
+
+### Step 2 - Choose Provider Shape
+
+For **Render**, decide whether the service should be configured as:
+- **Static Site**: client-side SPAs (Vite, React, Vue) with static publish path
+- **Web Service**: Node.js/Python/Go API or SSR server running on a specified port
+- **Background Worker**: queue consumers or long-running worker processes
+- **Cron Job**: periodic scheduled jobs
+- **Database**: PostgreSQL or Redis paired with a service
+
+For **Vercel**, decide whether the app should be:
+- **Framework Deployment**: Next.js, Nuxt, SvelteKit, Astro with zero-config auto-detection
+- **Static Output**: static site export
+- **Serverless / Edge Functions**: API routes or standalone serverless functions
+- **Monorepo Project**: root directory specification
+
+*Note*: If a provider is a poor fit for the stack, state it plainly and recommend the better target (e.g. long-running background workers fit Render better than Vercel serverless).
+
+---
+
+### Step 3 - Verify Local Readiness
+
+Run only local, non-destructive checks:
+1. **Dependency check**: verify required dependencies are installed.
+2. **Build check**: run the project build command (e.g. `npm run build`).
+3. **Test check**: run unit/integration tests when declared (e.g. `npm test`).
+4. **Smoke test**: start local server in test mode or verify health endpoints if safe.
+5. **Lint / Typecheck**: run typecheck/lint when listed in project scripts.
+
+If a command fails or is missing, report the exact gap. If a check requires remote credentials, list the required environment variable names and skip that check.
+
+---
+
+### Step 4 - Prepare Local Config Files
+
+Only create or update local configuration files when the target is clear or requested.
+
+#### For Render (`render.yaml`)
+Create or update `render.yaml` for repeatable infrastructure:
+```yaml
+services:
+  - type: web # or static, worker, cron
+    name: my-app
+    runtime: node # or python, docker, etc.
+    buildCommand: npm run build
+    startCommand: npm run start
+    staticPublishPath: dist # for static sites
+    healthCheckPath: /api/health
+    envVars:
+      - key: NODE_ENV
+        value: production
+      - key: DATABASE_URL
+        sync: false # prompt in Render dashboard, no secret in code
+```
+
+#### For Vercel (`vercel.json`)
+Create `vercel.json` only when default framework auto-detection is insufficient:
+```json
+{
+  "buildCommand": "npm run build",
+  "outputDirectory": "dist",
+  "framework": "vite",
+  "rewrites": [
+    { "source": "/(.*)", "destination": "/" }
+  ]
+}
+```
+
+#### For Both Providers
+- Sync `.env.example` with newly required environment variable names (with empty or dummy placeholder values).
+- Add deployment instructions to `README.md` if requested.
+- **Never write secret values into config files or git commits.**
+
+---
+
+### Step 5 - Report Deployment Readiness Packet
+
+Produce a clean, scannable summary:
+
+```markdown
+## 🚀 Deployment Readiness Packet
+
+- **Target Provider**: Render / Vercel (Rationale: ...)
+- **Service Shape**: Web Service / Static Site / Framework App / Worker
+- **Config Files Changed**: `render.yaml` / `vercel.json` / `.env.example` (or None)
+- **Local Checks Run**:
+  - Build: ✅ PASS
+  - Tests: ✅ PASS (X/X tests)
+  - Typecheck: ✅ PASS
+- **Required Env Variables**: `DATABASE_URL`, `API_KEY` (names only)
+- **Smoke Test Command / Path**: `/api/health`
+- **Blockers / Warnings**: None (or list any gaps)
+- **Next Action**: Review generated config files. When ready, deploy via Provider Dashboard or CLI.
+```
+
+---
+
+## Strict Rules & Guardrails
+
+1. **Optional Step**: `/release` is an optional helper sitting outside the core development loop.
+2. **No Unprompted Remote Actions**: Never deploy, create remote cloud services, modify remote environment variables, push, or publish without explicit confirmation in the current chat.
+3. **Zero Secret Leaks**: Never print, log, or commit passwords, tokens, API keys, or private certificates.
+4. **Lean Configurations**: Do not add unnecessary configuration files if platform zero-config defaults suffice.
+5. **No Hallucinations**: Do not mask failing local builds or unknown output directories; report failures accurately.

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

@@ -8,7 +8,7 @@ description: "[Devflow] Plan safe feature or run reversal with dependency and co
 Where this sits in the workflow:
 
 ```text
-completed run + git history  ->  [rollback]  ->  40-execute (or fix run)  ->  50-verify  ->  70-release
+completed run + git history  ->  [rollback]  ->  40-execute (or fix run)  ->  50-verify  ->  70-deliver
 (run archive + commits)          (risk review    (reverse product diff)          (prove)      (log & finalize)
                                   + plan)
 ```
@@ -51,7 +51,7 @@ Identify:
 
 - Exact commit SHA(s) introducing the feature.
 - Parent commit before the feature was introduced.
-- Associated stage artifacts (`20-spec.md`, `40-execute.md`, `70-release.md`).
+- Associated stage artifacts (`20-spec.md`, `40-execute.md`, `70-deliver.md`).
 
 ## Step 2 - Separate Product Changes From DevFlow History
 

package/template/AGENTS.md

@@ -30,14 +30,14 @@ Unused adapter families can be removed. Codex, Antigravity, and GitHub Copilot s
 
 ### Universal Invocation & Agent Directives:
 
-1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `00-discover`, `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `idea`, `ci`, `test`, `autopilot`, `prototype`, `report-html`, `brief`). The way you invoke commands depends on your AI Provider / Tool:
+1. **Canonical Command Names & AI Provider Invocation**: Each workflow stage and companion tool has exactly **one Canonical Name** (e.g. `feature`, `fix`, `implement`, `check`, `complete`, `00-explore`, `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-deliver`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `idea`, `ci`, `test`, `autopilot`, `prototype`, `report-html`, `brief`, `discovery`, `audit`, `release`). The way you invoke commands depends on your AI Provider / Tool:
    - **Canonical Name (Plain text)**: Directly invoke or prompt the command by its standard name (e.g., `feature`, `40-execute`, `devflow`).
    - **Slash Prefix (`/`)**: For tools supporting slash commands (Claude Code, Google Antigravity, Gemini CLI), e.g., `/feature`, `/fix`, `/implement`, `/40-execute`, `/devflow`.
    - **Dollar Prefix (`$`)**: For OpenAI Codex CLI or skill-invocation tools, e.g., `$feature`, `$fix`, `$40-execute`, `$devflow`.
 2. **OpenAI Codex & Non-Native CLI Tools**: In environments without automatic background skill discovery (such as OpenAI Codex CLI, Aider, or generic terminals), **you MUST use your file reading tool to inspect `.agents/skills/<skill>/SKILL.md` before executing the stage** to strictly follow its schema, artifact contract, and quality gates.
 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 `devflow/context/current-stage.md` and active context in `devflow/context/`.
-5. **Default Artifact & Communication Language (Thai)**: All generated markdown stage artifacts (`current-feature.md`, `00-discover.md`...`70-release.md`) and user communication MUST default to **Thai (`th`)**, while code, technical terms, file paths, and identifiers remain in English.
+5. **Default Artifact & Communication Language (Thai)**: All generated markdown stage artifacts (`current-feature.md`, `00-explore.md`...`70-deliver.md`) and user communication MUST default to **Thai (`th`)**, while code, technical terms, file paths, and identifiers remain in English.
 
 ---
 
@@ -66,17 +66,17 @@ Recommended for 85% of daily work (features, bug fixes, UI improvements, iterati
 Recommended for large architectural epics, database migrations, and multi-agent coordination:
 
 ```text
-00-discover ──▶ 10-define ──▶ 20-spec ──▶ 30-plan ──▶ 40-execute ──▶ 50-verify ──▶ 60-report ──▶ 70-release
+00-explore ──▶ 10-define ──▶ 20-spec ──▶ 30-plan ──▶ 40-execute ──▶ 50-verify ──▶ 60-report ──▶ 70-deliver
 ```
 
-1. `00-discover`: Explore request before delivery commitment without allocating running ID (`00-discover.md`).
+1. `00-explore`: Explore request before delivery commitment without allocating running ID (`00-explore.md`).
 2. `10-define`: Turn approved discovery into bounded delivery run in `devflow/context/current-run/10-define.md`.
 3. `20-spec`: Formalize markdown-first delivery contract & acceptance criteria (`20-spec.md`).
 4. `30-plan`: Breakdown spec into executable tasks with test decisions (`30-plan.md` + checklists).
 5. `40-execute`: Incremental task execution behind review gates (`40-execute.md`).
 6. `50-verify`: Senior QA review & multi-lane verification checks (`50-verify.md`).
 7. `60-report`: Standardized markdown delivery digest (`60-report.md`).
-8. `70-release`: Release packaging, git merge, archives `devflow/context/current-run/` ➔ `devflow/history/{category}/{xxx-slug}/`, and closes run.
+8. `70-deliver`: Release packaging, git merge, archives `devflow/context/current-run/` ➔ `devflow/history/{category}/{xxx-slug}/`, and closes run.
 
 ---
 

package/template/devflow/build-plan.md

@@ -0,0 +1,62 @@
+# 📋 Build Plan (User-Owned Feature Queue)
+
+> **Document Type**: Build Plan (User-Owned)  
+> **Purpose**: รายการคิวฟีเจอร์การพัฒนาปรับปรุงระบบตามลำดับ พร้อมการประเมินขนาด (Sizing) และความสัมพันธ์ (Dependencies) สำหรับ `/brief` และ `/feature`
+
+---
+
+## 🚀 Phase 1: Hard Quality Gates & Pre-commit Enforcement
+
+- [x] **1. Automated Quality Gatekeeper & Pre-commit Hook Integration** `[Size: S]`
+  - *Dependencies*: None
+  - *Scope*: ผสาน `nexus-devflow check-gate` เข้าสู่ Git Pre-commit Hooks และ CI เพื่อบล็อกการ Commit/Merge เมื่อมี Unchecked Tasks, Test ล้มเหลว หรือมี P0/P1 Finding ค้างอยู่
+
+---
+
+## ⚡ Phase 2: DevFlow Model Context Protocol (MCP) Server Hub
+
+- [x] **2. DevFlow MCP Server Hub & Type-Safe Schema Engine (`IDEA-004`)** `[Size: M]`
+  - *Dependencies*: Feature 1
+  - *Scope*: สร้าง Subcommand `nexus-devflow mcp` เปิด JSON-RPC Server พร้อมเครื่องมือ Typed Tools (`update_task`, `record_finding`, `get_stage_context`) ด้วย Zod Schema Validation
+
+---
+
+## 🌿 Phase 3: Branch-Scoped Context Isolation
+
+- [x] **3. Branch-Scoped Context Isolation & Dynamic Router** `[Size: M]`
+  - *Dependencies*: Feature 2
+  - *Scope*: แยกจัดเก็บ State ตาม Git Branch ใน `.nexus/branches/<branch-name>/`, ระบบ Canonical Dynamic Router สำหรับ AI Agent และระบบ Auto-Cleanup หลัง `/complete`
+
+---
+
+## ✂️ Phase 4: JIT Context Slicing & Token Optimizer
+
+- [x] **4. Just-In-Time (JIT) Dynamic Context Slicing Engine** `[Size: M]`
+  - *Dependencies*: Feature 3
+  - *Scope*: สร้างตัวตัดตอนบริบท (Context Slicer) สำหรับสคิล `/implement`, `/check`, `/00-explore` เพื่อส่งเฉพาะข้อมูลที่จำเป็นและควบคุม Token Budget ลดการใช้ Token 60–70%
+
+---
+
+## 🔄 Phase 5: State Drift Detection & Self-Healing
+
+- [x] **5. Git Diff Drift Reconciler & Self-Healing State Engine** `[Size: M]`
+  - *Dependencies*: Feature 4
+  - *Scope*: ตรวจจับความไม่สอดคล้องระหว่าง `git diff` กับรายการไฟล์ใน Living Spec พร้อมระบบแจ้งเตือนและ Auto-Reconcile ซิงค์สถานะอัตโนมัติ
+
+---
+
+## 🖥️ Phase 6: IDE Native Extension & Visual Studio
+
+- [x] **6. IDE Native Extension & Interactive Webview Studio** `[Size: L]`
+  - *Dependencies*: Feature 5
+  - *Scope*: พัฒนา Extension สำหรับ VS Code / Antigravity Webview เพื่อแสดง Live Kanban Board, ปุ่มกดรันคำสั่ง DevFlow และ Diff Inspector ในตัว IDE
+
+
+---
+
+## 🤖 Phase 7: Multi-Agent Swarm Orchestration & Code Graph RAG
+
+- [x] **7. Multi-Agent Swarm Orchestrator & Semantic Code Graph RAG** `[Size: L]`
+  - *Dependencies*: Feature 6
+  - *Scope*: พัฒนาระบบกระจายงานแบบคู่ขนานให้ Subagents (Coder, QA Verifier, Security Auditor) และระบบ Indexing Local Codebase Graph เพื่อดึงบริบทที่แม่นยำสูงสุด
+