0be354a920
Single-commit clean baseline after security scrub of niche-tells, project codenames, internal jargon, and contributor-email leaks. Contents: - 100 Rust crates (_primitives/_rust/) - 37 agent manifests (_manifests/) + generated specs (_generated/) - 67 user-invocable skills (skills/) - 33 hooks (hooks/) - Composition blocks (_blocks/) - Documentation (docs/, README.md) - TS adapter packages (_ts_packages/) - Assembler (_assembler/) - Roles (_roles/) - Templates (_templates/) - Forgejo CI (.forgejo/) Author: Denis Parfionovich <info@greendragon.info> License: see LICENSE.
63 lines
4.6 KiB
Markdown
63 lines
4.6 KiB
Markdown
---
|
|
description: Verify the factual accuracy of a document against the actual codebase, correct inaccuracies in place
|
|
---
|
|
Load the visual-explainer skill, then verify the factual accuracy of a document that makes claims about a codebase. Read the file, extract every verifiable claim, check each against the actual code and git history, correct inaccuracies in place, and add a verification summary.
|
|
|
|
For HTML files: read `./references/css-patterns.md` to match the existing page's styling when inserting the verification summary.
|
|
|
|
**Target file** — determine what to verify from `$1`:
|
|
- Explicit path: verify that specific file (`.html`, `.md`, or any text document)
|
|
- No argument: verify the most recently modified `.html` file in `~/.agent/diagrams/` (`ls -t ~/.agent/diagrams/*.html | head -1`)
|
|
|
|
Auto-detect the document type and adjust the verification strategy:
|
|
- **HTML review pages** (diff-review, plan-review, project-recap): detect from page content, verify against the git ref or plan file the review was based on
|
|
- **Plan/spec documents** (markdown): verify file references, function/type names, behavior descriptions, and architecture claims against the current codebase
|
|
- **Any other document**: extract and verify whatever factual claims about code it contains
|
|
|
|
**Phase 1: Extract claims.** Read the file. Extract every verifiable factual claim:
|
|
- **Quantitative**: line counts, file counts, function counts, module counts, test counts, any numeric metrics
|
|
- **Naming**: function names, type names, module names, file paths referenced in the document
|
|
- **Behavioral**: descriptions of what code does, how things work, before/after comparisons
|
|
- **Structural**: architecture claims, dependency relationships, import chains, module boundaries
|
|
- **Temporal**: git history claims, commit attributions, timeline entries
|
|
|
|
Skip subjective analysis (opinions, design judgments, readability assessments) — these aren't verifiable facts.
|
|
|
|
**Phase 2: Verify against source.** For each extracted claim, go to the source:
|
|
- Re-read every file referenced in the document — check function signatures, type definitions, behavior descriptions against the actual code
|
|
- For claims about git history: re-run git commands (`git diff --stat`, `git log`, `git diff --name-status`, etc.) and compare output against the document's numbers
|
|
- For diff-reviews: read both the ref version (`git show <ref>:file`) and working tree version to verify before/after claims aren't swapped or fabricated
|
|
- For plan docs: verify that files, functions, and types the plan references actually exist and behave as described
|
|
- For project-recaps: re-run `git log` commands to verify activity narrative and timeline
|
|
|
|
Classify each claim:
|
|
- **Confirmed**: claim matches the code/output exactly
|
|
- **Corrected**: claim was inaccurate — note what was wrong and what the correct value is
|
|
- **Unverifiable**: claim can't be checked (e.g., references a file that doesn't exist, or a behavior that requires runtime testing)
|
|
|
|
**Phase 3: Correct in place.** Edit the file directly using surgical text replacements:
|
|
- Fix incorrect numbers, function names, file paths, behavior descriptions
|
|
- Fix before/after swaps (a common error class in review pages)
|
|
- If a section is fundamentally wrong (not just a detail error), rewrite that section's content while preserving the surrounding structure
|
|
- For HTML: preserve layout, CSS, animations, Mermaid diagrams (unless they contain factual errors in node labels or edge descriptions)
|
|
- For markdown: preserve heading structure, formatting, and document organization
|
|
|
|
**Phase 4: Add verification summary.**
|
|
- **HTML files**: insert a verification section as a banner at the top or final section, matching the page's existing styling. Use a subtle card with muted colors.
|
|
- **Markdown files**: append a `## Verification Summary` section at the end of the document.
|
|
|
|
Include in the summary:
|
|
- Total claims checked
|
|
- Claims confirmed (with count)
|
|
- Corrections made (with brief list of what was fixed: "Changed `processCleanup` to `runCleanup` to match actual function name in `worker.ts:45`")
|
|
- Unverifiable claims flagged (if any)
|
|
|
|
**Phase 5: Report.** Tell the user what was checked, what was corrected, and open the file (HTML in browser, markdown path in chat). If nothing needed correction, say so — the verification still has value as confirmation.
|
|
|
|
This is not a re-review. It does not second-guess analysis, opinions, or design judgments. It does not change the document's structure or organization. It is a fact-checker — it verifies that the data presented matches reality, corrects what doesn't, and leaves everything else alone.
|
|
|
|
Write corrections to the original file.
|
|
|
|
Ultrathink.
|
|
|
|
$@
|