Mvp roadmap orchestrator
Skill Sheshiyer/skill-clusters/skills/mvp-roadmap-orchestrator
Hub-and-spoke agent-skill clusters, one per stack (Astro·GSAP·Remotion, Tauri, …). Installable via skills.sh.
npx -y skills add Sheshiyer/skill-clusters --skill mvp-roadmap-orchestratorAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when turning a problem statement into an MVP plan, prioritization stack (Value/Effort, RICE, KANO, MoSCoW), 2-week sprint roadmap, PRD pack, and governed delivery documentation.
SKILL.md
8.5 KB, ~1.9k tokens by cl100k_base, as published. Nobody here has run it
MVP Roadmap Orchestrator
Convert a raw idea into an execution-ready MVP plan with explicit prioritization, risk gates, scope control, and versioned product documentation.
Use When
Activate when the user asks for:
- problem statement → MVP
- roadmap, sprint plan, PRD, or delivery planning
- prioritization with Value/Effort, RICE, KANO, or MoSCoW
- POC before roadmap commitment
- 2-week sprint stories, Gantt/timeline, or scope governance
- documentation/versioning for product delivery
Out of Scope (Default)
Do not treat these as MVP by default unless explicitly requested:
- enterprise/compliance edge cases
- advanced automation and “nice-to-have” integrations
- multi-region scale architecture
- non-critical redesign work
Input Contract (Ask if Missing)
Before planning, gather:
- Target user + top pain
- Business objective + timeline
- Team capacity (roles, availability)
- Constraints (budget, legal, platform, dependencies)
- Success metric baseline (if available)
If key inputs are missing, ask targeted questions first.
Core Principles
- Problem-first, feature-second.
- Evidence over opinion.
- POC before full commitment on risky items.
- Scope discipline over roadmap vanity.
- Versioned docs and explicit decision ownership.
Execution Workflow
0) Discovery + Alignment
- Restate the problem and desired outcome in one paragraph.
- Confirm audience split: dev team, exec team, business, ops.
- Define planning horizon (MVP only vs MVP + next 2 horizons).
1) Problem Statement → Outcome Definition
- Capture pain, affected segment, current workaround, and impact.
- Define north-star metric + 2–4 leading indicators.
- Define MVP success threshold (launch is “done when …”).
2) Opportunity Backlog Creation
- Generate initiatives from user pain, business goals, and constraints.
- Add effort assumptions, dependencies, and risk notes per item.
- Mark each assumption as validated / unvalidated.
3) Prioritization Framework Stack (in order)
A) Value vs Effort
- Plot each opportunity: Quick Wins / Strategic Bets / Fill-ins / Avoid.
- Remove low-value high-effort items from MVP candidate list.
B) RICE
- Score formula:
(Reach × Impact × Confidence) / Effort. - Show scoring ranges and assumptions for each variable.
- Flag low-confidence high-score items for validation.
C) KANO
- Classify as Must-have / Performance / Delighter.
- Keep Delighters out of MVP unless they unlock adoption risk.
D) MoSCoW
- Gate final sprint scope into Must/Should/Could/Won’t (this cycle).
- Explicitly list exclusions and rationale.
4) POC Gate (Before Roadmap Lock)
- Select top 1–3 risks (technical, desirability, viability, operational).
- Define each POC with:
- hypothesis
- success/fail criteria
- timebox
- owner
- decision date
- Require Go / No-Go / Pivot decision before roadmap commitment.
5) Research + Testing Loop
- Plan lightweight validation: interviews, surveys, prototype tests, concierge.
- Capture insight → decision mapping:
- keep
- modify
- drop
- Update RICE confidence and MoSCoW gates after each evidence round.
6) SLC Framing + Data Events
Define MVP through SLC:
- Simple: minimum viable user journey
- Lovable: moments that create confidence and repeat use
- Complete: end-to-end task completion for one core use case
For each SLC element, define data events:
- event name
- trigger point
- properties
- owner
- dashboard metric linkage
7) PRD Pack
Create PRD sections:
- problem/opportunity statement
- target users + JTBD
- scope in/out
- assumptions + dependencies
- functional requirements
- non-functional requirements
- acceptance criteria
- data/analytics plan
- risk register + mitigations
- launch readiness gates
8) Sprint Plan (2-Week Cadence)
- Build 2-week sprints with capacity-aware allocation.
- Write user stories using INVEST quality bar.
- Include acceptance tests for each story.
- Sequence work by dependency chain (product/design/dev/ops/legal if needed).
9) Timeline + Gantt View
- Convert sprint plan to timeline with milestones and decision gates.
- Mark critical path, parallel tracks, and buffer windows.
- Include rollback/contingency milestones for risky deliveries.
10) Scope Governance + Execution
- Use change requests for any new item after sprint lock.
- Re-score new work with RICE + MoSCoW before acceptance.
- Enforce WIP limits and prevent stealth scope creep.
11) Iterate + Version Documentation
- Run sprint review + retro with user and stakeholder feedback.
- Update roadmap as a time-based vision expansion.
- Version PRD, roadmap, events taxonomy, decisions, and release notes.
Hardened Controls (20 Improvements)
- Explicit input contract before planning.
- Mandatory clarification when critical fields are missing.
- Scope boundary section (Out of Scope) to prevent bloat.
- Assumption tagging as validated/unvalidated.
- Standard RICE formula and transparent scoring.
- Confidence-risk flags for low-confidence high-score items.
- Ordered framework stack to avoid random prioritization.
- Explicit exclusion list with rationale.
- POC Go/No-Go/Pivot gate before roadmap lock.
- Timeboxed POC with owner and decision date.
- Evidence update loop that re-scores priorities.
- SLC model tied to measurable data events.
- Event schema fields (name/trigger/properties/owner/metric).
- PRD minimum required sections defined.
- INVEST quality bar for stories.
- Acceptance tests required per story.
- Capacity-aware 2-week sprint planning.
- Critical path + contingency in timeline/Gantt.
- Change request + re-prioritization for scope creep.
- Documentation versioning + decision log ownership.
Output Artifacts (Default)
- Problem-to-MVP summary (with success criteria)
- Prioritized opportunity backlog (with Value/Effort + RICE + KANO + MoSCoW)
- POC plan with decision gates
- PRD draft or structured PRD outline
- 2-week sprint plan + user stories + acceptance tests
- Gantt-style timeline with milestones and critical path
- Scope governance policy (change control + prioritization rules)
- Documentation/versioning checklist + decision log template
Reusable Templates (Use by Default)
PRDTemplate.mdDecisionLogTemplate.mdBacklogScoringTemplate.md
When generating deliverables, instantiate these templates first, then fill with project-specific details.
NotebookLM Asset Automation (Python Module)
Use wired scripts to generate source-backed research artifacts and prefill planning docs:
- Wrapper (recommended):
run_mvp_pipeline.py - Generator:
generate_assets_notebooklm.py - Prefill:
prefill_templates_from_assets.py - Guide:
NotebookLMIntegration.md
Default flow:
- Ensure auth (
notebooklm login). - Run generator with sources (URLs/files) and selected assets.
- Run prefill script to produce PRD/backlog/decision drafts.
- Review and finalize with team-specific constraints.
Default command pattern:
./run_mvp_pipeline.py \
--project-dir /path/to/project \
--owner "<Owner>" \
--asset report --asset mind-map --asset data-table
Manual two-step fallback:
./generate_assets_notebooklm.py \
--title "MVP Research - <project>" \
--source "https://example.com" \
--source ./problem-statement.md \
--asset report --asset mind-map --asset data-table \
--output-dir ./outputs/<project>
./prefill_templates_from_assets.py \
--assets-dir ./outputs/<project> \
--templates-dir . \
--output-dir ./outputs/<project>/prefilled \
--project "<Project Name>" \
--owner "<Owner>"
Quality Gates (Definition of Done)
A plan is complete only when:
- success metrics are measurable,
- assumptions are explicit and risk-ranked,
- POC gates are defined for top risks,
- priorities include transparent scoring and exclusions,
- stories are testable and capacity-bounded,
- data events map to outcomes,
- and document ownership/versioning is clear.
Failure Modes to Avoid
- jumping into roadmap before defining MVP success
- scoring without confidence assumptions
- mixing Must-have and Delighter work in same sprint without rationale
- accepting scope changes without re-scoring
- claiming completion without testable acceptance criteria