@plainconceptsplatform/agent-harness 2.0.0

package/src/content/.agents/skills/pc-make-evidence-scaffold/evidence-contract.md

@@ -0,0 +1,29 @@
+# Evidence contract
+
+Evidence captured by `/plan-goal` lives at `openspec/changes/archive/<dated>-<id>/evidence/`. A standalone pre-archive capture may use `openspec/changes/<id>/evidence/`, but archive moves it into the archived change before publication. That folder contains only:
+- ordered capture images (`01-{label}.png/webp`, ...) and/or `flow.gif`
+- `evidence.json`: the manifest, schema below.
+
+## version 1 schema
+
+```jsonc
+{
+  "version": 1,
+  "changeId": "...",
+  "required": true,
+  "status": "passed",            // passed | skipped | failed | blocked
+  "assets": [ { "type": "screenshot", "path": "openspec/changes/archive/<dated>-<id>/evidence/01-final.png", "caption": "...", "bytes": 0, "format": "png" } ],
+  "reason": "...",                 // skipped | blocked
+  "failedStep": "...",             // failed
+  "prMarkdown": "## Evidence ..."
+}
+```
+
+## Statuses
+
+- `passed`: evidence required and produced.
+- `skipped`: evidence not required (see decision rule). Exit success.
+- `blocked`: required but could not run (no harness, app won't start, budget exceeded). Not a skip. Surface it.
+- `failed`: a project harness ran and its assertions failed. Surface it.
+
+`blocked` (required but unrunnable) is never treated as a skip.

package/src/content/.agents/skills/pc-make-guardrails/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: pc-make-guardrails
+description: Generate or update the pc-guardrails-project skill from ARCHITECTURE.md and relevant project files, then wire it into every engineer agent. Invoked by the /make-guardrails command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Guardrails
+
+Analyze `ARCHITECTURE.md` and other project files to generate or update a `pc-guardrails-project` skill: a set of rules and constraints extracted from the project's own documentation that agents must follow.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-guardrails-project/SKILL.md`. Determine which mode to use:
+   - Does not exist: Generate mode. Create from scratch.
+   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
+   - Exists but no timestamp: proceed in Generate mode (full regeneration).
+
+2a. **Generate mode: read source documents**
+
+   Read ALL of the following that exist:
+   - `ARCHITECTURE.md` (primary source)
+   - `DESIGN.md` (design system, component conventions)
+   - `AGENTS.md` (existing agent instructions, optimizations)
+   - `README.md` (setup, conventions)
+   - `CONTRIBUTING.md` (if present)
+   - `.opencode/harness.json` (platform, models, concurrency)
+   - `openspec/config.yaml` (if present: domain context and rules)
+   - Root config files: `package.json`, `tsconfig.json`, `biome.json`, `.eslintrc*`, `Cargo.toml`, `go.mod`, `pyproject.toml`, `pom.xml`: whatever exists
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+
+   Use file tools to discover constraints: `read` the documents above, `grep` for lint/formatter config rules.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `ARCHITECTURE.md` and check its `<!-- Last updated:` timestamp. If ARCHITECTURE.md hasn't changed since the guardrails were last generated, report "Guardrails up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <config files, lint configs, CI workflows>` to find what convention/config files changed.
+   - If nothing changed: report "Guardrails up to date" and stop.
+   - Update only the affected rule categories. Preserve manually-added rules in unchanged categories.
+   - If changes are pervasive (new architecture, new framework, new platform), fall back to Generate mode.
+
+3. **Extract guardrails**
+
+   From the documents and code graph analysis, extract concrete, actionable rules. Follow the [category reference](category-reference.md) for the full list of categories, rule quality standards, and the skill file template.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real rules. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-guardrails-project` to the Guardrails ability line (skip if already present). Keep the line's existing entries exactly as they are: only insert `@pc-guardrails-project` after `@pc-guardrails-generic`, using this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ```
+
+   Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Store summary in configured persistent context**
+
+   `write_note` MCP tool with title `guardrails-summary` containing:
+   - The ISO timestamp of this run
+   - Number of rules per category
+
+7. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of rules extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-guardrails` any time the architecture or conventions change significantly."

package/src/content/.agents/skills/pc-make-guardrails/category-reference.md

@@ -0,0 +1,68 @@
+# Guardrails category reference
+
+From the documents and code graph analysis, extract concrete, actionable rules in these categories. Only include a category if you found real evidence for it.
+
+- Architecture constraints: layer boundaries, module dependencies, forbidden imports, directory ownership rules (e.g. "src/api/ must not import from src/ui/"). Verify actual import boundaries with the project-selected analysis tools.
+- File organization: avoid god-files and dumping-ground constants. Each file should have one clear responsibility. Split by domain or feature instead (e.g. `user-constants.ts`, `order-types.ts`, `auth-config.ts`). A file that imports from 5+ unrelated modules is a sign it should be split.
+- Naming conventions: file naming, component naming, API route conventions, branch naming
+- Code style: formatter config, lint rules, import ordering, max line length. Derive from actual config files.
+- Testing rules: test file locations, naming, coverage gates, what must be tested before merge
+- Build & deployment: build commands, env requirements, deployment targets, CI gates
+- Data & state: migration rules, schema change process, state management patterns
+- Security: auth boundaries, input validation requirements, secrets handling
+- Dependencies: package manager, lockfile rules, upgrade policy, forbidden packages
+- Git workflow: branch naming, commit message format, PR process (platform-specific from `harness.json`)
+- Domain-specific rules: anything in `openspec/config.yaml` context or `ARCHITECTURE.md` constraints/risks sections
+
+Each rule must be:
+- Concrete: "Use `pnpm` not `npm`" not "Use the right package manager"
+- Evidence-based: derive from the files/code graph you analyzed, do not invent rules
+- Actionable: an agent can check it before acting
+
+## Skill template
+
+Write (or update) `.agents/skills/pc-guardrails-project/SKILL.md`:
+
+```markdown
+---
+name: pc-guardrails-project
+description: Project-specific rules and constraints extracted from ARCHITECTURE.md. Load this skill before implementing any change to understand boundaries, conventions, and constraints for this codebase.
+license: MIT
+---
+
+# Project Guardrails
+
+> Auto-generated by `/make-guardrails`. Regenerate with the same command when architecture or conventions change.
+
+## Architecture Constraints
+- <rule>
+- <rule>
+
+## Naming Conventions
+- <rule>
+
+## Code Style
+- <rule>
+
+## Testing
+- <rule>
+
+## Build & Deployment
+- <rule>
+
+## Data & State
+- <rule>
+
+## Security
+- <rule>
+
+## Dependencies
+- <rule>
+
+## Git Workflow
+- <rule>
+
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Only include sections that have real rules. Omit empty sections.

package/src/content/.agents/skills/pc-make-merge-risk-assess/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: pc-make-merge-risk-assess
+description: Generate or update the pc-merge-risk-assess skill from project guardrails and architecture. Produces a PR-level risk assessment that loop recipes can gate automerge on. Invoked by the /make-merge-risk-assess command and the repo-initialize flow.
+license: MIT
+---
+
+# Make Merge Risk Assess
+
+Analyze `ARCHITECTURE.md`, the project guardrails skill, and other project files to generate or update an `pc-merge-risk-assess` skill: a checklist of risk indicators that an AI agent evaluates before auto-merging a pull request. When any indicator matches, the agent blocks automerge and leaves the PR for human review with an explanation.
+
+## Steps
+
+1. **Check current state**
+
+   Read `.agents/skills/pc-merge-risk-assess/SKILL.md`. Determine which mode to use:
+   - Does not exist: Generate mode. Create from scratch.
+   - Exists and has a `<!-- Last updated:` footer: Update mode. Incrementally update.
+   - Exists but no timestamp: proceed in Generate mode (full regeneration).
+
+2a. **Generate mode: read source documents**
+
+   Read ALL of the following that exist:
+   - `.agents/skills/pc-guardrails-project/SKILL.md` (primary source — project-specific constraints)
+   - `.agents/skills/pc-guardrails-generic/SKILL.md` (generic safety rules)
+   - `ARCHITECTURE.md` (architecture boundaries, critical paths)
+   - `AGENTS.md` (non-negotiable constraints, verification rules)
+   - `.opencode/harness.json` (platform, concurrency)
+   - CI/CD workflows: `.github/workflows/*`, `azure-pipelines.yml`: whatever exists
+   - Loop recipes: `.loops/recipes/*-loop.yaml` (understand the automerge flow)
+
+   Use file tools to discover risk-critical code paths: `grep` for calculation engines, audit appenders, auth middleware, schema migrations, permission checks, and other sensitive areas.
+
+2b. **Update mode: incremental analysis**
+
+   Extract the `<!-- Last updated: <ISO date> -->` timestamp from the existing skill file. Then:
+   - Read `.agents/skills/pc-guardrails-project/SKILL.md` and check its `<!-- Last updated:` timestamp. If the guardrails haven't changed and ARCHITECTURE.md hasn't changed since the risk skill was last generated, report "Merge risk assessment up to date" and stop.
+   - Run `git log --oneline --since="<date>" -- <relevant config and architecture files>` to find what changed.
+   - If nothing changed: report "Merge risk assessment up to date" and stop.
+   - Update only the affected risk categories. Preserve manually-added risk indicators in unchanged categories.
+   - If changes are pervasive, fall back to Generate mode.
+
+3. **Extract risk indicators**
+
+   From the documents and code analysis, extract concrete, testable risk indicators. Follow the [category reference](category-reference.md) for the full list of categories, indicator quality standards, and the skill file template.
+
+   Each risk indicator must identify a code path or change pattern that, when touched, makes a PR too dangerous to auto-merge. The indicator must be something an AI agent can detect by reading the PR diff.
+
+4. **Write the skill**
+
+   Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md` using the template from the [category reference](category-reference.md). Only include sections that have real indicators. Omit empty sections.
+
+5. **Update agents**
+
+   For every `*-engineer.md` in `.opencode/agents/`, add `@pc-merge-risk-assess` to the Agent Workflow ability group (skip if already present). This ensures every engineer can evaluate risk before merge. Use this pattern:
+   ```markdown
+   ## Abilities
+   - Guardrails: @pc-guardrails-generic, @pc-guardrails-project[, ...existing entries unchanged]
+   ...
+   - Development, Agent Workflow: @pc-merge-risk-assess[, ...existing entries unchanged]
+   ```
+
+   If no "Development, Agent Workflow" line exists, create it. Exclude tier variant files (`*-engineer.build.md`, `*-engineer.fast.md`, `*-engineer.plan.md`): they are generated copies; only update the base templates.
+
+6. **Report**
+
+   Tell the user:
+   - Whether the skill was generated or updated (and which categories changed)
+   - Number of risk indicators extracted per category
+   - Number of agent files updated
+   - Tip: "Rerun `/make-merge-risk-assess` any time the architecture or project guardrails change significantly."

package/src/content/.agents/skills/pc-make-merge-risk-assess/category-reference.md

@@ -0,0 +1,98 @@
+# Merge risk assessment category reference
+
+From the project guardrails, architecture, and code analysis, extract concrete, testable risk indicators in these categories. Only include a category if you found real evidence for it.
+
+- **Calculation integrity**: changes to pricing, quoting, or calculation engines; modifications to formula inputs, salary tables, assumptions, or margin waterfalls. Any file under a calculation or quoting namespace is a risk indicator.
+- **Audit & compliance**: modifications to audit appenders, audit log storage, hash-chaining, or tamper-evident mechanisms. Any change that could affect regulatory traceability.
+- **Authentication & authorization**: changes to auth middleware, permission checks, role definitions, token issuance, or session management. Changes to `.RequirePermission()` calls or permission seed data.
+- **Data schema & migration**: EF Core entity changes, new migrations, column type changes, constraint additions/removals, or seed data modifications. Schema changes are always risky because they affect production data.
+- **Reference data versioning**: changes to effective-dated configuration, salary bands, assumptions, or any "magic number" that affects calculations. Changes to versioning or snapshot logic.
+- **Cross-boundary violations**: imports that break the layering direction (e.g. Domain referencing Application, Application referencing ASP.NET), cross-context data access bypassing ports.
+- **Security surface**: new endpoints without authorization, input validation removal, secrets exposure, dependency version downgrades, or changes to security scanning configuration.
+- **Financial correctness**: any change that could produce incorrect monetary values, incorrect tax calculations, incorrect currency handling, or rounding changes. Money is `decimal` — changes to precision or conversion logic are risk indicators.
+- **State machine transitions**: modifications to entity lifecycle transitions (e.g. quote status flow, approval gates, sign-off logic). Breaking a state machine can leave data in unrecoverable states.
+- **Integration contracts**: changes to external API contracts, webhook payloads, or CRM integration ports. Breaking integrations can cascade to downstream systems.
+
+Each indicator must be:
+- **Concrete**: "Changes to `QuoteCalculator.Calculate`" not "Changes to important calculations"
+- **Evidence-based**: derive from the project guardrails, architecture, and actual code paths
+- **Detectable**: an AI agent can find it by reading the PR diff (file paths, class names, method names, import changes)
+- **Exclusive**: do not duplicate indicators across categories — each belongs in its primary category
+
+## Skill template
+
+Write (or update) `.agents/skills/pc-merge-risk-assess/SKILL.md`:
+
+```markdown
+---
+name: pc-merge-risk-assess
+description: Evaluate a pull request for merge risk. Load when a loop recipe or agent needs to decide whether a PR is safe to auto-merge or requires human review. Produces a structured risk assessment with a binary outcome and reasoning.
+license: MIT
+---
+
+# Merge Risk Assessment
+
+> Auto-generated by `/make-merge-risk-assess`. Regenerate when architecture or guardrails change.
+
+## Purpose
+
+Determine whether a pull request is safe to auto-merge or requires human review. This skill is loaded by AI agents in loop recipes (e.g. `dev-assess-risk`) before merging. The agent inspects the PR diff and evaluates each risk indicator below.
+
+## Output contract
+
+On completion, produce a single JSON object on stdout:
+
+```json
+{"riskLevel":"safe"|"risky","reason":"<one-sentence explanation if risky, or 'No risk indicators detected' if safe>"}
+```
+
+- `riskLevel: "risky"` → exit non-zero. The loop recipe routes to the "leave for human review" path.
+- `riskLevel: "safe"` → exit zero. The loop recipe routes to the automerge path.
+
+## Risk indicators
+
+### Calculation Integrity
+- <indicator: file path, class, or method pattern>
+- <indicator>
+
+### Audit & Compliance
+- <indicator>
+
+### Authentication & Authorization
+- <indicator>
+
+### Data Schema & Migration
+- <indicator>
+
+### Reference Data Versioning
+- <indicator>
+
+### Cross-Boundary Violations
+- <indicator>
+
+### Security Surface
+- <indicator>
+
+### Financial Correctness
+- <indicator>
+
+### State Machine Transitions
+- <indicator>
+
+### Integration Contracts
+- <indicator>
+
+## Evaluation rules
+
+1. **Load `@pc-guardrails-project` first.** Every non-negotiable constraint in the project guardrails is a potential risk indicator. If a change violates or weakens any guardrail, the outcome is `risky`.
+2. **Inspect the full PR diff** using `gh pr diff <url>`. Do not guess based on the PR title or description alone.
+3. **Check each risk indicator** against the diff. A single matching indicator is sufficient to flag as `risky`.
+4. **When risky, explain why.** The `reason` field must name the specific indicator that matched and the files involved. Do not give vague explanations.
+5. **Do not second-guess the developer.** If the changes look intentional and no indicator matches, classify as `safe`. The purpose is to catch dangerous changes, not to block all non-trivial work.
+6. **Pure additions are lower risk.** New files, new endpoints with authorization, new tests, new UI components that don't touch existing critical paths are generally safe unless they introduce schema changes or cross-boundary imports.
+7. **Refactors within a single layer are generally safe.** Renaming, extracting methods, or reorganizing within the same bounded context and same architectural layer rarely triggers a risk indicator unless the refactor changes behavior.
+
+<!-- Last updated: <current ISO timestamp> -->
+```
+
+Only include sections that have real indicators. Omit empty sections and their headers.

package/src/content/.agents/skills/pc-make-user-model/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: pc-make-user-model
+description: Set the model for a tier (plan, build, or fast). Team-wide or user-local override. Invoked by the /make-user-model command.
+license: MIT
+---
+Set the concrete model for one tier. Writes to `models` in either the team config (shared, git-tracked) or a user-local override (gitignored).
+
+Usage:
+
+```
+/make-user-model <tier> <model>
+/make-user-model user <tier> <model>
+```
+
+- `user`: optional prefix. If present, writes to `.opencode/harness.user.json` (gitignored, overrides team config for this machine only). If absent, writes to `.opencode/harness.json` (shared with the team).
+- `<tier>`: one of `plan`, `build`, `fast`.
+- `<model>`: a fully-qualified model id (e.g. `opencode/big-pickle`) OR the keyword `current` to use the model active in this session.
+
+Arguments: `$ARGUMENTS`
+
+Steps
+
+1. Parse `$ARGUMENTS`** by whitespace.
+   - If first token is `user`: `isUser = true`, `<tier>` = second token, `<model>` = third token.
+   - Otherwise: `isUser = false`, `<tier>` = first token, `<model>` = second token.
+   - If `$ARGUMENTS` is empty: read both `.opencode/harness.json` and `.opencode/harness.user.json` and show the current `models` from each (team first, user override second), then show the usage above. Change nothing.
+   - If `<tier>` is not exactly one of `plan` / `build` / `fast`, or `<model>` is missing: print the usage and stop. Change nothing.
+
+2. **Resolve `<model>`:**
+   - If it is the literal `current`: use the model id visible in the opencode status line for this session. Use only the model id shown there, not a guessed value.
+   - Otherwise use the value verbatim. It must look like `provider/model-id`. If it contains no `/`, warn that it looks malformed and call the `question` tool to confirm before writing:
+
+     ```json
+     {
+       "questions": [
+         {
+           "header": "Malformed model id",
+           "question": "\"<model>\" doesn't look like a valid model id (expected provider/model-id). Write it anyway?",
+           "options": [
+             { "label": "yes", "description": "Write the value as-is to the config file." },
+             { "label": "no", "description": "Cancel. Do not write anything." }
+           ]
+         }
+       ]
+     }
+     ```
+
+     Only proceed to write if the user answers `yes`.
+
+3. Determine target file.
+   - `isUser = false` -> `.opencode/harness.json` (team). If it does not exist, stop and tell the user onboarding has not generated it yet.
+   - `isUser = true` -> `.opencode/harness.user.json` (user override). If it does not exist, create it with `{ "models": {} }`.
+
+4. Update the config. Read the target file, set `models.<tier>` to the resolved model id (create `models` if absent). Do not touch any other field. Preserve the existing 2-space JSON formatting, then write the file back.
+
+5. Confirm:
+
+   ```
+   <team|user> config updated
+     <tier> model -> <resolved-id>
+     file: <path written>
+   ```
+
+   Restart opencode for the change to take effect. The `pc-subagent-tiers` plugin reads the model configs at startup and injects tier-suffixed agent variants (`<engineer>.<tier>`) into the live config. After restart, `/plan-apply` will spawn agents on the new model.
+
+This command edits `harness.json` (team) or `harness.user.json` (user) only. It never modifies agent files, `opencode.json`, or `tasks.md`. Tier variants are generated in-memory by the `pc-subagent-tiers` plugin at startup: no file re-stamping needed.

package/src/content/.agents/skills/pc-ops-evidence/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: pc-ops-evidence
+description: Writes a capturePlan in evidence.json for the Visual Evidence CI workflow to execute on a runner with Docker and Chrome access. Load after a change is implemented. Invoked by /ops-evidence and the plan-goal pipeline.
+license: MIT
+---
+
+# Ops Evidence
+
+Write a capture plan so the Visual Evidence CI workflow can capture screenshots on a runner with full Docker and Chrome access.
+
+The agent runs inside the awf sandbox where Docker-in-Docker is unsupported and headless Chromium's sandbox is blocked by the container security policy. The agent cannot capture screenshots itself. Instead, it analyzes the diff and writes a `capturePlan` in `evidence.json`. A separate CI workflow executes the plan.
+
+## Convention
+
+Every platform project has `pnpm run dev` at root that starts the **full stack** (database + API + web). The app runs with mock auth in development mode (no real authentication needed). This is the only contract — no per-project evidence harness, fixture apps, or scenario registries.
+
+## Input
+
+The caller provides (all optional):
+- change id: locates `openspec/changes/{change-id}/` (or the archived `archive/*{change-id}/`).
+- issue / work-item ref and PR number: where to publish.
+- output mode (`default` / `push` / `pr`): whether the branch was pushed.
+- operation: `capture` (default), `publish`, or `both`.
+
+## Part 1: Capture (operation: capture / both)
+
+**Step 1: Decide whether evidence is required.** Inspect the change's diff:
+- Required when changed files include user-visible UI: `*.tsx/jsx/vue/svelte`, `*.css/scss/less`, pages, layouts, components, navigation.
+- Skipped when docs-only, internal refactor, dependency-only, test-only, backend-only.
+- Mixed or unknown: required (be safe).
+
+If skipped: write `evidence.json` with `status: "skipped"` and reason. Done.
+
+**Step 2: Discover routes from git diff.** Parse changed files to determine which routes to screenshot:
+- `pages/**/*.tsx` or `app/**/page.tsx` → extract the route path
+- `features/**/*.tsx` or `components/**/*.tsx` → screenshot the homepage and any routes that import the changed component
+- If no routes found → screenshot `/` only
+- Always include `/` (homepage) as a baseline
+
+**Step 3: Write `evidence.json` with `capturePlan`.** The agent never attempts to start the app stack or launch a browser — those always fail inside the awf sandbox. Instead, write a `capturePlan` immediately.
+
+### The `capturePlan` schema
+
+```
+capturePlan:
+  routes:           # Array of route objects to screenshot (at minimum [{ path: "/" }])
+    - path: string  # URL path, e.g. "/quotes/:id"
+      sampleId:     # string | "first" | "any" — how to resolve dynamic segments
+      caption:      # string — human-readable description of what this screenshot shows
+  viewports:        # Array of viewport objects
+    - width: number
+      height: number
+      label: string # "desktop" | "mobile" | custom
+  requireApi:       # boolean — true when the route needs the backend API running
+  requireLogin:     # boolean — true when the route needs authentication
+  loginMethod:      # string — "mock-sso" | "none" | custom method identifier
+  reason:           # string — why evidence was blocked and what the screenshots should show
+```
+
+### Rules for writing capturePlan
+
+1. `routes` MUST always include `{ path: "/", caption: "Homepage" }` as the first entry.
+2. Every additional route discovered from the diff goes after the homepage entry.
+3. `sampleId: "first"` means the CI workflow should use the first record returned by the API (e.g. the first quote from the seed data). `sampleId: "any"` means any valid ID.
+4. `requireApi` is `true` when any route needs the backend to return data. It is `false` only for purely static pages (login, not-found).
+5. `requireLogin` is `true` when any route needs authentication. For dev mode with mock auth, `loginMethod` is `"mock-sso"`.
+6. `reason` should explain both WHY capture was blocked and WHAT the screenshots should show once captured.
+
+### Example `evidence.json`
+
+```json
+{
+  "version": 1,
+  "changeId": "currency-in-project-details",
+  "required": true,
+  "status": "blocked",
+  "assets": [],
+  "capturePlan": {
+    "routes": [
+      { "path": "/", "sampleId": "any", "caption": "Homepage / accounts list" },
+      { "path": "/quotes/:id", "sampleId": "first", "caption": "Quote editor with currency selector in ProjectDetailsCard" }
+    ],
+    "viewports": [
+      { "width": 1280, "height": 720, "label": "desktop" },
+      { "width": 375, "height": 667, "label": "mobile" }
+    ],
+    "requireApi": true,
+    "requireLogin": true,
+    "loginMethod": "mock-sso",
+    "reason": "Currency selector moved from editor body into ProjectDetailsCard; visual change in quote editor page."
+  },
+  "reason": "Visual evidence cannot be captured inside the awf sandbox (Docker-in-Docker unsupported, headless Chromium sandbox blocked). A capturePlan has been written for the Visual Evidence CI workflow.",
+  "prMarkdown": "## Evidence\n\nVisual evidence for this change is **blocked** in this agent run. A `capturePlan` has been written to `evidence.json` — the Visual Evidence CI workflow will execute it on a runner with full Docker and Chrome access.\n\nAutomated verification that did run:\n- Lint: clean\n- Tests: all pass\n- Build: success"
+}
+```
+
+### When evidence is not required
+
+If evidence is skipped (no UI files changed), write without a `capturePlan`:
+
+```json
+{
+  "version": 1,
+  "changeId": "{change-id}",
+  "required": false,
+  "status": "skipped",
+  "assets": [],
+  "reason": "No user-visible UI files changed in this PR.",
+  "prMarkdown": "## Evidence\n\nSkipped: no user-visible UI changes."
+}
+```
+
+Capture never commits, stages, or pushes. The caller owns git.
+
+## Part 2: Publish (operation: publish / both)
+
+Preconditions:
+- An issue/PR number was provided. Else skip.
+- Image URLs resolve only if the branch was pushed (`pr`/`push` modes).
+- Backlog platform from `.opencode/harness.json`; `none` means skip.
+
+<!-- PC-PLATFORM-EVIDENCE-START -->
+<!-- PC-PLATFORM-EVIDENCE-END -->
+
+## Report
+
+One block: the `status` (passed/skipped/failed/blocked) and why; capturePlan written or why not. Never present a blocked capture as passed.

package/src/content/.agents/skills/pc-ops-ship/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: pc-ops-ship
+description: Create a pull request for the current feature branch, with screenshots if UI changed. Load when shipping a finished feature branch. Invoked by the /ops-ship command and the plan-goal pipeline (pr mode).
+license: MIT
+---
+
+# Ops Ship
+
+## Input
+
+The caller provides (all optional):
+- PR title and body. When absent, derive them from the change context (change id, tasks completed, commit list).
+- The base branch. When absent, resolve the default branch as shown in the platform steps below.
+
+Repo platform is set in `.opencode/harness.json` `platform.repo`. The platform-specific content below is injected by the CLI during onboarding.
+
+<!-- PC-PLATFORM-SHIP-START -->
+<!-- PC-PLATFORM-SHIP-END -->

package/src/content/.agents/skills/pc-plan-apply/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: pc-plan-apply
+description: Implement tasks from a plan. OpenSpec-annotated tasks (from pc-plan-propose) run as parallel subagent waves; Todo pane tasks (from /plan-quick) run sequentially in-session. Load when implementing a prepared plan. Invoked by the /plan-apply command (interactive) and the plan-goal pipeline (autonomous).
+license: MIT
+---
+
+# Plan Apply
+
+## Input
+
+The caller provides (all optional):
+- A mode (see below). Default: `interactive`.
+- A `start_from` hint: `branch` (default, full protocol from step 1) or `load-plan` (the caller already created the feature branch; skip step 1).
+
+## Modes
+
+- `interactive` (default): report progress to the user and surface failures for their decision.
+- `autonomous`: do not return control between waves; keep looping until every task is DONE or the progress guard / retry limit trips. On a stall or exhausted retry, stop the wave loop and report to the caller (whose failure policy governs). When all tasks are DONE, the APPLY stage is complete. Hand control back to the caller (the `/plan-goal` pipeline) so it continues with the next phase. Do not end the turn here; "report N/N tasks" is a stage boundary, not a finish line.
+
+## Plan source detection
+
+1. Check if an OpenSpec change exists: inspect `openspec/changes/` for an active change folder with a `tasks.md`.
+2. If found and tasks have `<!-- agent` annotations (written by `pc-plan-propose`): OpenSpec mode. Follow the protocol below. Annotated tasks run in subagent waves. They never become sequential lead work because the task count seems small, the lead prefers direct implementation, or a worker has not yet been inspected.
+3. If no OpenSpec change exists, but there are `pending` items in the Todo pane (from `/plan-quick`): Simple mode. Follow the [simple mode](simple-mode.md) reference.
+
+## OpenSpec mode: parallel subagent waves
+
+Load `@openspec-apply-change` skill and follow its instructions, replacing Step 6 (Implement) with the protocol below.
+
+**Step 6: Implement via native subagent waves. Replace the default step 6 with this protocol.**
+
+You are the lead. You orchestrate from this session only; you spawn workers with the native `task` tool. Workers are ephemeral (one batch, then they exit) and navigable (`ctrl+x` arrow down, left/right arrows). There is no board, no claiming, no merging, no external dashboard.
+
+Core rule: push, don't pull. A worker is born with its work: every `task()` spawn prompt contains the exact task IDs and text it must do. There is no claim step, so a worker can never sit idle waiting for an assignment.
+
+**1. Branch.** Create `feature/{change-slug}` if not already on one. (Skip this step when the caller passed `start_from: load-plan`.)
+
+**2. Load the plan and workers.** Parse `tasks.md`. Each task carries `<!-- agent, depends_on, touches -->` (from `pc-plan-propose`). Inspect `.opencode/agents/` for each base engineer and its generated `.<tier>.md` variants. The tier-suffixed name in an annotation (for example, `backend-engineer.build`) is the worker to spawn: `pc-subagent-tiers` resolves its model at startup and registers it as `mode: subagent`. Read `.opencode/harness.json` -> `agents.maxConcurrent` (the wave cap, 1 to 5).
+
+Before hydrating the Todo board, resolve every task's annotated worker. If any task has a blank agent annotation, its base template is missing, or its tier variant is unavailable, stop the APPLY stage and report the task ID, expected worker, and missing file. Do not replace the worker with `fullstack-engineer`, `general`, or the lead session.
+
+**3. Hydrate the Todo board.** `todowrite` one item per task: `pending`. The Todo pane is the visible subagent board (opencode plugins cannot draw a custom pane, so the native Todo widget is the live UI). While a task is in flight, its label must carry the worker: `<agent> · <model>`: so the pane shows which agent on which model is doing what. The Todo list is a projection only: never read it for recovery; rebuild it from `tasks.md` and git and `.opencode/harness-run.json`.
+
+**4. Worker context.** Before each wave, derive file-disjointness from `touches:` globs and `git diff`.
+
+<!-- PC-OPTIMIZATION-CODEGRAPH-START -->
+<!-- PC-OPTIMIZATION-CODEGRAPH-END -->
+
+<!-- PC-OPTIMIZATION-MEMORY-START -->
+<!-- PC-OPTIMIZATION-MEMORY-END -->
+
+**5. The wave loop.** Repeat until no tasks remain:
+
+```
+eligible = unchecked tasks whose every depends_on is DONE (committed/checked)
+if eligible is empty but tasks remain  -> STALL: report blocked tasks + the failed
+                                           dependency causing it, then STOP.
+groups   = pack eligible tasks that share a file (touches and gathered context)
+            into ONE worker each, to run sequentially (the worker uses the task's `agent`)
+wave     = pick groups whose file-sets are pairwise DISJOINT, capped at maxConcurrentAgents
+            (you enforce the cap: opencode runs every task() you emit at once)
+```
+
+**6. Context per group.** For each group, gather the task text, relevant plan decisions, and source context needed to implement it.
+
+**7. Spawn the wave: one assistant turn, multiple `task()` calls (they run in parallel).** For each group:
+- `subagent_type` = the task's `agent` exactly as written in `tasks.md` (e.g. `frontend-engineer.build`, `backend-engineer.fast`). It is the tier-suffixed `mode: subagent` worker created by `pc-subagent-tiers`. Worker resolution happened in step 2; a missing worker stops the stage before spawning. `fullstack-engineer`, `general`, and the lead session are not fallbacks for annotated implementation work.
+- `description` = `"<task-ids>: <short label>"` (e.g. `"2.1,2.2: RPC endpoints"`) so the subagent is legible in the left/right list and the monitor.
+- `prompt` must contain the exact task IDs and text plus the gathered context. The worker follows the Engineer workflow defined in `@pc-guardrails-generic`; do not restate it in the prompt. **Worker output discipline:** instruct each worker to return a compact summary: what it changed (file names, not contents), pass/fail status of any verification it ran, and any blockers. Workers must NOT return file contents or full diffs as their result — the lead can `git diff` if needed.
+- Flip each spawned task's Todo item to `in_progress` and prefix its label with `<agent>: ` (e.g. `frontend-engineer.build: 2.1 Consolidate logic`) so the running worker is visible in the Todo pane. On completion, drop the prefix and mark `completed`.
+
+**8. Collect the wave.** Each foreground `task()` returns its result to you. For each group:
+- success: `git add` the group's `touches` paths and commit `"{ids}: {summary}"` in a single tool call (`git add <paths> && git commit -m "..."`); mark its Todo items `completed`; check `[x]` in `tasks.md`.
+- error / empty: revert that group's impact: `git checkout -- <tracked paths> && git clean -f -- <paths>` (one tool call). Mark `failed` and record the reason in `tasks.md`; `.opencode/harness-run.json` is owned by the monitor plugin. Then retry once with a shorter prompt. Still failing: leave failed and surface it; do not loop.
+- A failed group only blocks its dependents; unrelated tasks keep flowing.
+
+**9. Progress guard.** If a full wave moved zero tasks to DONE: STOP (do not re-spawn the identical failing set). Otherwise recompute `eligible` and loop to step 5.
+
+**10. Verify.** In this (lead) session, run the project's lint, typecheck, test, build, and proposal-required validation commands. Every command must exit 0. On failure, reopen the offending tasks (uncheck, mark failed) so they re-enter `eligible` and run another wave. When every task is checked, no eligible task remains, and every command passes, report `VERIFIED` to the caller.
+
+**11. Close.** Mark all `tasks.md` checkboxes, run `openspec status --change "<name>" --json`, and report progress (N/M tasks). The wave state in `.opencode/harness-run.json` persists for resume.
+
+Resume: re-loading this skill after any crash recomputes DONE / FAILED / eligible from `tasks.md`, git, and `harness-run.json` and continues. State is on disk, not in this conversation.