Team Deliverables
Templates and scoring rubrics for the final outputs of multi-agent team workflows.
When to Use This Skill
Auto-loaded by all six agents:
idea-researcher, market-researcher, idea-skeptic - For validation verdict and competitive synthesis scoring rubricsmarket-fit-reviewer, feasibility-reviewer, scope-reviewer - For PRD review report scoring rubrics
Use when you need:
- Generating the final output of a team workflow
- Scoring ideas, PRDs, or competitive positions
- Structuring multi-perspective findings into a single deliverable
- Ensuring consistent output format across team workflows
Template Selection Guide
| Command |
Template |
When |
/agent-teams:validation-sprint |
Validation Verdict |
After cross-examination of idea investigation |
/agent-teams:prd-stress-test |
PRD Review Report |
After cross-referencing PRD review dimensions |
/agent-teams:competitive-war-room |
Competitive Synthesis |
After parallel competitor deep-dives |
Scoring Rubrics
Validation Sprint Scores (1-10)
User Problem Score
| Score |
Meaning |
| 1-2 |
No evidence of real user pain. Problem is theoretical. |
| 3-4 |
Some users mention this, but it's a mild annoyance. Existing solutions work "well enough." |
| 5-6 |
Real problem, but unclear severity or frequency. Some workarounds exist. |
| 7-8 |
Clear, validated pain point. Users actively seeking solutions. Workarounds are inadequate. |
| 9-10 |
Hair-on-fire problem. Users spending significant time/money on bad workarounds. |
Market Opportunity Score
| Score |
Meaning |
| 1-2 |
Tiny niche. No evidence of willingness to pay. Market too small to sustain a business. |
| 3-4 |
Small market or crowded space with no clear differentiation angle. |
| 5-6 |
Viable market but competitive. Differentiation possible but unproven. |
| 7-8 |
Attractive market with clear gaps. Evidence of willingness to pay. Timing is right. |
| 9-10 |
Large, growing market with underserved segments. Strong demand signals. Clear entry point. |
Defensibility Score
| Score |
Meaning |
| 1-2 |
No moat. Any competitor could copy this in weeks. Pure feature play. |
| 3-4 |
Weak differentiation. First-mover advantage only, which isn't a moat. |
| 5-6 |
Some defensibility through domain expertise, data, or network effects. Not bulletproof. |
| 7-8 |
Strong differentiation with compounding advantages. Switching costs for users. |
| 9-10 |
Deep moat. Proprietary data, strong network effects, or structural advantage. |
PRD Review Scores (1-5)
Market Fit Score
| Score |
Meaning |
| 1 |
No clear target user or problem. Fundamental market questions unanswered. |
| 2 |
Target user defined but problem validation missing. "If you build it, will they come?" is unaddressed. |
| 3 |
Problem and user are clear, but differentiation is weak. Could be any competitor's PRD. |
| 4 |
Strong problem-solution fit. Clear differentiation. Minor positioning gaps. |
| 5 |
Excellent. Clear user, validated problem, sharp differentiation, compelling value prop. |
Feasibility Score
| Score |
Meaning |
| 1 |
Major technical unknowns. Requirements are vague or contradictory. Can't estimate effort. |
| 2 |
Core approach is clear but many requirements are ambiguous. Multiple "TBD" sections. |
| 3 |
Mostly clear. Some edge cases missing, some acceptance criteria need tightening. Buildable with clarification. |
| 4 |
Clear requirements, well-defined acceptance criteria. Minor gaps. Ready for engineering review. |
| 5 |
Precise, testable requirements. Edge cases covered. Acceptance criteria are specific and measurable. |
Scope Score
| Score |
Meaning |
| 1 |
Massive scope. Years of work presented as an MVP. No prioritization visible. |
| 2 |
Too much for V1. Some nice-to-haves mixed in with must-haves. Needs significant cutting. |
| 3 |
Reasonable but could be tighter. A few features could be deferred without losing core value. |
| 4 |
Well-scoped. Clear must-haves, reasonable timeline. Only minor fat to trim. |
| 5 |
Ruthlessly scoped. 3-5 core features. Clear what's in V1 vs. later. Ships fast. |
Template Standards
Required Elements in Every Deliverable
- Header: Command name, date, subject (idea/PRD/competitors)
- Scores: Numerical scores with brief justification
- Verdict: Clear recommendation (BUILD / DON'T BUILD / READY / NEEDS REVISION / etc.)
- Evidence: Key findings from each agent's investigation
- Conflicts: Where agents disagreed and why
- Next Steps: Specific, actionable recommendations
Formatting Rules
- Use tables for scores (scannable)
- Use bullet points for findings (not paragraphs)
- Bold the verdict and any blocking issues
- Keep the executive summary under 5 lines
- Put detailed evidence in expandable sections when the report is long
Ready-to-Use Resources
In assets/:
- validation-verdict-template.md: Go/No-Go format with three perspectives for validation sprints
- prd-review-report-template.md: Multi-dimensional review with conflicts section for PRD stress tests
- competitive-synthesis-template.md: Positioning map and battle cards format for competitive war rooms
Troubleshooting
"The template doesn't fit our findings": Adapt it. Drop sections that add nothing, expand sections where you have depth. A template that forces empty placeholder text is worse than no template. The structure is a starting point, not a constraint.
"Scores across reviewers aren't comparable": Check that all reviewers used the same rubric anchors. A 4/5 from one reviewer should mean the same thing as a 4/5 from another. If they're using different mental scales, re-calibrate by sharing the rubric definitions before the next run.
"The verdict is ambiguous (BUILD IF with too many conditions)": That usually means the idea needs more validation, not a conditional pass. If there are more than 3 conditions, downgrade to NEEDS MORE EVIDENCE and list what to validate next.
Related
/agent-teams:validation-sprint - Produces validation verdicts using these templates/agent-teams:prd-stress-test - Produces PRD review reports using these templates/agent-teams:competitive-war-room - Produces competitive syntheses using these templatesteam-coordination - Debate and synthesis protocols that feed into these deliverables
Remember: Templates create consistency, not rigidity. Adapt sections when the findings demand it. A template that forces you to fill in blanks with nothing useful is worse than no template.
1---2name: team-deliverables3description: Output templates and scoring rubrics for multi-agent team workflows. Use when generating final deliverables from agent team debates, formatting validation verdicts, or scoring PRD reviews. Trigger on: 'format the team output', 'validation verdict template', 'PRD review report format', 'competitive synthesis template', 'scoring rubric'.4---56# Team Deliverables78Templates and scoring rubrics for the final outputs of multi-agent team workflows.910## When to Use This Skill1112**Auto-loaded by all six agents**:1314- `idea-researcher`, `market-researcher`, `idea-skeptic` - For validation verdict and competitive synthesis scoring rubrics15- `market-fit-reviewer`, `feasibility-reviewer`, `scope-reviewer` - For PRD review report scoring rubrics1617**Use when you need**:1819- Generating the final output of a team workflow20- Scoring ideas, PRDs, or competitive positions21- Structuring multi-perspective findings into a single deliverable22- Ensuring consistent output format across team workflows2324## Template Selection Guide2526| Command | Template | When |27| ----------------------------------- | --------------------- | --------------------------------------------- |28| `/agent-teams:validation-sprint` | Validation Verdict | After cross-examination of idea investigation |29| `/agent-teams:prd-stress-test` | PRD Review Report | After cross-referencing PRD review dimensions |30| `/agent-teams:competitive-war-room` | Competitive Synthesis | After parallel competitor deep-dives |3132---3334## Scoring Rubrics3536### Validation Sprint Scores (1-10)3738**User Problem Score**3940| Score | Meaning |41| ----- | ------------------------------------------------------------------------------------------ |42| 1-2 | No evidence of real user pain. Problem is theoretical. |43| 3-4 | Some users mention this, but it's a mild annoyance. Existing solutions work "well enough." |44| 5-6 | Real problem, but unclear severity or frequency. Some workarounds exist. |45| 7-8 | Clear, validated pain point. Users actively seeking solutions. Workarounds are inadequate. |46| 9-10 | Hair-on-fire problem. Users spending significant time/money on bad workarounds. |4748**Market Opportunity Score**4950| Score | Meaning |51| ----- | ------------------------------------------------------------------------------------------ |52| 1-2 | Tiny niche. No evidence of willingness to pay. Market too small to sustain a business. |53| 3-4 | Small market or crowded space with no clear differentiation angle. |54| 5-6 | Viable market but competitive. Differentiation possible but unproven. |55| 7-8 | Attractive market with clear gaps. Evidence of willingness to pay. Timing is right. |56| 9-10 | Large, growing market with underserved segments. Strong demand signals. Clear entry point. |5758**Defensibility Score**5960| Score | Meaning |61| ----- | --------------------------------------------------------------------------------------- |62| 1-2 | No moat. Any competitor could copy this in weeks. Pure feature play. |63| 3-4 | Weak differentiation. First-mover advantage only, which isn't a moat. |64| 5-6 | Some defensibility through domain expertise, data, or network effects. Not bulletproof. |65| 7-8 | Strong differentiation with compounding advantages. Switching costs for users. |66| 9-10 | Deep moat. Proprietary data, strong network effects, or structural advantage. |6768### PRD Review Scores (1-5)6970**Market Fit Score**7172| Score | Meaning |73| ----- | ------------------------------------------------------------------------------------------------------ |74| 1 | No clear target user or problem. Fundamental market questions unanswered. |75| 2 | Target user defined but problem validation missing. "If you build it, will they come?" is unaddressed. |76| 3 | Problem and user are clear, but differentiation is weak. Could be any competitor's PRD. |77| 4 | Strong problem-solution fit. Clear differentiation. Minor positioning gaps. |78| 5 | Excellent. Clear user, validated problem, sharp differentiation, compelling value prop. |7980**Feasibility Score**8182| Score | Meaning |83| ----- | -------------------------------------------------------------------------------------------------------------- |84| 1 | Major technical unknowns. Requirements are vague or contradictory. Can't estimate effort. |85| 2 | Core approach is clear but many requirements are ambiguous. Multiple "TBD" sections. |86| 3 | Mostly clear. Some edge cases missing, some acceptance criteria need tightening. Buildable with clarification. |87| 4 | Clear requirements, well-defined acceptance criteria. Minor gaps. Ready for engineering review. |88| 5 | Precise, testable requirements. Edge cases covered. Acceptance criteria are specific and measurable. |8990**Scope Score**9192| Score | Meaning |93| ----- | -------------------------------------------------------------------------------------------- |94| 1 | Massive scope. Years of work presented as an MVP. No prioritization visible. |95| 2 | Too much for V1. Some nice-to-haves mixed in with must-haves. Needs significant cutting. |96| 3 | Reasonable but could be tighter. A few features could be deferred without losing core value. |97| 4 | Well-scoped. Clear must-haves, reasonable timeline. Only minor fat to trim. |98| 5 | Ruthlessly scoped. 3-5 core features. Clear what's in V1 vs. later. Ships fast. |99100---101102## Template Standards103104### Required Elements in Every Deliverable1051061. **Header**: Command name, date, subject (idea/PRD/competitors)1072. **Scores**: Numerical scores with brief justification1083. **Verdict**: Clear recommendation (BUILD / DON'T BUILD / READY / NEEDS REVISION / etc.)1094. **Evidence**: Key findings from each agent's investigation1105. **Conflicts**: Where agents disagreed and why1116. **Next Steps**: Specific, actionable recommendations112113### Formatting Rules114115- Use tables for scores (scannable)116- Use bullet points for findings (not paragraphs)117- Bold the verdict and any blocking issues118- Keep the executive summary under 5 lines119- Put detailed evidence in expandable sections when the report is long120121---122123## Ready-to-Use Resources124125### In `assets/`:126127- **validation-verdict-template.md**: Go/No-Go format with three perspectives for validation sprints128- **prd-review-report-template.md**: Multi-dimensional review with conflicts section for PRD stress tests129- **competitive-synthesis-template.md**: Positioning map and battle cards format for competitive war rooms130131---132133## Troubleshooting134135**"The template doesn't fit our findings"**: Adapt it. Drop sections that add nothing, expand sections where you have depth. A template that forces empty placeholder text is worse than no template. The structure is a starting point, not a constraint.136137**"Scores across reviewers aren't comparable"**: Check that all reviewers used the same rubric anchors. A 4/5 from one reviewer should mean the same thing as a 4/5 from another. If they're using different mental scales, re-calibrate by sharing the rubric definitions before the next run.138139**"The verdict is ambiguous (BUILD IF with too many conditions)"**: That usually means the idea needs more validation, not a conditional pass. If there are more than 3 conditions, downgrade to NEEDS MORE EVIDENCE and list what to validate next.140141---142143## Related144145- `/agent-teams:validation-sprint` - Produces validation verdicts using these templates146- `/agent-teams:prd-stress-test` - Produces PRD review reports using these templates147- `/agent-teams:competitive-war-room` - Produces competitive syntheses using these templates148- `team-coordination` - Debate and synthesis protocols that feed into these deliverables149150---151152**Remember**: Templates create consistency, not rigidity. Adapt sections when the findings demand it. A template that forces you to fill in blanks with nothing useful is worse than no template.
slgoodrich