/synthesize-verification-report
Aggregate all detected errors and gaps into the final verification report, apply strict accept/reject logic, and produce repair hints when rejected.
$ npx -y skills add frenzymath/Danus --skill synthesize-verification-report --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/synthesize-verification-report
Context preview
The summary Claude sees to decide when to auto-load this skill.
Aggregate all detected errors and gaps into the final verification report, apply strict accept/reject logic, and produce repair hints when rejected.
SKILL.md
synthesize-verification-report.SKILL.mdname: synthesize-verification-report
description: Aggregate all detected errors and gaps into the final verification report, apply strict accept/reject logic, and produce repair hints when rejected.
Synthesize Verification Report
Produce the final verification output JSON and verdict.
Input Contract
Aggregate all findings you produced earlier in this verification session — the per-item records from the sequential check and the reference check, held in context. Each issue must include `location` and `issue`.
Procedure
1. Collect all critical errors and all gaps from previous checks. 2. Build a complete `verification_report` object with:
- `summary`
- `critical_errors`
- `gaps`
3. Apply strict verdict rule:
- `correct` iff `critical_errors=[]` and `gaps=[]`.
- otherwise `wrong`.
4. If verdict is `wrong`, produce concrete non-empty `repair_hints`. 5. Self-check the JSON against its schema before emitting — do this by reasoning, not by calling a tool:
- `verdict` is exactly `"correct"` or `"wrong"`,
- `repair_hints` is non-empty **iff** `verdict == "wrong"` (empty string when `"correct"`),
- every entry of `critical_errors` and `gaps` has both `location` and `issue`,
- the verdict is consistent with the rule in step 3 (any critical error or gap forces `"wrong"`).
If the self-check fails, correct the object before continuing. 6. Write the final JSON to the run's result file and emit it as your final message. The verify service injects the absolute path for this run — write to `results/{run_id}/verification.json` under the service-provided run directory (`{run_id}` is the `Run_id` given to you). The verify service reads this file back and returns it verbatim as the HTTP `/verify` response; you invoke no MCP tool to persist it. Stop only after the file is written and the same JSON is your final message.
Output Contract
Final output JSON:
{
"verification_report": {
"summary": "string",
"critical_errors": [],
"gaps": []
},
"verdict": "correct",
"repair_hints": ""
}If there is any error or gap, verdict must be `"wrong"` and `repair_hints` must be non-empty.
Tools
- None — you build, self-check, and write the report by reasoning. The final JSON
is written to `results/{run_id}/verification.json`; the verify service returns it as the `/verify` response.
(The verdict is the verifier's only output — no memory is written; the worker does all writing to global memory and the fact graph.)
Read more
name: synthesize-verification-report description: Aggregate all detected errors and gaps into the final verification report, apply strict accept/reject logic, and produce repair hints when rejected.
Synthesize Verification Report
Produce the final verification output JSON and verdict.
Input Contract
Aggregate all findings you produced earlier in this verification session — the per-item records from the sequential check and the reference check, held in context. Each issue must include `location` and `issue`.
Procedure
1. Collect all critical errors and all gaps from previous checks. 2. Build a complete `verification_report` object with:
- `summary`
- `critical_errors`
- `gaps`
3. Apply strict verdict rule:
- `correct` iff `critical_errors=[]` and `gaps=[]`.
- otherwise `wrong`.
4. If verdict is `wrong`, produce concrete non-empty `repair_hints`. 5. Self-check the JSON against its schema before emitting — do this by reasoning, not by calling a tool:
- `verdict` is exactly `"correct"` or `"wrong"`,
- `repair_hints` is non-empty **iff** `verdict == "wrong"` (empty string when `"correct"`),
- every entry of `critical_errors` and `gaps` has both `location` and `issue`,
- the verdict is consistent with the rule in step 3 (any critical error or gap forces `"wrong"`).
If the self-check fails, correct the object before continuing. 6. Write the final JSON to the run's result file and emit it as your final message. The verify service injects the absolute path for this run — write to `results/{run_id}/verification.json` under the service-provided run directory (`{run_id}` is the `Run_id` given to you). The verify service reads this file back and returns it verbatim as the HTTP `/verify` response; you invoke no MCP tool to persist it. Stop only after the file is written and the same JSON is your final message.
Output Contract
Final output JSON:
{
"verification_report": {
"summary": "string",
"critical_errors": [],
"gaps": []
},
"verdict": "correct",
"repair_hints": ""
}If there is any error or gap, verdict must be `"wrong"` and `repair_hints` must be non-empty.
Tools
- None — you build, self-check, and write the report by reasoning. The final JSON
is written to `results/{run_id}/verification.json`; the verify service returns it as the `/verify` response.
(The verdict is the verifier's only output — no memory is written; the worker does all writing to global memory and the fact graph.)
Danus orchestrates mathematical reasoning agents with fact-graph memory. A main agent (Claude Code) steers a swarm of autonomous codex workers that prove; a cold-start verifier is the sole authority on correctness: a result becomes real only once it passes.
Other skills on danus.
- /consult
Consult a strong reasoning model for strategy — feed it the current elaboration, take its reply as the next master_guidance, and dispatch workers from it. This is the main agent's high-intelligence step (workers prove; the consult decomposes and steers). Runs over the gpt_pro
Open skill - /elaboration
Write a high-signal-to-noise mathematical progress synthesis of a project from the shared stores (global memory + fact graph), following a fixed verdict→routes→interfaces→dangers→bridges template and a strict honesty discipline. Use it each strategic cycle, right before the
Open skill - /human-summary
Write a human-readable mathematical progress report (compiled PDF) on a project for the operator / the mathematician who posed the problem. This is NOT `elaboration` (dense input for the strategy consult) and NOT the dashboard. Render from the fact graph's verified
Open skill - /initialize
First-run setup interview for a Danus deployment. Run it on the FIRST session, whenever runtime/.danus-initialized is absent or OPERATOR.md is still the blank template, or when the operator asks to set up / initialize / onboard / re-configure. It greets the operator, explains
Open skill - /write-paper
Turn a project's verified fact graph into a publishable LaTeX paper in a configurable house style — a standalone amsart .tex with a real bibliography, compiled to PDF. Use when a project's target theorem is established and the operator wants the paper, or asks to
Open skill - /check-referenced-statements
Validate externally referenced theorems by querying arXiv theorem search first and Codex's built-in web search second. Use when a markdown proof cites statements from external papers.
Open skill

