re-verify-logic
Logic Verification — Reverse Engineering Phase 2 Critic
Verify logic diagrams produced by re-visualize-logic against actual source code. Runs as an independent Critic in a separate agent context.
Gate rule: Phase 3 (re-extract-requirements) shall not proceed until verification produces a PASS or WARN verdict for all components.
Three Principles (Critic Perspective)
1. Code is Truth
- The source code is the sole authority. If the logic diagram says something the code does not confirm, the diagram is wrong.
2. Traceability to Line
- Every line number in the diagram must resolve to actual code. Unresolvable references are hallucinations.
3. Behavior over Intent
- Verify what the diagram claims against what the code shows. Do not interpret or justify discrepancies.
Execution
Step 1: Load Artifacts
Read docs/reverse/{analysis}/manifest.json.
Determine which components to verify:
- If
componentargument is provided, verify only that component - If omitted, verify all entries in
phase2.completedthat haveverification: null
For each component, read the logic diagram: docs/reverse/{analysis}/02-logic-{component}.md
Step 2: Line Number Verification
For each node in the Mermaid diagram and each row in the node-to-line mapping table:
- Extract the cited line number
- Read the source file at that line
- Compare the code at that line with the claim
Classify:
- ✅ MATCH: Code at cited line matches the description
- ⚠️ OFFSET: Code found within ±5 lines
- ❌ MISMATCH: Code at cited line does not match
- 🚫 HALLUCINATION: Described behavior not found in source at any location
Step 3: Mermaid Syntax Validation
Check each Mermaid code block for:
- Valid node definitions and arrow syntax
- No prohibited characters (
!=,>=,[],()in text) - Parseable structure (matching brackets, valid subgraphs)
Step 4: Completeness Check
Compare the logic diagram against the source method:
- Count control flow branches in source (if/else, switch cases, loops)
- Count corresponding nodes in the diagram
- Flag missing branches
Check side effects documentation:
- Grep source for database operations, network calls, file I/O, logging
- Verify each is documented in the side effects summary
Step 5: Generate Verification Report
Write to docs/reverse/{analysis}/verification/v2-logic-{component}.md:
# Logic Diagram Verification: {component}
**Verification Date**: {YYYY-MM-DD}
**Target Document**: 02-logic-{component}.md
**Verdict**: {PASS / WARN / FAIL}
## Summary
| Check | Result | Details |
|:------|:-------|:--------|
| Line Number Accuracy | {✅/⚠️/❌} | {match}/{total} nodes ({%}) |
| Mermaid Syntax | {✅/⚠️/❌} | {error_count} errors |
| Branch Coverage | {✅/⚠️/❌} | {covered}/{total} branches ({%}) |
| Side Effects | {✅/⚠️/❌} | {documented}/{total} side effects ({%}) |
## Verdict
{PASS/WARN/FAIL}: {explanation}
## Details
### Line Number Issues
| Node | Claimed Line | Actual Line | Issue |
|:-----|:-------------|:------------|:------|
### Missing Branches
- {description of missing branch at file:line}
### Missing Side Effects
- {description of undocumented side effect at file:line}
## Recommendations
1. **[{severity}]** {fix description}
Step 6: Update Manifest
For each verified component:
- Update
phase2.completed[].verificationto"verification/v2-logic-{component}.md"
After all components are verified:
- If all verdicts are PASS or WARN: set
phase2.statusto"verified" - If any verdict is FAIL: leave
phase2.statusas"completed" - Update
updatedtimestamp
Verdict Criteria
| Criterion | PASS | WARN | FAIL |
|---|---|---|---|
| Line number accuracy | >= 95% match | 80-94% | < 80% |
| Mermaid syntax errors | 0 | 1-2 | >= 3 |
| Branch coverage | >= 90% | 75-89% | < 75% |
| Side effect documentation | 100% | >= 80% | < 80% |
| Hallucinations | 0 | 0 | >= 1 |
Any single FAIL criterion results in overall FAIL.
Prohibited Actions
- Do NOT modify logic diagram documents
- Do NOT modify source code files
- Do NOT approve documents with FAIL status
- Do NOT access the Doer's conversation context
More from caldiaworks/caldiaworks-marketplace
ideation
Turn rough ideas into structured, validated idea documents through collaborative dialogue. Explores context, asks clarifying questions one at a time, proposes alternative approaches with feasibility evaluation, and produces documents ready for requirements definition. Use when: ideation, brainstorm, new idea, explore an idea, I want to build, what if we, let's think about, propose approaches, evaluate this idea, idea document, アイデア出し, 案出し, ブレスト, アイデアを整理, 検討したい.
36requirements-docx
Convert USDM/EARS requirements documents from Markdown to professionally formatted Word (.docx) files for client submission. Generates cover pages, table of contents, headers/footers, and styled requirement hierarchies. Leverages the docx skill for Word file generation. Use when: export requirements to Word, requirements to docx, USDM to Word, convert requirements document, 要件書をWord出力, 要件定義書のdocx変換, Word形式で要件書を作成, 要件定義書をWordに変換.
36usdm
Convert ambiguous user requests into structured USDM requirements documents. Decomposes requirements into Requirement -> Reason -> Description -> Specification hierarchy. Integrates with GitHub Issues, Asana, and Jira tickets as input sources. Use when: create requirements, write requirements document, USDM, decompose requirements, requirements definition, 要件定義, 要件を整理, 要件分解.
33ears
Write unambiguous specifications using EARS (Easy Approach to Requirements Syntax) patterns. Provides 6 sentence templates that eliminate ambiguity: Ubiquitous, Event-driven, State-driven, Unwanted behavior, Optional feature, and Complex. Use when: EARS, specification writing, write specs, 仕様を書く, EARS記法, 仕様を明確化, requirements specification, unambiguous specification.
33skill-creator
Create new skills, improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, update or optimize an existing skill, run evals to test a skill, or benchmark skill performance with variance analysis.
30en-explainer
Explain English technical documents and text in Japanese with contextual understanding. Not a simple translator -- reads the surrounding file or codebase context to provide deeper, more accurate explanations tailored for Japanese-speaking developers. Use when: explain this English, この英文を解説, 英語の解説, en-explainer, what does this mean, この英文の意味, 英文を日本語で説明, ドキュメントを解説, README解説, エラーメッセージの意味, コメントの意味, API仕様の解説, or when the user pastes English text and asks for explanation in Japanese. Also use when the user provides a file path and asks to explain specific English sections, or when they want to understand English code comments, error messages, config files, or technical documentation.
29