@jakkrichm/create-nexus-devflow 2.0.20 → 2.0.21

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."
+description: "[Devflow] Report stage in DevFlow 2.0 - produce standardized markdown summary report with retrospective lessons learned."
 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 Markdown (`60-report.md`) 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`) with retrospective lessons learned, findings summary, and release digest.
 
 ## Usage
 
@@ -21,110 +21,37 @@ Produce the final human-friendly summary of the full running flow in Markdown (`
 Write the primary stage artifact to:
 
 ```text
-devflow/runs/{ID}-{slug}/60-report.md
+devflow/context/current-run/60-report.md
 ```
 
-using:
-
-```text
-.agent/resources/schemas/report.template.md
-```
-
-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:
-
-- preserve every heading required by the selected template
-- write concrete information under every heading
-- when no information exists or the section does not apply, write exactly `-`
-- never leave a heading immediately followed by another heading with no body content
-- remove template placeholders from the final artifact
-- do not invent facts merely to avoid using `-`
-- re-read the saved artifact and verify every heading satisfies this rule
+> **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้! ระบบจะสร้างเฉพาะ `60-report.md` เท่านั้น หากต้องการดู HTML Report ให้เรียกคำสั่งแยก: `/report:html`
 
 ## Process
 
-### Loop Contract
-
-Run reporting as an outcome-evidence loop, not as a dump of prior artifacts.
-
-- **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.
-- **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 `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
-
+### 1. Gather Full Run Context & Verification Evidence
 Read all relevant stage artifacts:
-
-- the shared `00-discover.md` referenced by `source_discovery` when it materially explains the delivery decision
 - `10-define.md`
 - `20-spec.md`
 - `30-plan.md`
 - `40-execute.md`
 - `50-verify.md`
-- `checklists/implementation-checklist.md` when present
-- `checklists/verification-checklist.md` when present
-
-Include supporting artifacts only when they add real context.
-
-### 2. Summarize The Run
-
-Explain:
-
-- what problem was addressed
-- what direction was chosen
-- what was implemented
-- how it was verified (พร้อมบันทึกสถานะ Findings Ledger ใน `devflow/context/findings.md`)
-- how checklist progress moved across the run
-- **Manual Try Guide**: สรุปขั้นตอนการทดสอบสำหรับมนุษย์ ("Where to go", "What to click", "What to expect")
-- what approval or review state remained at each important gate
-- what the release recommendation is
-- what follow-up items still exist
-
-### 3. Produce Standardized Outputs
-
-Write:
-
-- a readable Markdown report (`60-report.md`) for contributors
-
-Keep checklist summaries and follow-up status inside `60-report.md`.
-
-Both outputs should summarize checklist state when checklist artifacts exist, including:
-
-- completion progress
-- blocked or skipped items
-- notable evidence snapshots
-- approval status, review blockers, and next allowed command when they still matter
-- remaining follow-up work
-
-## Output
-
-Report:
-
-- what the run accomplished
-- checklist completion status and remaining items
-- important remaining follow-ups
-- where `60-report.md` was written
-- standalone HTML command tip: `/report:html` (if HTML view is desired)
 
-## Relationship To DevFlow 2.0
+### 2. Retrospective Lessons Learned & Gotchas (Insight Extraction)
+Extract durable insights from the completed run:
+- **Reusable Patterns**: Design choices or implementations that future runs should mirror.
+- **Gotchas & Pitfalls**: Unforeseen issues or quirks encountered during execution.
+- **Unresolved Follow-ups**: Route any residual out-of-scope ideas to `devflow/ideas.md`.
 
-- Classification: Mainline workflow
-- Previous state: `50-verify`
-- Next state: `70-release` when the summary is aligned and release can proceed
-- Common companion commands: `/report:html` for standalone HTML dashboard, `Wiki` for durable knowledge capture, `Help` for routing or explanation
+### 3. Produce Standardized Report (`60-report.md`)
+Structure the report in **Thai (`th`)**:
+1. **Executive Summary**: ปัญหาและแนวทางแก้ไข
+2. **Delivery Scope**: รายการฟีเจอร์และคอมโพเนนต์ที่ส่งมอบ
+3. **Verification Evidence Snapshot**: ผลการทดสอบทุก Lane
+4. **Retrospective & Lessons Learned**: บทเรียนและข้อควรระวัง
+5. **Manual Try Guide**: ขั้นตอนสำหรับมนุษย์ทดสอบระบบ
 
 ## Next Workflow Recommendation
 
-- **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.
+- **Primary**: `70-release {ID}`
+- **Optional Standalone HTML**: `/report:html`

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

@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Package approved work for delivery after the report stage has captured the final verified story. Archives the active run from `devflow/context/current-run/` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}/`, updates `HISTORY.md`, performs git merge, and closes the run.
+Package approved work for delivery after the report stage has captured the final verified story. Archives the active run from `devflow/context/current-run/` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}/`, updates `HISTORY.md` and `CHANGELOG.md`, executes pre-flight smoke checks, performs conventional git commit & merge, and closes the run.
 
 ## Usage
 
@@ -40,14 +40,39 @@ Before packaging, merging, or releasing:
    - Inspect `devflow/context/findings.md`.
    - No Finding of severity `P0` or `P1` in `open` or `fixed` status is permitted.
    - `fixed` still blocks release until reviewed and closed in `50-verify`.
-2. **2-Stage Approval Separation**:
+2. **Pre-flight & Deployment Smoke Validation**:
+   - Verify environment variables and configuration parameters.
+   - Run production build or package smoke check (`npm run build` or `npm run test:package`).
+   - Validate that clean state exists with no untracked experimental files.
+3. **2-Stage Approval Separation**:
    - Consent to merge into `main` is strictly separate from consent to `git push` to remote or deploy.
-3. **Archive Resolved Findings**:
-   - Move resolved findings (`closed`, `accepted`, `invalid`) into release archive notes and clean `findings.md`.
-4. **Archive Run Folder to Categorized History**:
-   - Determine Category (`features`, `fixes`, `rollbacks`).
-   - Move directory `devflow/context/current-run/` (or `devflow/runs/{xxx-slug}/`) ➔ `devflow/history/{category}/{xxx-slug}/`.
-5. **Append to Master History Ledger**:
-   - Append entry to `devflow/history/HISTORY.md` linking to `history/{category}/{xxx-slug}/60-report.md`.
-6. **Update Workspace State**:
-   - Set `devflow/context/current-stage.md` to `Idle`.
+
+### 1. Changelog & SemVer Version Bump
+
+1. Calculate next version according to **Semantic Versioning (SemVer)**:
+   - `Major`: Breaking architectural changes, removed public APIs
+   - `Minor`: New backward-compatible features added
+   - `Patch`: Bug fixes, optimizations, documentation
+2. Append new release entry to `CHANGELOG.md` in [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) format (`Added`, `Changed`, `Fixed`, `Removed`, `Security`).
+
+### 2. Conventional Commit & Git Merge
+
+1. Stage all release and tracking files.
+2. Commit with conventional format: `chore(release): release {version}` or `feat({scope}): {summary}`.
+3. Squash-merge to base branch (`main`) with explicit user approval.
+
+### 3. Archive Run Folder to Categorized History
+
+1. Determine Category (`features`, `fixes`, `rollbacks`).
+2. Move directory `devflow/context/current-run/` ➔ `devflow/history/{category}/{xxx-slug}/`.
+3. Clean resolved findings (`closed`, `accepted`, `invalid`) from `devflow/context/findings.md` and append to the release notes.
+4. Append entry to `devflow/history/HISTORY.md` linking to `history/{category}/{xxx-slug}/60-report.md`.
+
+### 4. Update Workspace State
+
+Set `devflow/context/current-stage.md` to:
+- `Active Discovery ID`: `None`
+- `Active Running ID`: `None (Idle)`
+- `Current Stage`: `Idle (Ready for new run)`
+- `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
+- `Last Updated`: `{YYYY-MM-DD}`

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

@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $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 (`devflow/context/current-feature.md`).
+Quality assurance and multi-lane verification stage in Fast-Track. Validates implementation against Acceptance Criteria, executes Scrutinize QA & Security checks, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`devflow/context/current-feature.md`).
 
 ## Invocations & Aliases
 
@@ -31,15 +31,26 @@ When invoked:
 2. Read `devflow/context/current-feature.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)**:
+### 2. Multi-lane Verification & Scrutinize QA
+
+Execute verification gates across all lanes:
+
+1. **Lane 1: Typecheck & Static Code Quality**:
    - Run typecheck and linting (e.g. `npm run typecheck`, `npm run lint`).
-2. **Lane 2 (Test Suites & Coverage)**:
+   - Confirm 0 type errors, 0 lint warnings.
+2. **Lane 2: Automated Test Suites (TDD Gate)**:
    - Run automated unit and integration tests (e.g. `npm test`).
-3. **Lane 3 (Manual / Scenario Proof)**:
+   - Confirm 100% tests pass with no disabled/skipped tests.
+3. **Lane 3: Scrutinize & Edge Cases Review**:
+   - **Boundary Conditions**: Check empty collections, 0/1 limits, off-by-one errors.
+   - **Null / Undefined Safety**: Verify optional chaining and nullish coalescing.
+   - **Error Handling & Propagation**: Verify errors are logged and handled without swallow.
+4. **Lane 4: Security & Hygiene Audit**:
+   - **Secrets Check**: No hardcoded API keys, passwords, or tokens in source code.
+   - **Injection & Sanitization**: Ensure inputs are validated and parameterized.
+5. **Lane 5: 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".
+   - Provide concrete walkthrough: "Where to go", "What to run/click", "What to expect".
 
 ### 3. Update Living Spec (`current-feature.md`)
 Append or update `## 5. Verification Evidence` in `devflow/context/current-feature.md` in **Thai (`th`)**:
@@ -48,6 +59,7 @@ Append or update `## 5. Verification Evidence` in `devflow/context/current-featu
 ## 5. Verification Evidence
 - **Typecheck & Linter**: Passed (0 errors, 0 warnings)
 - **Automated Test Suites**: All tests passed (e.g. 12/12 passed, 0 failed)
+- **Scrutinize & Security Audit**: Clean (No boundary issues, 0 secrets, safe inputs)
 - **Acceptance Criteria Verification**:
   - [x] AC-1: {ผลการตรวจสอบเงื่อนไขที่ 1 ผ่าน 100%}
   - [x] AC-2: {ผลการตรวจสอบเงื่อนไขที่ 2 ผ่าน 100%}

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

@@ -8,7 +8,7 @@ argument-hint: "{running-id or workspace path}"
 
 $ARGUMENTS
 
-Final delivery, safety pass, archive, and run closure stage in Fast-Track. Validates verification status, archives `devflow/context/current-feature.md` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`, resets the stub, performs git merge, and closes the run **without auto-generating HTML reports**.
+Final delivery, safety pass, archive, and run closure stage in Fast-Track. Validates verification status, archives `devflow/context/current-feature.md` to `devflow/history/{features|fixes|rollbacks}/{xxx-slug}.md`, resets the stub, updates changelog, performs conventional commit & git merge, and closes the run **without auto-generating HTML reports**.
 
 ## Invocations & Aliases
 
@@ -62,20 +62,30 @@ When invoked:
    _Nothing in progress. Run /feature, /fix, or /rollback to start._
    ```
 
-### 4. Update Master Ledger (`HISTORY.md`)
-Append a new row to `devflow/history/HISTORY.md` under `## 📜 Master Release Log`:
-```markdown
-| {YYYY-MM-DD} | `{ID}` | {Category} | {Title} | `{commit_hash}` | `Released` | [`{xxx-slug}.md`]({category}/{xxx-slug}.md) |
-```
+### 4. Update Master Ledger (`HISTORY.md`) & CHANGELOG.md
+1. Append a new row to `devflow/history/HISTORY.md` under `## 📜 Master Release Log`:
+   ```markdown
+   | {YYYY-MM-DD} | `{ID}` | {Category} | {Title} | `{commit_hash}` | `Released` | [`{xxx-slug}.md`]({category}/{xxx-slug}.md) |
+   ```
+2. **Keep a Changelog & SemVer**:
+   - If `CHANGELOG.md` exists, append a new version block following SemVer principles:
+     - `Major (+1.0.0)`: Breaking architectural changes or API removal
+     - `Minor (0.+1.0)`: New user-facing feature additions (`Added`)
+     - `Patch (0.0.+1)`: Bug fixes (`Fixed`), documentation (`Docs`), or tweaks (`Changed`)
 
 ### 5. Policy on HTML Reports (Strict Rule)
 > [!IMPORTANT]
 > **No Auto-Generated HTML**: ห้ามสร้างไฟล์ `report.html` หรือ `60-report.html` แบบอัตโนมัติในขั้นตอนนี้โดยเด็ดขาด!
 > หากผู้ใช้ต้องการดู HTML Dashboard สวยงาม ให้แจ้งผู้ใช้ว่าสามารถเรียกคำสั่งแยกได้: `/report:html`
 
-### 6. Git Merge & Branch Cleanup
-1. Commit all modified tracking files.
-2. Squash-merge feature branch into target base branch (`main` / `master`) with explicit user approval.
+### 6. Conventional Commits, Git Merge & Branch Cleanup
+1. **Conventional Commits Format**:
+   - Stage relevant files explicitly.
+   - Use imperative mood: `<type>(<scope>): <short imperative summary>` (e.g. `feat(auth): add password reset flow`, `fix(cli): handle missing config gracefully`).
+   - Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`.
+2. **Squash-Merge**:
+   - Squash-merge feature branch into target base branch (`main` / `master`) with explicit user approval.
+   - Clean up short-lived feature branch.
 
 ### 7. Close Active Run
 Update `devflow/context/current-stage.md`:
@@ -86,9 +96,10 @@ Update `devflow/context/current-stage.md`:
 - `Last Completed Run`: `{ID} ({YYYY-MM-DD})`
 - `Last Updated`: `{YYYY-MM-DD}`
 
-### 8. Output Completion Report
+### 8. Output Completion Report & PR Template
 Report to the user:
 - Run successfully completed and merged
 - Archived path: `devflow/history/{category}/{xxx-slug}.md`
 - Standalone HTML command tip: `/report:html` (if HTML view is desired)
+- Pull Request summary block (if PR creation is needed)
 - Workspace is now Idle and ready for the next task.

package/template/AGENTS.md

@@ -30,7 +30,7 @@ Unused adapter families can be removed. Codex and Antigravity projects keep `.ag
 
 ### 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`, `report-html`, `devflow`, `onboard`, `adopt`, `doctor`, `try`, `rollback`, `ci`, `brief`, `autopilot`, `idea`, `spec`). 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-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:
    - **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`.

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

@@ -16,9 +16,14 @@
 
 ## 2. CLI Architecture & Engineering Principles
 
-- **Separation of Concerns (Deep Modules)**:
+- **Separation of Concerns (Deep Modules & Information Hiding)**:
   - Keep CLI entry points (`bin/create-nexus-devflow.ts`) thin: handle argument parsing, option normalization, and terminal formatting.
   - Encapsulate all core business logic, filesystem operations, and parsing inside modular libraries (`lib/current-work.ts`, `lib/findings.ts`, `lib/git.ts`, `lib/uninstall.ts`, `lib/update.ts`).
+  - **Deep Modules**: Strive for simple, narrow interfaces that hide extensive implementation complexity internally.
+- **Refactoring & Code Simplification (Simplify Discipline)**:
+  - **Early Returns**: Guard conditions should exit early to eliminate deep nesting.
+  - **Single Responsibility (SRP)**: Functions should do one cohesive thing and stay under 50 lines whenever possible.
+  - **Pure Functions**: Favor deterministic functions without side effects for data transformation and parsing.
 - **Safety Flags & Idempotency**:
   - Destructive or mutating operations (e.g. `uninstall`, `update`, `install`) must support safety flags:
     - `--dry-run`: Preview actions and affected files without modifying the disk.
@@ -33,18 +38,33 @@
 
 ---
 
-## 3. File Organization & Directory Structure
+## 3. 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.
+- **Defensive Input Validation**: Validate all inputs at module boundaries before processing. Never trust user or external JSON input without structural validation.
+
+---
+
+## 4. Database & Storage Architecture (When Applicable)
+
+- **Migration Safety**: Schema changes must be backward-compatible (Expand and Contract pattern). Never drop columns or rename fields in a single step.
+- **Indexing Strategy**: Always index foreign keys, search filters, and unique constraints.
+- **Connection Hygiene**: Use connection pooling and ensure connections/file handles are closed cleanly in `finally` blocks.
+
+---
+
+## 5. File Organization & Directory Structure
 
 ```text
 nexus-devflow/
 ├── .agents/skills/             # Codex & Google Antigravity skill definitions
 ├── .claude/skills/             # Claude Code mirrored skill adapters
 ├── .nexus/                     # Metadata tracking & upstream baseline ledger
-├── devflow/                    # Framework workspace context, runs, and discoveries
+├── devflow/                    # Framework workspace context, history, and discoveries
 │   ├── context/                # Living source-of-truth context files
 │   ├── discoveries/            # Pre-delivery discovery records (00-discover.md)
-│   ├── runs/                   # Running delivery artifacts (current-feature.md / 00-70)
-│   ├── history/                # Master delivery archive (HISTORY.md)
+│   ├── history/                # Master delivery archive (features/, fixes/, rollbacks/, HISTORY.md)
 │   └── ideas.md                # Idea Inbox and backlog
 ├── packages/
 │   └── create-nexus-devflow/   # Distribution npm package source
@@ -56,7 +76,7 @@ nexus-devflow/
 
 ---
 
-## 4. Naming Conventions
+## 6. Naming Conventions
 
 - **Files & Directories**:
   - Skills and command directories: `kebab-case` (e.g. `00-discover`, `report-html`, `sync-upstream`).
@@ -70,7 +90,7 @@ nexus-devflow/
 
 ---
 
-## 5. Testing & Empirical Proof Standards
+## 7. Testing & Empirical Proof Standards
 
 Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
@@ -81,14 +101,15 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
   - Use isolated temporary directories (`fs.mkdtemp` in `os.tmpdir()`) and ensure cleanup in `finally` blocks.
 - **Empirical Proof Contract**:
   - Never claim a task is "working", "tested", or "verified" without providing concrete empirical proof (exact command executed, terminal output, pass/fail counts, exit code).
-- **3-Lane Verification Matrix**:
+- **Multi-Lane Verification Matrix**:
   - **Lane 1 (Type & Syntax Safety)**: `tsc --noEmit` (0 type errors).
   - **Lane 2 (Automated Test Suites & Evals)**: `npm test` (Unit tests 100% pass) + `npm run test:routing` (Skill routing accuracy).
-  - **Lane 3 (Manual / Scenario Proof)**: Concrete walkthrough steps ("Where to go", "What to run", "What to expect").
+  - **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").
 
 ---
 
-## 6. Findings Ledger & Quality Gates (`findings.md`)
+## 8. Findings Ledger & Quality Gates (`findings.md`)
 
 - All quality defects, security findings, or regression issues identified during review must be logged in `devflow/context/findings.md`.
 - **Finding State Machine**:
@@ -100,7 +121,7 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
 ---
 
-## 7. Error Handling & Exit Codes
+## 9. Error Handling & Exit Codes
 
 - Use structured `try / catch` blocks around filesystem and process operations.
 - Create meaningful, actionable error messages for the user (explain what failed and how to resolve it).
@@ -110,22 +131,12 @@ Testing is a core quality gate in Nexus-DevFlow, not an afterthought:
 
 ---
 
-## 8. Comments & Documentation Discipline
-
-Write code that explains itself; comment only what the code cannot say:
-
-- Comment the **why**, not the **what**. Avoid comments that simply rephrase the line of code.
-- Avoid noisy banner blocks, section divider lines (`// ====================`), or obvious step narrations.
-- Comments earn their place when documenting:
-  - Non-obvious architectural decisions.
-  - Upstream compatibility quirks or workarounds.
-  - Edge-case handling rationale.
-- Keep JSDoc minimal and useful: provide a one-line summary and document non-obvious parameters.
-
----
-
-## 9. Writing & Language Conventions
+## 10. Conventional Commits & Release Discipline
 
-- **Default Communication & Artifacts**: Thai (`th`) for all generated markdown stage artifacts (`current-feature.md`, `00-discover.md`, etc.), explanations, and user interactions.
-- **Code & Identifiers**: English for all source code, variable names, file paths, CLI flags, and commit messages.
-- **Typography**: Do not use em dashes (`—`) in AI-generated commit messages or technical summaries; use standard hyphens (`-`) or colons.
+- **Conventional Commits**:
+  - Format: `<type>(<scope>): <short imperative summary>`
+  - Types: `feat`, `fix`, `docs`, `refactor`, `test`, `chore`
+- **SemVer Versioning**:
+  - `Major`: Breaking architectural change
+  - `Minor`: New feature addition
+  - `Patch`: Bug fix or documentation update

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

@@ -1,165 +0,0 @@
----name: agent
-
-description: "[Devflow] Invoke specialist persona or role-based agent on a target file, folder, stage artifact, or concern."
----
-# Phase 90: Invoke Agent
-
-Run a specialist agent persona for targeted expertise while preserving the DevFlow 2.0 stage-first contract.
-
-Primary behavior now lives in the `specialist-agent-routing` skill. Keep this workflow as the compatibility wrapper and advanced user-facing agent entry point.
-
-## Usage
-
-```text
-Agent {AGENT_NAME} {TARGET}
-```
-
-Examples:
-
-```text
-Agent requirements-engineer devflow/runs/007-auth-refactor20-spec.md
-Agent codebase-explorer src/services/
-Agent code-reviewer devflow/runs/007-auth-refactor
-```
-
-## Available Agents
-
-Agent definitions live in `../agents/`.
-
-Planning and requirements:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-planner` | Create implementation plans from specs and codebase patterns. |
-| `requirements-engineer` | Refine `10-define.md` and `20-spec.md` before planning. |
-| `prp-core-prd-architect` | Draft PRD documents from early ideas. |
-| `orchestrator` | Coordinate complex work and recommend next specialist steps. |
-| `prp-core-boss` | Route `/goal` requests, decompose work, enforce turn budgets, and validate worker output. |
-
-Research and exploration:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `codebase-explorer` | Find files and patterns; analyze architecture, data flow, and module relationships. |
-| `web-researcher` | Research external APIs, docs, and best practices. |
-
-Implementation:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-coder` | Implement planned subtasks. |
-| `prp-core-worker` | Execute focused Boss-assigned `/goal` subtasks and report validation status. |
-| `backend-specialist` | Backend, APIs, database, server logic. |
-| `frontend-specialist` | UI/UX and frontend implementation. |
-| `database-architect` | Schema, indexing, and query design. |
-
-Quality and debugging:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `test-engineer` | Unit and integration tests. |
-| `prp-core-debugger` | Root cause analysis. |
-| `code-reviewer` | Code review, risk, regressions. |
-| `security-auditor` | Security and logic risk. |
-| `performance-engineer` | Performance bottlenecks. |
-
-Git and docs:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `prp-core-git-committer` | Commit preparation and message quality. |
-| `prp-core-git-pr-maker` | Pull request summary and preparation. |
-| `documentation-maintainer` | Documentation impact analysis. |
-
-Maintenance and infrastructure:
-
-| Agent | Purpose |
-| :--- | :--- |
-| `ob-loop-engineer` | Overnight infrastructure maintenance, code debt pruning, and variant branch testing loops. |
-
-
-## Reusable Skills
-
-The following former narrow agents are now skills. Invoke them through the responsible agent or workflow instead of `Agent`:
-
-| Skill | Apply Through |
-| :--- | :--- |
-| `code-simplification` | `prp-core-coder`, `code-reviewer`, or `Simplify` |
-| `type-design` | `backend-specialist`, `frontend-specialist`, `database-architect`, or `code-reviewer` |
-| `silent-failure-audit` | `code-reviewer`, `test-engineer`, `backend-specialist`, or `security-auditor` |
-
-## Artifact Contract
-
-Specialist agents must use the DevFlow 2.0 stage-first contract:
-
-- Prefer `00-discover.md`, `10-define.md`, `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md`, `70-release.md`, and `60-report.md` as the primary artifacts.
-- Do not silently rewrite legacy JSON artifacts.
-- If migration work still requires JSON, prefer CLI-backed minimal updates instead of full-file rewrites.
-- If the specialist is only reviewing, recommend exact commands instead of mutating artifacts.
-- Keep reports readable without requiring a dashboard or JSON viewer.
-
-## 9arm-Skills Discipline Routing
-
-When the target task matches one of these review or communication modes, apply the credited local pack under `.agents/skills/9arm-skills/` while preserving the normal specialist output contract:
-
-| Situation | Apply |
-| :--- | :--- |
-| `code-reviewer`, PR review, plan critique, or change risk review | `9arm-skills/scrutinize` |
-| debug or RCA specialist work | `9arm-skills/debug-mantra` |
-| completed bug or regression lesson extraction | `9arm-skills/post-mortem` |
-| stakeholder-readable summary, PR body, release note, standup, or status update | `9arm-skills/management-talk` |
-
-Reports that use the pack should include a short `Source Discipline` note with credit to `thananon/9arm-skills`.
-
-## Process
-
-1. Load the persona from `../agents/{AGENT_NAME}.md`.
-2. Read the target file, folder, stage directory, or recent changes.
-3. Apply the persona's specialist logic.
-4. If artifact changes are needed, prefer stage markdown updates first.
-5. Record lightweight context usage in the report when the agent loads notable context.
-6. Produce either a concise report or a focused set of changes.
-
-## Output
-
-If a report is substantial, save it to:
-
-```text
-devflow/reports/{date}-{agent-name}-{timestamp}.md
-```
-
-Before saving a substantial agent report, inspect `.agent/resources/schemas/agent_report.template.md` and use its required headings unless the target workflow provides a more specific template.
-
-Before reporting completion, run:
-
-Review `{report_path}` against `agent_report.template.md`, keep the required headings, and remove placeholder text before completion.
-
-Replace any placeholder or template text with concrete files reviewed, findings, recommendations, and validation needs.
-
-For substantial reports, add a short `Context Usage Notes` subsection under the context reviewed area with files or artifacts loaded, any known token counts, and one practical optimization note for future runs.
-
-Short reports can be returned directly in chat.
-
-## Relationship To DevFlow 2.0
-
-- Classification: Companion command
-- Mainline status: Specialist invocation command, not a numbered stage
-- Typical entry points: any stage that needs focused specialist judgment
-- Typical handoff targets: return to the owning workflow such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`
-
-## Sources
-
-- `AGENTS.md`
-- `.agent/agents/README.md`
-- `.agent/resources/schemas/agent_report.template.md`
-- Related commands: `Research`, `PR-Review`, `Debug`, `Help`, all mainline stages
-
-## Next Workflow Recommendation
-
-- **Primary**: the workflow that owns the target's lifecycle, such as `10-define`, `20-spec`, `30-plan`, `40-execute`, `50-verify`, `60-report`, `70-release`, or `PR-Review`.
-- **Why**: `Agent` supplies specialist judgment; the owning workflow should execute the next lifecycle step.
-- **Alternatives**:
-  - `Research` when the specialist work uncovered unresolved external uncertainty
-  - `Wiki` when the specialist report contains reusable project knowledge
-  - `Help {target}` when the correct next route is unclear
-