@webpresso/plugin-antigravity 0.0.0-stage → 0.0.17

package/skills/opencode-go/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: opencode-go
+description: "OpenCode Go aggregate outside-voice reviewer for read-only plan, code, or implementation critique."
+license: MIT
+---
+
+# OpenCode Go aggregate outside-voice review
+
+Use only for a requested content-bound plan or delivery review. Treat output as external advice
+until independently verified.
+
+## MCP-only contract
+
+- Call `review_gate` exactly once for the real plan version or delivery diff.
+- Observe the same durable operation with `review_gate_wait` when needed.
+- Never invoke a provider command, the legacy review CLI, or a removed review-run surface.
+- If the review MCP is unavailable, stop and report it unavailable. There is no CLI fallback.
+
+## Gate call
+
+```jsonc
+{
+  "project_id": "<project>",
+  "slug": "<blueprint-slug>",
+  "purpose": "delivery",
+  "base_ref": "<full-base-sha>",
+  "authority_ref": "<full-head-sha>",
+  "caller_model": "<your own model id, exactly as your host reports it>",
+  "repository_access": "none",
+}
+```
+
+Each newly executed provider review that reaches a verdict is one formal round of the
+slug's budget, and its approval is authority. An identical-subject call replays the recorded
+verdict with no new review and no new round. A partial approval, withheld because adjudication
+is incomplete (not every prior finding was briefed, or a briefed prior claim was marked
+still-open without a matching finding), grants no authority and spends no round.
+
+## Reviewer selection
+
+Pass `caller_model` with your OWN model id, exactly as your host reports it, and omit
+`provider`, `model`, and `effort`: the gate selects the reviewer route itself — a cross-family
+reviewer chosen for capability, current provider limits, and measured daily cost — and reports
+the choice in `policy_selection`. Never name a reviewer model, probe a provider CLI for its
+catalog, or read a credential store to discover models at invocation time; provider catalog
+discovery belongs to the snapshot drift workflow. An operator may still pass an explicit
+`provider`/`model` as a human override; agents must not.
+
+## Review quality
+
+Follow `catalog/agent/rules/review-methodology-sota.md`; report typed verdict, model,
+artifact, grounded findings, and independently verified conclusions.

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,122 @@
+---
+type: skill
+slug: plan-refine
+title: Plan Refinement Methodology
+status: active
+scope: repo
+applies_to: [agents]
+related:
+  [
+    best-practice-research,
+    deep-research,
+    plan-eng-review,
+    plan-ceo-review,
+    plan-design-review,
+    plan-devex-review,
+    ralplan,
+  ]
+created: "2026-05-07"
+last_reviewed: "2026-08-02"
+name: plan-refine
+description: "Plan hardening to 100% confidence. Use for plan-refine, step back, evaluate plan, don't implement yet."
+---
+
+# Plan Refinement Methodology
+
+## Use when (freeform)
+
+- "take a step back", "evaluate", "don't thrash", "parallel plan"
+- "plan-refine", "fact check the plan", "don't implement yet"
+- hardening a draft blueprint before promotion or execution
+
+## Phase 0 — Sync and isolation preflight
+
+Before deep plan surgery: confirm intended base (e.g. fetch/align with
+`origin/main` when the user said sync), and do not plan implementation that
+will thrash a dirty primary checkout — bind a managed worktree/blueprint owner
+first when edits will follow.
+
+Use when a blueprint or implementation plan needs fact-checking, architecture hardening, parallel task shaping, or review consolidation before execution.
+
+## Non-negotiable bar
+
+Refine until the plan hits **all four targets** — not “good enough to start”:
+
+| Target              | Meaning                                                                                                                        |
+| ------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
+| **100% confidence** | Every material claim is verified. No residual “we think / probably / should work”. Unverified → **blocked** or rewrite.        |
+| **Elegance**        | Smallest coherent design that solves the real problem. Prefer delete/reuse over add; reject heavier options that merely work.  |
+| **Durability**      | Survives version upgrades, ownership boundaries, and the next adjacent change without a rewrite. Record _why_ the shape lasts. |
+| **Efficiency**      | Critical path is minimal; wall-clock is maximized via true parallel waves; no speculative layers or busywork tasks.            |
+
+**Zero assumptions.** Every path, symbol, API, version, env var, and “existing pattern” is either proven with evidence or removed from the plan. Model memory is not evidence.
+
+## Core principle
+
+A plan is only as strong as its weakest unchecked claim, only as elegant as what it refuses to add, and only as fast as its coarsest task granularity.
+
+## Required workflow (parallel by default)
+
+Run **1–3 (and relevant review lenses) in parallel** whenever tools allow. Do not serialize independent verification. Phases 5–6 wait on their inputs only.
+
+1. **Technology fact-check (official, latest).**
+   - Enumerate every external claim (API, package, runtime, platform limit, protocol, CLI flag).
+   - Verify each against **official/upstream docs for the exact latest (or pinned) version** in use: vendor docs, release notes, changelogs, package registry metadata — not blogs, Stack Overflow, or model recall.
+   - Record version + source URL (or registry identity) next to the claim. Stale or mismatched version → fix the plan.
+   - Use `best-practice-research` / official-doc fetch; escalate to `deep-research` only when multi-source depth is required.
+
+2. **Codebase verification (pinpoint to code).**
+   - Confirm file paths, exports, signatures, call sites, config keys, and conventions with **exact anchors**: `path` + symbol and, when useful, line range.
+   - Prefer `rg`/grep + read of the real definition over summaries. “Likely exists” is a fail.
+   - Correct every plan statement that does not match the repo **as it is today**.
+
+3. **Architecture review.**
+   - Adversarial: races, TOCTOU, error cascades, auth/session edges, ownership boundaries, public-package leakage, unnecessary abstractions.
+   - Score alternatives on elegance, durability, and efficiency; keep only the winner and write the rejection rationale for heavier options.
+
+4. **Plan-review lenses (skip when the caller already ran them).** Folded `/autoplan`: run relevant CEO/founder, design, engineering, and DevEx lenses **in parallel when independent**; consolidate keep/change/drop, unresolved taste calls, tests, go/no-go.
+   - **Review cost — know it before you dispatch.** An `approve`, `approve-with-nits`, or `reject` verdict from a `review_gate` run spends ONE formal review round (per slug and purpose). A no-verdict attempt spends none; editing the plan spends and resets nothing already spent. `src/review/budgets.ts` owns the numeric allowance — never restate it in prose — and `wp review budget <slug>` reports remaining capacity live.
+   - **Skip condition.** If the caller states `plan-* reviews complete for this pass`, do **not** re-run the lenses. `ralplan` runs them before handing off, so re-running them here is duplicated spend, not a second opinion.
+   - **Re-entry.** If refinement itself **materially changes scope**, re-run only the affected lens — never the full set — then continue applying.
+   - **Re-review rounds.** `catalog/agent/rules/review-methodology-sota.md` Principle 5 sets the delta-anchored adjudication contract subsequent `review_gate` rounds follow.
+
+5. **Blueprint enforcement (max parallel).**
+   - Split for independent execution; declare `Depends`; file-conflict CP = 0 per wave; TDD/proof steps; preserve acceptance criteria.
+   - Target high ready-width and CPR; break false dependencies (interface extraction); front-load Wave 0.
+
+6. **Apply and record.** Update edge cases, risks, technology choices, cross-plan refs, verification gates. **Do not edit implementation code** during plan refinement.
+
+## Mandatory gates
+
+- **0 assumptions** — stop on any material claim without a code pinpoint or official-doc citation at the stated version.
+- **Code pinpoints** — paths/symbols in tasks, risks, and corrections; no floating advice.
+- **Official latest docs** — third-party behavior only from primary sources at the version the plan pins or the latest stable the repo already depends on.
+- Apply DRY, SOLID, YAGNI, KISS; reject speculative abstractions.
+- Choose the most elegant and durable solution constraints allow, not merely a correct one; record why that shape is durable.
+- Prefer deletion/reuse over new layers or dependencies.
+- Package/catalog/generated-surface/release changes → package-surface and public-content checks.
+- Unverified external claims, unresolved shared-file conflicts, or missing authority for destructive work → **blocked**, not “ready with hope”.
+
+## Parallel execution of refinement itself
+
+| Lane | Work                      | Tools                                            |
+| ---- | ------------------------- | ------------------------------------------------ |
+| A    | Official-doc fact-check   | Web/doc fetch, Context7, registry, release notes |
+| B    | Code pinpoints            | Grep, Read, package exports, config              |
+| C    | Architecture + elegance   | Blueprint only + evidence from A/B               |
+| D    | Review lenses (as needed) | plan-*-review skills                             |
+
+A/B/C(/D) concurrent → then dependency graph / waves → then single coherent blueprint write.
+
+## Output
+
+Return a concise plan review with:
+
+- **verdict:** ready / ready with edits / blocked
+- **confidence:** only `ready` when residual material unknowns are **None** (every claim pinned or dropped)
+- material corrections with **evidence** (code pinpoints and/or official doc URL + version)
+- task/dependency changes for **maximum parallel** execution (waves, CPR/RW/CP if non-trivial)
+- required tests and audits
+- residual risks only as closed Material Decisions or tech-debt with owner — never open prose in Residual Unknowns (`None.` at promotion)
+
+For the full historical checklist and examples, read `references/full-methodology.md` only when deeper plan surgery is needed.