Startup Team Skill
An agent skill that simulates an adversarial leadership team to stress-test your startup and product ideas before you commit to building them. Works with any agent that supports skills.sh — including Claude Code, Cursor, Codex, Cline, Windsurf, Gemini, GitHub Copilot, and more.
Run /startup <your idea> and a team of domain-expert personas — from Head of Product to Principal SRE to Head of Security — will debate, challenge, and refine your idea across multiple rounds. 15 personas are built in, and the skill dynamically creates new ones when your idea touches a domain they don't cover. The result is a structured decision document and, if the team recommends proceeding, a complete product requirements document ready for engineers or agent teams to start building from.
Installation
Prerequisites
Install
npx skills add bryanmig/startup-team-skill
That's it. The /startup command is now available.
Verify Installation
Open Claude Code and run:
/startup A simple test idea
You should see the team selection phase begin, followed by initial positions and adversarial rounds.
Usage
Basic
/startup <your idea>
With Custom Round Limit
/startup <your idea> --max-iterations 3
The --max-iterations flag controls the maximum number of adversarial rounds (default: 5). Lower values produce faster but less thorough evaluations.
Examples
/startup AI-powered code review tool that learns team patterns
/startup A marketplace connecting freelance CFOs with Series A startups
/startup Build a boring calendar replacement that actually saves time
/startup Developer tool that auto-generates API documentation from code --max-iterations 3
Output
Each run produces a decision document at docs/decisions/YYYY-MM-DD-<slug>.md:
- Idea Summary — the idea refined through discussion
- Participants — who weighed in and their final stances
- Recommendation — PROCEED / PROCEED WITH CONDITIONS / DO NOT PROCEED / PIVOT TO...
- Supporting Arguments — strongest points in favor, attributed to specific personas
- Dissenting Views — who disagreed and why, preserved faithfully
- Risks & Mitigations — failure modes with concrete mitigations
- Vetoes — any veto holders who blocked, and resolution status
- Next Steps — concrete actions if proceeding
If the recommendation is PROCEED or PROCEED WITH CONDITIONS, a product requirements document is also generated at docs/prd/YYYY-MM-DD-<slug>-prd.md:
- Problem Statement — who, what pain, why now
- Target User — specific role, context, workflow
- Success Metrics — with concrete targets and measurement methods
- Functional Requirements — numbered, prioritized (P0/P1/P2), with acceptance criteria
- Non-Functional Requirements — security, reliability, quality, performance, observability
- Architecture Guidance — chosen approach, rejected alternatives, open questions
- Out of Scope — what was explicitly excluded and why
- Implementation Phases — phased delivery with decision gates and veto holder sign-offs
- Traceability Matrix — every requirement mapped to the persona argument that established it
How It Works
/startup AI-powered code review tool that learns team patterns
Phase 0 — Team Selection. A selector agent analyzes your idea and picks 5-8 relevant personas from the built-in 15 plus any previously-created project-local personas. Veto holders are always included when their domain applies. If the idea touches a domain no existing persona covers, the selector flags the gap, asks you to confirm, and a new full-depth persona is created and saved to .claude/personas/ in your project for future reuse.
Phase 1 — Initial Positions. All selected personas respond in parallel with their domain-specific assessment: opportunities, risks, conditions for support, and an initial stance.
Phase 2 — Adversarial Rounds. Personas challenge each other directly. They quote specific arguments, explain why they're wrong, defend when challenged, and update their stances. A facilitator evaluates convergence after each round. Rounds continue until consensus or until disagreements are clearly irreconcilable (max 5 rounds by default).
Phase 3 — Synthesis. The decision owner makes the final call using a Truth Hierarchy to resolve value conflicts:
Reality > Safety > Correctness > Long-Term > UX > Market > Speed > Narrative
Phase 4 — Decision Document. A decision document is written to docs/decisions/YYYY-MM-DD-<slug>.md with the full recommendation, supporting arguments, dissenting views, risks, vetoes, and next steps.
machinesoul11
slgoodrich
SergeiGorbatiuk
Hainrixz
wshobson
phuryn