@webpresso/plugin-opencode 0.0.4

package/skills/fix/SKILL.md

@@ -0,0 +1,174 @@
+---
+type: skill
+slug: fix
+title: Fix
+status: active
+scope: repo
+applies_to: [agents]
+related: [verify, testing-philosophy]
+created: "2026-05-13"
+last_reviewed: "2026-07-21"
+name: fix
+description: "Root-cause fix workflow that runs investigate first when diagnosis or failing proof is still missing."
+argument-hint: '<target> where target is: file|symptom|error|test|"free-text description"'
+---
+
+# Fix Command
+
+Fix the issue at its root, future-proof, aligned with repo philosophy.
+
+**Arguments**: $ARGUMENTS
+
+This command turns "please fix it well" into an enforceable workflow: diagnose
+first, repair at the owner, prove the repair, and escalate to `/verify` when
+the blast radius is broader than a local fix.
+
+## Tooling map
+
+| Need                   | Prefer                                                                      |
+| ---------------------- | --------------------------------------------------------------------------- |
+| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`, `wp_session_execute_file` |
+| Recall prior evidence  | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve`            |
+| Capture decisions      | `wp_session_capture` (do not paste full reports back as user text)          |
+| Scoped proof           | `wp_test`, `wp_lint`, `wp_typecheck`, or `wp_qa`                            |
+| Audits                 | `wp_audit` / `wp_audits`                                                    |
+| Worktree isolation     | `wp_blueprint_put` / `wp_worktree` — never thrash primary checkout          |
+| PR follow-up           | `wp_pr_status`, `wp_pr_upsert` when landing the fix                         |
+
+## Non-negotiable invariants
+
+1. **Root cause, not symptom.** Trace the failure to the invariant that actually broke. Do not patch callers when the owner is fixable.
+2. **Loud failures, no silent fallbacks.** No default shims, sentinel returns, or catch-and-continue behavior that hides missing config, bad state, or broken boundaries.
+3. **Use the repo's real execution surface.** Prefer MCP `wp_*` tools and repo wrappers over host Bash for search/test/lint. Use bounded session-memory paths for large output.
+4. **Regression proof is mandatory.** Add or strengthen a test or other reliable proof that would fail against the old behavior.
+5. **Raising timeouts is not a fix.** If a timeout fires, investigate the bottleneck. Only raise a bound when the repo already documents that workload and you can cite measurement.
+6. **Zero suppressions, zero papering over.** No lint disables, ts-ignore, compat aliases, or "temporary" branches to sneak the fix through.
+7. **Minimal correct diff.** Update every consumer of a changed contract in the same change, but do not bundle unrelated cleanup.
+8. **Primary checkout is sacred.** If HEAD is detached, primary is dirty with unrelated work, or you are not on a managed worktree for non-trivial edits → **stop** and move to `wp_worktree` / blueprint owner. Never leave the primary checkout broken.
+
+## Opportunistic fix budget (when called from ultragoal / autopilot)
+
+- At most **`fix_budget` (default 1)** pre-existing issues per controller phase.
+- Each must have: named invariant, failing proof, owning path.
+- If the repair needs its own blueprint or expands epic scope → **handoff backlog**, do not inline.
+- Additional discoveries: list in the final report; do not thrash.
+
+## Protocol
+
+### Step 0a — Worktree preflight
+
+Before editing: confirm you are on a managed worktree or an explicitly allowed branch.
+If the primary checkout is dirty/detached with unrelated state, stop and isolate first.
+
+### Step 0 — Run the investigate phase when evidence is missing
+
+Before editing, check whether the current context already contains all of the
+following:
+
+- a named root-cause hypothesis
+- a failing proof tied to that hypothesis
+- the owning boundary that should be repaired
+
+If any of those are missing, run the `investigate` phase inline first:
+
+- reproduce or capture the failure
+- read the full error site and one nearby working pattern
+- disconfirm cheap alternative explanations
+- produce failing proof
+- stop only when you can name the broken invariant and owner
+
+Do not skip this phase because the fix "looks obvious". If the evidence is not
+there, the investigation work is part of `fix`.
+
+### Step 1 — Reproduce and name the broken invariant
+
+- Run the exact command, test, or user flow that surfaces the failure.
+- Capture the evidence that matters: error text, file:line, exit code, failing assertion, or log path.
+- Read enough surrounding code to say the broken invariant in one sentence.
+- If the issue is nondeterministic, gather evidence until you can describe the slow/flaky/failing case without guessing.
+
+If the "issue" is actually several unrelated failures, stop and ask which one to fix first.
+
+### Step 2 — Decide where the fix belongs
+
+State briefly:
+
+- the broken invariant
+- the owner that should enforce it
+- whether the fix changes a public contract
+- which direct consumers must change in the same diff
+
+If the blast radius is broader than the owner + direct consumers, keep going with `/fix` only if the change is still one coherent repair. If the work becomes a broader hardening pass, plan a `/verify` handoff before claiming done.
+
+### Step 3 — Write failing proof first when feasible
+
+- For a reproducible bug, write or strengthen the smallest regression test that fails on the old behavior.
+- Verify that it fails for the right reason before changing production code.
+- If test-first is genuinely infeasible at that boundary, record why and create the nearest reliable proof instead (for example a deterministic integration reproduction, fixture, or logged command).
+
+Do not keep production code written before the test as "reference". If you wrote code first, throw it away and restart from the failing proof.
+
+### Step 4 — Implement the minimal correct fix
+
+- Edit the file or module that owns the invariant.
+- Update every changed consumer in the same diff. No half-migrations.
+- Delete compat shims, dead aliases, and TODO branches made obsolete by the repair.
+- Keep complexity down by extracting helpers instead of nesting conditionals.
+
+### Step 5 — Run scoped verification
+
+Run the narrowest checks that prove the repaired behavior on the real repo surface:
+
+- `wp_test` / targeted tests for the repaired path
+- `wp_lint` / `wp_typecheck` for changed surfaces
+- `wp_qa` only when the blast radius needs the bookend
+- Before push: `wp_ci_preflight` (use global `wp ci-preflight` only when MCP is
+  unavailable). Do not use remote CI
+  re-runs as the primary fix loop (`ci-cost-local-first`).
+
+Rules:
+
+- Prefer MCP `wp_*` over raw host Bash.
+- Reuse fresh logs / session-memory indexed output; do not re-run long commands just to re-read.
+- Read the exit code and summary before making a claim.
+- Never `git push --no-verify` to land an unproven fix.
+
+Escalate to `/verify <target>` (local) or `/verify <target> --merge-ready` when any of these are true:
+
+- the fix crosses packages
+- the fix changes a public or shared contract
+- the fix touched docs, plans, blueprints, or repo SSOT
+- the fix needs dead-code / compat / broad regression review before claiming done
+
+If the repaired behavior is already green but the diff still needs a bounded
+cleanup pass, use `ai-deslop` before the final verify handoff.
+
+### Step 6 — Report with evidence
+
+Keep it short:
+
+- what invariant broke
+- how the change restores it
+- what proof ran (tests, commands, log paths, exit codes)
+- adjacent issues noticed but intentionally not fixed
+
+## Done looks like
+
+- [ ] Root cause named in one sentence
+- [ ] Fix applied at the owning boundary
+- [ ] Regression proof fails against the old behavior
+- [ ] Minimal code change restores the invariant
+- [ ] Scoped verification passed on the changed surface
+- [ ] `/verify` handoff used when blast radius exceeded a local fix
+- [ ] Report cites evidence, not intent
+
+## Anti-patterns this command refuses
+
+- Fixing the nearest symptom while leaving the real invariant broken
+- Catching an error and returning a sentinel to "keep things moving"
+- Raising a timeout, retry count, or polling interval instead of finding the bottleneck
+- Adding a deprecated alias instead of updating consumers
+- Introducing `any`, suppressions, or lint disables to unblock the fix
+- Bundling unrelated refactors with the repair
+- Claiming done from intuition, partial output, or another agent's success message
+- Writing a planning/doc artifact when the user asked for a fix

package/skills/grok/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: grok
+description: "Grok outside-voice review."
+license: MIT
+---
+
+Use for bounded Grok Build outside-voice review.
+
+- One bounded review invocation per request.
+- No fan-out, probe, retry, account rotation, or provider switch unless the user sets `review_budget`/`N` > 1.
+- Use `wp_review_run` unless MCP is unavailable.
+- Grok review is prompt-only: gather diff excerpts and verification yourself;
+  pass that supplied artifact to Grok.
+- Call `wp_review_run` exactly once with `repository_access: "none"`. The runtime
+  owns the empty execution workspace.
+- The prompt must say "supplied artifact text only", "do not inspect a
+  workspace", "do not announce future work", and require a final `VERDICT:` line.
+
+```jsonc
+{
+  "prompt": "You are doing a bounded advisory code review of the supplied artifact text only. Do not inspect a workspace. Do not announce future work. <diff excerpts + verification + questions>. Final line must start with VERDICT:",
+  "provider": "grok",
+  "repository_access": "none",
+  "skipProbe": true,
+  "stage": "review",
+  "expectedMarker": "VERDICT:",
+}
+```
+
+`wp_review_gate` is plan-only exact-version draft approval/auto-promotion.
+Implementation/phase review uses advisory `wp_review_run` and never mutates
+blueprint approval state. CLI delivery gates are MCP-unavailable compatibility only.

package/skills/hooks-doctor/SKILL.md

@@ -0,0 +1,78 @@
+---
+type: skill
+slug: hooks-doctor
+title: Hooks Doctor
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-05-07"
+name: hooks-doctor
+description: "Webpresso hook/plugin doctor: verify install health and debug broken hooks or plugin integration."
+argument-hint: "[--skip-mcp]"
+allowed-tools:
+  - Bash
+---
+
+# Hooks Doctor
+
+Verify the webpresso plugin hooks installation is healthy. Run this first when:
+
+- A hook seems not to be firing
+- The plugin was just installed or updated
+- Claude Code can't find expected tools
+- Any plugin integration issue arises
+
+## Running the Check
+
+Run the doctor command directly:
+
+```
+wp hooks doctor
+```
+
+Or skip the MCP server check (for CI environments):
+
+```
+wp hooks doctor --skip-mcp
+```
+
+## Interpreting Results
+
+Each check prints `[x]` (pass) or `[ ]` (fail) with a detail line:
+
+```
+[x] pretool-guard
+[x] post-tool (lint-after-edit)
+[x] stop (qa-changed-files)
+[x] guard-switch
+[x] sessionstart
+[x] test-quality-check
+[x] plugin.json integrity
+[x] MCP server liveness: MCP server already running (sentinel found)
+```
+
+## Failure Remediation
+
+| Check                                            | Likely Cause                                                   | Fix                                                               |
+| ------------------------------------------------ | -------------------------------------------------------------- | ----------------------------------------------------------------- |
+| `pretool-guard` / `post-tool` / etc. — not found | `wp run build` not run after install                           | `wp run build`                                                    |
+| `pretool-guard` / etc. — not executable          | `chmod +x` not persisted                                       | Re-run `wp run prepare` or `wp run build` which runs `chmod-bins` |
+| `plugin.json integrity` — missing                | Claude adapter manifest absent from `@webpresso/plugin-claude` | Re-run `wp setup --host claude` or reinstall the Claude plugin    |
+| `MCP server liveness` — timeout                  | MCP server cold-start too slow                                 | Wait and retry, or run `wp hooks doctor --skip-mcp`               |
+| Any check — not found at `dist/esm/...`          | Build artifacts missing                                        | Run `wp run build` in the webpresso repo                          |
+
+After fixing, re-run `wp hooks doctor` to confirm.
+
+## How It Works
+
+The doctor runs five categories of checks:
+
+1. **Bin existence** — each hook binary exists at the expected `dist/esm/hooks/...` path
+2. **Executable bit** — bins have execute permission (skipped on Windows)
+3. **stdin response** — interactive hooks (`pretool-guard`, `guard-switch`, `sessionstart`) respond to `{}` input with valid JSON and exit 0; fire-and-forget hooks (`lint-after-edit`, `qa-changed-files`) exit 0
+4. **plugin.json integrity** — adapter manifest exists, has required fields, and all referenced bins exist on disk
+5. **MCP server liveness** — spawns the MCP server and sends a `tools/list` JSON-RPC request; times out at 5s (soft-fail — warning only, does not fail the overall check)
+
+If `isMcpReady()` detects a live MCP sentinel, the MCP check fast-passes without spawning.

package/skills/investigate/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: investigate
+description: "Root-cause investigation workflow: reproduce, isolate, prove, and hand off the minimal repair scope."
+license: MIT
+---
+
+# Investigate
+
+Use this skill when the task is to understand a bug, failure, regression,
+flaky behavior, or confusing symptom before editing code.
+
+## Boundary
+
+- `investigate` owns diagnosis, reproduction, hypothesis testing, and proof.
+- `fix` owns repair. If the user asked to fix the problem and root-cause
+  evidence is still missing, `fix` should run this phase inline first.
+- Stop once you can name the broken invariant, show the failing proof, and
+  point at the owner that should be repaired.
+
+## Tooling map
+
+| Need                   | Prefer                                                           |
+| ---------------------- | ---------------------------------------------------------------- |
+| Reproduce / large logs | `wp_session_execute`, `wp_session_batch_execute`                 |
+| Large files            | `wp_session_execute_file`                                        |
+| Prior continuity       | `wp_session_search`, `wp_session_restore`, `wp_session_retrieve` |
+| Capture findings       | `wp_session_capture` (short pointer, not full paste-back)        |
+| Proof runs             | `wp_test`, `wp_qa`, `wp_lint`, `wp_typecheck`                    |
+| Code search/read       | host Grep/Read first; avoid shell-as-IDE                         |
+
+## Workflow
+
+1. Reproduce or capture the failure.
+   - Run the exact failing command or trace the exact user path (prefer `wp_session_execute`).
+   - Keep the evidence that matters: error text, failing assertion, exit code,
+     log path, or boundary mismatch.
+2. Read the whole boundary.
+   - Inspect the full error site, the owning module, and one nearby working
+     pattern.
+   - Do not edit code yet.
+3. State the root-cause hypothesis.
+   - Name the broken invariant in one sentence.
+   - Name the owner that should enforce it.
+   - Separate facts from guesses.
+4. Disconfirm cheap alternatives.
+   - Test the obvious competing explanations before settling on one cause.
+   - Add temporary diagnostics only when needed, and remove them after one pass.
+5. Produce failing proof.
+   - Prefer a targeted failing test.
+   - If test-first is impossible at this boundary, use the nearest deterministic
+     reproduction instead.
+6. Hand off the minimal repair scope.
+   - List the owner, direct consumers, and the smallest safe verification set.
+   - If the issue is broader than one coherent repair, say so before any edit.
+
+## Output
+
+Return:
+
+- reproduced symptom
+- broken invariant
+- root-cause hypothesis status: confirmed / likely / blocked
+- failing proof
+- owning file or boundary
+- recommended next step: `fix`, `verify`, or a scoped blocker
+
+## Anti-patterns
+
+- Editing before you can name the invariant
+- Treating a stack trace as proof of root cause
+- Hiding uncertainty behind broad "probably X" explanations
+- Expanding a debugging pass into cleanup or refactor work

package/skills/lore-protocol/SKILL.md

@@ -0,0 +1,84 @@
+---
+type: skill
+slug: lore-protocol
+title: lore-protocol
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-05-07"
+name: lore-protocol
+description: "Manual Lore commit-message trailers with wp audit commit-message; no hook enforcement because PRs squash."
+---
+
+# lore-protocol
+
+Use Lore commit-message trailers manually with `wp audit commit-message`. Hook enforcement is intentionally not installed because this repo uses squash commits.
+
+Lore is a lightweight protocol for embedding decision context directly into
+commit messages — constraints, rejected alternatives, confidence, and
+forward-looking directives — so future engineers understand _why_ a change
+was made, not just _what_ changed.
+
+## Quick start
+
+```bash
+# Validate a commit message file (hard-fail mode — exits non-zero on violations)
+wp audit commit-message --message-file .git/COMMIT_EDITMSG --require-lore
+
+# Soft-warn mode — emits warnings but always exits 0 (adoption ramp)
+wp audit commit-message --message-file .git/COMMIT_EDITMSG --lore-warn
+
+# Opt in per-commit by adding [lore] to the subject line:
+# feat(auth): prevent silent session drops [lore]
+```
+
+## Hook policy
+
+Lore trailers are advisory/manual. Do not install commit-msg or pre-push hooks for Lore enforcement; squash commits are the durable review boundary.
+
+## Trailer format
+
+```
+<intent line: why the change was made, not what changed>
+
+<body: narrative context — constraints, approach rationale>
+
+Constraint: <external constraint that shaped the decision>
+Rejected: <alternative considered> | <reason for rejection>
+Confidence: <low|medium|high>
+Scope-risk: <narrow|moderate|broad>
+Directive: <forward-looking warning for future modifiers>
+Tested: <what was verified>
+Not-tested: <known gaps in verification>
+```
+
+## Required trailers (for `--require-lore` or `[lore]` subject tag)
+
+| Trailer                                      | Required     | Allowed values                   |
+| -------------------------------------------- | ------------ | -------------------------------- |
+| `Confidence:`                                | yes          | `low`, `medium`, `high`          |
+| `Constraint:` or `Rejected:` or `Directive:` | at least one | free text                        |
+| `Scope-risk:`                                | optional     | `narrow`, `moderate`, `broad`    |
+| `Reversibility:`                             | optional     | `clean`, `messy`, `irreversible` |
+| `Tested:`                                    | optional     | free text                        |
+| `Not-tested:`                                | optional     | free text                        |
+| `Related:`                                   | optional     | free text                        |
+
+## Example commit
+
+```
+Prevent silent session drops during long-running operations
+
+The auth service returns inconsistent status codes on token
+expiry, so the interceptor catches all 4xx responses.
+
+Constraint: Auth service does not support token introspection
+Rejected: Extend token TTL to 24h | security policy violation
+Confidence: high
+Scope-risk: narrow
+Directive: Error handling is broad — do not narrow without verifying upstream behavior
+Tested: Single expired token refresh (unit)
+Not-tested: Auth service cold-start > 500ms behavior
+```

package/skills/opencode-go/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: opencode-go
+description: "OpenCode Go aggregate outside-voice reviewer for read-only plan, code, or implementation critique."
+license: MIT
+---
+
+# OpenCode Go aggregate reviewer via OpenCode Go
+
+Use when the user asks for an OpenCode Go aggregate reviewer / OpenCode Go review. Treat output as external advice until independently verified.
+
+## Model routing
+
+Rendered from the committed OpenCode reviewer policy. It does not hardcode model IDs; it resolves the live `opencode models opencode-go` catalog.
+Use the aggregate reviewer when the user wants an OpenCode Go review but did not specify a family. Select one available model in this order: Kimi K2.7 Code for coding quality, DeepSeek V4 Pro for deeper review depth, DeepSeek V4 Flash for cheap/high-availability coverage, then the remaining families.
+Use the aggregate reviewer for general outside-voice plan critique, implementation review, or when the user wants the current best OpenCode Go lane without naming a family.
+
+## Primary path: MCP
+
+When MCP is available, call `wp_review_run` exactly once with provider `opencode`, one selected live model, stage `review`, and a bounded prompt/marker. If no eligible model is known, call `wp_session_execute` at most once for a bounded catalog read before that single review call.
+
+Do not retry or probe, rotate accounts, or change provider within the invocation. The shell blocks below are the MCP-unavailable fallback only.
+
+## MCP-unavailable fallback: auth check
+
+```bash
+opencode providers list >/dev/null
+```
+
+## MCP-unavailable fallback: portable prompt file
+
+```bash
+PROMPT_FILE=$(mktemp -t wp-opencode-go-review.XXXXXX)
+trap 'rm -f "$PROMPT_FILE"' EXIT
+```
+
+## Dashboard helper relation
+
+When `wp dash` provides dashboard context, use the shared helper emitter around this outside-voice review. The commands leave standalone OpenCode Go reviews unchanged.
+
+```bash
+DASH_HELPER_RUN_ID=""
+if [ "${WP_DASH:-}" = "1" ] && [ -n "${WP_DASH_RUN_ID:-}" ]; then
+  DASH_HELPER_RUN_ID=$(wp dash-helper-start --provider opencode-go --role reviewer --artifact "${OPENCODE_GO_REVIEW_ARTIFACT:-}")
+fi
+```
+
+After the review runtime exits, record its actual result and optional artifact:
+
+```bash
+OPENCODE_GO_REVIEW_CODE=$?
+if [ -n "$DASH_HELPER_RUN_ID" ]; then
+  if [ "$OPENCODE_GO_REVIEW_CODE" -eq 0 ]; then
+    wp dash-helper-complete --provider opencode-go --run-id "$DASH_HELPER_RUN_ID" --role reviewer --outcome completed --artifact "${OPENCODE_GO_REVIEW_ARTIFACT:-}"
+  else
+    wp dash-helper-complete --provider opencode-go --run-id "$DASH_HELPER_RUN_ID" --role reviewer --outcome failed --artifact "${OPENCODE_GO_REVIEW_ARTIFACT:-}"
+  fi
+fi
+```
+
+The managed OpenCode plugin currently has no parent-linked native subagent completion lifecycle. This capability is explicit unsupported coverage, not an inferred dashboard relation.
+
+## MCP-unavailable fallback: review command
+
+Use read-only prompts. Run from the repo directory; do NOT pass `--dir "$PWD"` because opencode already uses the current directory and the extra index can stall reviews.
+Review is advisory. `wp_review_gate` is plan-only exact-version draft approval/auto-promotion; `wp_review_run` never mutates approval state.
+
+```bash
+# Aggregate reviewer: honor the canonical model-selection policy (Kimi K2.7 Code → DeepSeek V4 Pro → DeepSeek V4 Flash first, then cross-family selection fallbacks).
+CATALOG=$(opencode models opencode-go)
+MODEL=$(echo "$CATALOG" | grep '^opencode-go/kimi' | grep -- '-code$' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/deepseek' | grep -- '-pro$' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/deepseek' | grep -- '-flash$' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/qwen' | grep -- '-max$' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/glm' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/minimax' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | grep '^opencode-go/mimo' | grep -- '-pro$' | sort -V | tail -1)
+[ -z "$MODEL" ] && MODEL=$(echo "$CATALOG" | sort -V | tail -1)
+
+# Resolve one model from one bounded catalog read, then launch one review.
+[ -n "$MODEL" ] || { echo "No OpenCode Go model resolved for this reviewer." >&2; exit 2; }
+OPENCODE_GO_REVIEW_EFFORT=${OPENCODE_GO_REVIEW_EFFORT:-medium}
+[ "$OPENCODE_GO_REVIEW_EFFORT" = medium ] || [ "$OPENCODE_GO_REVIEW_EFFORT" = high ] || { echo "OPENCODE_GO_REVIEW_EFFORT must be one of: medium, high" >&2; exit 2; }
+OPENCODE_GO_REVIEW_IDLE_SECONDS=${OPENCODE_GO_REVIEW_IDLE_SECONDS:-180}
+OPENCODE_GO_REVIEW_ARTIFACT_ROOT=${OPENCODE_GO_REVIEW_ARTIFACT_ROOT:-"$(pwd)/.webpresso/reviews"}
+wp review run \
+  --provider opencode \
+  --prompt-file "$PROMPT_FILE" \
+  --model "$MODEL" \
+  --effort "$OPENCODE_GO_REVIEW_EFFORT" \
+  --stage review \
+  --artifact-root "$OPENCODE_GO_REVIEW_ARTIFACT_ROOT" \
+  --idle-seconds "$OPENCODE_GO_REVIEW_IDLE_SECONDS"
+```
+
+The single catalog read above resolves `$MODEL`; do not perform another model-catalog command.
+The typed runtime advances its idle clock only on monotonic semantic progress and has no total wall-clock cutoff.
+OpenCode Go usage limit ends all OpenCode models this review (no family hop). Next: Grok (`--provider grok`). Gate fails over to Grok when accounts cool. Treat `true-idle`, `protocol-unsupported`, provider/abort/spawn/artifact failure as unavailable. Never replace with static timeout, byte-growth heartbeat, or buffered-output fallback.

package/skills/plan-ceo-review/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: plan-ceo-review
+description: "CEO/founder plan review for scope, ambition, customer value, sequencing, and whether the plan is the right bet."
+license: MIT
+---
+
+# CEO plan review
+
+Review the plan as a founder accountable for product leverage and customer value.
+
+## Modes
+
+Choose one mode explicitly:
+
+- **Scope expansion:** the plan is too timid; propose a bigger wedge.
+- **Selective expansion:** keep the core but add one or two high-leverage improvements.
+- **Hold scope:** ambition is right; demand sharper execution and proof.
+- **Scope reduction:** remove distracting work and ship the smallest valuable slice.
+
+## Review checklist
+
+1. Who urgently wants this outcome and why now?
+2. What is the 10-star version, and what is the smallest credible slice of it?
+3. What should be deleted because it does not advance the wedge?
+4. What proof will convince us the work mattered?
+
+Return a verdict, the recommended mode, and specific plan edits.

package/skills/plan-design-review/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: plan-design-review
+description: "Designer plan review for UI/UX clarity, hierarchy, interaction quality, accessibility, and visual coherence."
+license: MIT
+---
+
+# Design plan review
+
+Review the plan as a product designer before code is written.
+
+## Scorecard
+
+Rate each dimension from 0-10 and explain what would make it a 10:
+
+- User intent and primary task clarity
+- Information hierarchy and content structure
+- Interaction states and error recovery
+- Accessibility and keyboard/screen-reader paths
+- Visual coherence, spacing, and affordances
+- Responsiveness and empty/loading states
+
+## Output
+
+- Overall score and verdict
+- Top three design risks
+- Minimal plan edits that improve the score
+- Acceptance criteria for visual and accessibility verification

package/skills/plan-devex-review/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: plan-devex-review
+description: "Developer-experience plan review for onboarding, docs, CLI/API ergonomics, migration risk, and time-to-hello-world."
+license: MIT
+---
+
+# Developer-experience plan review
+
+Use before implementing developer-facing features, setup flows, CLIs, docs, SDKs, or migrations.
+
+## Review checklist
+
+- Who is the developer and what are they trying to do?
+- Is the first successful path obvious and short?
+- Are errors actionable and copy-pastable?
+- Does the plan preserve existing workflows and migration safety?
+- What docs, examples, and smoke tests prove the experience?
+
+Return DX score, blockers, simplifications, and acceptance tests.

package/skills/plan-eng-review/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: plan-eng-review
+description: "Engineering-manager plan review for architecture, data flow, sequencing, edge cases, tests, and rollout risk."
+license: MIT
+---
+
+# Engineering plan review
+
+Review the plan as an engineering manager who must make it safe to execute.
+
+## Process
+
+1. Identify the target outcome, non-goals, constraints, owners, and stop condition.
+2. Map the implementation path: changed files, data flow, public interfaces, migrations, and backward-compatibility concerns.
+3. List edge cases and failure modes by severity.
+4. Check test shape: unit, integration, e2e, fixtures, regression coverage, and verification commands.
+5. Recommend the smallest plan repair that materially reduces risk.
+
+## Output
+
+- **Verdict:** ready / ready with edits / not ready
+- **Blocking issues:** concrete fixes required before coding
+- **Recommended edits:** concise patch-level plan changes
+- **Verification contract:** commands and evidence required before completion