@jakkrichm/create-nexus-devflow 2.1.0 → 2.2.0

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

@@ -1,99 +1,100 @@
 ---
 name: brief
-description: "[Devflow] Deep read-only scope, codebase impact, dependency, and sub-feature split briefing before speccing a run (reads build-plan.md or ideas.md)."
-argument-hint: "[feature-number | 'feature-name' | IDEA-xxx]"
+description: "[devflow][B] Read-only briefing on an upcoming build-plan feature before you spec it. With no argument, briefs the next unchecked item; given a number or name, briefs that one. Reads build-plan.md and project-overview.md and explains what the feature is, what it depends on, what it will touch, how big it is, and whether it will split - without writing anything. Use when the user runs /brief, asks what the next feature involves, wants to understand or preview a feature before /feature, or is deciding what to build or reorder next."
 ---
 
-# brief - Deep Scope, Dependency & Codebase Impact Briefing
+# brief - understand a feature before you spec it
 
 Where this sits in the workflow:
 
-```text
-devflow/build-plan.md (or ideas.md)  ──▶  [brief]  ──▶  feature / 20-spec  ──▶  implement / 40-execute
-(feature queue & context)                 (deep read-only  (write spec)          (build it)
-                                           explainer)
-```
-
-This skill answers one essential question: ***"What does this upcoming feature actually touch and involve in the real codebase before I commit to writing a full specification?"***
-
-It inspects `devflow/build-plan.md` (or `devflow/ideas.md` / `project-overview.md`) and conducts a **Deep Static Codebase Analysis** to provide a concise briefing — calculating files touched, dependency chains, estimated size (`XS`..`XL`), and actionable sub-feature split proposals before any work begins.
-
-It is **strictly read-only 100%**. It never writes specs, creates directories, branches, or commits code.
-
----
-
-## Usage & Invocations
-
-```text
-brief                     # Briefs the next unchecked feature in build-plan.md
-brief 2                   # Briefs feature #2 in build-plan.md
-brief "OAuth Login"       # Briefs a specific feature by name
-brief IDEA-003            # Briefs a pending idea from ideas.md
-```
-
-If there is no build plan or pending idea, plainly report that context is needed and recommend `/discovery` or `/overview`.
-
----
-
-## 3-Step Briefing Protocol
-
-### Step 1 - Read Context & Target Resolution (Read-Only)
-
-1. **Target Item Resolution**:
-   - If argument provided (`2`, `"OAuth Login"`, `IDEA-003`): find matching item in `devflow/build-plan.md` or `devflow/ideas.md`.
-   - If no argument: locate the first unchecked item (`- [ ]`) in `devflow/build-plan.md`. If build plan is empty, locate the first pending item in `devflow/ideas.md`.
-2. **Project Architecture**: Read `devflow/context/project-overview.md` and `devflow/context/coding-standards.md`.
-3. **Deep Codebase Inspection**:
-   - Inspect existing directory structures, routing files, data models/schemas, database migrations, API handlers, and UI component trees.
-   - Trace existing modules related to the target feature.
-
----
-
-### Step 2 - Analyze Scope, Dependencies & Sizing
-
-Evaluate with concrete facts:
-
-1. **What It Is**: Core capability and user-visible or system-visible outcome.
-2. **Dependencies & Prerequisites**: Upstream database models, authentication layers, environment variables, or sibling features that must be complete first.
-3. **Unblocks**: Downstream features or workflows enabled once this item ships.
-4. **Files & Modules Touched**: List predicted files and folders likely to be created or modified (e.g. `lib/`, `routes/`, `components/`, `test/`).
-5. **Estimated Size**:
-   - `XS`: Small tweak / config (~15-30 mins, 1-2 files)
-   - `S`: Single component or route (~1-2 hours, 2-4 files)
-   - `M`: Full CRUD feature or service integration (~half day, 4-7 files)
-   - `L`: Complex multi-component subsystem (~1 day, 7-12 files)
-   - `XL`: Major epic (>12 files or heavy cross-cutting concerns)
-6. **Sub-Feature Split Engine (for L and XL)**:
-   - If the feature is `L` or `XL`, draft a concrete 2-3 sub-feature breakdown (e.g. `4a: Backend Schema & Core APIs`, `4b: Frontend UI & Client State`) with individual sizing and sequential dependencies.
-7. **Key Risks & Open Questions**: Unsettled API contracts, performance bottlenecks, migration risks, or design decisions.
-
----
-
-### Step 3 - Output Structured Briefing Card
-
-Produce a clean, scannable briefing directly in the chat in **Thai (`th`)**:
-
-```markdown
-### 📋 Feature Briefing: [หมายเลขหรือรหัส - ชื่อฟีเจอร์]
-
-- **🎯 What**: [สรุปเป้าหมายและความสามารถหลักสั้นๆ]
-- **🔗 Dependencies**: [ฟีเจอร์หรือโมดูลก่อนหน้าที่ต้องมี หรือ 'None']
-- **🔓 Unlocks**: [ฟีเจอร์ถัดไปในแผนงานที่จะถูกปลดล็อก]
-- **📁 Files Touched**: [รายชื่อไฟล์และโมดูลที่คาดว่าจะต้องแก้ไขหรือสร้างใหม่]
-- **⚖️ Estimated Scope & Size**: `[XS | S | M | L | XL]`
-- **✂️ Sub-Feature Split Proposal** *(กรณีขนาด L หรือ XL)*:
-  - `[ID]a: [ขอบเขตย่อยส่วนที่ 1]` (Size: M, Dependencies: None)
-  - `[ID]b: [ขอบเขตย่อยส่วนที่ 2]` (Size: M, Dependencies: [ID]a)
-- **⚠️ Key Risks & Open Questions**: [ความเสี่ยงทางเทคนิคหรือคำถามที่ต้องตอบใน Spec]
-
----
-👉 **Next Recommended Action**: `/feature {target}` (หรือเริ่มทำ sub-feature แรก เช่น `/feature 4a`)
-```
-
----
-
-## Strict Rules & Guardrails
-
-1. **Always Read-Only**: Never edit workspace files, allocate running IDs, switch branches, or commit code during `/brief`.
-2. **Explain, Don't Spec**: Focus on scope, architectural dependencies, and size estimation. The formal delivery contract belongs to `/feature` or `20-spec`.
-3. **Ground In Reality**: Trace all assertions back to `project-overview.md` and active codebase inspection. Do not hallucinate non-existent files or packages.
+    build-plan + overview  ->  [brief]  ->  /feature  ->  /implement
+    (what exists)              (read-only    (spec it)     (build it)
+                                explainer)
+
+This skill answers one question: *what does this feature actually involve, before
+I commit to spec'ing it?* It reads the two files that describe the work and prints
+a short briefing so you can decide whether to spec it now, reorder it, split it,
+or clear a blocker first. It is the read-only precursor to `/feature`.
+
+It never writes anything: no spec, no edits to `build-plan.md`, no branch, no
+commit. `/feature` is the mutating step that turns a briefing into a spec; this
+one just explains.
+
+How it differs from its neighbors:
+
+- `/status` reports the *whole project*: progress, current work, git, next action.
+  `/brief` zooms into *one feature* and explains it in depth.
+- `/feature` *writes* the spec (and may split the item in `build-plan.md`).
+  `/brief` previews what `/feature` would tackle, changing nothing.
+
+## Input
+
+A feature from `build-plan.md`, by number or name - e.g. `/brief 4` or
+`/brief "validator"`.
+
+**With no argument, brief the next one** - the first unchecked leaf in
+`build-plan.md`, the same target `/feature` would pick.
+
+If `build-plan.md` is still a placeholder stub or the overview is missing, say so
+plainly and point at `/overview` (or filling the plans) rather than inventing a
+briefing.
+
+## What it reads
+
+Gather these, then synthesize. Don't dump file contents; explain.
+
+1. **The target** - the feature's line in `devflow/build-plan.md`, plus whether
+   a parent was already split into sub-items (`4a`, `4b`, ...).
+2. **Full context** - `devflow/context/project-overview.md`: the data model,
+   routes/endpoints, stack, UI/UX, conventions, and open questions that touch this
+   feature.
+3. **What already exists** - earlier checked build-plan items and, if useful, git
+   history, to ground the dependency read (what must be in place first, what this
+   unblocks later).
+4. **Design reference** - if `prototypes/` exists and the feature is UI-facing,
+   note which mockups apply (that `/feature` will link them and port `theme.css`).
+
+## Output
+
+A short, scannable briefing, not a wall of text. Aim for something like:
+
+    Feature 5 - Submission draft flow
+    What: maintainers submit a skill by GitHub URL (primary) or zip (fallback);
+      drafts are saved before validation runs.
+    Depends on: apps/api must be stood up first (this is the first feature that
+      needs the backend); builds on the Skill / SkillVersion shapes from feature 3.
+    Unblocks: queue-backed validation (6) and the publishable flow (7).
+    Touches: new User, Submission, SkillVersion tables (Drizzle); GitHub OAuth;
+      POST /submissions; R2 snapshot upload; a React upload island (client).
+    Size: large - likely splits into 5a (OAuth + maintainer profile), 5b
+      (GitHub-URL submission + draft record), 5c (zip upload + R2).
+    Reference: no prototype for this flow; upload.html covers the later validation
+      panel, not this form.
+    Open questions: apps/api (Hono) is not scaffolded yet - resolve before spec'ing.
+
+    Next: run /feature 5 to spec 5a, or clear the apps/api blocker first.
+
+Adapt the lines to the feature; drop any that don't apply. Always end with a
+single **Next** action - usually `/feature N` to spec it, but `/overview` if the
+plans aren't ready, `/prototype` if it's UI-facing and the look isn't locked, or
+"clear X first" when a dependency blocks it.
+
+## Rules
+
+- **Read-only, always.** Never write a file, never edit `build-plan.md` or
+  `current-feature.md`, never branch, commit, install, or build. To act on the
+  briefing, the user runs `/feature` next.
+- **Explain, don't spec.** Size, dependencies, and a likely sub-split are the
+  value here; the actual build steps are `/feature`'s job. Don't write step lists.
+- **Trace to the plans.** Everything in the briefing comes from `build-plan.md`
+  and `project-overview.md`. Don't invent scope; if something is underspecified,
+  say so and flag it as a question for `/feature` or `/overview`.
+- **Be honest about gaps.** If the plans are a stub, the overview is stale, or a
+  dependency isn't built yet, say that plainly - catching a blocker before
+  spec'ing is half the value.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -1,80 +1,100 @@
 ---
 name: check
-description: "[Devflow] Fast-Track Check stage in DevFlow (Blueprint Mode) - perform senior QA review, run multi-lane verification, and record evidence in current-feature.md in context."
-argument-hint: "{running-id or workspace path}"
+description: "[devflow][F] Prove the current work actually does what its spec says by running the real app and observing behavior against the \"done when\" criteria in current-feature.md. Drives the app (browser, CLI, or server), captures evidence (screenshots, output, console/network errors), and reports pass/fail per criterion. Does not edit source or commit - it observes; fixing stays /implement's job. Use when the user runs /check, asks to confirm a step or feature works, wants proof before /complete, or wants to check a change in the running app rather than just the build. (Supersedes the built-in /verify with a spec-aware version inside blueprint projects.)"
 ---
 
-# Fast-Track: Check (Blueprint Mode)
-
-$ARGUMENTS
-
-Quality assurance and multi-lane verification stage in Fast-Track. Validates implementation against Acceptance Criteria, executes Scrutinize QA & Security checks, runs test suites, checks for regressions, and records evidence in the Single Living Spec (`devflow/context/current-feature.md`).
-
-## Invocations & Aliases
-
-- `/check`: Run verification on current active run
-- `/check {id}`: Run verification on specified ID
-- `$check`: Codex CLI invocation
-
-## Fast-Track Mainline Workflow
-
-```text
-/feature (หรือ /fix) ──▶ /implement ──▶ /check ──▶ /complete
-```
-
-## Behavior & Contract
-
-When invoked:
-
-### 1. Load Active Context
-1. Identify active Running ID from `devflow/context/current-stage.md` or `devflow/context/current-feature.md`.
-2. Read `devflow/context/current-feature.md`.
-3. Locate `## 1. Specification & Scope` (Acceptance Criteria) and `## 3. Implementation Checklist`.
-
-### 2. Multi-lane Verification & Scrutinize QA
-
-Execute verification gates across all lanes:
-
-1. **Lane 1: Typecheck & Static Code Quality**:
-   - Run typecheck and linting (e.g. `npm run typecheck`, `npm run lint`).
-   - Confirm 0 type errors, 0 lint warnings.
-2. **Lane 2: Automated Test Suites (TDD Gate)**:
-   - Run automated unit and integration tests (e.g. `npm test`).
-   - Confirm 100% tests pass with no disabled/skipped tests.
-3. **Lane 3: Scrutinize & Edge Cases Review**:
-   - **Boundary Conditions**: Check empty collections, 0/1 limits, off-by-one errors.
-   - **Null / Undefined Safety**: Verify optional chaining and nullish coalescing.
-   - **Error Handling & Propagation**: Verify errors are logged and handled without swallow.
-4. **Lane 4: Security & Hygiene Audit**:
-   - **Secrets Check**: No hardcoded API keys, passwords, or tokens in source code.
-   - **Injection & Sanitization**: Ensure inputs are validated and parameterized.
-5. **Lane 5: Manual Scenario Proof**:
-   - Verify specific scenarios against Acceptance Criteria (`AC-1`, `AC-2`).
-   - Provide concrete walkthrough: "Where to go", "What to run/click", "What to expect".
-
-### 3. Update Living Spec (`current-feature.md`)
-Append or update `## 5. Verification Evidence` in `devflow/context/current-feature.md` in **Thai (`th`)**:
-
-```markdown
-## 5. Verification Evidence
-- **Typecheck & Linter**: Passed (0 errors, 0 warnings)
-- **Automated Test Suites**: All tests passed (e.g. 12/12 passed, 0 failed)
-- **Scrutinize & Security Audit**: Clean (No boundary issues, 0 secrets, safe inputs)
-- **Acceptance Criteria Verification**:
-  - [x] AC-1: {ผลการตรวจสอบเงื่อนไขที่ 1 ผ่าน 100%}
-  - [x] AC-2: {ผลการตรวจสอบเงื่อนไขที่ 2 ผ่าน 100%}
-- **Manual Verification Guide**:
-  - *Where to go*: `http://localhost:3000/api/auth`
-  - *Action*: Send POST request with test credentials
-  - *Expected Result*: Received HTTP 200 with valid JWT token
-```
-
-### 4. Update Workspace Status
-Update `devflow/context/current-stage.md`:
-- `Current Stage`: `check (Fast-Track -> Verification Passed -> Ready for /complete)`
-
-### 5. Output Summary & Next Step
-Report to the user:
-- Summary of verification results across all lanes
-- Evidence recorded in `devflow/context/current-feature.md`
-- **Next Command**: `/complete` (or `/complete {ID}`)
+# check - prove it works against the spec, with evidence
+
+Where this sits in the workflow:
+
+    /implement  ->  [check]  ->  /complete
+    (built a       (run the app,    (only once the
+     step or        prove each       done-whens are
+     the feature)   done-when)       proven)
+
+`/implement` builds and does a quick build-plus-screenshot check inline. `/check`
+is the deeper, repeatable gate for when a "done when" needs the *real running app*,
+not just a green build: a click that triggers a download, a route that returns a
+file, a flow across screens. Run it on a single step whose done-when is
+behavioral, or on the whole feature as the acceptance check before `/complete`.
+
+The point is evidence. A passing build proves the code compiles; `/check` proves
+the thing the spec promised actually happens. It changes no source and commits
+nothing - it runs the app and reports what it saw.
+
+## Input
+
+Optional: a specific thing to check (a step, a flow, a URL). With no argument,
+verify the whole current feature against every "done when" in
+`devflow/context/current-feature.md`.
+
+## Step 1 - build the checklist
+
+Read `devflow/context/current-feature.md`. Pull the observable "done when"
+criteria from the build steps (and any acceptance notes in the Testing section).
+Turn them into a concrete checklist of claims to prove - each one a specific,
+observable behavior, not "it works". If the user named one thing, scope to that.
+
+If there's no current feature spec, ask what to verify rather than guessing.
+
+## Step 2 - get the app running
+
+Use the project's real commands (see Commands in `AGENTS.md`). Match the project
+type:
+
+- **Web app** - start (or reuse) the dev/preview server, then drive a real browser
+  to the relevant routes. Prefer reusing an already-running server over starting a
+  duplicate. If Playwright is already installed or declared in `AGENTS.md`, prefer
+  it for browser driving, screenshots, console errors, and failed request checks.
+  If it is not installed, do not add it from `/check`; use another real-browser
+  evidence path and report what you used.
+- **CLI** - run the actual command(s) with representative inputs.
+- **Server/API** - start it and hit the endpoints.
+- **Library** - exercise the public API through an example or the test command.
+
+If a `test` command is declared in `AGENTS.md`, you may run it as *one* input, but
+`/check` is broader than unit tests: it checks real behavior, which is exactly the
+evidence UI and integration steps ride on instead of unit tests.
+
+## Step 3 - exercise each claim
+
+Drive the app to each checklist item and capture evidence as you go:
+
+- Navigate and interact for real (click, type, submit, download) - don't assert
+  from the code what the running app would do.
+- Capture **screenshots** for visual/UI claims, **output** for CLI/API claims.
+- Watch for **console errors and failed network requests**; a clean-looking screen
+  with errors in the console is not a pass.
+
+## Step 4 - report
+
+Give a short, honest verdict, one line per checklist item:
+
+    [pass] Download PDF saves certificate-<slug>.pdf - file downloaded, opened to the cert
+    [pass] Both buttons show a loading state - screenshot: loading-state.png
+    [fail] PDF border missing - printBackground not set; screenshot: pdf-no-border.png
+    [skip] Vercel render - can't verify locally (feature 9)
+
+Then state the bottom line: are all the feature's done-whens proven, or not yet.
+
+- All proven -> say it's ready for `/complete`.
+- Anything failed -> hand back to `/implement` to fix; name what to fix. Don't fix
+  it here.
+- Anything unverifiable -> say so plainly and why; never report it as a pass.
+
+## Rules
+
+- **Observe, don't change.** `/check` runs the app and reports. It never edits
+  source, never commits, never merges. Fixing is `/implement`'s job.
+- **Evidence or it didn't happen.** Every `pass` is backed by something observed -
+  a screenshot, output, a response. No assumed passes from reading the code.
+- **Honest over green.** "Couldn't verify" and "failed" are valid, useful results.
+  Faking a pass defeats the entire gate.
+- **Check the spec, not vibes.** Verify against the done-whens in
+  `current-feature.md`, so "works" means what the spec said it would do.
+
+## Formatting
+
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -1,78 +1,157 @@
 ---
 name: ci
-description: "[Devflow] Set up automated GitHub Actions CI workflow (.github/workflows/verify.yml) aligned with project verify command."
+description: "[devflow][B] Set up or normalize automatic GitHub checks for a Blueprint project around one documented Verify command. Detects the real stack, package manager, existing checks, default branch, and workflows; preserves existing CI; combines only configured typecheck, test, and build commands; runs the command locally; and stops before push or remote ruleset changes. Use when the user runs /ci, invokes $ci, asks to add CI, set up GitHub Actions, add pull-request checks, or create automatic GitHub checks."
 ---
 
-# CI/CD Pipeline Automation & Quality Gates
+# ci - set up automatic GitHub checks
 
-## Overview
+Where this sits in the workflow:
 
-This is the CI/CD and automation master skill for Nexus-DevFlow. It automates quality gates so that no change reaches production without passing static analysis, typechecking, tests, security audits, and builds.
+    /onboard or /adopt  ->  [ci]  ->  Verify locally  ->  GitHub runs Verify
+    (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 the Blueprint.
+
+Keep the beginner explanation simple:
+
+- **Verify is the recipe.** It runs checks the project already has.
+- **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.
+
+This skill configures the recipe and worker. It never changes the remote ruleset,
+pushes, publishes, deploys, or adds local git hooks.
+
+## Input
+
+No argument is required. A named provider or workflow preference is a request to
+review, not permission to replace existing CI. This skill's default provider is
+GitHub Actions because it creates GitHub pull-request checks.
+
+## Step 1 - inspect without changing files
+
+Read enough to identify the real project setup:
+
+- `AGENTS.md`, especially Commands and any documented `Verify` command
+- package or language manifests and task-runner files
+- lockfiles and the package manager they imply
+- existing typecheck, test, build, lint, and other quality commands
+- test configuration and actual test files
+- runtime version files such as `.nvmrc`, `.node-version`, `.python-version`,
+  `go.mod`, or `rust-toolchain.toml`
+- `.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 Blueprint template. Do not
+run installs or edit files during inspection.
+
+If an existing workflow already provides equivalent pull-request checks, explain
+what it runs. If it is healthy and aligned with a documented Verify command,
+report that no setup is needed. If normalization would change existing CI, show
+the proposed change and get explicit approval before editing it.
+
+## Step 2 - define one Verify command
+
+Build one command from meaningful checks that actually exist, in this order:
+
+1. typecheck
+2. tests, only when a runner and real test command are configured
+3. build
+
+Omit missing checks. Do not install a test runner, invent an empty test suite, or
+add a placeholder command. Lint, formatting, coverage, browser tests, security
+scans, dependency audits, and version matrices are not part of the beginner
+default. Preserve them when existing CI already requires them, and discuss any
+normalization before changing that behavior.
+
+For JavaScript and TypeScript, add or reuse a package script named `verify` and
+invoke it with the detected package manager. For other stacks, use the existing
+native task runner or the smallest clear combined command. Document the exact
+invocation as `Verify` in the Commands section of `AGENTS.md`.
+
+Examples are explanatory only. Never copy them without detecting the project:
 
 ```text
-PR / Push ➔ Lint & Typecheck ➔ Unit & Integration Tests ➔ Build Verification ➔ Security Audit
+Verify: npm run verify
+Verify: make verify
+Verify: cargo test && cargo build --locked
 ```
 
----
+If no meaningful check exists, stop and explain what is missing. Do not create a
+workflow that always passes.
 
-## 1. Shift-Left Quality Gate Pipeline
+## Step 3 - create or align the workflow
 
-1. **Static Analysis & Typecheck**: `tsc --noEmit`, `eslint`, `biome` (Catches syntax & type flaws in seconds).
-2. **Automated Tests**: Unit & Integration tests (`npm test`, `pytest`, `go test`).
-3. **Build Integrity**: `npm run build` (Ensures bundle compiles cleanly without warnings).
-4. **Security Hygiene**: `npm audit --audit-level=high` (Flags vulnerable dependencies).
+Create `.github/workflows/verify.yml` only when that path is free. If it already
+exists, never overwrite it silently. Show the exact proposed diff and ask before
+changing it.
 
----
+The workflow should contain only what the detected project needs:
 
-## 2. GitHub Actions Setup (`.github/workflows/verify.yml`)
-
-When setting up or updating CI:
-- **Trigger**: Pull requests and pushes to `main` / `master`.
-- **Permissions**: Enforce least privilege (`permissions: contents: read`).
-- **Concurrency**: Cancel stale in-progress runs on the same PR.
-- **Deterministic Install**: Use `npm ci` or `--frozen-lockfile`.
-
-```yaml
-name: Verify
-
-on:
-  push:
-    branches: [main, master]
-  pull_request:
-    branches: [main, master]
-
-concurrency:
-  group: ${{ github.workflow }}-${{ github.ref }}
-  cancel-in-progress: true
-
-permissions:
-  contents: read
-
-jobs:
-  verify:
-    name: Run Verification Checks
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout Code
-        uses: actions/checkout@v4
-
-      - name: Setup Node
-        uses: actions/setup-node@v4
-        with:
-          node-version: 20
-          cache: npm
-
-      - name: Install Dependencies
-        run: npm ci
-
-      - name: Run Verify Checks
-        run: npm run check
-```
+- a clear workflow name such as `Verify`
+- `pull_request`
+- pushes to the detected default branch
+- `permissions: contents: read`
+- the real runtime version
+- checkout and the appropriate runtime setup action
+- the lockfile-safe dependency install command
+- one final step that runs the exact `Verify` command from `AGENTS.md`
 
----
+If the default branch cannot be identified from git or project context, ask
+before writing the push trigger instead of guessing. Preserve all other workflow
+files. When another workflow overlaps, report the overlap and ask whether to
+reuse, align, or leave it alone.
+
+## Step 4 - prove the setup locally
+
+Run the exact documented `Verify` command locally. The individual build, test,
+or typecheck commands may still be run separately for diagnosis, but the final
+proof must use Verify because that is what GitHub will run.
+
+If Verify fails, report the failing subcommand and stop. Do not weaken the
+command, remove a legitimate check, or describe CI as ready.
+
+Do not push the workflow. A local workflow file does nothing on GitHub until the
+user later approves a push.
+
+## Step 5 - report
+
+Finish with a concise setup report:
+
+- existing CI found and whether it was preserved or changed
+- exact `Verify` command
+- checks included and checks omitted
+- test gate status
+- workflow path and triggers
+- local Verify result
+- files changed
+- any overlap, uncertainty, or follow-up
+
+Explain that making the GitHub check required is a separate remote ruleset choice
+after the workflow is pushed. Do not change repository settings or treat that as
+part of this skill.
+
+## Interaction with other skills
+
+- `/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.
+- `/doctor` diagnoses drift between `AGENTS.md`, the project command, and the
+  workflow. Missing CI remains informational.
+
+## Rules
+
+- Preserve existing CI and custom checks.
+- Never invent tests or install a runner as part of CI setup.
+- 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.
 
-## Relationship To DevFlow 2.0
+## Formatting
 
-- **Classification**: Companion command & Automated testing infrastructure
-- **Mainline integration**: Invoked via `/ci` during `onboard` or `adopt`.
-- **Handoff**: `50-verify`, `70-deliver`
+Format the output to match the project's conventions in
+`devflow/context/ai-interaction.md`: concise, scannable markdown, with lists for
+enumerations and tables for matrices rather than dense paragraphs.