Arch mvp roadmap

Skill ai-enhanced-engineer/aiee-skills/skills/arch-mvp-roadmap

MVP definition, MoSCoW prioritization, and phased delivery planning. Use for scoping minimum viable products, ordering features by value and dependency, or creating implementation roadmaps.From its SKILL.md

Install

npx -y skills add ai-enhanced-engineer/aiee-skills --skill arch-mvp-roadmap

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 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.

SKILL.md

3.5 KB, as published. Nobody here has run it

MVP & Roadmap Planning

Patterns for defining what to build first and in what order.

Core Principle

"Build the smallest thing that proves value."

An MVP is not a half-built product—it's a complete vertical slice that validates assumptions.

MoSCoW Prioritization

Priority	Definition	Criteria
Must Have	System doesn't function without	Core journey incomplete, no workarounds
Should Have	Important but not blocking	Workarounds exist, high value
Visible as Placeholder	UI ships visible but non-functional at launch; wired up in a later phase	Surface needed for UX coherence/nav completeness; functionality deferred
Could Have	Nice to have	Enhances experience, low priority
Won't Have	Explicitly out of scope	Prevents scope creep, document for later

Visible-as-Placeholder Tier — When To Use

Standard MoSCoW leaves a gap: features that need to be visible at launch but not functional yet. Naming this tier explicitly makes the app feel coherent without over-promising.

Use Visible-as-Placeholder (not Could-have) when:

Removing the surface would leave a hole in nav, settings, or a flow users will notice
A linked feature elsewhere references this surface (deep links, empty-state CTAs, dashboard tiles)
The functional version is planned for a known later phase

Use Could-have instead when the feature's absence is invisible or there is no committed plan to ship it.

See reference.md § Visible-as-Placeholder for a worked marketplace example with five surfaces.

MVP Scoping Checklist

Single complete user journey end-to-end
Validates core assumption/hypothesis
Deployable and demonstrable
Measurable success criteria defined
No features without corresponding tests

Phased Delivery Pattern

Each phase should:

Build on previous phase (not parallel development)
Be independently deployable
Have clear success criteria
Include tests for new functionality

Dependency Ordering

Order features by:

Factor	Question
Technical	What must exist first?
Value	What provides most value soonest?
Risk	What validates riskiest assumptions?
Learning	What teaches us most about the domain?

Roadmap Template

Phase	Features	Success Criteria	Dependencies
MVP	[Must-haves]	[Measurable outcomes]	None
Phase 2	[Should-haves]	[Measurable outcomes]	MVP complete
Phase 3	[Could-haves]	[Measurable outcomes]	Phase 2 complete

Extensible Algorithm Design

Design algorithms for evolution using stable interfaces. MVP delivers value immediately while building ground truth for future ML phases. Evolution path: Deterministic (MVP) → Statistical (Phase 2) → ML/embeddings (Phase 3) → LLM-powered (Phase 4). Switch implementations via dependency injection against a stable Protocol interface; MVP uses zero ML infrastructure.

See reference.md § Extensible Algorithm Design for the interface pattern, key principles, and workstream-split sizing. See examples.md for sample roadmaps.