Verifying Spec

Verifying Spec (Main-Agent Verification Gate)

This is the verification gate after upstream superpowers' self-review. The user explicitly required main-agent verification (NOT a subagent) for context preservation, transparency, and accuracy.

When to Invoke

-requirements.md is the source of truth and is therefore not a verification target.

Procedure

digraph verify_flow {
    "Read target MD + all upstream MDs" [shape=box];
    "A. Consistency check" [shape=box];
    "C. Code impact analysis" [shape=box];
    "Compose 4-axis report" [shape=box];
    "Present to user" [shape=diamond];
    "User decision:\nproceed / no" [shape=diamond];
    "Re-enter prior skill\n(tech-design or writing-plans)" [shape=box];
    "Proceed" [shape=doublecircle];

    "Read target MD + all upstream MDs" -> "A. Consistency check";
    "Read target MD + all upstream MDs" -> "C. Code impact analysis";
    "A. Consistency check" -> "Compose 4-axis report";
    "C. Code impact analysis" -> "Compose 4-axis report";
    "Compose 4-axis report" -> "Present to user";
    "Present to user" -> "User decision:\nproceed / fix";
    "User decision:\nproceed / no" -> "Re-enter prior skill\n(tech-design or writing-plans)" [label="no"];
    "User decision:\nproceed / no" -> "Proceed" [label="proceed"];
}

A. Consistency Check

Verify every upstream item is reflected in the target. Two failure modes:

• 누락 (gap): an upstream FR/decision that does not appear downstream
• 모순 (conflict): an upstream constraint contradicted downstream

Checklist

When target = <slug>-tech-design.md:

• Every FR-N from -requirements.md is mapped to -tech-design.md §2 (impacted components) or §4 (external interfaces)
• Every NFR is addressed in -tech-design.md §6 (risks) or §7 (test strategy)
• -tech-design.md does not contradict -requirements.md (e.g., out-of-scope items are not added back)

When target = <slug>-implementation-plan.md:

• Every key decision in -tech-design.md §5 maps to at least one task in -implementation-plan.md §1
• Every risk category from -tech-design.md §6 has at least one entry in -implementation-plan.md §2 위험 코드 지점
• Every FR is implementable through the listed tasks (trace FR → decision → task chain)

C. Code Impact Analysis

For files/functions/endpoints named in the target MD:

1. File existence — Read/Glob to confirm the file exists or is explicitly created in a task
2. Caller mapping — Grep the function/symbol name to count usage sites
3. Side-effect candidates — Apply the risk-annotation 3-checklist (complex branching, public signature/schema changes, shared state) to each touched function
4. Test coverage — Check whether the touched files have tests (Glob test_*.py or *.test.* adjacent or under tests/)

When grep results span ≥10 files, optionally dispatch ONE read-only Explore subagent for the impact survey only, then synthesize the report yourself.

Report Format

Output to the conversation in this exact structure:

🔍 verifying-spec 보고서 — 대상: <target>.md (upstream: <list>)

## A. Consistency
✅ Mapped: <count> items (e.g., FR-1, FR-2, FR-3 → §2/§4)
⚠️ Gaps: <count>
   - <upstream item ID> "<title>" → not found in <target> §<section>
❌ Conflicts: <count>
   - <upstream item> says X, <target> says Y

## C. Code Impact
- Impacted files: <list> (<count>)
- Callers: <function> referenced in <count> places (<list>)
- Risk candidates: <category-counts> (e.g., side-effect: 2, breaking: 1)
- Test coverage: <existing test files / coverage gaps>

## 권장 (recommendation)
- <gap or conflict> → suggest <action>
- <risk candidate> → suggest <mitigation or §6 augmentation>

진행 / 수정 중 선택해주세요.

The 진행 / 수정 line is in Korean because the user chooses verbally.

Anti-Patterns

Red Flags

Acceptance

A verification run is complete when ALL hold:

1. Report includes all 4 axes (consistency-gaps, consistency-conflicts, impact-files+callers+risks, test-coverage)
2. Counts are concrete (not "some" or "a few")
3. The closing prompt offers 진행 / 수정 choices to the user

Related Skills

• tech-design — invokes this on save
• writing-plans — invokes this on save
• risk-annotation — supplies the 3-checklist used in §C
• change-history — captures the verification outcome in the next entry's 영향범위 field