@jakkrichm/create-nexus-devflow 2.17.9 → 2.18.0

package/template/.agents/skills/setup-tests/reference/browser.md

@@ -0,0 +1,95 @@
+# Browser test setup
+
+This is an explicit optional setup command. It creates a project-owned browser
+test path that later Feature, Implement, Check, and Continuous runs can reuse. It
+does not replace live browser inspection, install during another workflow
+command, or make browser testing mandatory for every DevFlow project.
+
+> 💡 **Nexus-DevFlow Superpower**:
+> Nexus-DevFlow also provides the dedicated first-class skill **`/browser-tests`** which natively connects with Playwright test harnesses and the user's MCP `browseros-neo` (live real-browser inspection). Both paths are fully supported under DevFlow Dual Compatibility.
+
+## Input
+
+This reference is selected by `/setup-tests browser`, `/tests browser`, or an explicit request to set up
+browser or end-to-end testing. A named runner, browser, application surface, or
+flow is a preference to verify against the real project.
+
+## Step 1 - inspect the project
+
+Read enough files to identify the actual browser surface and existing setup:
+
+- `AGENTS.md`, especially Commands and any Verify command
+- package or language manifests, lockfiles, workspaces, and runtime versions
+- existing browser, integration, and end-to-end test configs and files
+- build, dev, preview, extension-build, and test commands
+- relevant CI workflows and ignore rules
+- `devflow/context/coding-standards.md`
+- Git branch and worktree state
+
+Do not assume Node.js, npm, a web server, or a blank test setup. Do not install
+dependencies or edit files during inspection.
+
+## Step 2 - choose the smallest useful harness
+
+Reuse a working browser runner already established by the project. For a
+compatible JavaScript or TypeScript web app or browser extension with no runner,
+prefer Playwright Test. If the stack or executable surface is unclear, stop and
+ask instead of inventing a framework.
+
+Choose one representative smoke path through a real project surface. It must
+prove the harness can launch the app and observe behavior, not merely assert that
+a static fixture exists. Keep authentication state, profiles, secrets, generated
+reports, traces, videos, and screenshots out of Git unless the project already
+has a deliberate safe convention.
+
+## Step 3 - present the setup
+
+Before editing, state:
+
+- runner selected or reused
+- exact dependency install command, when needed
+- config, script, test, and ignore files to add or change
+- application or extension surface covered by the smoke test
+- exact browser-test command that will be documented
+- any server, build, authentication, or browser-chrome limitation
+
+Dependency installation and browser-binary downloads require the user's approval
+through the current tool's normal approval flow. Do not treat running this skill
+as permission to change CI, download unrelated browsers, or add a broad suite.
+
+## Step 4 - create or normalize the harness
+
+Make the smallest practical diff:
+
+1. Add only the required runner dependency and config.
+2. Add one project-relevant smoke test.
+3. Add or reuse a conventional command such as `test:browser`.
+4. Document the exact invocation in the Commands section of `AGENTS.md` as
+   `Browser tests: <command>`. Include a working directory when a workspace
+   needs one.
+5. Configure runner-owned server lifecycle only when the project has a safe,
+   documented command and the runner can start and stop it reliably. Do not
+   create a duplicate server when the established harness reuses one.
+6. Ignore generated browser-test artifacts that should stay local.
+
+Do not add browser tests to the default Verify command or GitHub workflow unless
+the user separately asks for that slower gate or the project already requires
+it. Preserve existing CI and existing browser coverage.
+
+## Step 5 - verify the path
+
+Run the documented Browser tests command. Confirm that the smoke test exercises
+the intended real surface and that the runner exits cleanly. Inspect generated
+console, request, trace, screenshot, or report evidence only when relevant to
+the claim.
+
+## Step 6 - report
+
+Return a concise setup report:
+
+- runner and browser surface
+- command documented in `AGENTS.md`
+- smoke behavior proven
+- files added or changed
+- verification result
+- remaining manual or environment-specific boundary

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

@@ -87,32 +87,6 @@ When generating or logging test runs during `/implement` or `/check`:
 
 ---
 
-## 7. 5-Tier Test File Classification Strategy
-
-Do not write identical test patterns for all file types. Classify files into 5 distinct tiers:
-
-| Tier | Category / File Paths | Recommended Test Strategy | What NOT to do |
-| :--- | :--- | :--- | :--- |
-| 🧠 **Tier 1** | **Pure Logic & Algorithms**<br>`src/utils/`, `src/services/`, `lib/` | Fast in-memory Unit Tests with 100% boundary & edge cases coverage. Use TDD (Red-Green-Refactor). | Do not over-mock pure mathematical or transformation functions. |
-| 🎨 **Tier 2** | **UI Components**<br>`src/components/`, `src/pages/` | Component rendering, event dispatching, visual verification via Playwright / BrowserOS Neo. | **Prohibited**: Do not write trivial unit tests that merely assert static HTML tags exist. |
-| 🔌 **Tier 3** | **API & Data Integration**<br>`src/api/`, route handlers, DB models | Contract tests, schema validation (Zod), HTTP status codes, error payload shapes. | Do not test external third-party network APIs without isolated fakes. |
-| ⚙️ **Tier 4** | **Config & Build Tooling**<br>`*.json`, `*.yaml`, `scripts/` | Static contract validation (`npm run check:static`), budget linters (`npm run check:budgets`), smoke tests. | Do not skip static validation on build tool modifications. |
-| 📝 **Tier 5** | **Documentation & Prose**<br>`*.md`, `devflow/docs/` | Structural checks, markdown contract scans, and link integrity verification. | Do not write artificial unit test suites for documentation files. |
-
----
-
-## 8. Acceptance Criteria (`AC-N`) Traceability Protocol
-
-To guarantee 100% spec fidelity, every automated test suite must trace back to the active Living Spec:
-- **Test Title Tagging**: Prefix test titles or describe blocks with the target Acceptance Criterion:
-  ```typescript
-  it('AC-1: enforces 32KB byte budget on SKILL.md files', async () => { ... });
-  it('AC-2: returns exit code 1 when budget violation occurs', async () => { ... });
-  ```
-- **Traceability Verification**: During `/check`, cross-reference every `- [ ] AC-N` against the passing test assertion name to ensure zero untracked requirements.
-
----
-
 ## Relationship To DevFlow 2.6.x
 
 - **Classification**: Companion command & Engineering standard

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

@@ -300,10 +300,8 @@ expectations. Apply only the selected lens or lenses:
   - *Question Intent & Simpler Alternatives*: State what the change actually attempts in one sentence. Ask: is there a simpler, smaller, or more elegant way to achieve the same goal (reusing existing code, config vs code, solving at a different layer)?
   - *Full Call-Path Tracing*: Follow the call graph through real code paths (entry point → call sites → branches taken → state mutated → exit/side effect), including unchanged code on either side of the diff where bugs hide.
   - *Verify Claims & Edge Cases*: Does the traced path actually produce the claimed behavior? What inputs/states would break it (concurrency, retries, null/unicode/huge payloads, ordering)? What does it silently change?
-  - *Assumed Decision Debt Check*: Scan `devflow/decisions/` for any ADR with `Status: Assumed`. Flag unratified assumptions as `Q-xxx` (P2) to ensure ratification before production handoff.
   - *No Rubber-Stamping*: "LGTM" is prohibited. State what was traced, what was verified, and what evidence supports the verdict.
 
-
 Do not nitpick harmless style differences unless they signal drift from the local
 patterns. Prefer a short list of real findings over a broad list of guesses.
 
@@ -321,8 +319,7 @@ Maintain the durable record in `devflow/context/{xxx-slug}/findings.md` (or `dev
 3. Set severity honestly:
    - `P0`: critical blocking bug, data corruption, severe vulnerability, complete outage.
    - `P1`: serious defect, missing critical test, unhandled core error.
-   - `P2`: moderate debt, performance degradation, missing edge cases, or pure proportionality finding.
+   - `P2`: moderate debt, performance degradation, missing edge cases.
    - `P3`: minor improvement, code cleanup, cosmetic tweak.
-   *(For a proportionality finding, state in Suggested fix what can be deleted. An otherwise pure proportionality finding is P2 or P3. Raise to P0/P1 only when the unnecessary machinery causes a concrete reachable defect or violates an established security or data-integrity boundary.)*
 4. Set status: `open`, `fixed`, `closed`, `accepted`, or `invalid`.
 5. Display concise findings summary and next actions.

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

@@ -29,11 +29,10 @@ Use this when:
 - Identify technical, business, or timeline constraints.
 
 ### 2. Option Formulation (Divergent Phase)
-Provide at least 2-3 materially distinct approaches. Where applicable, map each option to its **Slicing Archetype** ([`devflow/reference/slicing-archetypes.md`](file:///d:/Projects/devtools/nexus-devflow/devflow/reference/slicing-archetypes.md)):
-- **Option A (Standard / Conservative)**: Low risk, proven pattern, minimal changes (e.g. *Skateboard* or *Tracer Bullet*).
-- **Option B (Modern / Optimized)**: Best-practice architecture, balanced trade-off, scalable (e.g. *Journey*).
-- **Option C (Alternative / Fast-Feedback)**: High innovation, simplified scope, or UX-first (e.g. *Facade*).
-
+Provide at least 2-3 materially distinct approaches:
+- **Option A (Standard / Conservative)**: Low risk, proven pattern, minimal changes.
+- **Option B (Modern / Optimized)**: Best-practice architecture, balanced trade-off, scalable.
+- **Option C (Alternative / Unconventional)**: High innovation, simplified scope, or creative alternative.
 
 ### 3. Trade-off Comparison Matrix
 Construct a structured evaluation table:

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

@@ -1,6 +1,6 @@
 ---
 name: bughunter
-description: "[devflow] Investigate security vulnerabilities with evidence. Use for /bughunter or an authorized security review of code or endpoints."
+description: "[devflow] Offensive security orchestrator & bug hunting guide. Indexes 83 vulnerability classes, 5-phase methodology (Think, Hunt, Perimeter, Ship), 681 disclosed HackerOne patterns, and JIT reference guides in devflow/.vendor/bughunter/. Use when running /bughunter, performing security reviews, verifying auth/injection risks in /check or /audit, or testing API endpoints for vulnerabilities."
 argument-hint: "[{target, vuln-class, or topic}]"
 ---
 

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

@@ -1,36 +1,126 @@
 ---
 name: check
-description: "[devflow] Check the running app, CLI, or server against the active spec's done-when criteria and capture observable pass or fail evidence without editing source. Use /check to verify real feature behavior, or /check guide [latest|scope] for a read-only manual walkthrough: how to test manually, where to click, expected and incorrect results, or a human review path."
-argument-hint: "[guide] [latest | <step> | <path> | <route>]"
+description: "[devflow] Check the running app, CLI, or server against the active spec's done-when criteria and capture observable pass or fail evidence without editing code. Use for /check, proving behavior before completion beyond builds and tests."
+argument-hint: "[{run-id, number, or name}]"
 ---
 
-# check - verify behavior or explain how to try it
+# check - Dual-Axis Independent Verification Engine
 
-**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.
+$ARGUMENTS
 
-## Select the mode before any tool call
+**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`.
 
-- `/check guide` or `$check guide`: generate a read-only manual walkthrough.
-  Pass remaining arguments such as `latest`, a step, a path, route, or command
-  to `reference/guide.md`. Read and follow that reference only. Do not write
-  activity state, run checks or the app, edit files, update spec status, or
-  produce verification receipts.
-- A natural-language request for instructions on how the user can manually test
-  or review a change also selects guide mode. If the request mixes a guide with
-  agent verification, clarify which mode to run first before any activity.
-- `/check` or `$check`, optionally with a verification scope: verify observed
-  behavior against the spec. Follow verification startup below, then read and
-  follow `reference/verify.md` only.
+Where this sits in the workflow:
 
-Load only the selected reference. Do not read both references preemptively.
-Guide generation never satisfies a verification gate. The existing
-`qualityGates.regular.tryGuide` and `qualityGates.continuous.tryGuide` keys now
-select `/check guide`; their policy values and automatic invocation rules are
-unchanged. The separate `check` gates continue to select verification mode.
+    /implement  ->  [check]  ->  /complete
+    (built a       (dual-axis       (only once both
+     step or        review with      axes pass with
+     the feature)   empirical proof) evidence)
 
-## Verification startup (verification mode only)
+`/implement` builds and does a quick build-plus-screenshot check inline. `/check` is the rigorous, repeatable gate for when a feature or step needs **empirical proof** on the running app and **two-axis code review** before merging.
 
-**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`, with command `check`. This precedes reading the
-verification reference. Guide mode must skip this startup entirely.
+It changes no source and commits nothing — it executes, inspects, and reports observed facts.
+
+---
+
+## Input
+
+- **Given an ID or name** (e.g. `/check 12`, `/check 012`) -> targets `devflow/context/{xxx-slug}/` and records audit ledger to `{xxx-slug}/findings.md`.
+- **With no argument** (`/check`) -> verifies the active run matching current git branch or single active spec.
+
+---
+
+## Hybrid Browser Verification Engine
+
+Nexus-DevFlow uses a **Dual-Layer Browser Verification Hierarchy**:
+
+```text
+┌─────────────────────────────────────────────────────────────────────────────┐
+│                    🌐 Hybrid Browser Verification Engine                    │
+├──────────────────────────────────────┬──────────────────────────────────────┤
+│ 1. Code-Driven Test Automation (CI)  │ 2. Interactive AI Visual QA (MCP)    │
+│    • Framework: Playwright           │    • Server: MCP browseros-neo       │
+│    • Command: npm run test:browser   │    • URL: http://127.0.0.1:9010/mcp  │
+│    • Purpose: Assertions, Headless,  │    • Purpose: Live DOM Inspection,   │
+│      Regression Suite & Pre-commit   │      Real Screenshot Proofs, /try    │
+└──────────────────────────────────────┴──────────────────────────────────────┘
+```
+
+1. **Layer 1: Code-Driven Repeatable Tests (Playwright)**:
+   - If `AGENTS.md` declares `Browser tests: <command>`, run that exact command as repeatable automated evidence.
+2. **Layer 2: Interactive AI Visual QA (MCP browseros-neo)**:
+   - When the `browseros-neo` MCP server (`http://127.0.0.1:9010/mcp`) is active, use it to inspect the live running app, verify rendered CSS/layout, test click flows, and capture actual screenshot proofs.
+
+---
+
+## Step 1 - Build the Dual-Axis Review Matrix
+
+Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/context/coding-standards.md`. Prepare the inspection criteria across two independent axes:
+
+1. **Axis 1 (Standards & Architecture Criteria)**:
+   - Coding conventions in `coding-standards.md`
+   - Deep Modules discipline (Small interface, deep implementation, clean seams, no leaky abstractions)
+   - Baseline 12 Fowler Code Smells (Primitive obsession, Feature envy, Shotgun surgery, Speculative generality, etc.)
+   - Multi-lane technical gates (Typecheck, test suites, zero secrets, zero P0/P1 findings)
+2. **Axis 2 (Spec Fidelity & Behavioral Observables)**:
+   - Line-by-line Acceptance Criteria (ACs) and "Done When" observables from `devflow/context/{xxx-slug}/spec.md`
+   - Scope Creep detection (Unrequested behavior in the diff)
+   - Missing Requirements detection (Unimplemented edge cases)
+
+---
+
+## Step 2 - Get the App Running & Exercise Live Proof
+
+Use the project's real commands (from `AGENTS.md`):
+
+- **Web app**: Start (or reuse) the local dev server. Drive a real browser to relevant routes. If `Browser tests: <command>` is declared, run it. When MCP `browseros-neo` is active, connect to inspect live visual state.
+- **CLI**: Execute commands with representative input fixtures, asserting exit codes and output snapshots.
+- **Server / API**: Hit endpoints with real payloads and assert on HTTP response status and bodies.
+- **Library**: Exercise public interfaces through integration tests or sample scripts.
+
+> [!IMPORTANT]
+> **Evidence or it didn't happen**: Every verdict must be backed by empirical evidence (screenshot, command output, status code, response time). Never assume a pass from reading source code alone.
+
+---
+
+## Step 3 - Dual-Axis Independent Report & State Update
+
+Format the report into two distinct, un-merged review axes:
+
+```markdown
+# 🔍 Verification Report: [Feature Name]
+
+## ⚖️ Axis 1: Standards, Architecture & Quality Gate
+
+- **Technical Lanes**:
+  - [pass] Type Safety: `tsc --noEmit` (0 errors)
+  - [pass] Automated Tests: `npm test` (All tests green)
+  - [pass] Browser Tests: `npm run test:browser` (Playwright passed)
+  - [pass] Visual Inspection: MCP browseros-neo verified UI layout & zero console errors
+  - [pass] Security & Hygiene: Zero secrets, sanitized inputs
+  - [pass] Findings Ledger: 0 blocking P0/P1 in `devflow/context/{xxx-slug}/findings.md`
+- **Deep Modules & Architecture**:
+  - [pass] Seam Integrity: Public interfaces remain small, implementation details hidden.
+  - [pass] The Deletion Test: Complexity is concentrated inside the module, not scattered across callers.
+- **Code Smells Assessment**:
+  - [clean] 12 Fowler Code Smells evaluated across git diff: No critical smells detected.
+
+## 🎯 Axis 2: Spec Fidelity & Behavioral Acceptance Gate
+
+Line-by-line verification against `devflow/context/{xxx-slug}/spec.md`:
+- [pass] **AC-1 (<title>)**: <Observed empirical evidence / screenshot path>
+- [pass] **AC-2 (<title>)**: <Observed empirical evidence / terminal output>
+- [fail] **AC-3 (<title>)**: <Exact observed failure with reproduction command>
+- [clean] **Scope Creep Check**: No unrequested features or unnecessary abstractions introduced.
+- [clean] **Completeness Check**: 100% of spec requirements addressed.
+
+---
+
+## 🚦 Final Routing & Verdict
+
+- **ALL PASSED**: Both axes green. Update `stage.md` (Passed -> Ready for `/complete`).
+- **ANY FAILURE**: Hand back to `/implement` with exact failure evidence and reproduction steps.
+- **UNVERIFIABLE**: Clearly document the gap and residual risk. Never fabricate a pass.
+```

package/template/.claude/skills/check/reference/guide.md

@@ -4,11 +4,10 @@
 
 Where this sits in the workflow:
 
-    /implement or /complete  ->  [check guide]  ->  human review
-    (work exists)                (manual           (where to go,
-                                  path)             what to click)
+    /implement or /complete  ->  [check guide / try]  ->  human review
+    (work exists)                (manual walkthrough)     (where to go, what to click)
 
-`/check` proves behavior from the agent side. `/check guide` gives the user a practical
+`/check` proves behavior from the agent side. `/check guide` (and its alias `/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.
 
@@ -18,16 +17,15 @@ produce verification receipts. Reading files and git status is allowed. A guide
 never counts as acceptance evidence or proof that any check passed.
 
 The quality-gate config controls when another workflow generates this guide
-automatically. An explicit `/check guide` or `$check guide` request always runs.
+automatically. An explicit `/check guide` or `/try` request always runs.
 A generated guide never counts as evidence that the user performed the walkthrough.
 
 ## Input
 
 Optional scope:
 
-- no argument: use the active task spec in `devflow/context/{xxx-slug}/spec.md`
-- `latest`: use the most recent archive under `devflow/history/features/`,
-  `devflow/history/fixes/`, or `devflow/history/rollbacks/`
+- no argument: use the active feature, fix, or rollback in `devflow/context/{xxx-slug}/spec.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 task step
 - a path, route, or command: include it as the main thing to try
 
@@ -40,19 +38,11 @@ Read:
 
 - `AGENTS.md`
 - `devflow/config.json`
-- `devflow/context/{xxx-slug}/spec.md`
+- `devflow/context/{xxx-slug}/spec.md` (or latest archive)
 - `devflow/context/project-overview.md`
 - `devflow/context/coding-standards.md`
 - `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
-
-For `latest`, use the most recent archive even when an active spec exists.
-Otherwise prefer the active spec. If the active spec is missing, use
-the most recent archived feature, fix, or rollback by filename or modification time and
-say that is what you used.
+- Git branch and working tree status
 
 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.
@@ -64,37 +54,25 @@ include one unaffected regression path from the rollback spec.
 Use the Commands section in `AGENTS.md`. Match the project type:
 
 - **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.
+- **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.
+- **Hybrid app** - list the smallest set of commands needed, such as backend plus web dev server.
 
 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.
 
 ## Step 3 - write the manual guide
 
-Produce a short guide with these sections:
+Produce a concise guide with these 5 sections (respond in Thai per project convention):
 
 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.
-
-Keep it concrete. Prefer:
-
-    Open http://127.0.0.1:7788/api/snapshot
-    Expect a JSON object with `generated_at`, `services`, `projects`, and
-    `conflicts`.
+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.
 
-Avoid:
-
-    Check that the snapshot works.
+Keep it concrete.
 
 ## Step 4 - include confidence and gaps
 
@@ -102,25 +80,11 @@ End 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.
+- **Gaps** - anything the guide cannot know from the docs, such as missing route names, seed data, credentials, or external services.
 
 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
-
-- Read-only only. Do not edit, commit, merge, push, install, or delete.
-- Do not run the app or verification commands in guide mode. If the user asks
-  you to try it for them, leave guide mode and explicitly route to `/check`
-  verification, following its activity and authorization rules.
-- 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`.
-
-## Formatting
+## Dual Compatibility with `/try`
 
-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.
+In Nexus-DevFlow, `/try` and `/check guide` serve the same user purpose and can be used interchangeably.

package/template/.claude/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/.claude/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/.claude/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/.claude/skills/discovery/SKILL.md

@@ -77,18 +77,10 @@ devflow/discoveries/{DISCOVERY_ID}-{slug}/discovery.md
    - Codebase-grounded interactive inquiry to clarify entity boundaries, data flows, and edge cases.
    - Record agreed terminology in `devflow/context/glossary.md` and major architecture decisions in `devflow/decisions/ADR-xxx-{slug}.md`.
 6. **🎨 Visual Architecture & Diagram Design Lens (`archify` / `diagram-design`)**:
-   - When exploring system topologies, legacy IT modernizations, sequence flows, data platform pipelines, state machines, or user journeys, check for `archify` or `diagram-design` in `.claude/skills/`.
-   - **For interactive system architecture, dataflows, state transitions, and sequence traces**: Use `archify` (`.claude/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` (`.claude/skills/diagram-design/SKILL.md`).
+   - When exploring system topologies, legacy IT modernizations, sequence flows, data platform pipelines, state machines, or user journeys, check for `archify` or `diagram-design` in `.agents/skills/`.
+   - **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: