cross-review

Cross-Review — Structured Cross-File Verification

Execute multi-round cross-consistency verification on changed files. Exit only when a round produces zero findings. Focuses on inter-file structural consistency.

Announce at start: "Using ecw:cross-review to verify cross-file consistency."

Relationship with Other Verification Components

Component	What It Reviews	Distinction
ecw:cross-review (this skill)	Intra-file/cross-file structural consistency	Multi-round convergence, focuses on document consistency, manual optional
ecw:impl-verify	Code correctness + quality	Multi-round convergence, focuses on code vs requirements/rules/Plan/standards, mandatory step
ecw:spec-challenge	Plan blind spots, boundary conditions	Plan phase, not implementation phase
verify-completion hook	Reference existence, compilation, knowledge sync	Mechanical hard intercept, not semantic check

Execution Protocol

Round 1 — Cross-File Consistency Matrix

Goal: Is the same concept described consistently across multiple files?

Operations:

1. List all files changed in this round (git diff --name-only or from task context)
2. Extract structured content from each file:
   • Table rows (markdown table rows)
   • List items (bulleted/numbered lists)
   • Enumerated values (e.g., "4 checks", "6 knowledge files")
   • Config items (YAML keys, JSON fields)
   • Dimension/field lists (e.g., comparison table rows)
3. For the same concept appearing in 2+ files, cross-compare item by item:
   • Table A row count = Table B row count?
   • List A items = List B items? Same content?
   • Are terms/names consistent across all files? (e.g., "Phase 3" vs "Risk Phase 3")
   • Do quantity references ("4 checks") match actual content?
4. For each inconsistency, record: [FileA:line] vs [FileB:line] — describe the difference

Round 2+ (Conditional Trigger) — Fix Side-Effect Check

Triggered only when Round 1 found issues that have been fixed.

Operations:

1. For files involved in fixes, re-run Round 1 cross-comparison
2. Confirm fixes did not introduce new inconsistencies
3. If this round finds more issues, fix and continue to next round

Convergence Condition

Most recent round has zero findings → exit, output verification passed report.

• Loop cap: Maximum 5 rounds. If findings remain after 5 rounds, output all unresolved items and suggest user intervention.
• Recurring inconsistency detection: If the same inconsistency (same File A + File B + same concept) appears in 2 consecutive rounds, mark it as [Known issue: persists after fix attempt] and exclude from convergence blocking. This prevents infinite loops from inconsistencies that resist automated fixing.

Output Format

Per-round output:

### Cross-Review Round {N} — {dimension name}

**Check scope**: {file list}

**Findings**:

| # | File A | File B | Inconsistency Description | Severity |
|---|--------|--------|--------------------------|----------|
| 1 | README.md:148 | ecw-validate-config.md:132 | Knowledge file list differs by 1 item (missing cross-domain-rules.md) | must-fix |
| 2 | SKILL.md:395 | SKILL.md:320 | Step 4 table has 4 rows, Step 1 table has 5 rows (missing "external systems") | must-fix |

**This round: {N} issues found. Will execute Round {M} after fixes.**

Zero findings output:

### Cross-Review Round {N} — {dimension name}

**Check scope**: {file list}

**Findings**: None

**This round zero findings, verification passed.**

Final pass summary:

## Cross-Review Verification Passed

After {N} rounds of verification (fixed {M} issues), cross-file consistency check passed for all changed files.

Error Handling

Scenario	Handling
git diff --name-only returns empty	No changed files to review → notify user and exit
File listed in diff no longer exists (deleted after diff)	Skip that file in cross-comparison, note [Skipped: {file} deleted]

Constraints

• Loop cap: Maximum 5 rounds. If findings remain after 5 rounds, output all unresolved items and suggest user intervention.
• Skippable scenarios: Pure formatting changes, comment/log-only changes with clearly no business logic impact.
• Out of scope:
  • Does not verify code correctness or quality (ecw:impl-verify's responsibility)
  • Does not analyze business impact (ecw:biz-impact-analysis's responsibility)
  • Does not check compilation/references (verify-completion hook's responsibility)
  • Does not review plan design (ecw:spec-challenge's responsibility)

Common Rationalizations

Your Thought	Reality
"It's just a terminology difference, not a real inconsistency"	Users reading different files will see different terms for the same concept. This IS an inconsistency. Fix it.
"The counts are close enough"	If one file says 6 items and another checks 5, there is a missing check. "Close enough" in documentation becomes a missed dimension in production.
"Round 2 found no new issues, probably clean"	Round 2 checks fixes for side effects. A fix in File A may introduce inconsistency with File C not in Round 1's scope.
"These are just docs, not code, severity is low"	Documents drive behavior. Inconsistent docs produce inconsistent implementations. must-fix applies to structural inconsistencies regardless of file type.
"5 rounds is enough, remaining issues are minor"	If findings persist after 5 rounds, they need user intervention, not dismissal. Output all unresolved items.

Common Cross-Inconsistency Patterns

For focused attention in Round 1:

Pattern	Example
List length mismatch	README says "6 knowledge files", validate-config only checks 5
Table dimension omission	Comparison table Step 1 has 5 dimension rows, Step 4 template only has 4
Inconsistent terminology	One place says "Phase 3", another says "Risk Phase 3"
Component reference omission	Added new command, but ecw-init "Next Steps" doesn't mention it
Incomplete routing chain	Workflow diagram has a step, but Skill Interaction table does not
Config-implementation desync	Template added a field, but validation command doesn't check it