メニュー
Swarm planning session with PM, UX, and Engineering agents who debate an idea, ask clarifying questions, and produce a detailed spec written to plans/$plan-name.md.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/dyad-sh/dyad --skill dyadswarm-to-planコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
SOC 職業分類に基づく
Diagnose and fix failing CI checks on a pull request from its latest GitHub Actions CI run. Use when PR CI has E2E/Playwright failures, macOS or Windows unit-test failures, or presubmit/type/build failures; analyzes the exact run logs and artifacts, invokes dyad:deflake-e2e-from-run for E2E failures, reproduces targeted unit tests locally, and publishes the fixes.
Address all outstanding issues on a GitHub Pull Request by handling both review comments and failing CI checks.
Read all unresolved GitHub PR comments from trusted authors and address or resolve them appropriately.
| name | dyad:swarm-to-plan |
| description | Swarm planning session with PM, UX, and Engineering agents who debate an idea, ask clarifying questions, and produce a detailed spec written to plans/$plan-name.md. |
This skill uses a team of specialized agents (Product Manager, UX Designer, Engineering Lead) to collaboratively debate an idea, identify ambiguities, clarify scope with the human, and produce a comprehensive plan.
$ARGUMENTS: The idea or feature to plan (e.g., "add collaborative editing", "redesign the settings page")plans/$plan-name.mdRead the idea from $ARGUMENTS. Explore the codebase briefly to understand:
IMPORTANT: Read rules/product-principles.md and include the product design principles in the context summary shared with the team. All agents should use these principles to guide decisions autonomously — only flag a tension or trade-off to the user if it is genuinely unresolvable within the principles.
Prepare a brief context summary to share with the team.
Use TeamCreate to create the team:
TeamCreate:
team_name: "plan-<slugified-idea-name>"
description: "Planning session for: <idea>"
Create 4 tasks:
pmuxengSpawn all 3 teammates in parallel using the Task tool with team_name set to the team name. Each teammate should be a general-purpose subagent.
IMPORTANT: Each teammate's prompt must include:
references/)For each teammate, the prompt should follow this structure:
You are the [ROLE NAME] on a product planning team. Read your role description carefully:
<role>
[Contents of references/<role>.md]
</role>
You are planning this idea: "<IDEA DESCRIPTION>"
<codebase_context>
[Brief summary of tech stack, relevant architecture, and existing patterns]
</codebase_context>
## Instructions
1. Read your role description carefully and analyze the idea from your expert perspective.
2. Produce a thorough analysis following the output format described in your role description.
3. Identify 2-5 **open questions** — things that are ambiguous, underspecified, or could go multiple ways. For each question, explain WHY the answer matters (what changes depending on the answer).
4. Send your analysis to the team lead using SendMessage.
After sending your initial analysis, wait for the team lead to share the other team members' analyses. When you receive them:
- **AGREE** with points you think are correct
- **CHALLENGE** points you disagree with, giving specific reasoning
- **BUILD ON** ideas from other roles that intersect with your expertise
- **FLAG** any new concerns that emerged from reading others' analyses
Focus on genuine trade-offs and real disagreements, not superficial consensus.
Wait for all 3 teammates to send their initial analyses.
Once all initial analyses are in:
The message to each teammate should look like:
All initial analyses are in. Here are the perspectives from all three roles:
## Product Manager Analysis:
[PM's full analysis]
## UX Designer Analysis:
[UX's full analysis]
## Engineering Lead Analysis:
[Eng's full analysis]
Please review the other team members' analyses from YOUR expert perspective:
- AGREE with points that are well-reasoned (say "AGREE: <point> — <why>")
- CHALLENGE points you disagree with (say "CHALLENGE: <point> — <your counter-argument>")
- BUILD ON ideas that intersect with your expertise (say "BUILD: <point> — <your addition>")
- FLAG new concerns that emerged (say "FLAG: <concern> — <why this matters>")
Focus on genuine disagreements and real trade-offs. Don't agree with everything just to be nice.
After the debate, compile all open questions and unresolved disagreements. Group them into themes and prioritize by impact.
Use AskUserQuestion to ask the human clarifying questions. Structure the questions to resolve the highest-impact ambiguities. You can ask up to 4 questions at a time using the multi-question format. Key things to ask about:
If there are more than 4 questions, ask the most critical ones first, then follow up with additional rounds if needed.
Send the human's answers back to all teammates and ask each to provide their final refined take given the clarifications. This should be brief — just adjustments to their original analysis based on the new information.
After receiving final input from all teammates, compile a comprehensive plan document. The plan should synthesize all three perspectives into a coherent spec.
Create the plans/ directory if it doesn't exist, then write the plan to plans/<plan-name>.md:
mkdir -p plans
The plan file should follow this format:
# <Plan Title>
> Generated by swarm planning session on <date>
## Summary
<2-3 sentence overview of what we're building and why>
## Problem Statement
<Clear articulation of the user problem, from PM>
## Scope
### In Scope (MVP)
- <feature 1>
- <feature 2>
### Out of Scope (Follow-up)
- <deferred feature 1>
- <deferred feature 2>
## User Stories
- As a <user>, I want <goal> so that <reason>
- ...
## UX Design
### User Flow
<Step-by-step walkthrough of the primary interaction>
### Key States
- **Default**: <description>
- **Loading**: <description>
- **Empty**: <description>
- **Error**: <description>
### Interaction Details
<Specific interactions, gestures, feedback mechanisms>
### Accessibility
<Keyboard nav, screen readers, contrast, motion considerations>
## Technical Design
### Architecture
<How this fits into the existing system>
### Components Affected
- `path/to/file.ts` — <what changes>
- ...
### Data Model Changes
<New or modified schemas, storage, state>
### API Changes
<New or modified interfaces>
## Implementation Plan
### Phase 1: <name>
- [ ] <Task 1>
- [ ] <Task 2>
### Phase 2: <name>
- [ ] <Task 3>
- [ ] <Task 4>
## Testing Strategy
- [ ] <What to test and how>
## Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
| ------ | ---------- | ------- | ---------- |
| <risk> | <H/M/L> | <H/M/L> | <strategy> |
## Open Questions
<Any remaining questions that should be resolved during implementation>
## Decision Log
<Key decisions made during planning and the reasoning behind them>
---
_Generated by dyad:swarm-to-plan_
After writing the plan:
plans/<plan-name>.mdreferences/
pm.md - Role description for the Product Manager
ux.md - Role description for the UX Designer
eng.md - Role description for the Engineering Lead