/identify-key-failures
Synthesize the common stuck points across failed decomposition plans. Use when the current batch of decomposition plans has failed — whether they failed already at direct proving or only after further attempts.
$ npx -y skills add frenzymath/Danus --skill identify-key-failures --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
/identify-key-failures
Context preview
The summary Claude sees to decide when to auto-load this skill.
Synthesize the common stuck points across failed decomposition plans. Use when the current batch of decomposition plans has failed — whether they failed already at direct proving or only after further attempts.
SKILL.md
identify-key-failures.SKILL.mdname: identify-key-failures
description: Synthesize the common stuck points across failed decomposition plans. Use when the current batch of decomposition plans has failed — whether they failed already at direct proving or only after further attempts.
Identify Key Failures
Use this skill to turn many failed attempts into reusable guidance for the next planning round.
Input Contract
Read:
- the failed decomposition plans
- direct-proving stuck points
- existing `failed_paths`
- relevant `counterexamples` and `toy_examples`
Procedure
1. Gather the reports from all failed plans. If only direct proving has run so far, work directly from the direct-proving failures. 2. List the key stuck points for each plan. 3. Identify common points across those failures:
- recurring obstructions or counterexamples
- decomposition patterns that keep breaking
- search gaps or missing background facts
4. Summarize what the failures suggest for the next generation of decomposition plans. 5. When all current decomposition plans have failed and no pattern is leading anywhere, publish the synthesized `dead_end` (below): the main agent reads it and consults for a fresh missing-mechanism or alternative direction (delivered as `master_guidance`), which the next planning round picks up. 6. Save the synthesized failure knowledge to `failed_paths` so later planning skills can use it. 7. After recording the failure synthesis, return control to `$propose-subgoal-decomposition-plans`.
Output Contract
Publish the failure synthesis to global memory with `gm_add` (kind `dead_end`): `claim` = the common stuck points, `evidence` = the per-plan failures, so siblings skip these paths. Carry these fields:
{
"record_type": "key_failures_summary",
"failed_plan_ids": ["..."],
"plan_failures": [
{
"plan_id": "...",
"stuck_points": ["..."]
}
],
"common_failures": ["..."],
"implications_for_next_plans": ["..."]
}Also note in your local memory (`events`) that a new planning round is needed.
Tools
- `gm_add` (publish the dead_end synthesis)
- `gm_search` (gather the failed plans and stuck points across the swarm)
Failure Logging
If the reports are too weak to identify meaningful common failures, note in local memory (`events`) `event_type="key_failures_inconclusive"` and state what information is still missing.
Read more
name: identify-key-failures description: Synthesize the common stuck points across failed decomposition plans. Use when the current batch of decomposition plans has failed — whether they failed already at direct proving or only after further attempts.
Identify Key Failures
Use this skill to turn many failed attempts into reusable guidance for the next planning round.
Input Contract
Read:
- the failed decomposition plans
- direct-proving stuck points
- existing `failed_paths`
- relevant `counterexamples` and `toy_examples`
Procedure
1. Gather the reports from all failed plans. If only direct proving has run so far, work directly from the direct-proving failures. 2. List the key stuck points for each plan. 3. Identify common points across those failures:
- recurring obstructions or counterexamples
- decomposition patterns that keep breaking
- search gaps or missing background facts
4. Summarize what the failures suggest for the next generation of decomposition plans. 5. When all current decomposition plans have failed and no pattern is leading anywhere, publish the synthesized `dead_end` (below): the main agent reads it and consults for a fresh missing-mechanism or alternative direction (delivered as `master_guidance`), which the next planning round picks up. 6. Save the synthesized failure knowledge to `failed_paths` so later planning skills can use it. 7. After recording the failure synthesis, return control to `$propose-subgoal-decomposition-plans`.
Output Contract
Publish the failure synthesis to global memory with `gm_add` (kind `dead_end`): `claim` = the common stuck points, `evidence` = the per-plan failures, so siblings skip these paths. Carry these fields:
{
"record_type": "key_failures_summary",
"failed_plan_ids": ["..."],
"plan_failures": [
{
"plan_id": "...",
"stuck_points": ["..."]
}
],
"common_failures": ["..."],
"implications_for_next_plans": ["..."]
}Also note in your local memory (`events`) that a new planning round is needed.
Tools
- `gm_add` (publish the dead_end synthesis)
- `gm_search` (gather the failed plans and stuck points across the swarm)
Failure Logging
If the reports are too weak to identify meaningful common failures, note in local memory (`events`) `event_type="key_failures_inconclusive"` and state what information is still missing.
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

