Orchestrates technical review of a PRD: evaluates completeness and feasibility, validates estimation quality, and produces a technical risk report across four phases.
HARD-GATE
Review the document, not the idea.
Every finding must cite a specific PRD section.
Halt Phase 1 if more than two items in any checklist category are unchecked.
Do not silently continue past a High-severity feasibility concern.
Halt Phase 3 if coverage is below 80% or more than three realism flags are raised.
Agent Phases
Phase 1: PRD Review
- Audit the PRD for completeness, testability, and clarity using the checklist below:
Completeness
- Problem statement is clearly defined with measurable success criteria
- All user roles and actors are identified
- Functional requirements are explicit
- Non-functional requirements (performance, security, scalability) are stated
- Out-of-scope items are explicitly listed
Testability
- Each requirement has a verifiable acceptance criterion
- Edge cases and failure modes are specified
- Integration touchpoints have defined contracts or SLAs
Clarity
- No ambiguous terms (e.g., "fast", "easy", "scalable" without thresholds)
- Data flows and ownership are unambiguous
- Dependencies on external systems are named and versioned
- Gate check — PRD Completeness: If more than two items in any category are unchecked, halt and return a structured list of gaps to the requester, requesting PRD revision before proceeding. If the PRD passes, continue to Phase 2.
Phase 2: Feasibility Assessment
-
For each functional and non-functional requirement, evaluate:
- Technical feasibility: Can this be built with known, available technology?
- Dependency risk: Are external systems, APIs, or data sources reliable and accessible?
- Architectural fit: Does the proposed approach align with common scalable patterns, or does it introduce structural contradictions?
- Constraint conflicts: Do performance, security, or compliance requirements conflict with each other or with stated scope?
-
Assign each concern a severity level:
- High: Blocks delivery or requires fundamental redesign
- Medium: Requires significant rework but is solvable within scope
- Low: Minor risk, addressable during implementation
-
Gate check — Feasibility: If any High-severity concern is identified, flag it explicitly, explain the blocker, and recommend either (a) revising the PRD to remove the constraint, (b) reducing scope, or (c) proceeding with a documented risk. Do not silently continue.
Phase 3: Estimation Quality Review
-
Review all task estimates provided in or alongside the PRD using the checklist below:
Coverage
- All functional requirements have associated estimates
- Non-functional requirements (performance tuning, security hardening) are costed
- Integration, testing, and deployment tasks are included
- Buffer or contingency is present for high-uncertainty items
Realism
- Estimates are broken into tasks no larger than 2 days (or a defined sprint unit)
- No single estimate covers an entire phase without decomposition
- Dependencies between tasks are sequenced (parallelism is not assumed by default)
Consistency
- Similar tasks have similar estimates (flag outliers)
- Estimates align with the stated team size and skill level
-
Gate check — Estimation Quality: If coverage is below 80% of requirements, or if more than three realism flags are raised, return a structured estimation gap report and request revised estimates before producing the final risk report.
Phase 4: Technical Risk Report
Produce a structured Technical Risk Report using the following format:
## Technical Risk Report
### PRD Review Summary
- Completeness: [Pass / Conditional Pass / Fail]
- Testability: [Pass / Conditional Pass / Fail]
- Clarity: [Pass / Conditional Pass / Fail]
- Open gaps: <bulleted list of unresolved items, or "None">
### Feasibility Assessment
| Concern | Area | Severity | Recommendation |
|---------|------|----------|----------------|
| <description> | <e.g., Integration / Architecture / NFR> | High / Medium / Low | <action> |
### Estimation Quality
- Coverage: <percentage or qualitative rating>
- Realism flags: <count and summary>
- Consistency issues: <summary or "None">
### Go / No-Go Recommendation
**Recommendation**: [Go | Go with Conditions | No-Go]
**Rationale**: <2–4 sentences summarising the basis for the recommendation>
**Conditions (if applicable)**:
- <Condition 1 that must be resolved before proceeding>
- <Condition 2>
### Next Steps
- <Actionable step 1 — owner if known>
- <Actionable step 2>
Worked example: assets/example-risk-report.md.
Feedback Loop
- PRD fails Phase 1 gate: Return gap list to requester, suspend further phases, and await revised PRD.
- Feasibility blocker in Phase 2: Flag High-severity items immediately. If requester confirms proceeding at risk, document the decision and continue with a "Go with Conditions" posture.
- Estimation gaps in Phase 3: Return estimation gap report. If requester cannot provide revised estimates, note coverage deficit in the final risk report and adjust the recommendation accordingly.
- All gates pass: Proceed directly to Phase 4 and issue a Go recommendation with any Low/Medium concerns listed as watch items.
Integration
| Skill | When to chain |
|---|---|
review-prd |
Phase 1 |
estimate-tasks |
Phase 3 |
create-prd |
When Phase 1 returns Needs Revision |
identify-risks |
After a Go-with-conditions report |