@jakkrichm/create-nexus-devflow 2.0.12 → 2.0.14

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

@@ -0,0 +1,105 @@
+---
+name: spec
+description: "[Devflow] Fast-Track Spec stage in DevFlow (Blueprint Mode) - define, spec, plan, and create the single living spec.md contract."
+argument-hint: "{feature title, bug description, IDEA-xxx, or running-id}"
+---
+
+# Fast-Track: Spec (Blueprint Mode)
+
+$ARGUMENTS
+
+Fast-Track entry point combining Discovery, Definition, Specification, and Implementation Planning into one streamlined, review-gated step. Creates and maintains the **Single Living Spec (`spec.md`)** for the run. Supports intake from Idea Inbox (`IDEA-xxx`).
+
+## Invocations & Aliases
+
+- `/spec <title>` or `spec <title>`: Standard Fast-Track specification
+- `/spec IDEA-xxx`: Intake and promote a pending idea from `devflow/ideas.md`
+- `/feature <title>` or `feature <title>`: Fast-Track feature workflow
+- `/fix <bug-description>` or `fix <bug-description>`: Fast-Track ad-hoc bugfix workflow
+- `$spec`, `$feature`, `$fix`: Codex CLI invocation
+
+## Fast-Track Mainline Workflow
+
+```text
+/spec ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Work Identity & Idea Intake
+1. Inspect `devflow/context/current-stage.md` and `devflow/runs/`.
+2. **Idea Inbox Intake**: If the argument is an idea identifier (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 ({RUNNING_ID})` and move it under `## 📦 Archived / Shipped Ideas`.
+3. Determine or allocate the sequential Running ID (e.g. `RUN-016-{slug}`).
+4. Identify Git branch naming:
+   - For features: `feature/{slug}-{RUNNING_ID}`
+   - For bug fixes: `fix/{slug}-{RUNNING_ID}`
+5. Create directory `devflow/runs/{RUNNING_ID}/`.
+
+### 2. Generate the Single Living Spec (`spec.md`)
+Write `devflow/runs/{RUNNING_ID}/spec.md` using the structured template below in **Thai (`th`)**:
+
+```markdown
+# 📐 [{RUNNING_ID}] {Title} (Living Spec)
+
+> **Status**: In-Progress  
+> **Track**: Fast-Track (Blueprint Mode)  
+> **Branch**: `{branch_name}`  
+> **Created Date**: {YYYY-MM-DD}  
+> **Owner**: {Contributor or Team}  
+
+---
+
+## 1. Specification & Scope
+- **Problem Statement**: {ปัญหาหรือที่มาที่ต้องทำ}
+- **In-Scope**:
+  - {ขอบเขตสิ่งที่ต้องทำ}
+- **Out-of-Scope**:
+  - {สิ่งที่ไม่ทำในรอบนี้}
+- **Acceptance Criteria**:
+  - [ ] AC-1: {เงื่อนไขการตรวจรับข้อที่ 1}
+  - [ ] AC-2: {เงื่อนไขการตรวจรับข้อที่ 2}
+
+## 2. Plan & Test Strategy
+- **Files to Modify / Create**:
+  - `{path/to/file1}`: {หน้าที่ที่ต้องแก้ไข}
+  - `{path/to/file2}`: {หน้าที่ที่ต้องแก้ไข}
+- **Test Decision**: `Required (TDD)` | `Manual/Command Only` | `Not Required`
+  - *Rationale*: {เหตุผลความจำเป็นในการเขียนเทสต์}
+  - *Planned Cases*: {กรณีทดสอบหลักตาม AAA Pattern}
+- **Impact & Rollback Strategy**:
+  - *Impact*: {ผลกระทบต่อโมดูลอื่น}
+  - *Rollback*: {วิธีย้อนคืนการทำงานกรณีเกิดปัญหา}
+
+## 3. Implementation Checklist
+- [ ] Task 1.1: {งานย่อยข้อที่ 1}
+- [ ] Task 1.2: {งานย่อยข้อที่ 2}
+- [ ] Task 1.3: {งานย่อยข้อที่ 3}
+
+## 4. Implementation Record
+- *(จะถูกบันทึกเมื่อรัน /implement)*
+
+## 5. Verification Evidence
+- *(จะถูกบันทึกเมื่อรัน /check)*
+
+## 6. Release & Handoff
+- *(จะถูกบันทึกเมื่อรัน /complete)*
+```
+
+### 3. Update Workspace Status
+Update `devflow/context/current-stage.md`:
+- `Active Running ID`: `{RUNNING_ID}`
+- `Current Stage`: `spec (Fast-Track -> Ready for /implement)`
+- `Last Updated`: `{YYYY-MM-DD}`
+
+### 4. Output Summary & Next Step
+Report to the user:
+- Running ID and allocated branch
+- Summary of Scope and Acceptance Criteria
+- Living Spec path: `devflow/runs/{RUNNING_ID}/spec.md`
+- If promoted from `IDEA-xxx`, confirm status update in `devflow/ideas.md`
+- **Next Command**: `/implement` (or `/implement {RUNNING_ID}`)

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

@@ -1,82 +1,94 @@
 ---
 name: test
-description: "[Devflow] Test execution, missing test generation, and coverage analysis across unit, integration, and smoke test suites."
+description: "[Devflow] Test-driven development, test generation, test execution, and coverage analysis across unit, integration, and smoke test suites."
 ---
 
----
-description: Test Generation and Execution - Generates missing tests, runs existing test suites, or checks test coverage for the project.
----
-# ๐Ÿงช Test Generation and Execution
-
-## Usage: `/13-Test [target]`
+# Test-Driven Development, Generation & Execution
 
-Generates missing tests, runs existing test suites, or checks test coverage for the project.
+## Overview
 
-Primary behavior now lives in:
+This is the comprehensive testing master skill for Nexus-DevFlow. It drives development with tests (TDD), handles test generation, execution, coverage analysis, and bug reproduction. Tests are proof — "seems right" is not done.
 
 ```text
-.agents/skills/test-execution-and-coverage/SKILL.md
+    RED                GREEN              REFACTOR
+ Write a test    Write minimal code    Clean up the
+ that fails  ──→  to make it pass  ──→  implementation  ──→  (repeat)
+      │                  │                    │
+      ▼                  ▼                    ▼
+   Test FAILS        Test PASSES         Tests still PASS
 ```
 
-Treat this workflow file as a compatibility wrapper around that skill.
+## Usage & Sub-Commands
+
+- `/test`                - Run all project test suites
+- `/test [file/feature]` - Generate tests for a specific target
+- `/test coverage`       - Show test coverage report
+- `/test watch`          - Run tests in watch mode
 
 ---
 
-## ๐Ÿ› ๏ธ Sub-commands
+## 1. The TDD Cycle
+
+### Step 1: RED — Write a Failing Test
+Write the test first. It must fail. A test that passes immediately proves nothing.
+
+### Step 2: GREEN — Make It Pass
+Write the minimum code to make the test pass. Avoid premature over-engineering.
 
-- `/13-Test`                - Run all tests
-- `/13-Test [file/feature]` - Generate tests for a specific target
-- `/13-Test coverage`       - Show test coverage report
-- `/13-Test watch`          - Run tests in watch mode
+### Step 3: REFACTOR — Clean Up
+Improve code readability, naming, structure, and eliminate duplication while keeping tests green.
 
 ---
 
-## ๐Ÿšฆ Internal Process
+## 2. The Prove-It Pattern (Bug Reproduction)
 
-### Scenario A: Generate Tests
-If the user requests tests for a target:
-1. **Analyze**: Identify functions, edge cases, and external dependencies.
-2. **Template Verification**: **MANDATORY:** Before generating the test plan, inspect `.agent/resources/schemas/test_report.template.md`, preserve its required layout, and replace placeholder text with concrete coverage, command output, failures, and gaps.
-3. **Generate Cases**: Develop Happy path, Error cases, Edge cases.
-4. **Write**: Implement the tests using the project's testing framework (Pytest, Jest, Vitest, etc.). Follow the `Arrange-Act-Assert` pattern and mock external dependencies.
-5. **Save Test Report**: Save the test plan and results to `devflow/reports/{date}-test-report-{target}.md` (where `{date}` is today's date in `YYYY-MM-DD` format and `{target}` is a slugified version of the file or feature name).
+When fixing any defect, **do not attempt a fix without proving the bug exists first**:
 
-### Scenario B: Execute Tests
-Use the project's native command (e.g., `npm test`, `pytest`) to run the tests and format the output clearly for the user. Highlight any failed tests with expected vs received values. Save the execution summary report matching the template to `devflow/reports/{date}-test-report-run.md` (where `{date}` is today's date in `YYYY-MM-DD` format).
+```text
+Bug report arrives ➔ Write reproduction test (FAILS) ➔ Implement fix ➔ Test PASSES ➔ Guard regression
+```
 
 ---
 
-## ๐Ÿ›ก๏ธ Key Principles
-- **Test behavior, not implementation.**
-- **One assertion per test** (when practical).
-- **Descriptive test names.**
-- **Arrange-Act-Assert pattern.**
-- **Save Report**: Always save the test plan or results to disk for persistent logging.
+## 3. The Test Pyramid & Resource Sizes
 
-## ๐Ÿ“ Output Formats
+| Level | Size | Target % | Scope & Characteristics |
+| :--- | :--- | :--- | :--- |
+| **Unit** | Small | ~80% | Pure logic, in-memory, single process, milliseconds each |
+| **Integration** | Medium | ~15% | API boundaries, database interaction, component seams |
+| **E2E** | Large | ~5% | Critical user journeys, full workflows, browser automation |
 
-### For Test Generation
-Generate a summary indicating:
-- **Test Plan**: Table of Test Case, Type, Coverage (Happy path, error case, validation)
-- **Generated Tests**: File path and the code block
-- **Report Location**: Confirm the report has been written to the specified workspace path.
-- **Run command**: e.g. `npm test`
+---
 
-### For Test Execution
-Display an organized output listing Passed/Failed files, and explicitly show the expectation vs received outcome for failed assertions.
+## 4. Key Testing Principles & Best Practices
 
-## Relationship To DevFlow 2.0
+1. **Test behavior, not implementation details**: Assert on output and state changes, not private method call sequences.
+2. **DAMP over DRY in tests**: Descriptive and meaningful test setup beats overly abstract shared helpers.
+3. **Arrange-Act-Assert**: Distinct setup, action, and verification phases in every test case.
+4. **Prefer real implementations & fakes over heavy mocks**: Mock only at boundaries where real dependencies are slow or non-deterministic.
+5. **One assertion concept per test**: Isolate test failure reasons clearly.
 
-- Classification: Companion command
-- Mainline status: Verification support command, not a numbered stage
-- Typical entry points: `40-implement`, `50-verify`, `Debug`
-- Typical handoff targets: `50-verify`, `Debug`, `QA-Orchestrate`
+---
+
+## 5. Browser Testing & Runtime Verification
+
+For browser and UI features, unit tests alone are insufficient:
+- **Console**: Zero errors and unhandled exceptions in production code.
+- **Network**: Accurate status codes, payload shapes, and CORS handling.
+- **DOM & Styles**: Verified layout rendering, accessibility tree, and responsive behaviors.
+
+---
+
+## 6. Test Generation & Persistent Execution Reports
 
-## Sources
+When generating or logging test runs during `40-implement` or `50-verify`:
+- Save summary reports to `devflow/reports/{date}-test-report-{slug}.md`
+- Include: Target, Test Cases (Happy Path, Error, Edge Cases), Pass/Fail statistics, and gaps/risks.
 
-- `AGENTS.md`
-- `.agents/skills/test-execution-and-coverage/SKILL.md`
-- `.agent/resources/schemas/test_report.template.md`
-- Related commands: `40-implement`, `50-verify`, `Debug`, `QA-Orchestrate`
+---
 
+## Relationship To DevFlow 2.0
 
+- **Classification**: Companion command & Engineering standard
+- **Mainline stages**: `30-plan` (TDD decisions), `40-implement` (TDD execution), `50-verify` (QA gate)
+- **Handoff**: `50-verify`, `Debug`, `autopilot`

package/template/.claude/skills/00-discover/SKILL.md

@@ -14,12 +14,14 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 
 ```text
 00-discover {title or request}
+00-discover IDEA-xxx
 00-discover {discovery-id}
 ```
 
 Use this when:
 
 - a new request needs discussion before the team commits to delivery
+- exploring a pending idea from `devflow/ideas.md` (`00-discover IDEA-xxx`)
 - the best route may be `Brainstorm`, `PRD`, `Research`, or `Debug`
 - supporting findings need to be synthesized into a go/no-go decision
 

package/template/.claude/skills/60-report/SKILL.md

@@ -1,6 +1,6 @@
----name: 60-report
-
-description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown and HTML summary report for the completed run."
+---
+name: 60-report
+description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown summary report for the completed run."
 argument-hint: "{running-id or workspace path}"
 ---
 
@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Produce the final human-friendly summary of the full running flow in both Markdown and HTML so the outcome is easy to communicate every time.
+Produce the final human-friendly summary of the full running flow in Markdown (`60-report.md`) so the outcome is easy to communicate every time.
 
 ## Usage
 
@@ -16,19 +16,12 @@ Produce the final human-friendly summary of the full running flow in both Markdo
 60-report {running-id or workspace path}
 ```
 
-Use this when:
-
-- verification is complete and the run is ready for a final standardized summary before release
-- the team needs a standardized summary for communication
-- non-technical readers should be able to understand what happened
-
 ## Markdown-First Contract
 
-Write the primary stage artifacts to:
+Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}60-report.md
-devflow/runs/{ID}-{slug}60-report.html
+devflow/runs/{ID}-{slug}/60-report.md
 ```
 
 using:
@@ -39,6 +32,9 @@ using:
 
 Before writing `60-report.md`, read `artifact_language` from `report.template.md` and produce the markdown artifact in that language.
 
+> [!IMPORTANT]
+> **No Auto-Generated HTML**: ยกเลิกการสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากผู้ใช้หรือทีมต้องการสร้าง HTML Report สวยงาม ให้เรียกคำสั่งแยกต่างหาก: `/report:html` หรือ `npm run report:html`
+
 ## Required Section Content
 
 Before completing any generated artifact:
@@ -57,13 +53,13 @@ Before completing any generated artifact:
 
 Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
 
-- **Intent**: produce a final markdown and HTML summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
+- **Intent**: produce a final markdown summary that lets a reader understand the outcome, evidence, decisions, risks, and next actions without replaying the whole run.
 - **Context**: read all relevant stage artifacts, checklist files, verify impact notes, release notes, validation output, and supporting artifacts that materially explain the result.
-- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions, then render the HTML report.
+- **Action**: summarize the problem, direction, completed work, validation outcome, checklist progress, final decision, open risks, and next actions.
 - **Observation**: use concrete evidence such as checklist completion, blocked or skipped items, validation results, release state, impact notes, and unresolved follow-ups.
 - **Adjustment**: if evidence is missing, return to the owning stage; if the report must support continuation, use `handoff`; if the run produced reusable lessons, use `insight-capture` or `Wiki`.
-- **Stop Condition**: stop when `70-report.md` and `70-report.html` both exist, summarize the outcome accurately, include checklist and evidence snapshots, and name any remaining follow-up work.
-- **Handoff**: `70-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
+- **Stop Condition**: stop when `60-report.md` exists, summarizes the outcome accurately, includes checklist and evidence snapshots, and names any remaining follow-up work.
+- **Handoff**: `60-report.md` must close the mainline run or tell the next reader exactly where follow-up work should continue.
 
 ### 1. Gather Full Run Context
 
@@ -98,19 +94,9 @@ Explain:
 
 Write:
 
-- a readable Markdown report for contributors
-- a consistent HTML report for stakeholder sharing
-
-In phase 1, `artifact_language` governs the markdown report text. HTML output is derived directly from `60-report.md` through the shared markdown-to-html renderer.
+- a readable Markdown report (`60-report.md`) for contributors
 
-To render the HTML consistently from the markdown report, use one of:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-npm run render:html -- --stage 60-report <workspace-path-or-running-id>
-```
-
-Keep checklist summaries and follow-up status inside `60-report.md` so they carry through into the rendered HTML.
+Keep checklist summaries and follow-up status inside `60-report.md`.
 
 Both outputs should summarize checklist state when checklist artifacts exist, including:
 
@@ -120,27 +106,6 @@ Both outputs should summarize checklist state when checklist artifacts exist, in
 - approval status, review blockers, and next allowed command when they still matter
 - remaining follow-up work
 
-The HTML should stay visually consistent across runs while preserving the report markdown as the source of truth.
-
-### 4. Keep The Audience In Mind
-
-Prefer clarity over internal detail.
-
-Do not bury the outcome inside implementation trivia. The report should help a reader understand the run without replaying the whole workflow.
-
-When checklists exist, use them as the most human-readable operational record of what actually happened.
-Use `handoff` when the report must support continued work, and `insight-capture` when the run produced lessons that should become reusable knowledge.
-
-### 5. Manual Review Soft Gate
-
-Use the report as the final visibility checkpoint before release.
-If any stage still shows unresolved approval, blockers, or deferred work:
-
-- surface that state clearly in `60-report.md`
-- pull the relevant signal forward from checklist approval sections when they exist
-- do not imply the phase is fully closed when review is still open
-- recommend the real next action, even if that means returning to an earlier stage
-
 ## Output
 
 Report:
@@ -148,37 +113,18 @@ Report:
 - what the run accomplished
 - checklist completion status and remaining items
 - important remaining follow-ups
-- where `60-report.md` and `60-report.html` were written
-- render command used or recommended:
-
-```text
-npm run report:html -- <workspace-path-or-running-id>
-```
+- where `60-report.md` was written
+- standalone HTML command tip: `/report:html` (if HTML view is desired)
 
 ## Relationship To DevFlow 2.0
 
 - Classification: Mainline workflow
 - Previous state: `50-verify`
 - Next state: `70-release` when the summary is aligned and release can proceed
-- Common companion commands: `Wiki` for durable knowledge capture, `Help` for routing or explanation
-- Support skills: `handoff`, `insight-capture`, and writing skills when final reporting must support continuation or reusable learning
-
-## Sources
-
-- `AGENTS.md`
-- `docs/workspace-artifacts.md`
-- `.agent/resources/schemas/report.template.md`
-- Related commands: `50-verify`, `70-release`, `Wiki`, `Help`
+- Common companion commands: `/report:html` for standalone HTML dashboard, `Wiki` for durable knowledge capture, `Help` for routing or explanation
 
 ## Next Workflow Recommendation
 
-- **Primary**: `70-release {ID}` after `60-report.md` and `60-report.html` reflect the verified state clearly.
-- **Render HTML**: `npm run report:html -- {ID}` after `60-report.md` is finalized so the standardized stakeholder HTML stays in sync
-- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues
-- **Additional Alternative**: `handoff` when another session or agent must continue from the completed run.
-
-## Nexus Event
-
-- Use `Wiki` when the final summary should become durable project or framework knowledge.
-- Use `Help` when approval signals, ownership, or route timing still feel ambiguous.
-- Return to `50-verify` when unresolved evidence, blockers, or review state mean the report should not advance yet.
+- **Primary**: `70-release {ID}` after `60-report.md` reflects the verified state clearly.
+- **Optional Standalone HTML**: `/report:html` (or `npm run report:html -- {ID}`) if an interactive HTML report is desired for stakeholder presentation.
+- **Alternative**: `Wiki` when the completed run should be promoted into durable reusable knowledge before release packaging continues.

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

@@ -77,6 +77,8 @@ Before packaging, merging, or releasing:
    - **การ Push ไปยัง Remote หรือ Deploy จะต้องขออนุมัติแยกต่างหากอย่างชัดเจน (Merge approval DOES NOT equal Push approval)**
 3. **Archive Resolved Findings**:
    - ย้ายรายการ Findings ที่ปิดแล้ว (`closed`, `accepted`, `invalid`) ไปบันทึกในเอกสาร Release และรีเซ็ต `findings.md` ให้สะอาด
+4. **Append to Master History Ledger**:
+   - บันทึก Entry ใหม่ลงใน `devflow/history/HISTORY.md` พร้อมระบุ Running ID, Title, วันที่, Git Commit Hash / Tag, สถานะ (`Released`), และลิงก์ไปยังรายงานสรุป `60-report.md`
 
 ### 1. Load Verified Context
 
@@ -146,7 +148,7 @@ Report:
 - Classification: Mainline workflow
 - Previous state: `60-report`
 - Next state: End of the mainline run when release packaging or handoff is complete
-- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Common companion commands: `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`, `overview`
 - Support skills: `resolving-merge-conflicts`, `handoff`, and `setup-pre-commit` when release packaging needs conflict resolution, transfer notes, or local quality gates
 
 ## Sources
@@ -154,13 +156,14 @@ Report:
 - `AGENTS.md`
 - `docs/workspace-artifacts.md`
 - `.agent/resources/schemas/release.template.md`
-- Related commands: `60-report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`
+- Related commands: `60-report`, `Commit`, `PR`, `Deploy`, `Changelog`, `Merge`, `Wiki`, `overview`
 
 ## Next Workflow Recommendation
 
-- **Primary**: End of Timeline flow
+- **Primary**: End of Timeline flow (or run `/overview` to sync living project context)
 - **Why**: The report is already complete, and this phase is the final release-facing execution step.
 - **Alternatives**:
+  - `overview` - choose this to immediately sync newly shipped capabilities into `devflow/context/project-overview.md`.
   - `60-report` - choose this when the release package diverges from the approved report and the summary must be refreshed first.
   - `50-verify` - choose this when release readiness becomes uncertain.
   - `40-implement` - choose this when additional fixes are needed before release can proceed.
@@ -168,7 +171,7 @@ Report:
 
 ## Nexus Event
 
-- Use `Commit`, `PR`, `Deploy`, `Merge`, or `Changelog` when release execution still needs a concrete lane.
+- Use `Commit`, `PR`, `Deploy`, `Merge`, `Changelog`, or `overview` when release execution still needs a concrete lane.
 - Return to `60-report` when release notes, scope, or handoff wording diverge from the approved summary.
 - Return to `50-verify` or `40-implement` when release readiness changes because unresolved issues are discovered.
 

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

@@ -0,0 +1,68 @@
+---
+name: check
+description: "[Devflow] Fast-Track Check stage in DevFlow (Blueprint Mode) - perform senior QA review, run multi-lane verification, and record evidence in spec.md."
+argument-hint: "{running-id or workspace path}"
+---
+
+# Fast-Track: Check (Blueprint Mode)
+
+$ARGUMENTS
+
+Quality assurance and multi-lane verification stage in Fast-Track. Validates the implementation against Acceptance Criteria, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`spec.md`).
+
+## Invocations & Aliases
+
+- `/check`: Run verification on current active run
+- `/check {running-id}`: Run verification on specified running ID
+- `$check`: Codex CLI invocation
+
+## Fast-Track Mainline Workflow
+
+```text
+/spec ──▶ /implement ──▶ /check ──▶ /complete
+```
+
+## Behavior & Contract
+
+When invoked:
+
+### 1. Load Active Context
+1. Identify active Running ID from `devflow/context/current-stage.md` or argument.
+2. Read `devflow/runs/{RUNNING_ID}/spec.md`.
+3. Locate `## 1. Specification & Scope` (Acceptance Criteria) and `## 3. Implementation Checklist`.
+
+### 2. Multi-lane Verification Execution
+Execute the verification gates across all lanes:
+1. **Lane 1 (Type & Syntax Safety)**:
+   - Run typecheck and linting (e.g. `npm run typecheck`, `npm run lint`).
+2. **Lane 2 (Test Suites & Coverage)**:
+   - Run automated unit and integration tests (e.g. `npm test`).
+3. **Lane 3 (Manual / Scenario Proof)**:
+   - Verify specific scenarios against Acceptance Criteria (`AC-1`, `AC-2`).
+   - Summarize "Where to go", "What to click/call", and "What to expect".
+
+### 3. Update Living Spec (`spec.md`)
+Append or update `## 5. Verification Evidence` in `spec.md` in **Thai (`th`)**:
+
+```markdown
+## 5. Verification Evidence
+- **Typecheck & Linter**: Passed (0 errors, 0 warnings)
+- **Automated Test Suites**: All tests passed (e.g. 12/12 passed, 0 failed)
+- **Acceptance Criteria Verification**:
+  - [x] AC-1: {ผลการตรวจสอบเงื่อนไขที่ 1 ผ่าน 100%}
+  - [x] AC-2: {ผลการตรวจสอบเงื่อนไขที่ 2 ผ่าน 100%}
+- **Manual Verification Guide**:
+  - *Where to go*: `http://localhost:3000/api/auth`
+  - *Action*: Send POST request with test credentials
+  - *Expected Result*: Received HTTP 200 with valid JWT token
+```
+
+### 4. Update Workspace Status
+Update `devflow/context/current-stage.md`:
+- `Current Stage`: `check (Fast-Track -> Verification Passed -> Ready for /complete)`
+
+### 5. Output Summary & Next Step
+Report to the user:
+- Summary of verification results across all lanes
+- Evidence recorded in `spec.md`
+- **Next Command**: `/complete` (or `/complete {RUNNING_ID}`)