nakane1chome/sdlc-cross-review

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.

0. 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

1. 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?

2. 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?

3. 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?

4. 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.

References

• V-model (software development) - Wikipedia
• The V-model explained - IAPM
• What Is the V-Model in Software Development? - Built In