This checklist is part of the Agentic SDLC — How to Deliver with Confidence guide. It is designed to be used independently. No prior reading is required.
Use this checklist when peer-reviewing a technical specification before code generation begins. The specification is the contract between the team and the generator. What is approved here determines what gets built. Review accordingly.
Completeness
- Every requirement from the PRD (if one exists) is addressed in the specification
- The specification describes both what is being built and how it will be built
- Data models are defined with field names, types, relationships, and constraints
- API contracts are defined with endpoints, request/response shapes, error codes, and versioning approach
- Edge cases and error conditions are identified and addressed
- Dependencies on external systems, services, or data sources are listed
- Non-functional requirements (performance targets, scalability constraints, availability expectations) are stated explicitly, not assumed
Testability of Acceptance Criteria
- Every acceptance criterion is verifiable — a reviewer can determine pass or fail without subjective judgment
- Acceptance criteria cover both the happy path and failure modes
- Acceptance criteria are specific enough to detect drift: if the generated code deviates from the specification, at least one criterion will fail
- No acceptance criterion relies on unstated assumptions about the implementation
Architecture Alignment
- The proposed design aligns with existing architecture decisions (check the team’s decision records)
- Any new architecture decisions introduced by the specification are identified and flagged for capture
- The specification does not introduce patterns that conflict with established conventions
- Integration points with existing systems are described clearly enough that the generator can implement them correctly
- If the specification deviates from existing decisions, the deviation is justified and the decision record is updated or superseded
Security Considerations
- Authentication and authorization requirements are stated for every endpoint and data access path
- Input validation rules are defined for all user-facing inputs
- Sensitive data handling (PII, credentials, tokens) is addressed: how it is stored, transmitted, and logged
- Third-party integrations are evaluated for trust boundaries and data exposure
- The specification does not introduce known vulnerability patterns (injection, privilege escalation, data leakage)
Domain Coverage
- The specification identifies which specialist review domains are relevant (database, security, API, infrastructure, performance, architecture)
- Database changes include migration strategy, rollback plan, and data integrity considerations
- API changes include backward compatibility analysis and consumer impact assessment
- Infrastructure changes include deployment strategy, scaling impact, and failure mode analysis
- Performance-sensitive paths are identified and performance expectations are stated
Reviewability
- The specification is scoped narrowly enough that a single reviewer can evaluate it in one session
- If the specification covers multiple independent concerns, it should be split
- The specification provides enough context that a reviewer who is not the author can understand the design without a walkthrough