GigLedger MVP Validator

Purpose

This skill provides fast scope validation for GigLedger features:

• •Check if a feature is in MVP scope
• •Verify acceptance criteria
• •Identify scope creep
• •Flag future roadmap items
• •Validate against PRD requirements

Source of Truth

Primary Reference: docs/02_mvp_prd.md

This document defines what is and is not in the MVP.

Core Principle

If it's not in the docs, it's not a requirement.

Before implementing ANY feature, validate it against the PRD.

In-Scope Features (MVP)

These features are APPROVED for implementation:

Reference: docs/02_mvp_prd.md section 3

[List your in-scope features from the PRD]

Out of Scope (Explicit Rejections)

These features are NOT in MVP - reject implementation requests:

Reference: docs/02_mvp_prd.md section 4

[List your out-of-scope features from the PRD]

Monetization (MVP-Compatible)

Free Tier

In Scope [List free tier features]

Pro Tier

In Scope (configurable at launch) [List pro tier features]

Pricing TBD - see docs/08_monetization_and_pricing.md

Reference: docs/02_mvp_prd.md section 5

Technical Constraints

[Backend]

• •[Constraint 1]
• •[Constraint 2]
• •[Constraint 3]

[External API] (if applicable)

• •[Constraint 1]
• •[Constraint 2]

[Framework]

• •[Constraint 1]
• •[Constraint 2]
• •[Constraint 3]

Reference: docs/02_mvp_prd.md section 6

Acceptance Criteria (High-Level)

MVP is complete when:

• • User can [key action 1]
• • User can [key action 2]
• • User can [key action 3]
• • App runs consistently on [platforms]
• • No sensitive credentials exposed client-side

Reference: docs/02_mvp_prd.md section 7

MVP Exit Criteria

MVP is considered complete when:

• • All in-scope features are implemented
• • Performance is acceptable on mid-range devices
• • Data accuracy is validated against known test cases
• • App is deployable to [stores/platforms]

Reference: docs/02_mvp_prd.md section 8

Validation Workflow

When Evaluating a Feature Request

Step 1: Check In-Scope List

• •Is the feature explicitly listed in section 3 of docs/02_mvp_prd.md?
• •If YES → Proceed with implementation
• •If NO → Go to Step 2

Step 2: Check Out-of-Scope List

• •Is the feature explicitly listed in section 4 of docs/02_mvp_prd.md?
• •If YES → Reject the feature (add to roadmap if valuable)
• •If NO → Go to Step 3

Step 3: Evaluate Against MVP Goals Ask:

1. •Does it help users [achieve core value]?
2. •Does it enable [core user journey]?
3. •Is it essential for MVP validation?

• •If YES to all → Consult with product owner, potentially add to docs first
• •If NO to any → Reject as scope creep

Step 4: Document Decision

• •If accepted: Update docs/02_mvp_prd.md section 3
• •If rejected: Update docs/09_roadmap.md for future consideration

Common Scope Questions

Q: [Common question 1]?

Answer: [Answer with reference]

Q: [Common question 2]?

Answer: [Answer with reference]

Q: [Common question 3]?

Answer: [Answer with reference]

Quick Validation Checklist

Before implementing a feature:

• • Feature is explicitly listed in docs/02_mvp_prd.md section 3
• • Feature is NOT in the out-of-scope list (section 4)
• • Acceptance criteria are defined
• • Technical constraints are understood
• • No scope creep - feature is minimal viable version
• • Feature aligns with MVP goals

If all boxes are checked → Proceed

If any box is unchecked → Consult PRD or product owner

When to Use This Skill

Use this skill when:

• •Starting a new feature (validate scope first)
• •Reviewing a GitHub ticket or feature request
• •Deciding if a bug fix is in scope
• •Evaluating a suggested enhancement
• •Planning sprint priorities
• •Reviewing PRs for scope creep

Example Validations

Example 1: "[Feature that's out of scope]"

Validation:

1. •Check in-scope list → Not found
2. •Check out-of-scope list → [Related item] explicitly out of scope
3. •Decision: Reject (add to roadmap)

Example 2: "[Feature that's in scope]"

Validation:

1. •Check in-scope list → Section 3.X "[Feature description]"
2. •Decision: Approve (explicitly in scope)

Example 3: "[Optional feature]"

Validation:

1. •Check in-scope list → Section 3.X (optional MVP+)
2. •Decision: Optional (implement if time permits, not blocking MVP)

Summary

The MVP Validator ensures:

• •Features align with documented scope
• •Scope creep is identified and prevented
• •Development stays focused on MVP goals
• •Future ideas are captured in roadmap, not MVP

Remember: Always reference docs/02_mvp_prd.md before implementing any feature. If it's not documented, stop and validate first.

Final Rule

If a feature is not explicitly in docs/02_mvp_prd.md section 3, it is OUT OF SCOPE until documented.

No exceptions. Update docs first, then code.