Review the target document(s) at $ARGUMENTS against its SDLC lifecycle context.
Stop after each stage and have changes reviewed with user.
Note: This skill checks a document's position and consistency within a project hierarchy — it does not polish the document itself. Stages 0-4 are analysis only — findings are presented for discussion, not applied as edits. The developer holds final authority on all judgment calls.
- •
Read and identify context (developer confirms)
- •Read the target document and its surrounding project structure
- •What is this document about and where does it sit in the project?
- •Can you identify a document hierarchy (V-model, or project-defined)?
- •If the project defines its own hierarchy, use that; otherwise ask the developer to clarify
- •Confirm understanding of the document's position before proceeding
- •
Assess completeness (agent proposes, developer decides)
- •Is this a skeleton that needs fleshing out, or a draft that needs polishing?
- •Skeletons need generative work (structure, diagrams, missing sections) — that's a flesh-out task, not a cross-review
- •Drafts with language issues need review-steps first
- •If the document isn't ready for cross-review, recommend the appropriate skill and stop
- •Ask: does the developer want to proceed with cross-review now, or address completeness first?
- •
Review vs parent document (agent critiques, developer discusses)
- •Identify the parent document(s) that constrain this document (left side, decomposition)
- •Is the target document consistent with decisions and constraints in its parent(s)?
- •Are there contradictions or gaps between the target and its parent documents?
- •Does the target document trace back to requirements or decisions in the parent?
- •Present findings and ask: are any inconsistencies intentional or reflect evolved thinking?
- •
Cross-validate against the right side (agent critiques, developer discusses)
- •Identify the validation pair for this document (see V-Model Context below)
- •Do validation artifacts exist that cover what the document specifies?
- •Is anything specified in the document that has no corresponding validation?
- •Is anything validated that isn't specified in the document?
- •Ask: are missing validation artifacts a known gap, or an oversight?
- •
Summary and recommendations (agent leads)
- •What is the document's overall consistency with its hierarchy?
- •What are the top issues to address?
- •Recommendation: consistent / minor gaps / needs rework
Pipeline Position
This skill sits outside the main pipeline (flesh-out -> review-steps -> strong-edit -> agent-optimize). It's a lateral check — validating a document against its project context, not polishing the document itself. Run it when a document is mature enough to check against its hierarchy.
When to Use This vs Other Skills
| Goal | Use |
|---|---|
| Raw notes need structure and expansion | flesh-out |
| Draft needs polish and consistency | review-steps |
| Complete draft needs critical evaluation | strong-edit |
| Check document against its SDLC hierarchy | sdlc-cross-review |
| Finalized document needs agent-friendly restructuring | agent-optimize |
V-Model Context
The V-model pairs each definition stage with a corresponding testing stage. The left side decomposes requirements; the right side validates them. Each level on the right validates the corresponding level on the left.
Requirements Analysis ◄──────────────────► Acceptance Testing
│ ▲
│ constrains │ validates
▼ │
System Design ◄────────────────────────────► System Testing
│ ▲
│ constrains │ validates
▼ │
Architecture Design ◄──────────────────────► Integration Testing
│ ▲
│ constrains │ validates
▼ │
Module Design ◄────────────────────────────► Unit Testing
│ ▲
│ constrains │ validates
▼ │
Implementation
Standard Cross-Validation Pairs
| Left Side (Definition) | Right Side (Validation) |
|---|---|
| Requirements analysis | Acceptance testing |
| System design | System testing |
| Architecture design | Integration testing |
| Module design | Unit testing |
Not every project will use all levels. Identify which levels the project uses and apply the relevant checks.