@webpresso/claude-plugin 3.1.12 → 3.1.13

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
-    "version": "3.1.12"
+    "version": "3.1.13"
   },
   "plugins": [
     {
@@ -34,5 +34,5 @@
       }
     }
   ],
-  "version": "3.1.12"
+  "version": "3.1.13"
 }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-kit",
-  "version": "3.1.12",
+  "version": "3.1.13",
   "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
   "author": {
     "name": "Webpresso",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webpresso/claude-plugin",
-  "version": "3.1.12",
+  "version": "3.1.13",
   "private": false,
   "description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
   "homepage": "https://github.com/webpresso/agent-kit#readme",

package/plugin-skill-ownership.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "host": "claude",
   "packageName": "@webpresso/claude-plugin",
-  "packageVersion": "3.1.12",
+  "packageVersion": "3.1.13",
   "runtimeDirs": [
     ".claude/skills"
   ],
@@ -10,6 +10,9 @@
     "autopilot": {
       "digest": "sha256:7fc1fe9f5fb5b8a3e755f8e3ac4b807e4f140288544ffcf39e4cbfdea984014d"
     },
+    "autoresearch": {
+      "digest": "sha256:b4d51cd53beb4a3271827172dfbd0b1d27bd58761ca07a35d49a5d6324b87fdf"
+    },
     "best-practice-research": {
       "digest": "sha256:b0d355c7f4afe9c38be83e293788bf582bea068c1db2fa5c45400441e315735d"
     },
@@ -61,6 +64,12 @@
     "plan-refine": {
       "digest": "sha256:891e84ff8592b8489b59e8642f6a602c9558fd57edd171af98499c94e2f62f13"
     },
+    "ralplan": {
+      "digest": "sha256:db285d477f43ed23df990d4c03750d9916cdc7809356c1bf025efdf6a9add9ed"
+    },
+    "team": {
+      "digest": "sha256:151ef81df917435073a2d7b41173d33c45cb8aa1e5fdf34a70043bb3a2e746ff"
+    },
     "tech-debt": {
       "digest": "sha256:8b1f30e55ec6e5ab185ff19ecf15384438dbd619f675c2c65f2e53cedecbae5c"
     },
@@ -71,7 +80,7 @@
       "digest": "sha256:bed3684a850651534f315d355cdeae50d951c429817df0f105cccdb7f4e1561b"
     },
     "verify": {
-      "digest": "sha256:b088b138a985f94e29970edac1bcae70b29b15b5b3573787652ad590b789c9c7"
+      "digest": "sha256:ce0dd3a77508d1bf11c805dec2de04e75b689201d376b2ff0fa957604d584500"
     }
   }
 }

package/skills/autoresearch/SKILL.md

@@ -0,0 +1,49 @@
+---
+type: skill
+slug: autoresearch
+title: Autoresearch
+status: active
+scope: repo
+applies_to: [agents]
+related: [deep-research, best-practice-research, plan-refine, verify]
+created: "2026-07-13"
+last_reviewed: "2026-07-13"
+name: autoresearch
+description: "Artifact-gated research loop with explicit validation."
+argument-hint: "<research mission and validator>"
+---
+
+# Autoresearch
+
+Use when the user wants research to continue until a concrete validator accepts the result. This is for bounded research deliverables, not quick factual lookup or ordinary planning context.
+
+## Boundary
+
+- Use `deep-research` for one-pass citation-backed reports.
+- Use `best-practice-research` for focused upstream guidance.
+- Use `autoresearch` when completion depends on an explicit evaluator, benchmark, review rubric, or acceptance artifact.
+
+## Workflow
+
+1. Define the research mission, output artifact path, validator, and stop condition.
+2. Choose one validation mode:
+   - command validator: a repo command or script must pass and write the result.
+   - review validator: an independent review must approve the produced artifact against the mission.
+3. Create or update the durable research artifact before iterating.
+4. Gather sources and repo context until the artifact addresses the mission and cites material claims.
+5. Run the validator. If it fails, preserve the failure evidence, revise the artifact, and repeat.
+6. Stop only when the validator passes or a blocker prevents more evidence-gathering.
+
+## Output
+
+Return:
+
+- mission
+- artifact path
+- validation mode
+- validator command or review rubric
+- evidence gathered
+- pass/fail result
+- remaining gaps or blocker
+
+Do not treat elapsed turns, model confidence, or a draft report as completion evidence. Completion requires the declared validator to pass.

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/verify/SKILL.md

@@ -7,14 +7,10 @@ scope: repo
 applies_to: [agents]
 related: [testing-philosophy, tph]
 created: "2026-05-07"
-last_reviewed: "2026-07-03"
+last_reviewed: "2026-07-13"
 name: verify
 description: "Post-implementation quality gate: run checks, TPH audit, cleanup, docs, proof."
 argument-hint: "<target> [--full] where target is: package|file|plan-slug|all"
-hooks:
-  Stop:
-    - command: wp audit agents
-      timeout: 20
 ---
 
 # Verify