| name | mvp-readiness-assessment |
| description | Use when determining MVP readiness status across domains, identifying blockers preventing completion, assessing domain maturity levels, or prioritizing next work targets |
MVP Readiness Assessment
Overview
Rapidly assess current MVP state against audit criteria and identify blockers. Provides structured readiness scoring, domain maturity analysis, and prioritized next-target recommendations based on leverage and impact.
When to Use
Trigger when:
- MVP phase transition decisions needed
- Current state of preparedness unclear across domains
- Prioritization of next work target required
- Stakeholder readiness reporting needed
- After major commits to verify progress
When NOT to use:
- Detailed code review (use verification-before-completion)
- Architectural redesign (requires design skill)
- Individual test debugging (use systematic-debugging)
Structured Approach
Phase 1: Quick State Inspection
- Run
git status to identify recent changes
- Check test results:
python run_tests.py --suite all
- Review recent commits (last 5-10) for scope
- Scan
'fy'-suites/ directories for audit reports
- Identify latest blockers from git history
Phase 2: Domain Checklist
Assess 6 critical domains (score: 0% = not started, 50% = partial, 100% = complete):
| Domain | Meaning | Status Check |
|---|
| Runtime Authority | Turn execution framework complete, seams verified | Check turn_graph.py, validation logic, commit effects |
| Validation Rules | GoC validation engine formalized and testable | Check GATE_SCORING_POLICY_GOC.md, rule specifications |
| Commit Effects | State transitions apply correctly, persistence works | Check world_state.py updates, database migrations |
| Evidence Visibility | Render/visibility pipeline complete and correct | Check render functions, observer pattern implementation |
| Continuity | Turn carry-forward logic correct, no state drift | Check state initialization, reset functions |
| Governance | Gates passing, baselines current, enforcement working | Check fy_governance_enforcement.yaml, audit reports |
Phase 3: Blocker Identification
For each domain scoring <100%, document:
- What's preventing completion? (missing code, failing tests, spec gap)
- Is it a hard blocker (other domains depend) or soft blocker (independent)?
- Effort estimate (hours)
- Risk level (low/medium/high)
Phase 4: Maturity Scoring
Current score: (domain1% + domain2% + ... + domain6%) / 6
Target: 100% across all domains
Gap analysis: 100% - current_score = work_remaining
Phase 5: Next-Target Intelligence
Identify 3 candidate targets:
- Highest leverage: Unlocks other work, reduces wait times
- Lowest risk: Can be completed independently, high confidence
- Fastest to complete: Quick win, builds momentum
Recommend best based on: leverage + confidence + time available
Required Inputs
- Access to git history and current status
- Test suite results (backend tests minimum)
- Audit reports from fy-suite directories
- Project documentation (GATE_SCORING_POLICY, turn graph specs)
Outputs
Markdown report with:
- Current readiness score (0-100%)
- Domain maturity matrix with scores and status
- Blocker list (what's preventing each incomplete domain)
- Recommended next target (with justification)
- Evidence snapshot (recent commits, test status)
Example Usage
Scenario: Ready to assess MVP before phase transition
User: "Is MVP ready for stakeholder review?"
You:
- Run quick state inspection (git, tests, audit reports)
- Score each domain against checklist
- Identify blockers per domain
- Calculate overall readiness score
- Recommend 3 targets, pick best
- Report: "MVP is 74% ready (runtime 100%, validation 50%, commit 85%, visibility 90%, continuity 60%, governance 80%). Primary blocker: validation engine not formalized. Recommend next: formalize validation rules (leverage: unblocks testing, risk: low, time: 8 hours)."
Related Project Docs
- GATE_SCORING_POLICY_GOC.md (validation principles)
- CANONICAL_TURN_CONTRACT_GOC.md (turn graph contract)
- fy_governance_enforcement.yaml (gate thresholds)
- test_reports/ (audit results)
- backend/tests/conftest.py (fixture definitions)
Common Mistakes
| Mistake | Fix |
|---|
| Scoring without checking code (opinion-based) | Always inspect: tests, audit reports, source files |
| Confusing "complete" with "perfect" | 100% means minimum viable, not fully optimized |
| Ignoring hard blocker dependencies | Check which domains other domains depend on |
| Picking next target by interest not leverage | Use leverage matrix to prioritize impact |
| Not documenting blocker evidence | Always capture "what prevents this" with specifics |
Real-World Impact
Saves 2-3 hours of stakeholder/team sync time per readiness check. Moves MVP decisions from ambiguous ("is it ready?") to data-driven ("here's the gap"). Enables prioritization by actual impact, not noise.
