re-verify-structure
npx skills add https://github.com/caldiaworks/caldiaworks-marketplace --skill re-verify-structure
Agent 安装分布
Skill 文档
Structure Verification â Reverse Engineering Phase 1 Critic
Verify the structure map produced by re-structure-analysis against the actual source code. This skill runs as an independent Critic in a separate agent context. It has no access to the Doer’s reasoning â only the artifacts.
Gate rule: Phase 2 (re-visualize-logic) shall not proceed until this verification produces a PASS or WARN verdict.
Three Principles (Critic Perspective)
1. Code is Truth
- The source code is the sole authority. If the structure map says something the code does not confirm, the structure map is wrong.
2. Traceability to Line
- Every
file:linereference in the structure map must resolve to actual code. Unresolvable references are hallucinations.
3. Behavior over Intent
- Verify what the structure map claims against what the code shows. Do not interpret or justify discrepancies.
Execution
Step 1: Load Artifacts
Determine the manifest path:
- If
manifestargument is provided, use it directly - If
analysisargument is provided, derive path asdocs/reverse/{analysis}/manifest.json - At least one of
manifestoranalysismust be provided
Read the manifest and structure map:
{manifest-path}
{analysis-dir}/01-structure-map.md
Extract from the manifest:
targets.entry_pointsâ original user-specified targetsphase1.statusâ must be"completed"to proceedlanguageâ for tool strategy
If phase1.status is not "completed", report error and stop.
Step 2: Reference Verification
Extract all file:line references from the structure map.
For each reference:
- File existence: Verify the file exists at the specified path.
- Line validity: Read the file and verify the line number is within range.
- Content match: Verify the content at the cited line matches the claim in the structure map.
Classify each reference:
| Category | Criteria |
|---|---|
| â VALID | File exists, line exists, content matches claim |
| â ï¸ INACCURATE | File exists, content found within ±10 lines of cited line |
| â INVALID | File does not exist, or line number grossly wrong |
| ð« HALLUCINATION | Component described in structure map cannot be found in source code at any location |
Step 3: Completeness Verification
Count actual components in the target scope and compare with the structure map.
With Serena:
mcp__serena__search_for_pattern(
substring_pattern="class |interface |def |function ",
restrict_search_to_code_files=true
)
Without Serena:
- Use Grep to count class/function definitions in the target scope
- Compare with the number listed in the structure map
Calculate coverage: (listed_in_map / actual_in_source) * 100
| Coverage | Verdict |
|---|---|
| >= 95% | PASS |
| 90% – 94% | WARN |
| < 90% | FAIL |
List any components found in source but missing from the structure map.
Step 4: Mermaid Diagram Validation
For each Mermaid code block in the structure map:
- Check syntax validity (matching brackets, valid node definitions, valid arrow syntax)
- Spot-check 3 nodes/relationships against source code
- Document any syntax errors or content inaccuracies
Step 5: Internal Consistency Check
Verify that:
- Components in dependency diagrams are also listed in component tables
- Entry points in diagrams match the entry point section
- File paths are consistent throughout the document
targets_for_phase2in the manifest references components that exist in the structure map
Step 6: Generate Verification Report
Write to docs/reverse/{analysis}/verification/v1-structure.md:
# Structure Map Verification Report
**Verification Date**: {YYYY-MM-DD}
**Target Document**: docs/reverse/{analysis}/01-structure-map.md
**Verdict**: {PASS / WARN / FAIL}
## Summary
| Check | Result | Details |
|:------|:-------|:--------|
| Reference Accuracy | {â
/â ï¸/â} | {valid}/{total} references ({%}) |
| Component Coverage | {â
/â ï¸/â} | {listed}/{actual} components ({%}) |
| Mermaid Syntax | {â
/â ï¸/â} | {error_count} errors |
| Internal Consistency | {â
/â ï¸/â} | {inconsistency_count} issues |
## Verdict
{PASS}: Phase 2 may proceed.
{WARN}: Minor issues found. Phase 2 may proceed. Corrections recommended.
{FAIL}: **Critical issues found. Phase 2 must not proceed. Corrections required.**
## Reference Verification Details
### Invalid References
| Claim | File:Line | Issue | Expected |
|:------|:----------|:------|:---------|
| {claim} | {reference} | {issue description} | {correct reference or "not found"} |
### Hallucinations
- {component}: {reason it is considered hallucinated}
## Completeness Details
### Missing Components
| Component | File | Type |
|:----------|:-----|:-----|
| {name} | {file path} | {class/function/interface} |
## Mermaid Validation
### Syntax Errors
- Block {N}: {error description}
### Content Inaccuracies
- Node "{node}": {discrepancy}
## Internal Consistency Issues
- {description of inconsistency}
## Recommendations
1. **[CRITICAL]** {fix description}
2. **[HIGH]** {fix description}
3. **[MEDIUM]** {fix description}
Step 7: Update Manifest
Read the current manifest, then update:
- Set
phase1.verificationto"verification/v1-structure.md" - If verdict is
PASSorWARN: setphase1.statusto"verified" - If verdict is
FAIL: leavephase1.statusas"completed"(do not promote) - Update
updatedtimestamp
Verdict Criteria
| Criterion | PASS | WARN | FAIL |
|---|---|---|---|
| Reference accuracy | >= 95% | 80-94% | < 80% |
| Component coverage | >= 95% | 90-94% | < 90% |
| Mermaid errors | 0 | 1-2 | >= 3 |
| Hallucinations | 0 | 0 | >= 1 |
Any single FAIL criterion results in an overall FAIL verdict.
Prohibited Actions
- Do NOT modify the structure map document
- Do NOT modify source code files
- Do NOT assume missing information â flag it as an issue
- Do NOT approve documents with FAIL status
- Do NOT access the Doer’s conversation context or reasoning