PRD Impact Analyzer

⛔ CRITICAL: Check git.autoCommit before committing registry changes

Trigger: Before running git commit in Step 7.

Check: Read project.json → git.autoCommit (or receive from parent agent)

• If true (default): Proceed with commit normally
• If false: NEVER run git commit — failure to comply violates project constraint

When autoCommit is disabled:

1. Stage files: git add docs/prd-registry.json docs/prd-impact-report.md
2. Report what would be committed and suggested message
3. Let parent agent handle commit reporting to user

Analyzes how a completed PRD affects other PRDs in the backlog. This ensures the PRD registry stays accurate and helps identify when:

• Dependencies are now satisfied
• Conflict risks have changed
• Stories in other PRDs are now simpler or unnecessary
• New capabilities enable additional features

Your Task

0. Load Project Context (FIRST)

   a. Get the project path:

   • The parent agent passes the project path in the prompt
   • If not provided, use current working directory

   b. Load project configuration:

   • Read <project>/docs/project.json if it exists — this tells you the project structure

   c. Project context provides:

   • Directory structure for understanding touchesAreas
   • API/component naming conventions for matching new capabilities

Examples

Example Impact Analysis

## PRD Impact Analysis

### Completed PRD: prd-user-preferences

**Summary:** Added user preferences system with settings panel, 
preferences API, and storage layer.

### Impact on Backlog PRDs

#### prd-notification-system (HIGH IMPACT)
**Status:** Draft
**Impact:** 
- Now depends on preferences API for notification settings
- US-003 (notification frequency) can use existing preferences storage
- Estimate reduced: preferences infrastructure already built

**Recommended changes:**
- Add dependency on prd-user-preferences
- Remove "build preferences storage" story (already done)
- Update US-003 to integrate with existing preferences API

#### prd-dark-mode (MEDIUM IMPACT)
**Status:** Ready
**Impact:**
- Theme preference can leverage existing preferences panel
- Storage mechanism already exists
- Add "theme" field to preferences schema

**Recommended changes:**
- Add story: "Add theme toggle to existing preferences panel"
- Remove duplicate storage implementation

#### prd-mobile-app (LOW IMPACT)
**Status:** Backlog
**Impact:**
- Mobile app will need to consume same preferences API
- No immediate changes needed
- Note: Ensure API is mobile-friendly

### No Impact

These PRDs are unaffected:
- prd-billing-improvements (unrelated domain)
- prd-admin-dashboard (different user type)

Example Dependency Graph

## Updated Dependency Graph

After completing prd-user-preferences:

\`\`\`
prd-user-preferences (COMPLETE)
    │
    ├── prd-notification-system (blocked → unblocked)
    │   └── prd-email-digests (still blocked by notifications)
    │
    ├── prd-dark-mode (can start integration)
    │
    └── prd-mobile-app (informational dependency)
\`\`\`

**Newly unblocked:** prd-notification-system
**Ready to integrate:** prd-dark-mode
**No change:** prd-mobile-app, prd-billing-improvements

When a PRD is completed, analyze its impact on all other PRDs (both drafts and active).

Input

You will receive:

• Completed PRD ID
• List of files changed
• List of new capabilities (APIs, tables, components)

Step 1: Gather Context

1. Read the completed PRD to understand what was built:

   # Find the archived PRD
   find docs/completed -name "*[prdId]*" -type f
   

2. Read the PRD registry:

   • docs/prd-registry.json - All PRDs with their status, dependencies, and conflict info

3. List all draft and active PRDs:

   ls docs/drafts/*.md docs/prds/*.json 2>/dev/null
   

4. Get the list of changed files from the completed PRD:

   # If you have the branch info, or from the task prompt
   

Step 2: Analyze Dependencies

For each PRD in the registry where dependsOn includes the completed PRD:

1. Check if the dependency is now satisfied
2. If yes, update the PRD status from "blocked" to "active" (if it was blocked)
3. Log: "[prdId] is now unblocked - [completedPrd] dependency satisfied"

Example:

prd-customer-portal depends on prd-customers-addresses
prd-customers-addresses just completed
→ prd-customer-portal is now unblocked

Step 3: Analyze Conflict Risks

For each PRD, check if the completed work changes conflict risk:

1. Compare touchesAreas between completed PRD and other PRDs

2. If completed PRD modified shared areas, the risk may have DECREASED:

   • Other PRDs touching the same area can now build on stable code
   • Update conflictRisk from high → medium or medium → low

3. If completed PRD introduced NEW areas that other PRDs will need:

   • Add those areas to touchesAreas for affected PRDs
   • This may INCREASE conflict risk with other in-progress PRDs

Example:

prd-time-slots completed, touched:
  - components/calendar/TimeSlotGrid.tsx
  - hooks/useTimeSlots.ts
  
prd-recurring-events also touches components/calendar/*
→ Conflict risk may have decreased since time-slots is done
→ Update: prd-recurring-events conflictRisk with time-slots: "none" (completed)

Step 4: Analyze Story Impact

For each draft PRD, check if any stories are affected:

1. Stories that are now SIMPLER:

   • If completed PRD added an API/component that a draft story planned to create
   • Mark in notes: "Can reuse [component] from [completedPrd]"

2. Stories that are now UNNECESSARY:

   • If completed PRD already implemented what a story planned
   • Mark in notes: "Already implemented by [completedPrd] - consider removing"

3. Stories that need UPDATING:

   • If completed PRD changed an API that a story depends on
   • Mark in notes: "API changed by [completedPrd] - update acceptance criteria"

Example:

prd-customers-addresses added:
  - Address validation API at /api/addresses/validate
  
prd-route-optimization had story:
  "US-005: Add address validation for route stops"
  
→ Story is now simpler: "Can call existing /api/addresses/validate"

Step 5: Update Registry

Update docs/prd-registry.json with findings:

1. Remove completed PRD from conflictsWith arrays in other PRDs
2. Update dependency status for PRDs that depended on completed PRD
3. Adjust conflictRisk levels based on analysis
4. Update touchesAreas if new shared areas discovered

Step 6: Generate Impact Report

Create docs/prd-impact-report.md with a summary:

# PRD Impact Report

**Completed PRD:** [name] ([id])
**Completed Date:** YYYY-MM-DD
**Analysis Date:** YYYY-MM-DD HH:MM

## Summary

- X PRDs unblocked
- Y conflict risks updated  
- Z stories in drafts affected

## Unblocked PRDs

| PRD | Was Blocked By | New Status |
|-----|----------------|------------|
| customer-portal | customers-addresses | active |

## Conflict Risk Changes

| PRD | Old Risk | New Risk | Reason |
|-----|----------|----------|--------|
| recurring-events | high (time-slots) | none | time-slots completed |

## Story Impact

### prd-route-optimization

| Story | Impact | Notes |
|-------|--------|-------|
| US-005 | Simpler | Can reuse /api/addresses/validate |

### prd-notifications

| Story | Impact | Notes |
|-------|--------|-------|
| US-003 | Unnecessary | Already implemented by time-slots (event notifications) |

## Recommendations

1. **prd-customer-portal** is now ready to start
2. **prd-route-optimization** should update US-005 to reference new address API
3. Consider removing US-003 from prd-notifications

---
*This report was auto-generated by prd-impact-analyzer*

Step 7: Commit Changes

If changes were made to the registry:

git add docs/prd-registry.json docs/prd-impact-report.md
git commit -m "docs: analyze impact of [prdId] completion"

Output

Return a summary of findings:

PRD Impact Analysis Complete

Completed: [prdId] - [name]

Changes made:
- Updated prd-registry.json
- Created docs/prd-impact-report.md

Key findings:
- 2 PRDs unblocked (customer-portal, route-optimization)
- 3 conflict risks reduced
- 4 stories in drafts can be simplified

Full report: docs/prd-impact-report.md

Notes

• Only update the registry if there are actual changes
• Be conservative with "unnecessary" story flags - let humans make final decisions
• Always create the impact report even if no changes, so there's an audit trail
• Delete the previous impact report before creating a new one (only keep most recent)