@webpresso/opencode-plugin 3.1.11 → 3.1.13

package/skills/opencode-go/SKILL.md

@@ -0,0 +1,106 @@
+---
+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. The default outside-voice lane is Kimi K2.7 Code first for coding quality, then DeepSeek V4 Pro for deeper review depth, then DeepSeek V4 Flash for cheap/high-availability follow-up passes; only after that should it fall back to 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.
+
+## Auth and availability check
+
+```bash
+opencode providers list >/dev/null
+opencode models opencode-go >/dev/null
+```
+
+## 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.
+
+## 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.
+
+```bash
+# Aggregate reviewer: honor the canonical reviewer policy (Kimi K2.7 Code → DeepSeek V4 Pro → DeepSeek V4 Flash first, then cross-family 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)
+
+# Fail fast on blocked quota before launching a long review. The typed runtime
+# consumes provider JSON events and resets its idle clock only on semantic progress.
+[ -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_PROBE_IDLE_SECONDS=${OPENCODE_GO_PROBE_IDLE_SECONDS:-180}
+OPENCODE_GO_REVIEW_IDLE_SECONDS=${OPENCODE_GO_REVIEW_IDLE_SECONDS:-180}
+OPENCODE_GO_REVIEW_ARTIFACT_ROOT=${OPENCODE_GO_REVIEW_ARTIFACT_ROOT:-"$(pwd)/.webpresso/reviews"}
+PROBE_FILE=$(mktemp -t wp-opencode-go-probe.XXXXXX)
+trap 'rm -f "$PROMPT_FILE" "$PROBE_FILE"' EXIT
+printf 'Reply exactly OPENCODE_GO_OK.\n' >"$PROBE_FILE"
+
+wp review run \
+  --provider opencode \
+  --prompt-file "$PROBE_FILE" \
+  --model "$MODEL" \
+  --effort "$OPENCODE_GO_REVIEW_EFFORT" \
+  --stage probe \
+  --expected-marker OPENCODE_GO_OK \
+  --artifact-root "$OPENCODE_GO_REVIEW_ARTIFACT_ROOT" \
+  --idle-seconds "$OPENCODE_GO_PROBE_IDLE_SECONDS"
+
+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"
+```
+
+If `$MODEL` is empty, run `opencode models opencode-go` and choose a present reviewer.
+Treat `true-idle`, `protocol-unsupported`, provider failure, abort, spawn failure, or artifact failure as unavailable review evidence. Never replace them with a static timeout, arbitrary 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

package/skills/plan-refine/SKILL.md

@@ -0,0 +1,49 @@
+---
+type: skill
+slug: plan-refine
+title: Plan Refinement Methodology
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-07-03"
+name: plan-refine
+description: "Blueprint hardening: fact-check assumptions, run plan reviews, split parallel tasks, and lock verification."
+---
+
+# Plan Refinement Methodology
+
+Use when a blueprint or implementation plan needs fact-checking, architecture hardening, parallel task shaping, or review consolidation before execution.
+
+## Core principle
+
+A plan is only as strong as its weakest unchecked assumption and only as fast as its coarsest task granularity.
+
+## Required workflow
+
+1. **Technology fact-check.** Verify API, version, runtime, platform, and package claims against official/upstream sources when external behavior matters.
+2. **Codebase verification.** Confirm file paths, exports, existing patterns, dependency availability, and local command surfaces in the repo.
+3. **Architecture review.** Challenge race conditions, error cascades, ownership boundaries, concurrency, auth/session edges, public-package leakage, and unnecessary abstractions.
+4. **Plan-review lenses.** Folded `/autoplan`: run the relevant CEO/founder, design, engineering, and DevEx review lenses; consolidate keep/change/drop decisions, unresolved taste calls, tests, and go/no-go.
+5. **Blueprint enforcement.** Split tasks for independent execution, declare dependencies, identify file conflicts, require TDD/proof steps, and preserve acceptance criteria.
+6. **Apply and record.** Update edge cases, risks, technology choices, cross-plan references, and verification gates. Do not edit implementation code during plan refinement.
+
+## Mandatory gates
+
+- Apply DRY, SOLID, YAGNI, and KISS; reject speculative abstractions.
+- For package, catalog, generated-surface, or release changes, require package-surface and public-content checks.
+- Prefer deletion/reuse over new layers or dependencies.
+- Stop on unverified external claims, unresolved shared-file conflicts, or missing authority for destructive work.
+
+## Output
+
+Return a concise plan review with:
+
+- verdict: ready / ready with edits / blocked
+- material corrections with evidence
+- task/dependency changes needed for parallel execution
+- required tests and audits
+- residual risks or explicit blockers
+
+For the full historical checklist and examples, read `references/full-methodology.md` only when deeper plan surgery is needed.