@jakkrichm/create-nexus-devflow 2.17.5 → 2.17.6

package/template/.claude/skills/feature/reference/feature-spec-template.md

@@ -14,18 +14,18 @@
 ## 1. Specification & Scope
 
 ### 1.1 Problem Statement
-{คำอธิบายปัญหาและที่มาของความจำเป็นในการพัฒนาฟีเจอร์นี้}
+{Description of the problem, background, and rationale for developing this feature}
 
 ### 1.2 In-Scope
-1. {ขอบเขตการทำงานข้อที่ 1}
-2. {ขอบเขตการทำงานข้อที่ 2}
+1. {In-scope item 1}
+2. {In-scope item 2}
 
 ### 1.3 Out-of-Scope
-- {สิ่งที่อยู่นอกเหนือขอบเขตหรือไม่ทำในรอบนี้}
+- {Items deliberately excluded or deferred to future features}
 
-### 1.4 Acceptance Criteria (เกณฑ์การยอมรับ)
-- [ ] **AC-1**: {เกณฑ์การตรวจรับข้อที่ 1}
-- [ ] **AC-2**: {เกณฑ์การตรวจรับข้อที่ 2}
+### 1.4 Acceptance Criteria
+- [ ] **AC-1**: {Acceptance criterion 1}
+- [ ] **AC-2**: {Acceptance criterion 2}
 
 ---
 
@@ -40,18 +40,18 @@
 - **Review Strategy**: One feature-level review packet at completion
 
 ### 2.3 Test Decision: Required (TDD) | Optional
-- **Rationale**: {เหตุผลความจำเป็นในการเขียน Unit Tests / TDD}
+- **Rationale**: {Reason for requiring Unit Tests / TDD}
 
 ---
 
 ## 3. Implementation Checklist (Strict TDD)
 
-- [ ] **Task 1: {หัวข้องานที่ 1}**
-  - [ ] 1.1 `[TDD-Red]`: {เขียน Test เคสล้มเหลว}
-  - [ ] 1.2 `[TDD-Green]`: {เขียนโค้ดขั้นต่ำเพื่อให้ Test ผ่าน}
-  - [ ] 1.3 `[TDD-Refactor]`: {Refactor และตรวจให้ 100% Tests Green}
+- [ ] **Task 1: {Task 1 title}**
+  - [ ] 1.1 `[TDD-Red]`: {Write failing unit or behavioral test}
+  - [ ] 1.2 `[TDD-Green]`: {Write minimal implementation to pass test}
+  - [ ] 1.3 `[TDD-Refactor]`: {Refactor and ensure 100% tests green}
 
-- [ ] **Task 2: {หัวข้องานที่ 2}**
+- [ ] **Task 2: {Task 2 title}**
   - [ ] 2.1 `[TDD-Red]`: ...
   - [ ] 2.2 `[TDD-Green]`: ...
   - [ ] 2.3 `[TDD-Refactor]`: ...
@@ -65,11 +65,11 @@
 - **Automated Test Matrix**: TBD
 - **Static Contract Verification**: TBD
 - **Package Smoke Test**: TBD
-- **Findings Ledger**: ตรวจสอบ `findings.md` สะอาด 100%
+- **Findings Ledger**: Verify `findings.md` is 100% clean
 
 ### 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
-- [ ] **AC-1**: {หลักฐานการผ่านเกณฑ์ข้อที่ 1}
-- [ ] **AC-2**: {หลักฐานการผ่านเกณฑ์ข้อที่ 2}
+- [ ] **AC-1**: {Empirical proof for AC-1}
+- [ ] **AC-2**: {Empirical proof for AC-2}
 
 ---
 

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

@@ -26,7 +26,7 @@ When invoked:
 3. Allocate the next sequential ID (e.g. `IDEA-001`, `IDEA-002`).
 
 ### 2. AI Feasibility & Value Analysis
-Evaluate the user's raw idea and generate an enriched entry in Thai (`th` per user communication rules):
+Evaluate the user's raw idea and generate an enriched entry:
 - **Raw Idea**: The user's input description
 - **AI Feasibility & Tech**: Feasibility rating (Easy / Medium / Complex) along with recommended libraries, APIs, or architectural approaches
 - **Value & Potential**: Business value, user benefits, and strategic impact
@@ -37,17 +37,17 @@ Insert the new idea block directly under `## 📌 Pending Ideas` in `devflow/ide
 
 ```markdown
 ### [IDEA-001] {Brief idea title}
-- **บันทึกเมื่อ**: {YYYY-MM-DD}
-- **ไอเดียตั้งต้น**: {User's raw idea text}
+- **Recorded Date**: {YYYY-MM-DD}
+- **Original Idea**: {User's raw idea text}
 - **AI Feasibility & Tech**: {Feasibility and tooling analysis}
 - **Value & Potential**: {Value and impact analysis}
-- **Quick Seed (กันลืม)**:
+- **Quick Seed**:
   1. {Key point 1}
   2. {Key point 2}
-- **สถานะ**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
+- **Status**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
 ```
 
-*(If placeholder `*(ยังไม่มีไอเดียค้างอยู่...)*` exists, remove it upon recording the first idea)*
+*(If placeholder `*(No pending ideas...)*` exists, remove it upon recording the first idea)*
 
 ### 4. Output Summary
 Report to the user:

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

@@ -111,10 +111,13 @@ When implementing a rollback task, follow the exact safety procedure in `referen
 Work in small reviewable diffs, keeping progress in the selected spec.
 
 1. For logic or behavior changes with the test gate on, use Red-Green-Refactor: write a focused failing test, confirm the assertion fails for the missing behavior, implement the smallest change, then refactor with affected tests green. Preserve the user's existing work. Consult [TDD anti-patterns](tdd-anti-patterns.md) when test design needs it.
+   - **Proportional Engineering**: Add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only when the approved spec or an established repository requirement needs it now. Prefer existing code, standard library, and native platform features.
 2. Match the step's done-when and run focused checks. Documentation or formatting-only edits use structural checks and review; they do not require artificial unit tests. Capture relevant runtime or browser proof for behavioral criteria, following the selected Check policy.
 3. Fix failures caused by the change and rerun affected checks without requesting authorization again. Broaden verification when dependencies, failures, or risk justify it.
 4. Record the diff summary and evidence. Mark a step complete once its done-when passes and any configured per-step review has been approved. A repaired finding becomes `fixed` with resolution evidence; only a subsequent audit can close it. Apply the review cadence above before proceeding.
 
+Run a proportionality check before final verification: every new abstraction, dependency, service, configuration surface, compatibility layer, and security mechanism must trace to the approved spec or an established repository requirement. Remove speculative machinery this work added without weakening real trust-boundary validation, data-loss prevention, accessibility, or configured verification.
+
 At the final handoff, run the exact documented Verify command and all required gates. If there is no Verify command, use the project's declared build and test commands. Reuse a passing result for unchanged inputs within this pass; rerun affected gates after subsequent edits. Do not add tests or tools just to inflate the verification matrix.
 
 ### Ticket execution

package/template/AGENTS.md

@@ -28,6 +28,17 @@ Explicit user scope takes precedence over skill guidance, within runtime permiss
 
 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.
 
+## 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.
+
+- 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.
+- Ask only when an unknown materially changes behavior, architecture, persisted data, interoperability, a real security boundary, or cost. Otherwise choose the simplest repository-native implementation.
+- Add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only for a current requirement.
+- Simplicity never removes real trust-boundary validation, data-loss prevention, accessibility, explicit security requirements, configured tests, or project rules.
+- Stack-specific template standards apply only when the project uses that stack.
+
 ## Project configuration
 
 `devflow/config.json` is the user-owned, machine-readable workflow policy for this project. Workflow skills read the relevant settings before acting. A missing file means built-in defaults. An invalid file falls back to defaults for read-only status reporting, but mutating workflow commands stop and point to `/doctor` instead of guessing.
@@ -50,7 +61,7 @@ Unused adapter families can be removed. Codex, Antigravity, GitHub Copilot, and
 
 ### 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`, `continuous`, `analyze`, `discovery`, `idea`, `grill`, `brainstorm`, `bughunter`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `ci`, `test`, `setup-tests`, `browser-tests`, `autopilot`, `prototype`, `report-html`, `brief`, `audit`, `release`, `convert-any-to-md`, `publish-devflow`, `vendor`). 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`, `continuous`, `analyze`, `discovery`, `explore`, `idea`, `grill`, `brainstorm`, `bughunter`, `devflow`, `doctor`, `overview`, `debug`, `onboard`, `adopt`, `try`, `rollback`, `ci`, `test`, `setup-tests`, `browser-tests`, `autopilot`, `prototype`, `report-html`, `brief`, `audit`, `release`, `convert-any-to-md`, `publish-devflow`, `vendor`). 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`, `implement`, `continuous`, `devflow`, `discovery`, `analyze`).
    - **Slash Prefix (`/`)**: For tools supporting slash commands (Claude Code, Google Antigravity, Gemini CLI), e.g., `/feature`, `/fix`, `/implement`, `/continuous`, `/devflow`, `/discovery`, `/analyze`.
    - **Dollar Prefix (`$`)**: For OpenAI Codex CLI or skill-invocation tools, e.g., `$feature`, `$fix`, `$continuous`, `$devflow`, `$discovery`, `$analyze`.

package/template/devflow/docs/USAGE.md

@@ -57,9 +57,9 @@ Before committing to delivery, use specialized companion skills:
 
 ---
 
-## 4. Core Skills Inventory (32 Skills)
+## 4. Core Skills Inventory (33 Skills)
 
-DevFlow ships **32 bundled Core Skills** from the ordered `core_skills` inventory
+DevFlow ships **33 bundled Core Skills** from the ordered `core_skills` inventory
 in `agent-bundle.manifest.json`, synchronized 1:1 across `.agents/skills/`
 (Codex / Antigravity / Copilot) and `.claude/skills/` (Claude Code). Local or
 Personal Skills may coexist in a workspace, but are excluded from the Core count
@@ -82,9 +82,10 @@ and package template until explicitly promoted.
 - `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)
+### C. Workspace & Governance Skills (20 Skills)
 - `devflow`: Interactive workspace inspector and intent router.
 - `doctor`: Read-only health check for setup, adapters, and workflow drift.
+- `explore`: Fast read-only query answering and codebase orientation without writing files.
 - `onboard`: Configure freshly scaffolded projects.
 - `adopt`: Bootstrap DevFlow into existing brownfield codebases.
 - `overview`: Compile living source of truth from planning docs.

package/template/devflow/docs/skill-selection-policy.md

@@ -42,6 +42,7 @@ Use pre-flight skills before committing to delivery when exploring new ideas or
 | **System Diagnostics** | `/doctor` | Read-only check of adapters, configs, and workflow drift. |
 | **Workspace Navigation** | `/devflow` | Flagship state inspector and next action router. |
 | **Root-Cause Analysis** | `/debug` | Scientific six-phase diagnosis using a deterministic red-capable feedback loop without modifying source. |
+| **Read-Only Code Exploration** | `/explore` | Fast read-only query answering and codebase orientation without writing files. |
 | **Architecture & Spec Verification** | `/check` | Reviews Deep Modules, documented standards, and behavioral acceptance as independent axes. |
 | **Manual QA Guide** | `/try` | Generates click-by-click human manual test guide. |
 | **Code & Security Audit** | `/audit` | Branch-aware or full-project code and security audit. |
@@ -57,7 +58,7 @@ Use pre-flight skills before committing to delivery when exploring new ideas or
 
 ## 4. Selection Boundaries & References
 
-- The **32 bundled Core Skills** are the names in `agent-bundle.manifest.json#core_skills`; Local or Personal Skills are workspace extensions, not automatic public commands.
+- The **33 bundled Core Skills** are the names in `agent-bundle.manifest.json#core_skills`; Local or Personal Skills are workspace extensions, not automatic public commands.
 - Prefer an existing Core Skill before adding a new public surface. Follow [governance rules](governance-rules.md) for promotion and placement decisions.
 - Generated artifacts follow the [Markdown metadata contract](markdown-metadata-contract.md).
 - Human review responsibilities are defined in the [manual review workflow](manual-review-workflow-spec.md).

package/template/devflow/docs/workflow-surface-map.md

@@ -1,8 +1,8 @@
-# Workflow Surface Map (32 Core Skills)
+# Workflow Surface Map (33 Core Skills)
 
 This document outlines the active workflow surfaces and command taxonomy in **Nexus-DevFlow 2.13.0**.
 
-The canonical surface contains **32 Core Skills** from
+The canonical surface contains **33 Core Skills** from
 `agent-bundle.manifest.json#core_skills`. Additional Local or Personal Skills
 may exist in a workspace, but are not bundled product commands until explicitly
 promoted into that inventory.
@@ -18,7 +18,7 @@ Each command in DevFlow has exactly **one canonical name** and can be invoked ac
 
 ---
 
-## 2. Canonical Surface Taxonomy (32 Core Skills)
+## 2. Canonical Surface Taxonomy (33 Core Skills)
 
 ### ⚡ 1. The 4-Stage Living Spec Lifecycle Skills (7 Skills)
 | Command | Category | Purpose | Primary Artifact |
@@ -44,11 +44,12 @@ Each command in DevFlow has exactly **one canonical name** and can be invoked ac
 
 ---
 
-### 🧰 3. Workspace Governance & Operations (20 Skills)
+### 🧰 3. Workspace Governance & Operations (21 Skills)
 | Command | Category | Purpose |
 | :--- | :--- | :--- |
 | `devflow` | Navigation | Flagship interactive guide, state inspector, and intent router. |
 | `doctor` | Diagnostics | Read-only health check for setup, adapters, and workflow drift. |
+| `explore` | Navigation | Fast read-only query answering and codebase orientation without writing files. |
 | `overview` | Context | Regenerate and validate `project-overview.md` from planning docs. |
 | `brief` | Planning | Scope and dependency briefing before speccing a feature. |
 | `debug` | Diagnostics | Scientific six-phase diagnosis using a deterministic red-capable feedback loop. |

package/template/devflow/reference/feature-spec-template.md

@@ -1,110 +1,82 @@
-# [ID-slug] Feature Title
+# 📐 [{xxx-slug}] {title}
 
-> **Template Type**: Task-Isolated Living Spec
-> **Active Location**: `devflow/context/{xxx-slug}/spec.md`
-> **Archive Location**: `devflow/history/{features|fixes|rollbacks}/{ID-slug}.md`
-
-- **Feature ID**: `{xxx-slug}`
-- **Category**: `features` | `fixes` | `rollbacks`
-- **Target Branch**: `feature/{xxx-slug}`
-- **Status**: `Spec Ready` | `In-Progress` | `Verified` | `Completed`
-- **Track**: `Unified Fast-Track`
-- **Discovery Ref**: `devflow/discoveries/DISC-xxx.md` (Optional)
-- **ADR Ref**: `devflow/decisions/ADR-xxx.md` (Optional)
-
----
-
-## 🎯 1. Define & Boundaries
-
-### Problem Statement & Goal
-- **Problem**: อธิบายปัญหาที่พบ หรือสิ่งที่ต้องการแก้ไข/ปรับปรุง
-- **Goal**: ผลลัพธ์หรือเป้าหมายที่ต้องการให้เกิดขึ้น
-
-### In-Scope & Out-of-Scope
-- **In-Scope**:
-  - สิ่งที่ต้องทำในรอบนี้
-- **Out-of-Scope**:
-  - สิ่งที่ไม่ทำในรอบนี้ หรือยกยอดไปทำในเฟสถัดไป
-
-### Risk & Mitigation Matrix
-| Risk | Severity | Mitigation |
-| :--- | :--- | :--- |
-| ความเสี่ยงที่อาจเกิดขึ้น | Low/Medium/High | แนวทางป้องกันหรือรับมือ |
-
-### Success Criteria
-1. เกณฑ์ชี้วัดความสำเร็จข้อที่ 1
-2. เกณฑ์ชี้วัดความสำเร็จข้อที่ 2
+> **Status**: In-Progress  
+> **Track**: Fast-Track (Task-Isolated Living Spec Mode - Feature)  
+> **Category**: Feature  
+> **Source**: `devflow/build-plan.md: Feature {n}` & `devflow/discoveries/{DISC-ID}/discovery.md`  
+> **Branch**: `feature/{xxx-slug}`  
+> **Started Date**: {YYYY-MM-DD}  
+> **Delivered Date**: TBD  
+> **Owner**: DevFlow Core Framework Team & AI  
 
 ---
 
-## 📐 2. Technical Spec & Contracts
+## 1. Specification & Scope
 
-### Architecture & Component Design
-- อธิบายโครงสร้างหรือ Flow การทำงานของ Component/Module
+### 1.1 Problem Statement
+{Description of the problem, background, and rationale for developing this feature}
 
-### Data Models & Schemas
-```typescript
-// Interface หรือ Type Definition
-```
+### 1.2 In-Scope
+1. {In-scope item 1}
+2. {In-scope item 2}
 
-### API & Interface Contracts
-- **Endpoint / Function**: `methodName(params: Type): ReturnType`
-- **Error Handling**: รายละเอียด Error Codes และวิธีจัดการ
+### 1.3 Out-of-Scope
+- {Items deliberately excluded or deferred to future features}
 
-### Non-Functional Constraints
-- **Security**: การตรวจสอบ Input, การจัดการสิทธิ์, Secrets
-- **Performance**: ข้อจำกัดเรื่องความเร็ว หรือ Resource Usage
-
-### Acceptance Criteria (AC)
-- [ ] **AC-1**: เงื่อนไขการยอมรับข้อที่ 1
-- [ ] **AC-2**: เงื่อนไขการยอมรับข้อที่ 2
+### 1.4 Acceptance Criteria
+- [ ] **AC-1**: {Acceptance criterion 1}
+- [ ] **AC-2**: {Acceptance criterion 2}
 
 ---
 
-## 📋 3. Execution Plan & TDD Checklist
+## 2. Plan & Test Strategy
 
-- [ ] **Task 1: Core Foundation & Types**
-  - [ ] 1.1 `[TDD-Red]` เขียน Unit Test สำหรับ Logic ส่วนที่ 1
-  - [ ] 1.2 `[TDD-Green]` Implement Logic ให้ผ่าน Test
-  - [ ] 1.3 `[TDD-Refactor]` Clean up และ Optimize โค้ด
+### 2.1 Files Modified / Created
+- `{file-path}` [NEW | MODIFY | DELETE]
 
-- [ ] **Task 2: Feature Implementation**
-  - [ ] 2.1 `[TDD-Red]` เขียน Test ครอบคลุม Edge Cases
-  - [ ] 2.2 `[TDD-Green]` Implement Feature ตาม Contract
-  - [ ] 2.3 `[TDD-Refactor]` ตรวจสอบความถูกต้องและ Architecture
+### 2.2 Quality Gates & Sensitivity Check
+- **Quality Gate Policy (`independentReview`)**: `manual` | `always` | `when-sensitive`
+- **UI Evidence / Browser Tests**: {Not applicable | Playwright / BrowserOS Neo}
+- **Review Strategy**: One feature-level review packet at completion
 
-- [ ] **Task 3: Integration & QA Verification**
-  - [ ] 3.1 `[TDD-Green]` เชื่อมต่อ UI/API และตรวจสอบ End-to-End
+### 2.3 Test Decision: Required (TDD) | Optional
+- **Rationale**: {Reason for requiring Unit Tests / TDD}
 
 ---
 
-## ⚡ 4. Implementation Log & Evidence
+## 3. Implementation Checklist (Strict TDD)
 
-*(จะถูกบันทึกและอัปเดตความคืบหน้าระหว่างรันคำสั่ง `/implement`)*
+- [ ] **Task 1: {Task 1 title}**
+  - [ ] 1.1 `[TDD-Red]`: {Write failing unit or behavioral test}
+  - [ ] 1.2 `[TDD-Green]`: {Write minimal implementation to pass test}
+  - [ ] 1.3 `[TDD-Refactor]`: {Refactor and ensure 100% tests green}
 
-- **Step 1**: ...
-- **Checkpoint Commit**: `feat(scope): ...`
+- [ ] **Task 2: {Task 2 title}**
+  - [ ] 2.1 `[TDD-Red]`: ...
+  - [ ] 2.2 `[TDD-Green]`: ...
+  - [ ] 2.3 `[TDD-Refactor]`: ...
 
 ---
 
-## 🧪 5. Multi-Lane Verification Matrix
+## 4. Verification Evidence Matrix
 
-*(จะถูกบันทึกผลการตรวจสอบระหว่างรันคำสั่ง `/check`)*
+### ⚖️ Axis 1: Standards, Architecture & Quality Gate
+- **Type Safety & Build Integrity**: TBD
+- **Automated Test Matrix**: TBD
+- **Static Contract Verification**: TBD
+- **Package Smoke Test**: TBD
+- **Findings Ledger**: Verify `findings.md` is 100% clean
 
-| Lane | Command / Verification Target | Result | Notes / Proof |
-| :--- | :--- | :--- | :--- |
-| **Typecheck** | `npm run typecheck` | ⏳ PENDING | |
-| **Lint** | `npm run lint` | ⏳ PENDING | |
-| **Unit Tests** | `npm test` | ⏳ PENDING | |
-| **Manual Proof** | UI / CLI Behavioral Verification | ⏳ PENDING | |
+### 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
+- [ ] **AC-1**: {Empirical proof for AC-1}
+- [ ] **AC-2**: {Empirical proof for AC-2}
 
 ---
 
-## 📦 6. Release Digest & Retrospective
-
-*(จะถูกสรุปและบันทึกอัตโนมัติก่อนทำการ Squash Merge ในคำสั่ง `/complete`)*
+## 5. Delivery Verification & Independent Receipt
 
-- **What Changed**: สรุปสิ่งที่เปลี่ยนแปลง
-- **Key Decisions**: การตัดสินใจสำคัญระหว่างพัฒนา
-- **Lessons Learned**: บทเรียนที่ได้รับ
-- **Known Limitations**: ข้อจำกัดที่ทราบและข้อเสนอแนะในอนาคต
+- **Delivery Date**: TBD
+- **Verification Verdict**: TBD
+- **Framework Tests**: TBD
+- **Static Contract**: TBD
+- **Package Smoke Test**: TBD