@jakkrichm/create-nexus-devflow 2.9.4 → 2.10.0

package/template/.agents/skills/browser-tests/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: browser-tests
+description: "[devflow] Add or normalize an optional repository-owned browser test harness (preferring Playwright) and connect with MCP browserOS neo (http://127.0.0.1:9010/mcp) when available for live visual inspection and repeatable E2E automation."
+argument-hint: "[{runner or surface}]"
+---
+
+# browser-tests - set up repeatable browser verification
+
+$ARGUMENTS
+
+**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`.
+
+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.
+
+---
+
+## Hybrid Browser Verification Architecture
+
+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)**:
+   - Sets up `@playwright/test` for headless, deterministic assertions.
+   - Documents command in `AGENTS.md` as `Browser tests: npm run test:browser` (or equivalent).
+   - Executed automatically during `/check` and Continuous mode.
+
+2. **Layer 2: Live Interactive QA (MCP browseros-neo)**:
+   - When the `browseros-neo` MCP server (`http://127.0.0.1:9010/mcp`) is active in IDE config (`mcp_config.json`), the AI Agent connects to it for live interactive inspection.
+   - Used during `/check` and `/try` to capture visual evidence, inspect rendered styles, and verify complex user interactions directly in a live browser.
+
+---
+
+## Input
+
+No argument is required. 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 (`@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.
+
+For browser extensions, use a persistent test browser context and load the built
+unpacked extension. Test an extension-owned page or content-script flow that the
+runner can reach. Browser toolbar UI, permission prompts, and other browser
+chrome may still require Check or Try evidence; do not claim those surfaces are
+automated when they are not.
+
+## 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
+- MCP `browseros-neo` availability for interactive checks
+
+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 (e.g. `playwright.config.ts`).
+2. Add one project-relevant smoke test (e.g. `e2e/smoke.spec.ts`).
+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 (e.g. `test-results/`, `playwright-report/`).
+
+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.
+
+A passing runner with no tests, a test against the wrong surface, or a skipped
+browser launch is not a successful setup. If credentials, an external service,
+browser chrome, or another unavailable dependency blocks the smoke path, report
+the harness as incomplete instead of weakening the test.
+
+## Step 6 - report
+
+Return a concise setup report:
+
+- runner and browser surface
+- command documented in `AGENTS.md`
+- smoke behavior proven
+- MCP `browseros-neo` connectivity status
+- files added or changed
+- verification result
+- remaining manual or environment-specific boundary
+
+Show the diff summary. Do not commit, merge, push, publish, or begin unrelated
+feature work.
+
+---
+
+## Integration contract
+
+Once `AGENTS.md` declares `Browser tests: <command>`:
+
+- **Feature** may include a focused browser-test expectation for stable behavioral done-whens.
+- **Implement** may add and run a focused browser test when it is proportionate to the current step.
+- **Check** runs the documented command as repeatable evidence, connects to MCP `browseros-neo` (if active) for live visual verification & screenshots, and directly observes any done-when the suite does not prove.
+- **Continuous** needs no separate browser mode. Its configured Check gate uses the same command.
+
+The harness supplements direct evidence. A green browser suite does not prove
+visual fidelity, authenticated real-profile behavior, browser chrome, or every
+done-when unless the test actually observes those claims.

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

@@ -1,11 +1,13 @@
 ---
 name: check
-description: "[devflow] Prove the current work actually does what its spec says and adheres to architectural standards through a Dual-Axis Independent Review. Supports Multi-Run: given an optional ID or name (/check 12), targets that spec and records proof to devflow/context/{xxx-slug}/findings.md. Drives the app, captures empirical evidence, checks Fowler smells, and reports pass/fail. Use when running /check, confirming work, or validating before /complete."
+description: "[devflow] Prove the current work actually does what its spec says and adheres to architectural standards through a Dual-Axis Independent Review. Supports Multi-Run: given an optional ID or name (/check 12), targets that spec and records proof to devflow/context/{xxx-slug}/findings.md. Drives the app, captures empirical evidence using Playwright and MCP browseros-neo, checks Fowler smells, and reports pass/fail. Use when running /check, confirming work, or validating before /complete."
 argument-hint: "[{run-id, number, or name}]"
 ---
 
 # check - Dual-Axis Independent Verification Engine
 
+$ARGUMENTS
+
 **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`.
@@ -30,6 +32,29 @@ It changes no source and commits nothing — it executes, inspects, and reports
 
 ---
 
+## 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:
@@ -50,7 +75,7 @@ Read the target spec from `devflow/context/{xxx-slug}/spec.md` and `devflow/cont
 
 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. Prefer Playwright when installed for screenshots, network errors, and console assertions.
+- **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.
@@ -60,7 +85,7 @@ Use the project's real commands (from `AGENTS.md`):
 
 ---
 
-## Step 3 - Dual-Axis Independent Report
+## Step 3 - Dual-Axis Independent Report & State Update
 
 Format the report into two distinct, un-merged review axes:
 
@@ -72,6 +97,8 @@ Format the report into two distinct, un-merged review axes:
 - **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**:
@@ -93,25 +120,7 @@ Line-by-line verification against `devflow/context/{xxx-slug}/spec.md`:
 
 ## 🚦 Final Routing & Verdict
 
-- **ALL PASSED**: Both axes green. Ready for `/complete`.
+- **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.
-```
-
----
-
-## Why Two Independent Axes?
-
-A code change can pass one axis and fail the other:
-- **Standards Pass, Spec Fail**: Code is beautifully architected and tested, but implements the wrong business behavior.
-- **Spec Pass, Standards Fail**: Feature works end-to-end, but violates encapsulation, introduces shallow modules, or leaks secrets.
-
-Reporting both axes side-by-side stops elegance from masking functional bugs, and stops functional completeness from excusing architectural rot.
-
----
-
-## Rules
-
-- **Observe, don't change**: `/check` runs the app and reports. It never edits source or commits. Fixing is `/implement`'s job.
-- **Honest over green**: "Failed" and "Could not verify" are valid, valuable outputs. Faking a pass destroys the gate.
-- **Check the spec, not vibes**: Verify against documented ACs, not subjective feelings.
+```

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

@@ -1,11 +1,13 @@
 ---
 name: complete
-description: "[devflow] Wrap up a finished feature, fix, or rollback. Supports Multi-Run: given an optional ID (/complete 12), archives that run from devflow/context/{xxx-slug}/ to devflow/history/, cleans up the run workspace, updates build-plan and HISTORY.md, and makes the work commit. Enforces mandatory user gate (Squash-merge vs MR/PR)."
+description: "[devflow] Wrap up a finished feature, fix, or rollback. Supports Multi-Run: given an optional ID (/complete 12), archives that run from devflow/context/{xxx-slug}/ to devflow/history/, verifies independent review receipt and findings ledger, cleans up the run workspace, updates build-plan and HISTORY.md, and makes the work commit. Enforces mandatory user gate (Squash-merge vs MR/PR)."
 argument-hint: "[{run-id, number, or name}]"
 ---
 
 # complete - log the finished work, make the work commit, and deliver
 
+$ARGUMENTS
+
 **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`.
@@ -28,6 +30,9 @@ passes.
 
 ## Before you start
 
+Read `devflow/config.json`. A missing file means the built-in defaults apply.
+If the file exists but is invalid, stop and point the user to `/doctor`.
+
 Confirm the target work is actually finished: `devflow/context/{xxx-slug}/spec.md`
 holds a real spec, its steps are built on a branch, and `Verify`, or the fallback
 build and tests, passes. If any of the
@@ -36,6 +41,19 @@ running app first - don't merge or complete on an unverified claim. Uncommitted
 expected (per-step checkpoints are optional); this skill commits it. Don't require
 the steps to be pre-committed.
 
+Read `devflow/context/{xxx-slug}/review.md` (or `devflow/context/review.md`) when present. A pending,
+changes-requested, malformed, or stale record is always a blocker because the
+user already initiated that gate, even when its configured policy is `manual`.
+
+## Configured regular quality gates
+
+Use `qualityGates.regular` for this work item:
+
+- **Audit:** `manual` runs only when the user explicitly requests `/audit`; `when-sensitive` runs for sensitive categories; `always` runs for every work item.
+- **Independent review:** `manual` runs only when explicitly requested (`/audit independent current`); `when-sensitive` requires it for sensitive domains; `always` requires it for every work item.
+- **Check:** `manual` runs only when explicitly requested; `when-behavioral` runs when done-whens need observed runtime behavior; `always` runs for every work item.
+- **Try guide:** `manual` runs only when explicitly requested; `when-user-facing` generates guide when change affects UI/UX; `always` generates one for every work item.
+
 ## Step 0 - final safety pass
 
 Before logging or committing, run a short safety pass and report blockers only:
@@ -47,15 +65,12 @@ Before logging or committing, run a short safety pass and report blockers only:
   declared test command and the change touched logic
 - behavioral done-whens have `/check` evidence or equivalent proof, and there is
   a clear manual try path
-- if workflow files changed, `.agents` and `.claude` stayed in sync where both
-  adapters exist
+- any check required by `qualityGates.regular` has evidence, and there is a clear manual try path
+- a selected independent-review gate has a `passed` receipt in `review.md` whose target equals `HEAD`, whose spec hash matches, and whose receipt is current. Any mismatch is stale and blocks completion.
+- if workflow files changed, `.agents` and `.claude` stayed in sync where both adapters exist
 - 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` (the user's
-  explicit decision in the current chat, reason recorded; never set it for
-  them) or `invalid` (an `/audit` re-examination verdict with recorded
-  evidence, or the user's explicit call). A missing ledger file means no
-  findings.
+  it - run `/audit` to close it. The only waivers are `accepted` or `invalid`.
 
 Do not claim "passed", "verified", or "working" without naming the command,
 route, screenshot, or output that proves it. Stop before Step 1 if required
@@ -71,20 +86,14 @@ and records the exact target feature, archive, commit, and parent.
 - **Fix** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/fixes/{xxx-slug}.md`, and record an entry into `devflow/history/HISTORY.md`.
 - **Rollback** - archive `devflow/context/{xxx-slug}/spec.md` to `devflow/history/rollbacks/YYYY-MM-DD-{xxx-slug}.md`, preserving the original completed feature archive. Uncheck the target item in `devflow/build-plan.md` and record in `devflow/history/HISTORY.md`.
 
-**Archive resolved findings.** If `devflow/context/{xxx-slug}/findings.md` holds any
-findings, append a `## Findings` section to the archive file just written with
-every `closed`, `accepted`, or `invalid` entry at its final status (`accepted`
-entries keep their recorded reason). Do not archive or remove a `fixed` finding
-at any severity; repaired findings must remain in the ledger until an `/audit`
-re-review closes them.
+**Archive resolved findings & review receipts.**
+- If `devflow/context/{xxx-slug}/findings.md` holds findings, append `## Findings` to the archive file with resolved entries.
+- If `devflow/context/{xxx-slug}/review.md` holds a completed passing receipt, append `## Independent Review` to the archive file with the receipt summary.
 
 **Clean up run workspace.** Delete the task directory `devflow/context/{xxx-slug}/`. In Pure Multi-Run architecture, completed work leaves zero residual stubs in `devflow/context/`.
 
 **Discard consumed prototypes.** If this feature built the look from `prototypes/`
-- its Design reference pointed there and an early step ported `prototypes/theme.css`
-into the app - delete the `prototypes/` folder now. The tokens live in the real
-stylesheet and the HTML mockups were always throwaway; fold the deletion into this
-feature's commit. Skip this if the feature didn't consume prototypes.
+delete the `prototypes/` folder now.
 
 ## Step 2 - make the work commit on feature branch
 
@@ -127,24 +136,4 @@ Present the user with two clear delivery options:
 ## Step 4 - Finish & Try Path
 
 Point the user at `/feature`, `/fix`, or `/rollback` for the next task.
-
-Finish with a concise **How to try it** note for the completed work. For a
-rollback, explain how to confirm the removed behavior is gone and name one
-unaffected regression path. If the
-manual path is more than a couple of steps, tell the user to run `/try latest`;
-that command can read the archived feature from history.
-
-## Rules
-
-- **Mandatory User Confirmation Gate**: Always ask before choosing between Team MR/PR Push vs Direct Squash-Merge.
-- **Never auto-merge into main/master**: The decision to merge into `main` or `master` belongs strictly to the user.
-- The work item is the unit of history: one squashed feature, fix, or rollback
-  commit, even if the branch carried several checkpoint commits.
-- A rollback preserves the original feature archive and adds a separate rollback
-  archive. Never rewrite history to make the feature look as if it never existed.
-- Don't merge or push unfinished or failing work. The documented `Verify` command, or
-  the fallback build and tests, must pass first.
-- Never merge or push while a P0 or P1 finding is `open` or `fixed` in the ledger.
-- Pushing to remote is always explicit: confirm before running `git push`.
-- One item per completion. If a parent feature still has unchecked sub-features,
-  leave the parent unchecked.
+Finish with a concise **How to try it** note for the completed work.

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

@@ -88,9 +88,21 @@ Where this sits in the workflow:
 ### 2.4 Apply Continuous Quality Gates
 ตรวจสอบตามการตั้งค่า `qualityGates.continuous` ใน `devflow/config.json`:
 - **Audit**: `manual` (ข้ามอัตโนมัติ), `when-sensitive` (รันเมื่อแตะ Auth/Security/Database/Secrets), `always` (รันทุกฟีเจอร์)
+- **Independent Review**: อ่าน `qualityGates.continuous.independentReview`; `manual` คือ opt-in, `always` บังคับทุกฟีเจอร์, และ `when-sensitive` บังคับเมื่อฟีเจอร์แตะ authentication, authorization, secrets, payments, personal data, destructive operations, dependencies, deployment หรือ security boundary อื่น บันทึกคำตัดสินและหลักฐานต่อฟีเจอร์ใน spec
 - **Check**: `manual` (ข้ามอัตโนมัติ), `when-behavioral` (รันเมื่อมี Runtime Behavior เช่น UI/CLI/API), `always` (รันทุกฟีเจอร์)
 - **Try Guide**: `manual` (ข้ามอัตโนมัติ), `when-user-facing` (สร้าง Try Guide เมื่อเป็น UI/CLI), `always` (สร้างทุกฟีเจอร์)
 
+ทุก product/spec edit ทำให้ receipt เดิมหมดอายุ เมื่อ Independent Review gate
+ทำงาน ให้รัน Verify และซ่อม audit findings ให้เสร็จก่อนส่ง
+`audit independent current` ไปยัง fresh reviewer context หากไม่สามารถรับ
+receipt ที่ verdict เป็น `passed` และ freshness เป็น `current` ให้หยุด Continuous
+Mode โดยคง workspace/branch ไว้ ห้ามข้ามไป archive หรือ local squash-merge
+
+สำหรับฟีเจอร์ browser-facing ให้รัน `npm run test:browser` เมื่อมี
+`test:browser` script และเก็บ interactive evidence ผ่าน `browseros-neo` เมื่อ
+พร้อมใช้งาน หาก script หรือ MCP ไม่มี ให้บันทึก limitation และหยุดเมื่อ evidence
+นั้นเป็น gate ที่จำเป็น ห้ามติดตั้งหรืออ้างผลโดยปริยาย
+
 ### 2.5 Repair Findings
 - ซ่อมแซม Finding ระดับ P0/P1 ที่เกิดขึ้นจากฟีเจอร์นี้โดยอัตโนมัติ (ไม่เกิน `continuous.maxRepairAttempts` ครั้ง)
 - หากไม่สามารถซ่อมแซมได้ หรือมี P0/P1 ค้างอยู่ ให้หยุดการทำงานทันที

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

@@ -39,12 +39,16 @@ Gather these, then summarize. Do not dump file contents.
      `devflow/history/rollbacks/`. A missing rollback folder on a legacy
      installation is a warning, not a blocker; `/complete` creates it on the
      first rollback.
-   - Check `devflow/context/findings.md`. Missing on a legacy installation is
-     a warning, not a blocker; `/audit` and `/complete` create it on first use.
+   - Check `devflow/context/findings.md` and `devflow/context/{xxx-slug}/findings.md`.
+     Missing on a legacy installation is a warning, not a blocker; `/audit` and `/complete` create it on first use.
      When present, confirm its entry headers still match
      `### <id> [<severity>] <status> - <title>` and warn on a malformed ledger.
      Report any P0 or P1 finding still `open` or `fixed` by ID, since it will
      block `/complete`. Never block on the ledger yourself.
+   - Check `devflow/context/review.md` and `devflow/context/{xxx-slug}/review.md`. Missing is a
+     warning, not a blocker; `/audit independent current` and `/complete` create
+     it on first use. When present, validate the required request or receipt
+     fields and report pending, changes-requested, malformed, or stale state.
    - If `.gitignore` marks DevFlow workflow files as local-only, still require
      the files to exist on disk. Ignored but present is healthy; ignored and
      missing means the local workflow needs to be restored.
@@ -53,7 +57,8 @@ Gather these, then summarize. Do not dump file contents.
      file with `schemaVersion: 1`. Reject unknown keys and unsupported values.
      Report the effective workflow, git, verification, regular quality-gate,
      Continuous quality-gate, and Continuous Mode settings. Confirm each audit,
-     check, and try-guide gate uses its supported values and defaults to `manual`.
+     independent-review, check, and try-guide gate uses its supported values and
+     defaults to `manual`.
      An invalid config is a setup blocker for mutating workflow skills because
      they must not guess which policy to follow.
 2. **Tool adapters**
@@ -61,7 +66,6 @@ Gather these, then summarize. Do not dump file contents.
      logical adapters: Codex, Claude Code, GitHub Copilot, Antigravity, and OpenCode.
    - Confirm at least one compatible skill tree exists. Codex, Antigravity, and
      GitHub Copilot use `.agents/skills/`. Claude Code uses `.claude/skills/`.
-     OpenCode can use either tree.
    - If both skill trees are present, say that is healthy when the selected
      tools require both. Compare their skill folder names and warn about missing
      skills on either side.

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

@@ -151,6 +151,27 @@ discarded at `/complete`.
 
 This is a draft. Don't present it yet - critique it first.
 
+### Quality-gate and browser-evidence plan
+
+Before finishing the draft, read `devflow/config.json` and record the effective
+`qualityGates.regular.independentReview` policy in the spec. `manual` does not
+activate an automatic gate, `always` does, and `when-sensitive` activates it
+only when the feature touches authentication, authorization, secrets, payments,
+personal data, destructive operations, dependencies, deployment, or another
+security-sensitive boundary. Record the sensitivity decision and its evidence;
+do not silently choose the conditional result later.
+
+When the gate is active, add an explicit post-implementation handoff to
+`audit independent current`. The receipt must be produced from a fresh reviewer
+context after the final product/spec change; `/feature` only plans this handoff
+and never fabricates or pre-approves a receipt.
+
+Also inspect the repository's declared scripts and the feature behavior. If the
+feature is browser-facing and `test:browser` exists, put `npm run test:browser`
+in the verification matrix. Record an interactive `browseros-neo` handoff for
+observable UI behavior when that MCP is available. If either capability is
+absent, record it as unavailable instead of installing or claiming evidence.
+
 ## Step 4 - red-team the draft, then tighten
 
 Before the user reads it, turn on the spec yourself and try to break it. The
@@ -211,4 +232,4 @@ checked), archive the finished `devflow/context/{xxx-slug}/spec.md` to
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -44,6 +44,26 @@ the visual target - build components to match them, and treat `prototypes/theme.
 as the token source (the spec's first step ports it into the app's global
 stylesheet before the components are built).
 
+### Quality-gate and browser preflight
+
+Read `devflow/config.json` and the target spec's recorded decision for
+`qualityGates.regular.independentReview`. `manual` does not activate an
+automatic gate, `always` does, and `when-sensitive` follows the sensitivity
+decision and evidence captured by `/feature` or `/fix`. Stop for a spec repair
+instead of guessing when a conditional decision is missing.
+
+Treat any product or living-spec edit in this build as invalidating an earlier
+receipt. After the final Verify pass, an active gate routes to
+`audit independent current`; only a fresh receipt with `passed` verdict and
+`current` freshness may proceed toward `/complete`. This skill never approves
+its own work or rewrites receipt evidence.
+
+For a browser-facing step, run `npm run test:browser` when the script exists and
+record the result in the step evidence. Use `browseros-neo` for the interactive
+handoff when it is available and the done-when is visual or behavioral. When the
+script or MCP is absent, report that exact limitation; do not silently install a
+runner or claim browser evidence.
+
 **Resuming?** If the spec already has some build steps checked off (`- [x]`), this
 feature was started earlier and interrupted (often a cleared context). The spec and
 its ticked steps are files, so pick up where it left off: read which steps are done,
@@ -217,4 +237,4 @@ approval. This skill does not touch main.
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -133,6 +133,22 @@ If no changes are needed, say so.
 
 ## Step 5 - point to optional CI setup
 
+Before the CI handoff, read `devflow/config.json` and report the effective
+`qualityGates.regular.independentReview` onboarding default. Preserve an
+existing valid user choice. Explain that `manual` is opt-in, `always` requires a
+fresh receipt for every regular run, and `when-sensitive` activates for work
+touching authentication, authorization, secrets, payments, personal data,
+destructive operations, dependencies, deployment, or another security boundary.
+Onboarding has no active task to review, so it must not create `review.md` or
+claim a verdict; when the future gate activates, the handoff is
+`audit independent current` after final implementation and verification.
+
+Detect browser capability without installing anything. If the project already
+declares `test:browser`, record `npm run test:browser` in the onboarding report.
+Also report whether `browseros-neo` is available for interactive UI evidence.
+When a browser-facing project lacks either capability, point to `/browser-tests`
+as an optional setup route and describe the gap honestly.
+
 Do not create or change Verify commands or GitHub workflows during onboarding.
 Report any verification command or CI already present. When equivalent automatic
 pull-request checks are absent, mention the optional standalone setup:
@@ -261,4 +277,4 @@ $overview
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -58,6 +58,17 @@ state.
 8. **Onboarding check** - Before recommending `/overview`, check whether `AGENTS.md`
    still contains the `<!-- devflow:onboarding-required -->` marker or standard template commands.
    When it does, onboarding is incomplete and `/onboard` is the next action.
+9. **Independent review and browser evidence** - read
+   `qualityGates.regular.independentReview` from `devflow/config.json` and the
+   recorded sensitivity decision for `when-sensitive`. For every active run,
+   report the `review.md` state, verdict, freshness, check result, warnings, and
+   whether the effective gate is satisfied. An active gate with a missing,
+   pending, malformed, changes-requested, or stale receipt routes to
+   `audit independent current`, never `/complete`. Also report whether the spec
+   requires browser proof, whether `npm run test:browser` is declared and has
+   recorded evidence, and whether an interactive `browseros-neo` handoff is
+   available or explicitly unavailable. This remains read-only: do not execute
+   either browser path from `/status`.
 
 ## Output
 
@@ -106,4 +117,4 @@ drift is half the value of the command.
 
 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.
+enumerations and tables for matrices rather than dense paragraphs.

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

@@ -17,7 +17,7 @@ Where this sits in the workflow:
 Testing is optional in the Blueprint until the project declares a real test
 command in `AGENTS.md`. This skill is the explicit setup path. It adds or
 normalizes **unit testing** only; browser automation and end-to-end testing are
-separate setup work.
+separate optional setup through `/browser-tests`.
 
 ## Input
 

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

@@ -1,10 +1,13 @@
 ---
 name: try
-description: "[devflow] 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."
+description: "[devflow] 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, connects with MCP browseros-neo when available for interactive previews, 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."
+argument-hint: "[{latest|step-id|path}]"
 ---
 
 # try - manual review guide
 
+$ARGUMENTS
+
 Where this sits in the workflow:
 
     /implement or /complete  ->  [try]  ->  human review
@@ -58,7 +61,7 @@ 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.
+- **Web app** - dev server command, URL, and the route or screen to open. If `browseros-neo` MCP server is active (`http://127.0.0.1:9010/mcp`), you can also offer to inspect or navigate in the live browser.
 - **Server/API** - server command, base URL, endpoint, method, and expected
   response shape.
 - **CLI** - exact command(s), arguments, and expected output.
@@ -77,9 +80,9 @@ Produce a short guide with these sections:
 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.
+    error.
 5. **Watch For** - common wrong outcomes, console or network errors, stale data,
-   missing fields, bad empty states, layout issues, or safety warnings.
+    missing fields, bad empty states, layout issues, or safety warnings.
 
 Keep it concrete. Prefer:
 
@@ -97,23 +100,5 @@ 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.
-
-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 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`.
-
-## Formatting
-
-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.
+- **MCP Visual Preview** - mention live browser inspection via MCP `browseros-neo` if active.
+- **Gaps** - anything the guide cannot know from the docs, such as missing route or seed data.