@webpresso/opencode-plugin 3.1.11 → 3.1.13

package/skills/ralplan/SKILL.md

@@ -0,0 +1,50 @@
+---
+type: skill
+slug: ralplan
+title: Ralplan Consensus Planning
+status: active
+scope: repo
+applies_to: [agents]
+related: [plan-refine, plan-eng-review, plan-ceo-review, plan-design-review, plan-devex-review]
+created: "2026-07-13"
+last_reviewed: "2026-07-13"
+name: ralplan
+description: "Consensus planning gate for plan-refine"
+---
+
+# Ralplan Consensus Planning
+
+Use when the user invokes `$ralplan`, asks for RALPLAN, or wants consensus planning before execution.
+
+`ralplan` is an agent-kit planning gate, not an implementation lane. It applies consensus review to a durable plan before execution starts.
+
+## Workflow
+
+1. Create or identify the durable blueprint or plan artifact that will own the work.
+2. Run the `plan-refine` methodology against that artifact: verify local code facts, verify external claims when relevant, sharpen acceptance criteria, split independent work, and lock verification gates.
+3. Apply the relevant review lenses before execution:
+   - `plan-eng-review` for architecture, sequencing, tests, and rollout risk.
+   - `plan-ceo-review` when scope, customer value, or sequencing tradeoffs matter.
+   - `plan-design-review` when UI/UX is material.
+   - `plan-devex-review` when docs, CLI/API ergonomics, onboarding, or migration risk is material.
+4. Consolidate the reviews into one decision record with:
+   - decision and drivers
+   - alternatives considered
+   - material corrections
+   - implementation tasks and dependencies
+   - verification gates
+   - residual risks or blockers
+5. Stop at an approved plan or an explicit blocker. Do not edit implementation code from this skill unless the user explicitly changes the task from planning to execution.
+
+## Output
+
+Return a concise consensus plan with:
+
+- verdict: ready / ready with edits / blocked
+- decision and rationale
+- accepted review findings
+- task breakdown
+- required verification
+- recommended execution lane, usually `goal` for durable sequential work or `autopilot` for the full autonomous pipeline
+
+Use `plan-refine` as the detailed checklist source of truth when deeper plan surgery is needed.

package/skills/team/SKILL.md

@@ -0,0 +1,60 @@
+---
+type: skill
+slug: team
+title: Team
+status: active
+scope: repo
+applies_to: [agents]
+related: [autopilot, goal, plan-refine, verify]
+created: "2026-07-13"
+last_reviewed: "2026-07-13"
+name: team
+description: "Coordinate multiple dashboard-backed agent sessions on one task."
+argument-hint: "<brief|role plan>"
+---
+
+# Team
+
+Use `team` when the work needs coordinated parallel lanes with a leader-owned
+task list, explicit handoffs, and independent verification. Prefer native
+subagents for small bounded lookups; use `team` when the parallel work should be
+visible, durable, and operator-controllable from `wp dash`.
+
+## Protocol
+
+1. Start from a grounded brief or an approved blueprint. If scope is vague, run
+   `plan-refine` first and define task lanes, shared files, and verification.
+2. Open or reuse `wp dash` and launch the provider sessions needed for the
+   lanes. Direct `wp claude`, `wp codex`, and `wp opencode` commands are
+   expected to enter the dashboard in interactive terminals.
+3. Assign one owner per lane. Include the task, allowed files or surfaces,
+   expected output, verification command, and blocker-report rule.
+4. Keep one lane or leader pass responsible for integration and evidence.
+   Workers report findings, patches, tests, and unresolved risks; they do not
+   self-approve or mark blueprint tasks complete.
+5. Integrate only after checking shared-file conflicts, updated assumptions,
+   and verification evidence. Use `wp_blueprint_task_verify` for task completion
+   when a blueprint owns the work.
+6. Stop when every lane is complete, cancelled, or explicitly blocked and the
+   leader has recorded verification evidence.
+
+## Coordination Rules
+
+- Use a single source of truth for assignments: the blueprint, goal handoff, or
+  leader-maintained task list.
+- Require ACK-style lane starts for shared files, dependency boundaries, or
+  handoffs.
+- Reassign or narrow blocked lanes instead of letting work drift.
+- Escalate changed assumptions before widening scope.
+- Never bypass review provenance, push to main, self-approve, or increase
+  timeouts to hide coordination failures.
+
+## Output
+
+Report:
+
+- lane roster and ownership
+- files or surfaces touched by each lane
+- integration decisions and conflicts resolved
+- verification commands and results
+- remaining blockers or risks

package/skills/tech-debt/SKILL.md

@@ -0,0 +1,79 @@
+---
+type: skill
+slug: tech-debt
+title: tech-debt
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-05-07"
+name: tech-debt
+description: "Tech-debt lifecycle skill for wp tech-debt creation, review, schema validation, and audits."
+---
+
+# tech-debt
+
+Manage the tech-debt lifecycle using `wp tech-debt` commands.
+
+## Usage
+
+```bash
+# Create a new tech-debt item (written to tech-debt/<status>/h-NNN-<kebab-title>.md by default)
+wp tech-debt new "Legacy CLI complexity" \
+  --severity medium \
+  --category complexity \
+  --review-cadence quarterly \
+  --status accepted
+
+# Preview without writing
+wp tech-debt new "Performance bottleneck" --severity high --category mutation --dry-run
+
+# List all tech-debt items (optional filters)
+wp tech-debt list
+wp tech-debt list --status accepted
+wp tech-debt list --status needs-remediation --severity high
+wp tech-debt list --category security
+
+# Review: show items past their review date (exits non-zero if any are overdue)
+wp tech-debt review
+
+# Audit tech-debt files against the schema (CI gate)
+wp audit tech-debt --root .
+```
+
+## File naming
+
+Files are named `h-NNN-<kebab-title>.md` where `NNN` is auto-incremented across all status directories.
+
+## Status lifecycle
+
+```
+accepted → needs-remediation → monitoring → resolved
+```
+
+## Severity + cadence rules
+
+| Severity | Minimum cadence           |
+| -------- | ------------------------- |
+| critical | weekly (required)         |
+| high     | biweekly or more frequent |
+| medium   | monthly                   |
+| low      | quarterly                 |
+
+## Categories
+
+`complexity`, `testing`, `mutation`, `duplication`, `dependency`, `security`, `documentation`
+
+## Frontmatter schema (required fields)
+
+```yaml
+---
+type: tech-debt
+status: accepted # accepted | needs-remediation | monitoring | resolved
+severity: medium # critical | high | medium | low
+category: complexity # see categories above
+review_cadence: quarterly # weekly | biweekly | monthly | quarterly
+last_reviewed: "2026-01-15"
+---
+```

package/skills/testing-philosophy/SKILL.md

@@ -0,0 +1,53 @@
+---
+type: skill
+slug: testing-philosophy
+title: Testing Philosophy
+status: active
+scope: repo
+applies_to: [agents]
+related: []
+created: "2026-05-07"
+last_reviewed: "2026-07-03"
+name: testing-philosophy
+description: "Integration-first TDD/testing philosophy: write failing tests, avoid over-mocking, and prove behavior."
+---
+
+# Testing Philosophy
+
+Use when writing tests, reviewing test quality, debugging "tests pass but production fails", or deciding the smallest proof for a change.
+
+## Iron laws
+
+1. **Failing proof first.** Folded `/test-driven-development`: for behavior changes, write or strengthen the failing test/proof, watch it fail for the right reason, implement the smallest passing code, then refactor while green.
+2. **Integration-first confidence.** Prefer tests that exercise real boundaries and behavior. Use unit tests for pure logic speed; use integration/E2E where correctness depends on wiring, persistence, CLI/browser flows, or user experience.
+3. **Mocks only at real external boundaries.** Do not mock business logic, framework internals, persistence semantics, or the code under test. Over-mocking creates false confidence.
+4. **Assertions prove behavior.** Avoid tautologies, snapshot-only checks, spy-count implementation assertions, and broad "does not throw" claims.
+5. **Mutation pressure.** New logic should be written so mutation testing could catch weak assertions; target the repo's 85% mutation-score standard where mutation is in scope.
+
+## Test-shape checklist
+
+- Name the user-visible behavior or invariant.
+- Cover mixed/partial/error cases for list, browse, batch, validation, and recovery flows.
+- Prefer repo-owned wrappers for test commands.
+- Verify RED before GREEN when feasible; if not feasible, record the nearest reliable proof.
+- Keep tests deterministic: no sleeps, timing guesses, hidden network, or random order dependence.
+- If a passing test would not fail against the old behavior, strengthen it before claiming coverage.
+
+## Output
+
+When reviewing tests, report:
+
+- strongest proof added or missing
+- over-mocking / weak assertion risks
+- required integration or E2E coverage
+- command evidence and whether the failure was observed before the fix
+
+After applying the checklist and judgment review, run the repo static smell audit as the final mechanical backstop when available:
+
+```bash
+wp audit test-smells
+```
+
+Treat this audit as the last step, not a substitute for the testing-philosophy review.
+
+For the full historical examples and anti-pattern catalog, read `references/full-testing-philosophy.md` only when detailed test-design guidance is needed.