PRD Implementation Precheck

Overview

Perform a short PRD precheck, surface material issues, then implement. Ask the user only when a missing choice would materially change behavior, architecture, data, or external side effects.

Workflow

Locate the PRD and any referenced files.
Precheck the PRD and summarize intent in 1-2 sentences.
List findings and questions with blockers first. If there are no material blockers, state assumptions and continue.
When a blocker exists, resolve it with the user before implementation.
Validate (tests or manual steps) or state what was not run.

Precheck Checklist

Basic Checks

Scope: Identify over-broad changes; suggest a smaller, targeted approach.
Alignment: Flag conflicts with existing patterns or architecture; propose alternatives.
Dependencies: Note missing hooks/providers/data sources or unclear ownership.
Behavior: Verify flows and edge cases are specified; ask for gaps.
Risks: Call out performance, regressions, or migration risks.
Testing: Check success criteria and test coverage; request specifics if vague.

Edge Case Coverage Checks

Verify the PRD addresses these edge cases (mark as ⚠️ if missing):

Data Boundaries

[ ] Null/Empty handling - What happens with empty inputs or null values?
[ ] Boundary values - Are min/max limits defined? What happens at boundaries?
[ ] Duplicate data - How are duplicates detected and handled?
[ ] Data format - Are input formats validated? What about special characters?

State Boundaries

[ ] State transitions - Are all valid state transitions defined?
[ ] Invalid transitions - What happens on illegal state changes?
[ ] Concurrent modifications - How are simultaneous edits handled?
[ ] Rollback scenarios - Can operations be undone? How?

Error Boundaries

[ ] Network failures - What happens when API calls fail?
[ ] Timeout behavior - Are timeouts defined? What's the retry strategy?
[ ] Partial failures - If step 2 of 3 fails, what happens to step 1?
[ ] Error messages - Are user-facing error messages defined?

UX Boundaries

[ ] Empty states - What does the user see with no data?
[ ] Loading states - How is loading indicated?
[ ] Success feedback - How does the user know the action succeeded?
[ ] Permission denied - What happens when user lacks permission?

Codebase Consistency Checks

Scan the codebase to verify PRD aligns with existing patterns:

# Check if PRD's proposed patterns match existing code
grep -r "pattern_from_prd" src/ --include="*.ts"

[ ] Delete strategy - Does PRD match existing soft/hard delete pattern?
[ ] Error handling - Does PRD use the same error display mechanism?
[ ] Component reuse - Does PRD leverage existing components?
[ ] API patterns - Does PRD follow existing API conventions?

Output Format

Precheck Report Template

## PRD Precheck Report

### Summary
{1-2 sentence summary of what the PRD aims to achieve}

### ✅ Covered Edge Cases
- {List edge cases that are well-defined in the PRD}

### ⚠️ Missing Edge Cases
| Edge Case | Category | Suggested Default | Needs Confirmation |
|-----------|----------|-------------------|-------------------|
| Empty list display | UX | Use existing EmptyState | No |
| Concurrent edit | State | Last write wins | **Yes** |

### 🔴 Blockers
- {Critical issues that must be resolved before implementation}

### 🟡 Warnings
- {Non-critical issues that should be addressed}

### Questions for User
1. {Specific question about missing edge case}
2. {Specific question about ambiguous requirement}

---

**Proceed as-is, or update the PRD?**

Output Expectations

Provide a concise precheck report with questions and risks.
Ask "Proceed as-is, or update the PRD?" only when the answer changes the implementation materially.
If there are no blockers, state assumptions and continue without a redundant confirmation round.