@jakkrichm/create-nexus-devflow 2.0.25 → 2.1.0

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

@@ -1,108 +1,120 @@
 ---
 name: try
-description: "[Devflow] Generate human manual QA review walkthrough guide (where to go, what to click, what to expect)."
+description: "[devflow][B] Generate a human manual try guide for the current or most recently completed Blueprint feature, fix, or rollback. Reads the spec, project commands, and available app context, then tells the user exactly what to start, where to go, what to click or run, what to expect, and what would count as wrong. Read-only. Use when the user runs /try, invokes $try, asks how to test manually, asks where to click, asks how to see the change, or wants a manual review path after /implement, /autopilot, /check, or /complete."
 ---
 
-# try - Manual QA & Review Walkthrough Guide
+# try - manual review guide
 
 Where this sits in the workflow:
 
-```text
-40-execute or 50-verify or 60-report  ->  [try]  ->  human review & verification
-(work implemented / verified)                  (manual    (where to go,
-                                               steps)     what to click)
-```
+    /implement or /complete  ->  [try]  ->  human review
+    (work exists)                (manual   (where to go,
+                                  path)     what to click)
 
-`50-verify` proves behavior from automated QA and test runs. `try` gives the user and testers an actionable, step-by-step manual walkthrough: start this command, open this route, click these controls, expect this result, and watch for these failure signs.
+`/check` proves behavior from the agent side. `/try` gives the user a practical
+manual walkthrough: start this command, open this route, click these controls,
+expect this result, and watch for these failure signs.
 
-It is always **read-only 100%**. It does not edit files, install dependencies, commit, merge, push, or run destructive commands.
+It is always read-only. It does not edit files, install dependencies, commit,
+merge, push, or run destructive commands.
 
 ## Input
 
 Optional scope:
 
-- **no argument**: use the active run in `devflow/context/current-stage.md` (or the latest completed run under `devflow/runs/`)
-- `latest`: use the most recent completed run in `devflow/runs/`
-- a run ID or path: e.g. `try RUN-002-add-onboard-adopt-doctor-skills`
-- a specific route, endpoint, or CLI command: focus the walkthrough on that surface
+- no argument: use the active feature, fix, or rollback in
+  `devflow/context/current-feature.md`
+- `latest`: use the most recent archive under `devflow/history/features/`,
+  `devflow/history/fixes/`, or `devflow/history/rollbacks/`
+- a step name or number: focus the guide on that current-feature step
+- a path, route, or command: include it as the main thing to try
 
-If there is no active run and no run history, ask what change or feature the user wants to test manually.
+If there is no active feature and no useful archive, ask what change the user
+wants to try instead of guessing.
 
-## Step 1 - Find The Work To Explain
+## Step 1 - find the work to explain
 
 Read:
 
-- `AGENTS.md` (Commands section)
-- `devflow/context/current-stage.md`
+- `AGENTS.md`
+- `devflow/context/current-feature.md`
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
-- Active run artifacts: `20-spec.md`, `30-plan.md`, `40-execute.md`, `50-verify.md` (or archived run artifacts)
-- Current git branch and status
+- `devflow/build-plan.md`
+- latest files under `devflow/history/features/`,
+  `devflow/history/fixes/`, and `devflow/history/rollbacks/`, if the current
+  feature is reset
+- git branch and working tree status
 
-Do not dump the full spec. Extract only the concrete routes, screens, CLI commands, API endpoints, test data, and expected outcomes that a human needs to verify the feature.
+Prefer the active spec. If `current-feature.md` is the reset stub, use the most
+recent archived feature, fix, or rollback by filename or modification time and
+say that is what you used.
 
-## Step 2 - Identify How To Run The App
+Do not dump the spec. Pull out the routes, commands, UI surfaces, CLI commands,
+API endpoints, data states, and done-whens that matter for a human trying it.
+For a rollback, lead with the path that proves the removed behavior is gone, then
+include one unaffected regression path from the rollback spec.
 
-Check the Commands section in `AGENTS.md`. Adapt to the project type:
+## Step 2 - identify how to run the app
 
-- **Web app**: dev server command (e.g. `npm run dev`), local URL (e.g. `http://localhost:3000`), and specific route/screen.
-- **Server / API**: start command, base URL, endpoint, HTTP method, payload, and expected response shape.
-- **CLI**: exact CLI command, flags, arguments, and expected terminal output.
-- **Library / Module**: sample usage snippet, REPL call, or interactive test command.
-- **Fullstack / Microservices**: minimal combined startup commands (e.g. backend + frontend).
+Use the Commands section in `AGENTS.md`. Match the project type:
 
-If a startup command is missing or unclear in `AGENTS.md`, report that as a configuration gap rather than guessing.
+- **Web app** - dev server command, URL, and the route or screen to open.
+- **Server/API** - server command, base URL, endpoint, method, and expected
+  response shape.
+- **CLI** - exact command(s), arguments, and expected output.
+- **Library** - example command, test fixture, REPL snippet, or sample call.
+- **Hybrid app** - list the smallest set of commands needed, such as backend plus
+  web dev server.
 
-## Step 3 - Produce The Manual Walkthrough Guide
+If the app may already be running, say how to reuse it. If a command is missing
+from `AGENTS.md`, report that as a gap rather than inventing certainty.
 
-Format the guide with these 5 standard sections:
+## Step 3 - write the manual guide
 
-1. **1. Start** - exact command(s) to start the system and where to run them.
-2. **2. Open** - URL(s), screens, tabs, API endpoints, or terminal locations.
-3. **3. Do** - specific clicks, form inputs, toggles, selections, or arguments.
-4. **4. Expect** - expected visible UI change, response payload, state change, output, or absence of errors.
-5. **5. Watch For** - common failure symptoms, console errors, network 4xx/5xx errors, stale state, layout breakage, or safety warnings.
+Produce a short guide with these sections:
 
-### Example Walkthrough Style:
+1. **Start** - commands to run and where to run them.
+2. **Open** - URLs, screens, tabs, API endpoints, or CLI commands.
+3. **Do** - clicks, inputs, selections, or command arguments.
+4. **Expect** - visible result, output, response, state change, file, or lack of
+   error.
+5. **Watch For** - common wrong outcomes, console or network errors, stale data,
+   missing fields, bad empty states, layout issues, or safety warnings.
 
-```markdown
-### 1. Start
-Run `npm run dev` in the project root.
+Keep it concrete. Prefer:
 
-### 2. Open
-Navigate to `http://localhost:3000/dashboard/reports`.
+    Open http://127.0.0.1:7788/api/snapshot
+    Expect a JSON object with `generated_at`, `services`, `projects`, and
+    `conflicts`.
 
-### 3. Do
-1. Click the **"Export Report"** button in the top right.
-2. Select **"Format: HTML"** from the dropdown.
-3. Click **"Download"**.
+Avoid:
 
-### 4. Expect
-- A new file `report.html` is downloaded.
-- The UI displays a green success toast: *"Report exported successfully"*.
-- The downloaded HTML file opens in the browser with full styling and charts.
+    Check that the snapshot works.
 
-### 5. Watch For
-- Spinner hanging indefinitely without downloading.
-- Console error related to `Blob` or `URL.createObjectURL`.
-- Broken styling or unrendered Mermaid charts in the exported HTML.
-```
+## Step 4 - include confidence and gaps
 
-## Step 4 - Include Confidence, Best Signal & Gaps
+End with:
 
-Conclude with:
+- **Best signal** - the one thing the user should try first.
+- **Optional deeper checks** - only if useful.
+- **Gaps** - anything the guide cannot know from the docs, such as missing route
+  names, seed data, credentials, or external services.
 
-- **Best Signal**: the single most critical action the user should try first to confirm functionality.
-- **Edge Cases & Error Flows**: optional secondary checks (e.g. invalid input, empty state, network failure).
-- **Gaps & Assumptions**: anything the guide cannot know for certain (e.g. seed credentials, third-party API keys, required database fixtures).
+If the feature is not user-visible, say so and provide the closest manual signal,
+such as an API response, CLI output, log line, or unit test command.
 
 ## Rules
 
-- **Strictly Read-Only**: Never edit code, commit, push, install packages, or mutate repository state.
-- **Do Not Run Automatically**: Do not launch the server or run commands unless the user explicitly instructs you to do so in the chat.
-- **Be Concrete & Specific**: Provide exact URLs, button labels, and payloads.
-- **Acknowledge Uncertainty**: If a route or behavior is not specified in the spec, state it clearly as an assumption.
+- Read-only only. Do not edit, commit, merge, push, install, or delete.
+- Do not run the app unless the user explicitly asks you to try it for them.
+- Do not pretend a path is known when the spec does not say it. Give the best
+  likely path and label uncertainty.
+- Keep the guide short enough to follow while the app is open.
+- Match the project's commands from `AGENTS.md`.
 
-## Output Formatting
+## Formatting
 
-Follow the project conventions in `devflow/context/ai-interaction.md`: concise, scannable markdown with numbered steps and clear bold headers.
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with numbered
+steps for the manual path and short bullets for warnings.

package/template/{.agents/skills/00-discover → .claude/skills/00-explore}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: 00-discover
-description: "[Devflow] Discover stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID."
+name: 00-explore
+description: "[Devflow] Explore stage in DevFlow 2.0 - explore a request, route supporting inquiry, and decide whether delivery work should begin without allocating a running ID."
 argument-hint: "{title, request, or discovery-id}"
 ---
 
-# Phase 00: Discover
+# Phase 00: Explore
 
 $ARGUMENTS
 
@@ -13,15 +13,15 @@ Explore a request before delivery commitment. Create or resume a Discovery ID, c
 ## Usage
 
 ```text
-00-discover {title or request}
-00-discover IDEA-xxx
-00-discover {discovery-id}
+00-explore {title or request}
+00-explore IDEA-xxx
+00-explore {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`)
+- exploring a pending idea from `devflow/ideas.md` (`00-explore IDEA-xxx`)
 - the best route may be `Brainstorm`, `PRD`, `Research`, or `Debug`
 - supporting findings need to be synthesized into a go/no-go decision
 
@@ -30,7 +30,7 @@ Use this when:
 Write the primary discovery artifact to:
 
 ```text
-devflow/discoveries/{DISCOVERY_ID}-{slug}/00-discover.md
+devflow/discoveries/{DISCOVERY_ID}-{slug}/00-explore.md
 ```
 
 A Discovery ID uses a separate namespace such as `DISC-YYYYMMDD-NNN`. It is not a Running ID and must not reserve a numeric delivery run.
@@ -74,7 +74,7 @@ Set one decision:
 - `Defer`: the idea remains relevant but timing, evidence, or ownership is not ready
 - `Reject`: the idea should not proceed under the current framing
 
-### 3. Write `00-discover.md`
+### 3. Write `00-explore.md`
 
 Record selected routes, returned findings, open questions, decision, and rationale.
 

package/template/.claude/skills/10-define/SKILL.md

@@ -37,13 +37,13 @@ using:
 1. Inspect `devflow/context/current-stage.md`, `devflow/context/current-feature.md`, and `devflow/context/current-run/`.
 2. If an active uncompleted run exists:
    - **HALT and reject opening a new define stage**.
-   - Warn the user to complete or close the active run with `/complete` or `70-release` first.
+   - Warn the user to complete or close the active run with `/complete` or `70-deliver` first.
 
 ### 2. Validate The Discovery Gate
 Require:
 - `Decision: Proceed`
 - `Approval Status: Approved`
-- A resolvable Discovery ID and `00-discover.md`
+- A resolvable Discovery ID and `00-explore.md`
 
 ### 3. Allocate Sequential ID
 - Inspect `devflow/history/HISTORY.md` and allocate sequential ID without prefix (e.g. `022-{slug}`).

package/template/.claude/skills/20-spec/SKILL.md

@@ -69,7 +69,7 @@ Run specification as a contract-hardening loop, not as a prose expansion of the
 Read:
 
 - `10-define.md`
-- the shared `00-discover.md` referenced by `source_discovery` when the original framing still matters
+- the shared `00-explore.md` referenced by `source_discovery` when the original framing still matters
 - research notes if they impose real constraints
 
 ### 2. Write The Specification

package/template/.claude/skills/30-plan/SKILL.md

@@ -55,7 +55,7 @@ Run planning as an evidence loop, not as a one-shot outline.
 Read:
 
 - `devflow/runs/{ID}-*20-spec.md`
-- `10-define.md` and the shared `00-discover.md` referenced by `source_discovery` when they help clarify intent
+- `10-define.md` and the shared `00-explore.md` referenced by `source_discovery` when they help clarify intent
 
 ### 2. Assess Complexity
 

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

@@ -53,5 +53,5 @@ Structure the report in **Thai (`th`)**:
 
 ## Next Workflow Recommendation
 
-- **Primary**: `70-release {ID}`
+- **Primary**: `70-deliver {ID}`
 - **Optional Standalone HTML**: `/report:html`

package/template/{.agents/skills/70-release → .claude/skills/70-deliver}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: 70-release
-description: "[Devflow] Release stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
+name: 70-deliver
+description: "[Devflow] Deliver stage in DevFlow 2.0 - package verified work for delivery, archive run to categorized history, git merge, PR, or deployment."
 argument-hint: "{running-id or workspace path}"
 ---
 
-# Phase 70: Release
+# Phase 70: Deliver
 
 $ARGUMENTS
 
@@ -13,7 +13,7 @@ Package approved work for delivery after the report stage has captured the final
 ## Usage
 
 ```text
-70-release {id or workspace path}
+70-deliver {id or workspace path}
 ```
 
 ## Markdown-First Contract
@@ -21,20 +21,14 @@ Package approved work for delivery after the report stage has captured the final
 Write the primary stage artifact to:
 
 ```text
-devflow/context/current-run/70-release.md
-```
-
-using:
-
-```text
-.agent/resources/schemas/release.template.md
+devflow/context/current-run/70-deliver.md
 ```
 
 ## Process & Quality Gates
 
 ### 0. Step 0 Safety Pass & Findings Ledger Gate
 
-Before packaging, merging, or releasing:
+Before packaging, merging, or delivering:
 
 1. **Findings Ledger Blockers**:
    - Inspect `devflow/context/findings.md`.

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

@@ -8,7 +8,7 @@ description: "[Devflow] Survey existing brownfield codebase and bootstrap DevFlo
 Where this sits in the workflow:
 
 ```text
-existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  00-discover or 10-define
+existing codebase  ->  [adopt]  ->  project-overview + coding-standards  ->  00-explore or 10-define
 (already has code)     (survey +    (seeded from the real code;               (first feature / refactoring
                         interview)   shipped architecture documented)          delivery lifecycle)
 ```
@@ -91,5 +91,5 @@ Present the adoption summary for review:
 - Inferred conventions and coding standards
 - Available verified commands in `AGENTS.md`
 - Recommended next step:
-  - Run `00-discover` (or `00-discover`, `$00-discover`) to explore the next major initiative or feature
+  - Run `00-explore` (or `00-explore`, `$00-explore`) to explore the next major initiative or feature
   - Run `10-define` (or `10-define`, `$10-define`) to immediately scope a delivery run for known roadmap items

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

@@ -0,0 +1,141 @@
+---
+name: audit
+description: "[Devflow] Code, quality, security, performance, and test audit skill with durable ledger tracking in devflow/context/findings.md."
+argument-hint: "{scope/path or lens: quality | security | performance | tests | full}"
+---
+
+# audit - Dedicated Multi-Lens Audit & Quality Ledger
+
+Where this sits in the workflow:
+
+```text
+git diff / codebase / path  ->  [audit]  ->  devflow/context/findings.md  ->  check-gate / /complete
+(target scope & lenses)         (analyze &   (durable findings ledger)        (quality gates)
+                                 record)
+```
+
+`audit` is the dedicated quality, security, performance, and test review engine for Nexus-DevFlow. It inspects changed files in the active branch, a targeted path, or the full repository, evaluates them through specialized review lenses, and records findings with durable IDs into `devflow/context/findings.md`.
+
+It is **strictly non-destructive**: it inspects and records findings in `findings.md`, but never modifies source code directly. Remediation is handled via `/fix <ID>` or `/implement`.
+
+## Usage & Invocations
+
+```text
+/audit                      # Audit active branch changes across all lenses (Default)
+/audit security             # Focused Security audit on active changes
+/audit quality              # Focused Quality, dead code & code smells audit
+/audit performance          # Focused Performance & efficiency audit
+/audit tests                # Focused Test quality & coverage gap audit
+/audit full                 # Full repository audit across all lenses
+/audit <path>               # Targeted audit on a specific file or directory
+$audit                      # Codex CLI invocation
+```
+
+---
+
+## Process
+
+### Step 1 - Determine Scope & Lens
+
+1. **Scope Resolution**:
+   - **Branch / Active Run (Default)**: Inspect `git diff main...HEAD` or files touched in `devflow/context/current-feature.md`.
+   - **Targeted Path**: If a directory/file path is passed (e.g. `src/auth/`), scope analysis to that path.
+   - **Full Project**: If `full` is passed, scope analysis across the entire project repository.
+2. **Lens Selection**:
+   - If a lens name is provided (`security`, `quality`, `performance`, `tests`), focus primarily on that domain.
+   - If none is provided, evaluate across all four lenses.
+
+---
+
+### Step 2 - Multi-Lens Inspection
+
+Evaluate code against standard criteria:
+
+#### 1. 🛡️ Security Lens
+- **Secrets & Credentials**: Look for hardcoded API keys, JWT secrets, passwords, or tokens.
+- **Injection Risks**: Unsanitized SQL, shell command execution, template injection, path traversal.
+- **Access Control & Auth**: Unprotected API routes, missing permission checks, insecure direct object references.
+- **Data Protection & Sanitization**: Missing XSS sanitization, unsafe HTML rendering, sensitive data leaks in logs.
+
+#### 2. 💎 Quality & Maintainability Lens
+- **Code Smells & Complexity**: Overly complex functions, deep nesting, high cyclomatic complexity.
+- **Duplication & Dead Code**: Repeated logic that should be abstracted, unused variables/imports/functions.
+- **Contract & Type Safety**: Unsafe `any` casts, missing error handling, unhandled Promise rejections.
+- **Standards & Conventions**: Compliance with `devflow/context/coding-standards.md`.
+
+#### 3. ⚡ Performance Lens
+- **Database & Query Efficiency**: N+1 queries, unindexed filter columns, unbounded queries without pagination.
+- **Resource Management**: Memory leaks, unclosed streams/handles, blocking synchronous operations in async loops.
+- **Bundle & Asset Footprint**: Unnecessary heavy dependencies, oversized client-side bundles.
+
+#### 4. 🧪 Test Quality Lens
+- **Coverage Gaps**: Critical business logic or branch conditions lacking unit or integration tests.
+- **Negative & Error Cases**: Testing only the happy path without asserting error handling and failure boundaries.
+- **Flakiness & Assertions**: Tests with race conditions, missing awaits, or non-deterministic assertions.
+
+---
+
+### Step 3 - Record Findings in `devflow/context/findings.md`
+
+For every confirmed issue found:
+
+1. Determine **Severity**:
+   - `P0` (Critical Blocker): Security vulnerabilities, data corruption bugs, crash-level defects.
+   - `P1` (High Blocker): Major regressions, broken critical flows, unhandled failure paths.
+   - `P2` (Medium): Code smells, missing non-critical tests, performance bottlenecks.
+   - `P3` (Low / Polish): Minor naming inconsistencies, style polish, documentation gaps.
+
+2. Determine **Durable ID**:
+   - Check existing IDs in `devflow/context/findings.md` and use the next sequential ID:
+     - `SEC-001`, `SEC-002` (Security)
+     - `QUAL-001`, `QUAL-002` (Quality)
+     - `PERF-001`, `PERF-002` (Performance)
+     - `TEST-001`, `TEST-002` (Tests)
+     - Or universal `FIND-001`, `FIND-002`
+
+3. Append to `devflow/context/findings.md`:
+   ```markdown
+   ### SEC-001 [P0] open - Hardcoded Secret Key in config.ts
+   - **Location**: `src/config.ts:24`
+   - **Impact**: API secret key exposed in client bundle
+   - **Remediation**: Move to environment variable `process.env.API_SECRET`
+   ```
+
+---
+
+### Step 4 - Output Audit Summary & Recommendations
+
+Present a clean markdown report in **Thai (`th`)**:
+
+```markdown
+### 🛡️ ผลการตรวจสอบความปลอดภัยและคุณภาพโค้ด (Audit Summary)
+
+- **ขอบเขตการตรวจสอบ (Scope)**: `{Branch Diff | Path | Full Project}`
+- **เลนส์การตรวจ (Lenses)**: `{Quality, Security, Performance, Tests}`
+- **ข้อบกพร่องที่พบ (Findings Summary)**:
+  - 🔴 **P0 (Critical)**: {count}
+  - 🟠 **P1 (High)**: {count}
+  - 🟡 **P2 (Medium)**: {count}
+  - 🔵 **P3 (Low)**: {count}
+
+#### รายการข้อบกพร่องใหม่ที่บันทึกใน Findings Ledger:
+1. `SEC-001 [P0] open - Hardcoded Secret Key in config.ts` (`src/config.ts:24`)
+2. `PERF-001 [P2] open - Unbounded query in user list` (`src/users.ts:58`)
+
+---
+👉 **คำแนะนำถัดไป (Next Actions)**:
+- หากมีข้อบกพร่องระดับ P0/P1: เรียก `/fix SEC-001` เพื่อเริ่มการแก้ไขที่ติดตามได้
+- ตรวจสอบสถานะ Blockers: `nexus-devflow findings --blockers`
+```
+
+---
+
+## Release Gatekeeper Rule
+
+> [!IMPORTANT]
+> Any `P0` or `P1` finding in `open` or `fixed` status in `devflow/context/findings.md` **unconditionally blocks**:
+> - `nexus-devflow check-gate` (Exit code 1)
+> - `/complete` (Fast-Track delivery close)
+> - `70-deliver` (Deep-Track release packaging)
+>
+> Findings must be repaired via `/fix` and verified with `/check` to reach `closed`, `accepted`, or `invalid` status.