<!-- Generated by mstack from Misbah's Build Like This workflow. Regenerate instead of editing. -->

plan-mvp

Plan an MVP that tests the highest-risk product assumption with the least product and operational complexity. This is earlier than feature-planning: use after research-idea when the idea deserves a bounded experiment, before or instead of a full feature-design pass. Do not treat this prompt as a synonym of the feature-planning skill.

This prompt follows Misbah Khursheed's Build Like This workflow: establish the user outcome and reasoning before generating implementation, then preserve that reasoning in contracts, boundaries, tests, and documentation.

Project identity and sources of truth

The repository where this prompt is installed is the host project being built. Build Like This is the engineering method used to build it, while mstack only installs and reconciles the method's resources. Do not mistake mstack or Build Like This for the host product unless project-owned sources explicitly say this repository develops mstack itself.

Project-owned docs/, decisions, executable code, and tests are the sources of truth. .mstack/templates/ are reference scaffolds that may be copied and adapted into project-owned documents; they are not requirements and do not replace docs/.

Treat the invocation arguments and current repository state as task input. Discover local instructions and relevant product, architecture, decision, contract, and test context before making material assumptions.

Method

1. Separate known evidence, assumptions, and open questions; identify the target user and painful current behavior.
2. Define the outcome and falsifiable success signal before proposing features.
3. Map the minimum end-to-end journey and all user-visible states needed for a trustworthy experience.
4. Rank assumptions by impact and uncertainty; choose scope that tests the riskiest one without speculative platform work.
5. Define non-goals, permissions, data/privacy boundaries, operational constraints, and explicit kill/revisit criteria.
6. Translate scope into a short learning and delivery sequence; hand agreed capabilities to feature-planning only when implementation slices are the next decision.

Deliverables

• Problem/evidence/assumption ledger and target outcome metric.
• MVP journey, scope, non-goals, acceptance criteria, and failure/degraded behavior.
• Ordered learning plan with risks, cost/operations considerations, and next-stage triggers (including when to invoke feature-planning).

Constraints

• Do not substitute feature count or launch date for a user outcome.
• Do not include multi-tenant scale, extensibility, or integrations without an MVP requirement.
• Do not present fabricated market evidence or metrics as fact.
• Do not expand into detailed contract/module task breakdowns that belong in feature-planning.

Delegation and parallel safety

• For a material lifecycle task, the active lead must delegate at least one bounded specialist lane when subagents are available; prefer two or more concurrent lanes only when their evidence or file ownership is independent.
• The active lead owns acceptance criteria and final integration. Supporting agents must not recursively delegate unless explicitly promoted to lead a named lane.
• Give each delegate distinct inputs, outputs, and ownership. Serialize shared documents, contracts, schemas, migrations, deployments, external writes, and overlapping file edits.
• If subagents are unavailable, perform the named specialist passes sequentially and report the limitation; do not imply parallel verification.
• Delegation does not authorize outreach, paid resources, destructive changes, consequential external writes, or production deployment.

Finish with what changed or was decided, exact verification evidence, remaining risks, and the next decision only if one is genuinely required.

Apply any arguments supplied by the user as task-specific input.