@jakkrichm/create-nexus-devflow 2.17.9 → 2.18.1

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

@@ -1,13 +1,10 @@
 ---
 name: ci
-description: "[devflow] Set up or normalize one project Verify command and matching GitHub Actions checks while preserving existing CI, with an optional local pre-push hook. Use for /ci, GitHub Actions setup, pull-request checks, automatic checks, pre-push hooks, or aligning verification."
-argument-hint: "[--hook | --no-hook]"
+description: "[devflow] Set up or normalize one project Verify command and matching GitHub Actions checks while preserving existing CI. Use for /ci, GitHub Actions setup, pull-request checks, automatic checks, or aligning verification."
 ---
 
 # ci - set up automatic GitHub checks
 
-**Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
-
 **First action:** Before project inspection, preflight, or any other tool call,
 publish `running` to `devflow/.state/run.json` using the dashboard activity
 contract in `AGENTS.md`.
@@ -18,7 +15,7 @@ Where this sits in the workflow:
     (project commands)     (setup)    (same recipe)      (pull requests)
 
 This skill gives local work and GitHub one shared automated command. It is an
-optional setup task, not a requirement for using DevFlow.
+optional setup task, not a requirement for using the Blueprint.
 
 Keep the beginner explanation simple:
 
@@ -26,12 +23,9 @@ Keep the beginner explanation simple:
 - **GitHub Actions is the worker.** It runs the same recipe automatically.
 - **A GitHub ruleset is the lock.** That optional remote setting can require the
   worker to report green before merge.
-- **A pre-push hook is the early warning.** That optional local setting runs the
-  recipe before a push leaves the machine. It is a convenience, not the lock:
-  `git push --no-verify` skips it.
 
-This skill configures the recipe and worker, and adds the hook only when the
-user opts in. It never changes the remote ruleset, pushes, publishes, or deploys.
+This skill configures the recipe and worker. It never changes the remote ruleset,
+pushes, publishes, deploys, or adds local git hooks.
 
 ## Input
 
@@ -53,7 +47,7 @@ Read enough to identify the real project setup:
 - `.github/workflows/` and any documented external CI
 - git's current branch, configured default branch, and remotes when available
 
-Do not assume npm, Node.js, `main`, or GitHub from the DevFlow template. Do not
+Do not assume npm, Node.js, `main`, or GitHub from the Blueprint template. Do not
 run installs or edit files during inspection.
 
 If an existing workflow already provides equivalent pull-request checks, explain
@@ -119,26 +113,11 @@ After the workflow exists, ask one question and default to no:
 
     Also add a local pre-push hook that runs Verify before every push? [y/N]
 
-Skip the question when the request already answered it (for example "/ci with
-hook" or "no hook"). When the answer is no, write nothing and move on. When it
-is yes:
-
-1. Write `.githooks/pre-push` (mode 755) that announces itself and then runs
-   the exact `Verify` command from `AGENTS.md` with `exec`, so the command's
-   exit code is the hook's exit code.
-2. Point git at the folder: `git config core.hooksPath .githooks`.
-3. For JavaScript and TypeScript projects, add a `prepare` script,
-   `git config core.hooksPath .githooks 2>/dev/null || true`, so a fresh
-   install wires the hook without a manual step. The `|| true` keeps installs
-   working where no git checkout exists, such as a deploy build. For other
-   stacks, document the `git config` line in the README instead.
-4. Run the hook once (`.githooks/pre-push`). If it fails, remove what this
-   step added and report the failing subcommand. Never leave a hook the
-   project cannot pass.
-
-The hook and the workflow run the same `Verify` command; if one changes, the
-other changes with it. Say in the report that `--no-verify` bypasses the hook,
-so the GitHub ruleset remains the lock.
+Skip the question when the request already answered it (for example "/ci with hook" or "no hook"). When the answer is no, write nothing and move on. When it is yes:
+
+1. Use `npx nexus-devflow hook install pre-push` or configure `.githooks/pre-push` running the exact `Verify` command with `git config core.hooksPath .githooks`.
+2. Run the hook once to verify it passes cleanly. If it fails, revert the hook setup and report the failure. Never leave a hook the project cannot pass.
+3. Note that `git push --no-verify` bypasses the hook if an emergency push is ever needed.
 
 ## Step 4 - prove the setup locally
 
@@ -167,7 +146,6 @@ Finish with a concise setup report:
 - checks included and checks omitted
 - test gate status
 - workflow path and triggers
-- whether a pre-push hook was added, and that `--no-verify` bypasses it
 - local Verify result and whether CI is only prepared locally or confirmed by a
   successful GitHub run
 - files changed
@@ -179,7 +157,7 @@ part of this skill.
 
 ## Interaction with other skills
 
-- `/setup-tests` or `/test` adds the real test command to an existing Verify command, but never
+- `/tests` adds the real test command to an existing Verify command, but never
   creates CI by itself.
 - `/implement`, `/complete`, and `/autopilot` run Verify when it is documented,
   with their existing fallback behavior when it is absent.
@@ -190,8 +168,8 @@ part of this skill.
 
 - Preserve existing CI and custom checks.
 - Never invent tests or install a runner as part of CI setup.
-- Never add coverage, browser tests, security scans, or matrices by default.
-- Add a git hook only through the Step 3b opt-in, never silently.
+- Never add git hooks, coverage, browser tests, security scans, or matrices by
+  default.
 - Never push or change a remote ruleset without separate explicit approval.
 - Keep one exact Verify command shared by local work and GitHub.
 

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

@@ -106,8 +106,6 @@ Before logging or committing, run a short safety pass and report blockers only:
 - no P0 or P1 finding in `devflow/context/{xxx-slug}/findings.md` is `open` or `fixed`.
   `fixed` still blocks on purpose: the repair exists but no review has looked at
   it - run `/audit` to close it. The only waivers are `accepted` or `invalid`.
-- any `Status: Assumed` ADR in `devflow/decisions/` has been surfaced with its ratification plan noted.
-
 
 Do not claim "passed", "verified", or "working" without naming the command,
 route, screenshot, or output that proves it. Stop before Step 1 if required

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

@@ -36,8 +36,7 @@ When invoked without an argument (or when determining the next step), inspect:
 
 ### Default State Recommendations
 - If no run is active and user wants to start a feature -> Recommend `/feature <name>`.
-- If the user requests a bugfix plan -> Recommend `/fix <bug>`.
-- If the user requests a completed fix -> preserve the implementation and verification scope; draft the required spec internally and continue to `/implement` using existing authorization.
+- If no run is active and user wants to fix a bug -> Recommend `/fix <bug>`.
 - If no run is active and user has pending ideas in `devflow/ideas.md` -> Highlight `/feature IDEA-xxx` or `/discovery IDEA-xxx`.
 - If no run is active and user wants deep architectural exploration -> Recommend `/discovery`.
 - If user asks to check system health -> Recommend `doctor`.
@@ -49,7 +48,7 @@ When invoked without an argument (or when determining the next step), inspect:
 | User Intent / Request Type | Recommended Skill | Normal Name / Alias | Lifecycle Path |
 | :--- | :--- | :--- | :--- |
 | **"Spec new feature / living spec"** | `feature` | `/feature` / `/spec` | **Unified**: `/feature` -> `/implement` -> `/check` -> `/complete` |
-| **"Draft a bugfix / small-change plan"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
+| **"Quick bugfix / ad-hoc change"** | `fix` | `/fix` | **Unified**: `/fix` -> `/implement` -> `/check` -> `/complete` |
 | **"Capture quick idea / thought"** | `idea` | `/idea` | **Companion**: Enriches & saves to `devflow/ideas.md` |
 | **"Pre-delivery exploration / research"**| `discovery`| `/discovery` | **Pre-Flight**: `discovery` -> `/feature` |
 | **"Socratic alignment / ADR / glossary"**| `grill` | `/grill` / `/align` | **Pre-Flight**: `grill` -> `/feature` |

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

@@ -81,15 +81,6 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
    - **For interactive system architecture, dataflows, state transitions, and sequence traces**: Use `archify` (`.agents/skills/archify/SKILL.md`) to compile validated interactive HTML artifacts with dark/light themes, motion, and route probes.
    - **For editorial, business, quadrant, or broad diagram types**: Use `diagram-design` (`.agents/skills/diagram-design/SKILL.md`).
    - Save diagram artifacts to `devflow/discoveries/{DISCOVERY_ID}-{slug}/diagrams/{name}.html` and reference them directly in `discovery.md`.
-7. **🧩 Slicing & Decomposition Lens (4 Slicing Archetypes)**:
-   - When breaking down a large initiative into sub-features or milestones, evaluate against [`devflow/reference/slicing-archetypes.md`](file:///d:/Projects/devtools/nexus-devflow/devflow/reference/slicing-archetypes.md):
-     - **Skateboard**: Minimal functional loop (prove core logic end-to-end with minimal UI).
-     - **Facade**: Rich UI/DX with mock backend (validate user flow & interaction first).
-     - **Tracer Bullet**: Deep vertical slice across all layers (DB -> API -> UI) for 1 happy path.
-     - **Journey**: Slice along natural user workflow milestones.
-   - Recommend the primary Archetype for each proposed sub-feature in `discovery.md`.
-
-
 
 ### Decision & Approval Gate:
 Set one visible decision:

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

@@ -100,10 +100,12 @@ Gather these, then summarize. Do not dump file contents.
      report it as an obsolete installer artifact. Its absence is healthy. An
      unchanged managed copy can be removed by the updater; a modified copy needs
      user review.
-   - Check whether `AGENTS.md` contains substantive proportional-engineering
-     guidance (`## Proportional engineering` or equivalent rules). Warn if
-     missing, explaining that updates preserve this file and provide manual repair
-     guidance.
+   - Check whether `AGENTS.md` has substantive proportional-engineering guidance,
+     under `## Proportional engineering` or equivalent customized wording.
+     Accept equivalent guidance anywhere in the file; do not require exact prose.
+     Look for current requirements over hypothetical scale, reuse before new
+     machinery, smaller reversible defaults, questions for material unknowns,
+     and harmonization with `ponytail`.
    - Check whether `AGENTS.md` has a `## Commands` section with dev and build
      commands.
    - Report missing lint or test commands as informational unless the project has
@@ -164,8 +166,6 @@ Gather these, then summarize. Do not dump file contents.
      last commit subject, and whether the branch is ahead of upstream.
    - If the directory is not a git repo, report that as a setup issue and keep
      going.
-9. **Token Economics & Session Cost Audit**
-   - When session transcript is available, report token efficiency, cache hit rate, and estimated model costs using `npm run analyze:tokens` or `scripts/analyze-token-usage.ts`.
 
 ## Output
 

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

@@ -1,21 +1,23 @@
 ---
 name: explore
 description: "[devflow] Explore an idea against the actual codebase without changing files. Investigate whether a change would help, compare alternatives and tradeoffs, and discuss uncertainty before deciding whether to plan anything. Use for /explore, considering an idea, or weighing options without writing a spec."
-argument-hint: "[<idea or question>]"
 ---
 
-# explore - investigate an idea before deciding to build
+# explore - investigate an idea before deciding to build (Read-Only)
 
 **Context reuse:** Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.
 
 Explore is a read-only conversation grounded in the actual project. It can help
-with questions such as whether caching would help a dashboard, whether teams
-belong in the product, or which upload approach fits existing code.
+with questions such as whether caching would help a dashboard, which upload approach
+fits existing code, or how to architect a new capability within the current system.
 
 No plans or active feature are required. Do not require `/overview`, invent a
 plan, or treat missing DevFlow context as a blocker to discussing the idea.
 This command never writes activity state, including `devflow/.state/run.json`.
 
+Per DevFlow rules, communicate and respond in Thai (`th`) while keeping code,
+technical terms, file paths, and identifiers in English.
+
 ## Start from the question
 
 Use the supplied topic or relevant conversation context. With neither, ask what
@@ -69,9 +71,11 @@ let the discussion continue as long as useful.
   size. Explore can discuss an unplanned idea or question a planned approach.
 - `/discovery` develops broader product direction and reviewed planning drafts.
   Explore does not draft either planning file.
+- `/grill` stress-tests plans, extracts domain glossary, and records ADRs.
+- `/ponytail` applies YAGNI discipline and cuts bloat/dependencies.
 - `/debug` reproduces and isolates an actual failure. Explore discusses options
   without executing code to diagnose or verify them.
-- `/feature` writes a buildable spec; `/fix` specifies a confirmed small change.
+- `/feature` writes a buildable task-isolated spec; `/fix` specifies a confirmed small change.
   Suggest the appropriate command only when the user is ready to proceed.
 
 Do not force a handoff at the end of every response. Keep discussing the idea

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

@@ -102,8 +102,6 @@ the data model, stack, and conventions. Decide how big the feature is:
   those sub-items back under the parent in `build-plan.md` as an indented
   checklist (`4a`, `4b`, `4c` ...). Spec only the **first** sub-feature now; the
   rest get picked up on later `/feature` runs.
-  *Use the **4 Slicing Archetypes** ([`devflow/reference/slicing-archetypes.md`](file:///d:/Projects/devtools/nexus-devflow/devflow/reference/slicing-archetypes.md)) to guide the split: 🛹 Skateboard (core logic first), 🎭 Facade (UI/DX mock first), 🎯 Tracer Bullet (end-to-end slice), or 🧭 Journey (workflow steps).*
-
 
 Two levels of breakdown - don't confuse them:
 
@@ -200,7 +198,7 @@ Before the user reads it, turn on the spec yourself and try to break it. The
 cheapest place to catch a scope problem or an oversized step is here, before any
 code exists. Run the draft against these questions:
 
-- **Coverage & Input Mapping.** What does this feature need that no step delivers? Run a mechanical **Input Coverage Test**: does every value this build produces, displays, or computes have a named source (input, DB column, formula, or settled decision) in the spec? Push on the
+- **Coverage.** What does this feature need that no step delivers? Push on the
   unhappy paths the happy-path spec skipped: empty / missing / malformed input,
   the error / loading / empty states, the first-run case, failure of anything
   external it calls.
@@ -220,7 +218,6 @@ code exists. Run the draft against these questions:
   anything pushed to "out of scope" that this feature actually can't ship without?
 - **Done-whens.** Is each one observable and checkable by `/check`, or is it a
   vague "it works"? Make it concrete.
-- **Proportionality.** Does any proposed abstraction, dependency, service, config surface, or security mechanism lack a current requirement, or duplicate existing code/platform features? If so, remove it.
 - **Testing.** Does the predicted coverage match the gate - in-scope logic gets a
   test when a `test` command is declared in `AGENTS.md`, UI/integration rides on
   screenshot + build?

package/template/.agents/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. {In-scope item 1}
-2. {In-scope item 2}
+1. {ขอบเขตการทำงานข้อที่ 1}
+2. {ขอบเขตการทำงานข้อที่ 2}
 
 ### 1.3 Out-of-Scope
-- {Items deliberately excluded or deferred to future features}
+- {สิ่งที่อยู่นอกเหนือขอบเขตหรือไม่ทำในรอบนี้}
 
-### 1.4 Acceptance Criteria
-- [ ] **AC-1**: {Acceptance criterion 1}
-- [ ] **AC-2**: {Acceptance criterion 2}
+### 1.4 Acceptance Criteria (เกณฑ์การยอมรับ)
+- [ ] **AC-1**: {เกณฑ์การตรวจรับข้อที่ 1}
+- [ ] **AC-2**: {เกณฑ์การตรวจรับข้อที่ 2}
 
 ---
 
@@ -40,18 +40,18 @@
 - **Review Strategy**: One feature-level review packet at completion
 
 ### 2.3 Test Decision: Required (TDD) | Optional
-- **Rationale**: {Reason for requiring Unit Tests / TDD}
+- **Rationale**: {เหตุผลความจำเป็นในการเขียน Unit Tests / TDD}
 
 ---
 
 ## 3. Implementation Checklist (Strict TDD)
 
-- [ ] **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 1: {หัวข้องานที่ 1}**
+  - [ ] 1.1 `[TDD-Red]`: {เขียน Test เคสล้มเหลว}
+  - [ ] 1.2 `[TDD-Green]`: {เขียนโค้ดขั้นต่ำเพื่อให้ Test ผ่าน}
+  - [ ] 1.3 `[TDD-Refactor]`: {Refactor และตรวจให้ 100% Tests Green}
 
-- [ ] **Task 2: {Task 2 title}**
+- [ ] **Task 2: {หัวข้องานที่ 2}**
   - [ ] 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**: Verify `findings.md` is 100% clean
+- **Findings Ledger**: ตรวจสอบ `findings.md` สะอาด 100%
 
 ### 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
-- [ ] **AC-1**: {Empirical proof for AC-1}
-- [ ] **AC-2**: {Empirical proof for AC-2}
+- [ ] **AC-1**: {หลักฐานการผ่านเกณฑ์ข้อที่ 1}
+- [ ] **AC-2**: {หลักฐานการผ่านเกณฑ์ข้อที่ 2}
 
 ---
 

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

@@ -1,6 +1,6 @@
 ---
 name: fix
-description: "[devflow] Draft a task-isolated spec for a bug or small change. Use when invoking /fix or requesting a fix plan."
+description: "[devflow] Write a task-isolated spec (devflow/context/{xxx-slug}/spec.md) for an ad-hoc bug fix or small unplanned change, then stop before implementation. Use for /fix, confirmed bugs, or small changes outside the build plan."
 argument-hint: "[{title or issue-description}]"
 ---
 
@@ -23,7 +23,7 @@ it creates a dedicated run folder at `devflow/context/{xxx-slug}/` (e.g. `059-fi
 ## Input
 
 A description of the bug or change, for example `/fix "password reset email never
-sends"`. Use the reported problem as input when the user asks for a fix plan. A request to diagnose a problem belongs to `/debug`; a request to fix and verify it retains its full delivery scope.
+sends"`. If the user just reported the problem in chat, use that.
 
 The input may also be a finding ID from `devflow/context/{xxx-slug}/findings.md` (or previous findings), alone
 or with a description, for example `/fix F-03`.
@@ -46,7 +46,7 @@ then write a short spec to `devflow/context/{xxx-slug}/spec.md`. Also initialize
   big to read. Each ends with an observable "done when".
 - **Verify** - how to confirm it's fixed (what to click or test).
 
-For an explicit `/fix` or a planning-only request, present the spec as the completed deliverable and identify `/implement` as the next command. For an existing request to implement and verify the fix, preserve that authorization: use this spec as the internal handoff and continue through `/implement` without an extra approval pause. Ask only for unresolved material scope, design, or permission decisions.
+Then stop. Tell the user to review the fix spec, then run `/implement` to build it.
 
 ## Rules
 

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

@@ -70,14 +70,10 @@ Allocate the next sequential ID (`ADR-001`, `ADR-002`, ...) and create `devflow/
 ```markdown
 # ADR-xxx: {Title}
 
-- **Status**: Accepted | Assumed (Fast-tracked Assumption)
+- **Status**: Accepted
 - **Date**: {YYYY-MM-DD}
 - **Context**: {Why was this decision needed? What problem does it solve?}
 - **Decision**: {What did we decide to do?}
-- **Assumption Metadata** *(Required when Status is Assumed)*:
-  - **Assumption**: {What was assumed to unblock progress}
-  - **Risk Level & Blast Radius**: {Risk if assumption fails}
-  - **Ratification Plan**: {Trigger, date, or test to ratify as Accepted or Rejected}
 - **Alternatives Considered**:
   - *Option 1*: {Pros / Cons}
   - *Option 2*: {Pros / Cons}
@@ -86,7 +82,6 @@ Allocate the next sequential ID (`ADR-001`, `ADR-002`, ...) and create `devflow/
   - *Trade-offs / Risks*: {Costs, constraints, or follow-ups}
 ```
 
-
 ---
 
 ## 4. Closing & Handoff

package/template/.agents/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:
+Evaluate the user's raw idea and generate an enriched entry in Thai (`th` per user communication rules):
 - **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}
-- **Recorded Date**: {YYYY-MM-DD}
-- **Original Idea**: {User's raw idea text}
+- **บันทึกเมื่อ**: {YYYY-MM-DD}
+- **ไอเดียตั้งต้น**: {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}
-- **Status**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
+- **สถานะ**: `Pending` (Ready for pickup via `/feature IDEA-001` or `/discovery IDEA-001`)
 ```
 
-*(If placeholder `*(No pending ideas...)*` exists, remove it upon recording the first idea)*
+*(If placeholder `*(ยังไม่มีไอเดียค้างอยู่...)*` exists, remove it upon recording the first idea)*
 
 ### 4. Output Summary
 Report to the user: