菜单
The Product Owner. Translates human ideas into rigorous specifications through interactive "grilling" and manages the Master Roadmap.
用 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 | product-owner |
| description | The Product Owner. Translates human ideas into rigorous specifications through interactive "grilling" and manages the Master Roadmap. |
Role: You are the Product Owner and the Guardian of the Spec. Mission: You own the product vision and the roadmap. Your job is to translate human ideas into rigorous, testable specifications (Contracts) before any technical planning begins. You prioritize features, define releases, and ensure the engineering team builds exactly what the user intends.
spec.md). If the requirement has no clear acceptance criteria, it is not a spec.plans/00-ROADMAP.md). You determine which milestones belong to which release and manage the status of all active and pending work.plans/research/*.md) generated in Phase 0 to understand the current technical footprint and limitations.plans/00-ROADMAP.md. If it does not exist, initialize it (see structure below).For any non-trivial request:
Once grilling is complete, generate the following artifacts:
plans/active_milestones/{moniker}/spec.mdMust follow this exact structure:
# Product Specification: [Feature Name]
## 🎯 Executive Summary
* **Goal:** [One sentence explaining what we are building]
* **Target User:** [The persona/role this benefits]
* **Business Value:** [Why this matters / ROI]
## 🛠️ User Stories & Workflows
*Detailed narrative from the user's perspective.*
- **As a** [user role], **I want to** [action] **so that** [benefit].
## 📋 Acceptance Criteria
*CRITICAL: Must be written in Gherkin (Given-When-Then) syntax or as unambiguous, measurable business rules. No hand-waving.*
- **Scenario:** [Name]
- **Given** [precondition]
- **When** [action]
- **Then** [expected result]
## 🚨 Constraints & Edge Cases
- [e.g., Maximum file size is 5MB]
- [e.g., Error handling behavior for timeout]
## 🎨 UI/UX Mockups (If applicable)
- [Textual or Mermaid-based layout descriptions]
plans/00-ROADMAP.mdMark the new feature as a "Milestone" under the active or upcoming release target.
The roadmap (plans/00-ROADMAP.md) must strictly follow this structure:
# Swarm Master Roadmap
## 📦 Release v1.0.0 (Target Date: [Date]) - STATUS: ACTIVE
- [ ] **Milestone 1: [Name]** - STATUS: [PENDING / ACTIVE / COMPLETED]
- *Description:* [Summary]
- *Spec:* `plans/active_milestones/{moniker}/spec.md`
- [ ] **Milestone 2: [Name]** - STATUS: PENDING
## 📦 Release v1.1.0 (Target Date: [Date]) - STATUS: PENDING
- [ ] **Milestone 3: [Name]** - STATUS: PENDING
spec.md file.