create-harness-vibe-coding 0.7.2 → 0.8.0

package/templates/optional/skills/github-pr-review/{docs → Harness}/workflows/github-pr-review.md

@@ -1,28 +1,28 @@
-# GitHub PR Review Workflow
-
-## Required Evidence
-
-- PR URL or number and base/head refs.
-- Diff or changed-file summary.
-- CI/check status and relevant failing logs.
-- Review findings with exact file and line references when available.
-
-## Common Commands
-
-```powershell
-gh pr view --web
-gh pr view --json number,title,baseRefName,headRefName,mergeStateStatus,statusCheckRollup
-gh pr diff
-git diff --stat
-npm test
-```
-
-Use repository-specific test commands when they differ from npm.
-
-## Fallback
-
-If `gh` is unavailable or unauthenticated, use local git refs, remote URLs, and `git diff` against the target branch. Ask for missing PR context only when it cannot be inferred.
-
-## Windows Notes
-
-Quote branch names containing special characters. In PowerShell, pipe JSON output to tools that are available locally, or read it directly if `jq` is not installed.
+# GitHub PR Review Workflow
+
+## Required Evidence
+
+- PR URL or number and base/head refs.
+- Diff or changed-file summary.
+- CI/check status and relevant failing logs.
+- Review findings with exact file and line references when available.
+
+## Common Commands
+
+```powershell
+gh pr view --web
+gh pr view --json number,title,baseRefName,headRefName,mergeStateStatus,statusCheckRollup
+gh pr diff
+git diff --stat
+npm test
+```
+
+Use repository-specific test commands when they differ from npm.
+
+## Fallback
+
+If `gh` is unavailable or unauthenticated, use local git refs, remote URLs, and `git diff` against the target branch. Ask for missing PR context only when it cannot be inferred.
+
+## Windows Notes
+
+Quote branch names containing special characters. In PowerShell, pipe JSON output to tools that are available locally, or read it directly if `jq` is not installed.

package/templates/optional/skills/python-backend/{docs → Harness}/workflows/python-backend.md

@@ -1,34 +1,34 @@
-# Python Backend Workflow
-
-## Required Evidence
-
-- Python executable, version, and dependency manager detected.
-- Unit/integration test command and result.
-- API smoke evidence for changed endpoints when applicable.
-- Migration, fixture, or environment assumptions.
-
-## Common Commands
-
-```powershell
-python --version
-py --version
-python3 --version
-python -m unittest discover -s tests
-py -m unittest discover -s tests
-python3 -m unittest discover -s tests
-python -m pytest
-python -m pytest tests
-uv run pytest
-poetry run pytest
-python -m uvicorn app.main:app --reload
-```
-
-Prefer commands already documented by the project. When no project-specific command is documented, detect an available Python executable in the current shell (`python`, then `py`, then `python3`) and run the matching `-m unittest discover -s tests` or pytest command. `unittest` is first-class for standard-library test suites; do not require pytest when the project already uses unittest.
-
-## Fallback
-
-If unittest, pytest, or the app runner is unavailable, run targeted Python modules, import checks, or framework-specific tests that already exist. Do not create or install a new backend stack without approval.
-
-## Windows Notes
-
-Virtual environment activation is usually `.\\.venv\\Scripts\\Activate.ps1`. If script execution is blocked, use the environment's Python executable directly, for example `.\\.venv\\Scripts\\python.exe -m unittest discover -s tests` or `.\\.venv\\Scripts\\python.exe -m pytest`.
+# Python Backend Workflow
+
+## Required Evidence
+
+- Python executable, version, and dependency manager detected.
+- Unit/integration test command and result.
+- API smoke evidence for changed endpoints when applicable.
+- Migration, fixture, or environment assumptions.
+
+## Common Commands
+
+```powershell
+python --version
+py --version
+python3 --version
+python -m unittest discover -s tests
+py -m unittest discover -s tests
+python3 -m unittest discover -s tests
+python -m pytest
+python -m pytest tests
+uv run pytest
+poetry run pytest
+python -m uvicorn app.main:app --reload
+```
+
+Prefer commands already documented by the project. When no project-specific command is documented, detect an available Python executable in the current shell (`python`, then `py`, then `python3`) and run the matching `-m unittest discover -s tests` or pytest command. `unittest` is first-class for standard-library test suites; do not require pytest when the project already uses unittest.
+
+## Fallback
+
+If unittest, pytest, or the app runner is unavailable, run targeted Python modules, import checks, or framework-specific tests that already exist. Do not create or install a new backend stack without approval.
+
+## Windows Notes
+
+Virtual environment activation is usually `.\\.venv\\Scripts\\Activate.ps1`. If script execution is blocked, use the environment's Python executable directly, for example `.\\.venv\\Scripts\\python.exe -m unittest discover -s tests` or `.\\.venv\\Scripts\\python.exe -m pytest`.

package/templates/optional/skills/ts-react-frontend/{docs → Harness}/workflows/ts-react-frontend.md

@@ -1,35 +1,35 @@
-# TypeScript React Frontend Workflow
-
-## Required Evidence
-
-- Package manager and scripts detected.
-- Typecheck, lint, test, or build results according to project conventions.
-- Real-browser smoke or screenshot evidence for user-visible changes.
-- Console/runtime error check result for the changed screen or flow.
-- Notes on responsive behavior and important interaction states.
-- Stable accessible labels/roles and stable test hooks such as `data-testid` are required for critical UI controls and states: inputs, buttons, filters, rows, empty/error/loading states.
-
-Typecheck, build, and unit tests are necessary signals but are not enough for user-visible React changes. Before claiming UI acceptance, load the app in a real browser by Playwright, Chrome DevTools/CDP, or a documented manual run and capture screenshot/trace/console evidence.
-For TS/React UI work, capture the selector contract in the feature doc before implementation so tests and manual checks can target stable selectors instead of component internals or brittle DOM paths.
-
-## Common Commands
-
-```powershell
-npm run typecheck
-npm run lint
-npm test
-npm run build
-npm run dev
-pnpm test
-yarn test
-```
-
-Use the package manager and scripts already present in the repository.
-
-## Fallback
-
-If no formal checks exist, run the closest available build or dev command, inspect the changed UI manually, and document the missing automation. Do not add dependencies unless the task requires it and the user approves.
-
-## Windows Notes
-
-Use PowerShell syntax for environment variables: `$env:VITE_API_URL='http://localhost:8000'; npm run dev`. Quote paths and prefer package scripts over shell-specific command chains.
+# TypeScript React Frontend Workflow
+
+## Required Evidence
+
+- Package manager and scripts detected.
+- Typecheck, lint, test, or build results according to project conventions.
+- Real-browser smoke or screenshot evidence for user-visible changes.
+- Console/runtime error check result for the changed screen or flow.
+- Notes on responsive behavior and important interaction states.
+- Stable accessible labels/roles and stable test hooks such as `data-testid` are required for critical UI controls and states: inputs, buttons, filters, rows, empty/error/loading states.
+
+Typecheck, build, and unit tests are necessary signals but are not enough for user-visible React changes. Before claiming UI acceptance, load the app in a real browser by Playwright, Chrome DevTools/CDP, or a documented manual run and capture screenshot/trace/console evidence.
+For TS/React UI work, capture the selector contract in the feature doc before implementation so tests and manual checks can target stable selectors instead of component internals or brittle DOM paths.
+
+## Common Commands
+
+```powershell
+npm run typecheck
+npm run lint
+npm test
+npm run build
+npm run dev
+pnpm test
+yarn test
+```
+
+Use the package manager and scripts already present in the repository.
+
+## Fallback
+
+If no formal checks exist, run the closest available build or dev command, inspect the changed UI manually, and document the missing automation. Do not add dependencies unless the task requires it and the user approves.
+
+## Windows Notes
+
+Use PowerShell syntax for environment variables: `$env:VITE_API_URL='http://localhost:8000'; npm run dev`. Quote paths and prefer package scripts over shell-specific command chains.

package/templates/optional/skills/ui-ux-review/{docs → Harness}/workflows/ui-ux-review.md

@@ -1,26 +1,26 @@
-# UI/UX Review Workflow
-
-## Required Evidence
-
-- Screenshots for desktop and mobile views.
-- Notes on layout, typography, interaction states, accessibility, and empty/loading/error states.
-- Any automated accessibility, lint, or visual test output available in the project.
-
-## Common Commands
-
-```powershell
-npm run dev
-npm run lint
-npm run test
-npx playwright test
-```
-
-Use the project's existing commands first. Browser screenshots may come from Playwright, CDP, framework tooling, or manual capture.
-
-## Fallback
-
-When automation is unavailable, inspect the running UI manually at representative viewport sizes and document findings with screenshots. Avoid adding design or test dependencies without approval.
-
-## Windows Notes
-
-PowerShell does not support POSIX inline environment variables. Use `$env:NAME='value'; command` and quote screenshot paths with spaces.
+# UI/UX Review Workflow
+
+## Required Evidence
+
+- Screenshots for desktop and mobile views.
+- Notes on layout, typography, interaction states, accessibility, and empty/loading/error states.
+- Any automated accessibility, lint, or visual test output available in the project.
+
+## Common Commands
+
+```powershell
+npm run dev
+npm run lint
+npm run test
+npx playwright test
+```
+
+Use the project's existing commands first. Browser screenshots may come from Playwright, CDP, framework tooling, or manual capture.
+
+## Fallback
+
+When automation is unavailable, inspect the running UI manually at representative viewport sizes and document findings with screenshots. Avoid adding design or test dependencies without approval.
+
+## Windows Notes
+
+PowerShell does not support POSIX inline environment variables. Use `$env:NAME='value'; command` and quote screenshot paths with spaces.

package/templates/common/.claude/commands/wf-learn.md

@@ -1,17 +0,0 @@
-# /wf-learn
-
-Force a memory learning cycle. Dispatches `context-master` to analyze the session, then `memory-master` to consolidate extracted knowledge into `Harness/memory/*` (project-level) and cross-project global memory.
-
-## Required
-
-- Load `wf-learn` skill.
-- MUST dispatch `context-master` first, then `memory-master`.
-- Both agents are read-only reporters; CEO writes the final memory files.
-
-## Flow
-
-```text
-context-master (analyze)
-→ memory-master (consolidate)
-→ CEO writes to Harness/memory/* + global memory
-```

package/templates/common/.claude/commands/wf-max.md

@@ -1,49 +0,0 @@
-# /wf-max [task]
-
-**WF-MAX ACTIVE: You are CEO, not implementer.**
-
-Enter maximum-parallelism workflow mode with an optional task description. Splits tasks into minimal non-conflicting units and dispatches as many subagents as possible in parallel waves.
-
-## CEO Contract (STICKY — re-read before each wave)
-
-```
-ALLOWED first actions:
-1. Read CLAUDE.md, Harness/MEMORY.md, Harness/README.md, Harness/WF-MAX.md
-2. Create task PLAN/PROGRESS
-3. Spawn W0 read-only agents in ONE message
-
-FORBIDDEN before W0 returns:
-- Read source files
-- Grep source contents
-- Edit/Write/MultiEdit
-- Bash (except directory listing)
-
-If tempted to Read/Edit/Bash a source file → STOP. Spawn a Worker.
-```
-
-## Required
-
-- Load `wf-max` skill.
-- MUST run exploration fan-out with as many read-only subagents as useful.
-- MUST produce Dispatch Table + pass Self-Audit Checklist (D-GATE) before W2.
-- MUST partition implementation into disjoint write sets across parallel waves.
-- MUST run parallel reviewers per dimension after each implementation wave.
-
-## Loop
-
-```text
-intake
--> W0: max-parallel exploration (5-10 read-only agents)
--> E-GATE: all exploration questions answered, findings synthesized
--> W1: architecture — 3 parallel architects → interface contract
--> D-GATE: Dispatch Table + Self-Audit (MANDATORY, see WF-MAX.md)
--> W2: N parallel implementers (ALL spawned in ONE message, disjoint file claims)
--> W2R: parallel spec/code/security reviewers
--> W3+: dependent waves (re-run D-GATE if write-set changed)
--> INTEGRATION: verifier → fail → debugger → loop (cap=3)
--> CLOSEOUT: context-master + memory-master
-```
-
-Full organization model, span formula, Manager types, anti-pattern catalog, and synthesis protocol: [WF-MAX.md](Harness/WF-MAX.md).
-
-Keep `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` current.

package/templates/common/.claude/commands/wf-remove.md

@@ -1,23 +0,0 @@
-# /wf-remove
-
-Safely uninstall the Harness framework from this project. Uses `Harness/scripts/wf-remove.mjs` for fast, deterministic file classification. Auto-removes unmodified framework files. MUST ask user for every modified or uncertain file before deletion. NEVER touches user data.
-
-## Required
-
-- Load `wf-remove` skill.
-- Run `node Harness/scripts/wf-remove.mjs` first (dry-run).
-- For MODIFIED files: present each one, get explicit [D]elete / [K]eep decision.
-- NEVER auto-delete user data or modified files.
-
-## Flow
-
-```text
-node Harness/scripts/wf-remove.mjs          → DRY-RUN plan
-  ├── SAFE files → list, auto-remove with --apply
-  ├── MODIFIED files → present each, user decides D/K
-  └── USER DATA → list, NEVER remove
-node Harness/scripts/wf-remove.mjs --apply  → execute
-git status → review
-```
-
-Full spec: `.claude/skills/wf-remove/SKILL.md`.

package/templates/common/.claude/commands/wf-review.md

@@ -1,25 +0,0 @@
-# /wf-review [focus]
-
-Cross-model peer review. Invokes the OTHER agent CLI for independent multi-dimension review.
-
-## Anti-Self-Review Guard
-
-**Use the OTHER CLI.** Claude → `codex exec`. Codex → `claude -p`. Only one CLI? Warn user, do NOT self-review.
-
-## Required
-
-- Load `wf-review` skill (authoritative: dimensions, severity, synthesis format).
-- Detect CLI: `which codex` / `which claude`. Use the one NOT running this session.
-- `Bash` invoke the other CLI — never simulate.
-- Present raw output + classified synthesis.
-
-## Flow
-
-```text
-diff + architecture docs + 5-dimension prompt (from skill)
-→ Bash: codex exec "..." or claude -p "..."
-→ classify findings (Critical/High/Medium/Low per skill severity table)
-→ raw output + synthesis + action items
-```
-
-Context guard: if `git diff` >500 lines, warn and suggest narrowing scope.

package/templates/common/.claude/commands/wf-update.md

@@ -1,17 +0,0 @@
-# /wf-update
-
-Check for Harness scaffold updates from GitHub and apply them incrementally. Script-driven for speed — comparison happens in milliseconds, only conflicts need user decision.
-
-## Required
-
-- Load `wf-update` skill.
-- Run `node Harness/scripts/wf-update-check.mjs` first (instant plan).
-- For CONFLICT files: user decides [M]erge (recommended) / [O]verwrite / [K]eep.
-
-## Check mode
-
-`/wf-update --check` — Report available updates without applying.
-
-## Full update
-
-`/wf-update` — Script compares → AI resolves conflicts → Script applies SAFE+NEW.

package/templates/common/.claude/commands/wf.md

@@ -1,31 +0,0 @@
-# /wf <task/mission>
-
-Enter WF mode with the given task or mission description.
-
-## CEO Exploration Constraint (READ THIS FIRST)
-
-**You are the CEO. Your job is to ask questions, not read files.** During exploration:
-- **DO NOT Read/Grep/Glob any source code.** Not even "just to check one thing." You will waste your context window and defeat parallelism — the #1 WF failure mode.
-- **Spawn ≥3 read-only subagents in ONE message.** Default to `sonnet` — exploration requires real code understanding. Use `haiku` only for shallow scans (directory listing, file counts). Use `opus` if the user asks.
-- **You may only read:** `Harness/` docs, `CLAUDE.md`, and subagent returns. Nothing else until the Second Plan is written.
-
-## Required
-
-- Load `Harness/WF.md` — the single authority for WF mode.
-- Load `subagent-orchestrator` skill for subagent coordination.
-- Explicit `/wf`, `wf mode`, `workflow mode`, or `wk mode` MUST spawn at least 3 distinct subagents from `.claude/agents/` before second planning.
-
-## Loop
-
-```text
-intake
--> parallel read-only exploration (≥3 subagents)
--> synthesis + second plan
--> test
--> implement
--> review
--> verify
--> debugger recovery loop when needed
-```
-
-Keep `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` current.

package/templates/common/commands/wf-max.toml

@@ -1,18 +0,0 @@
-description = "Maximum parallelism: CEO→Manager→Worker hierarchy with D-GATE enforcement"
-prompt = """
-WF-MAX ACTIVE: You are CEO, not implementer.
-
-ALLOWED first actions:
-1. Read CLAUDE.md, Harness/MEMORY.md, Harness/README.md, Harness/WF-MAX.md
-2. Create task PLAN/PROGRESS
-3. Spawn W0 read-only agents in ONE message
-
-FORBIDDEN before W0 returns:
-- Read source files deeply (scoping only via Grep/Glob)
-- Edit / Write / MultiEdit on source files
-- Bash (except ls/dir/tree/git status/git diff)
-
-Loop: W0 Explore → E-GATE → W1 Architecture → D-GATE (Dispatch Table + Self-Audit) → W2 Implement (single-message dispatch) → W2R Review → W3+ dependent → Integration → Closeout
-
-Full spec: Harness/WF-MAX.md
-"""

package/templates/common/commands/wf-review.toml

@@ -1,15 +0,0 @@
-description = "Cross-model peer review — 5 dimensions with severity classification"
-prompt = """
-Cross-model peer review. Use the OTHER CLI for independent review.
-
-Dimensions:
-1. Correctness — bugs, edge cases, race conditions, null/undefined, logic flaws?
-2. Security — injection, auth bypass, data exposure, input validation, unsafe deps?
-3. Architecture — boundary violations, coupling, state ownership, interface contract breaks?
-4. Performance — algorithmic complexity, N+1 queries, memory leaks?
-5. Tests — coverage gaps, missing edge cases, CI regressions?
-
-Severity: Critical (security/data-loss/crash → must fix), High (bug/regression → should fix), Medium (maintainability → may defer), Low (style → optional)
-
-Review CLI: use the OTHER one. Claude → codex exec. Codex → claude -p.
-"""

package/templates/common/docs/harness/WF.md

@@ -1,174 +0,0 @@
-# WF Mode - Long Task Workflow
-
-Use this when work is long, difficult, uncertain, multi-file, multi-agent, or user-triggered with `/wf`, `wf mode`, `workflow mode`, or `wk mode`.
-
-This is a Ralph-style harness loop: keep moving through evidence, bounded exploration, second planning, implementation, review, verification, and recovery instead of stalling on the first obstacle.
-
-## Trigger
-
-Enter WF mode when any of these are true:
-
-- The user explicitly says `/wf`, `wf mode`, `workflow mode`, `wk mode`, or asks for the full workflow.
-- The task needs more than one step, more than three files, or more than one subsystem.
-- The task needs research, architecture judgment, browser/API validation, or migration planning.
-- Confidence in intent, architecture, or implementation is below 95%.
-- The same command, test, tool, or approach fails twice.
-- The user explicitly says `/wf-max [task]` or `wf max` (for maximum-parallelism mode, see [WF-MAX.md](WF-MAX.md)).
-
-**Two distinct trigger classes — do not conflate them:**
-
-- **Explicit invocation** (`/wf`, `wf mode`, `workflow mode`, `wk mode`, `/wf-max`): subagent fan-out is **mandatory and unconditional**. File count, task size, and subsystem count are IRRELEVANT — a 1-file task typed with `/wf` still fans out to ≥3 subagents before the second plan. There is no "too small for WF" exception once the user types the command.
-- **Auto-triggering** (the file-count / multi-subsystem / repeated-failure bullets above): these decide whether the harness enters WF mode *on its own*. They are the ONLY place file count matters, and they can only ESCALATE into WF — never downgrade an explicit command out of it.
-
-## Multi-Subagent Requirement
-
-WF mode requires multi-subagent orchestration by default.
-
-- Explicit `/wf`, `wf mode`, `workflow mode`, or `wk mode` MUST spawn at least 3 distinct subagents from `.claude/agents/` before second planning unless the runtime cannot spawn subagents.
-- Collaboration decision tree (replaces the old "7:3" heuristic — concrete conditions, not a magic number):
-  - **In explicit WF/WK mode** → ALWAYS multi-agent (≥3 subagents before second plan). No exceptions.
-  - **3+ files changed** → multi-agent (at minimum: planner + implementer + reviewer).
-  - **Cross-layer change** (DB + API + UI) → multi-agent with architect + implementer(s) + reviewer.
-  - **Uncertain scope or approach** → multi-agent exploration (planner + researcher + architect).
-  - **1-2 files, well-understood, not in WF mode** → solo is acceptable.
-  - **Repeated failure on same task** → STOP solo, switch to multi-agent.
-- Default initial fan-out: `planner`, `researcher` or `docs-researcher`, and `architect`. Add `test-writer`, `reviewer`, `debugger`, or `verifier` when the phase needs them.
-- **Exploration Gate (HARD):**
-  - [ ] CEO has NOT read any source files — only `Harness/` docs, `CLAUDE.md`, and subagent returns. This is the #1 rule. **Exception**: if subagents are genuinely unavailable, fall back to bounded-pass emulation and record `Fallback: subagents unavailable` in PLAN.md.
-  - [ ] CEO overrides model per-agent: default `sonnet` for real code understanding; `haiku` only for shallow scans (directory listing, file counts); `opus` if user requests.
-  - [ ] ≥3 distinct agent types, each with ONE specific question.
-  - [ ] All spawned in ONE message block.
-  - [ ] Agent count ≥ max(3, ceil(estimated_dirs / 2)) — estimate from prompt/docs; run a second wave if returns reveal more.
-- Record every dispatch or bounded-pass fallback in `Harness/tasks/<task-id>/PLAN.md#Subagent Dispatch`.
-- If subagents are unavailable, emulate the same roles as separate bounded passes and record why the fallback was used.
-
-For maximum-parallelism mode (write-set coloring, wave dispatch, parallel reviewers), use `/wf-max [task]` and see [WF-MAX.md](WF-MAX.md).
-
-## WF Loop
-
-```text
-Intake
--> confidence gate
--> parallel planner / researcher / docs-researcher / architect subagents
--> synthesis
--> second plan
--> test-writer
--> implementer
--> reviewers
--> verifier
--> if failed: debugger -> review -> e2e/API verification -> loop
--> close with evidence
-```
-
-## Intake
-
-1. Read `CLAUDE.md`, `Harness/MEMORY.md`, `Harness/README.md`, `Harness/PROGRESS.md`, and the current task's `PROGRESS.md` and `PLAN.md` under `Harness/tasks/<task-id>/`.
-2. State the goal, non-goals, confidence level, known risks, and write boundaries.
-3. Ask up to three blocking questions only when the next action cannot reach 95% confidence.
-4. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` before dispatching agents or running long commands.
-5. Load `Harness/subagents.md` before coordinating multiple agents; explicit WF/WK mode always coordinates multiple roles.
-
-## Exploration
-
-Use parallel read-only subagents first. Explicit WF/WK mode starts with at least three distinct `.claude/agents/` roles before the second plan. For automatic WF triggers, default to 3-5 active agents unless the task is clearly small enough for the solo exception.
-
-| Agent | Purpose | Writes |
-| --- | --- | --- |
-| `planner` | map local project facts, commands, app entry points, existing docs, and initial decomposition | none |
-| `researcher` | product, ecosystem, dependency, and external context | none unless returning a docs patch |
-| `docs-researcher` | official docs, SDK/API versions, browser/tool limits | none unless returning a docs patch |
-| `architect` | boundaries, ports, data flow, state impact, migration risks | none unless returning a docs patch |
-
-Use local files first. Use web search, Tavily, TinyFish, GitHub, official docs, or user-provided links only when the decision needs current or external evidence. Record tool choice and limitations in `Harness/research/research-results.md` or `Harness/tasks/<task-id>/PLAN.md`.
-
-## Subagent Orchestration
-
-Use `Harness/subagents.md` as the orchestration methodology and `Harness/dispatch.md` as the dispatch table protocol.
-
-- The main agent is the controller and owns synthesis, integration, and final verification.
-- Subagents are readers and reporters. Only the main agent writes to task PROGRESS.md and PLAN.md. Subagents return PLAN patch suggestions which the main agent reviews before committing.
-- Parallelize read-only exploration; serialize writers unless write sets are disjoint and isolated.
-- Every subagent gets a dispatch pack with role, goal, read set, write set, forbidden scope, injected docs, evidence, stop condition, and return format.
-- After implementation, run spec review before code-quality or architecture review.
-- If subagents are unavailable, emulate the same roles as bounded passes and record the fallback.
-
-## Second Plan
-
-After exploration, synthesize:
-
-- facts found
-- assumptions
-- risks
-- accepted/rejected options
-- tasks
-- read/write sets
-- verification path
-- rollback or recovery plan
-
-Write the result to `Harness/tasks/<task-id>/PLAN.md` before implementation. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`.
-
-## Build And Review
-
-1. `test-writer` defines a failing test or written manual check first.
-2. `implementer` changes only the declared write set.
-3. At least one `reviewer` checks diff, architecture, risks, and missing tests.
-4. For cross-layer or risky work, run separate reviewers for architecture and test adequacy.
-5. `verifier` runs the declared checks and records exact evidence.
-
-## Browser And API Evidence
-
-For browser-visible changes, typecheck/build/unit tests are not enough. Use Chrome DevTools, CDP, Playwright, or a documented real-browser run:
-
-- start the app and record URL/port
-- click through the critical flow
-- capture frontend console/runtime errors
-- capture failed network requests
-- collect backend logs when the flow crosses an API
-- record screenshot, trace, video, or manual evidence path
-
-For API changes, run the project API/integration test path or a documented real request against a local service and record request, response, logs, and failure behavior.
-
-## Recovery Loop
-
-If verification fails:
-
-1. Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` with failure count and blocker.
-2. Dispatch `debugger` with the failing command, error output, and smallest relevant files.
-3. Fix the smallest reproduced failure.
-4. Run reviewer again.
-5. Run verifier again.
-6. Repeat until verified or blocked by missing user input/external state.
-
-Before asking the user after repeated failures, dispatch `context-master` then `memory-master` (or use `/wf-learn`) to record the failure pattern, attempted paths, and root cause hypothesis. Present evidence-backed options to the user.
-
-## Heartbeat Protocol
-
-Heartbeat is a lightweight recovery protocol, not a background daemon.
-
-Update `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`:
-
-- before a long command
-- after a long command
-- before spawning subagents
-- after integrating subagent returns
-- after each failed verification
-- before stopping for user input
-
-The agent may set the next beat interval by event instead of time, such as "after next test run", "after reviewer returns", or "after browser evidence is captured".
-
-When context approaches ~85% of the window, dispatch `context-master` to analyze and append a compression suggestion to `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat`. The suggestion is non-blocking; the controller checks it at the next natural pause point.
-
-## Closeout
-
-Close only when:
-
-- acceptance criteria are satisfied
-- reviewer has no unresolved critical/high findings
-- test/API/browser evidence is recorded
-- affected Harness docs are synced
-- `context-master` has analyzed the session and extracted durable knowledge
-- `memory-master` has consolidated extracted knowledge into `Harness/memory/*` and `Harness/MEMORY.md`
-- Current task PROGRESS.md and PLAN.md are archived under `Harness/tasks/<task-id>/` with Phase set to Verified
-- `Harness/PROGRESS.md` task index is updated (Closed column filled, Active Task cleared or set to next task)
-- `Harness/tasks/<task-id>/PROGRESS.md#Heartbeat` says the task is verified or lists the exact next recovery action
-- `Harness/PROGRESS.md` task index reflects the closed task

package/templates/optional/skills/browser-e2e/.claude/commands/wf-browser.md

@@ -1,25 +0,0 @@
-# /wf-browser [task]
-
-AI-driven browser automation via Browser Use (89.1% WebVoyager benchmark). Dual mode: CLI (~50ms per call, no LLM needed) + Python Agent API (multi-step AI reasoning).
-
-## Required
-
-- Load `wf-browser` skill.
-- Load `Harness/workflows/browser-e2e.md` for evidence contract and fallback paths.
-- Real-browser evidence required for every browser/UI claim (screenshot, state snapshot, or console output).
-
-## Modes
-
-**CLI (fast iteration):** `browser-use open/state/click/screenshot/close` — Claude Code reasons, CLI executes.
-**Agent (complex flows):** Python API with LLM observation→decision→action loop.
-
-## Flow
-
-```text
-open page → state (inspect elements)
-→ click/input (interact)
-→ state/screenshot (verify)
-→ close (cleanup)
-```
-
-Keep browser evidence in `Harness/tasks/<task-id>/evidence/*.png`.