菜单
Use when every milestone under the active release in 00-ROADMAP.md is completed and committed — to finalize, tag, and ship the release behind explicit human approval. Symptoms - "ship it", "cut the release", "tag the version", supervisor Phase 4, all milestones in the active release marked COMPLETED.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Renders a completed Claude Code dynamic Workflow run (wf_<runId>.json) as a self-contained, offline HTML page with a run→phase→agent tree and a parallelism timeline. Trigger when the user asks to "visualize the workflow run", "render wf trajectory", "trace a workflow", or "show the last workflow execution".
No-Python remote drop-in for plan-validator - runs the adversarial plan review on remote models over the Interactions API (curl + ADC from caller subagents; configurable roster; Vertex fallback), with a synthesis model casting an extra vote and nominating the first domino. Symptoms - "run the interactions plan panel", "remote plan validation without Python", "validate this plan via the Interactions API", "GEAP plan validation, no local scripts", geap-plan-validator wanted but no venv/Python available.
No-Python remote drop-in for spec-validator - runs the adversarial spec review on remote models over the Interactions API (curl + ADC from caller subagents; configurable roster; Vertex fallback), with a synthesis model casting an extra vote. Symptoms - "run the interactions spec panel", "remote spec validation without Python", "validate this spec via the Interactions API", "GEAP spec validation, no local scripts", geap-spec-validator wanted but no venv/Python available.
Use when a drafted implementation plan spans territories no single agent can hold at once — the spec's intent, multiple subsystems of the real codebase, and the delivery pipeline — BEFORE plan-validator, to improve the plan by deliberation rather than attack. Dispatches delegate agents each assigned a different territory to deep-read and speak for, who deliberate over bounded rounds until they converge on a single jointly revised plan, negotiating the trade-offs (migration strategy, group boundaries, scope) that a validator can only flag, never decide. Symptoms - "deliberate on this plan", "improve this plan from multiple perspectives", "the plan touches three subsystems", "we need to pick a migration strategy", plan.md spans code no one context window can deep-read whole, resolving the unconfirmed tail of a plan-validator run.
Use when a drafted spec depends on knowledge that is siloed across stakeholders, documents, or repos — BEFORE adversarial validation — to improve the spec by deliberation rather than attack. Dispatches delegate agents with deliberately DISJOINT context bundles (product, engineering, ops/security) who deliberate over bounded rounds, relayed verbatim by the orchestrator, until they converge on a single jointly revised spec. Symptoms - "deliberate on this spec", "improve this spec from multiple perspectives", "get product/eng/security input on the spec", "the constraints live in different places", spec touches systems whose limits no single context window can hold, resolving the unconfirmed tail of a spec-validator run.
Remote drop-in alternative to plan-validator - runs the adversarial implementation-plan review on Vertex AI foundation models (3 configurable skeptics + a synthesis model) instead of local subagents, attacking the plan text for ordering defects, hidden assumptions, and missing failure handling. Symptoms - "run the remote plan panel", "GEAP plan validation", "validate this plan with cloud/Vertex models", "get a second opinion on this plan from other models", plan-validator requested with remote or Gemini/Claude-on-Vertex models.
| name | release |
| description | Use when every milestone under the active release in 00-ROADMAP.md is completed and committed — to finalize, tag, and ship the release behind explicit human approval. Symptoms - "ship it", "cut the release", "tag the version", supervisor Phase 4, all milestones in the active release marked COMPLETED. |
Finalize a release: confirm every milestone is done, get explicit approval, create the git tag,
optionally push, and have product-owner mark the release Shipped and activate the next one.
Every milestone under the active release in plans/00-ROADMAP.md is COMPLETED and committed. See
Supervisor → Contract 1 & Contract 4.
plans/00-ROADMAP.md (release + milestone statuses)plans/00-ROADMAP.md and confirm all milestones under the active
release are COMPLETED. If any is not, return to the Supervisor — you are not in Phase 4 yet.{version} are complete. Shall I finalize the release and create the git
tag?" Do nothing irreversible until they approve.git tag -a {version} -m "Release {version}"
git push --tags.product-owner (Supervisor → Contract 2) to mark the release Shipped in
plans/00-ROADMAP.md and activate the next release.The tag exists, 00-ROADMAP.md shows the release as Shipped, and the next release is Active.
Back to the Supervisor — idle until the next user request restarts the lifecycle at research.
(Consider /swarm:archive to move completed milestones out of the active context.)
git push --tags.| Thought | Reality |
|---|---|
| "Most milestones are done, tag it." | Every milestone must be COMPLETED. Partial ≠ shippable. |
| "I'll tag and push in one go." | Tag, then ask separately before pushing. |
| "Tagging done, we're finished." | Have product-owner mark Shipped and activate the next release. |