PAPER_STRUCTURE
This is the **structure** companion to `STYLE_GUIDE.md` (which governs *voice*). It says **what each part of a paper contains** and **how the paper is organized**, as a function of the paper's length. It is deliberately **field-neutral**: it names no subject area, bakes in no
$ npx -y skills add frenzymath/Danus --agent claude-codeHow it fires
How this agent 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.
Context preview
The summary Claude sees to decide when to auto-load this agent.
This is the **structure** companion to `STYLE_GUIDE.md` (which governs *voice*). It says **what each part of a paper contains** and **how the paper is organized**, as a function of the paper's length. It is deliberately **field-neutral**: it names no subject area, bakes in no
Agent definition
PAPER_STRUCTURE.mdPAPER_STRUCTURE — the per-section content plan, organized by length tier
This is the **structure** companion to `STYLE_GUIDE.md` (which governs *voice*). It says **what each part of a paper contains** and **how the paper is organized**, as a function of the paper's length. It is deliberately **field-neutral**: it names no subject area, bakes in no area-specific notation or reference set, and uses placeholders (e.g. *"the standard reference(s) for the area"*) wherever a real paper would name something concrete. The LaTeX conventions it references (document class, theorem environments, bibliography form) are `STYLE_GUIDE.md`'s **configurable defaults for an AMS-style mathematics paper**, not universal requirements — a different venue or subfield may change them.
A `PROJECT_BRIEF.md` per-paper rule, or an operator-supplied anchor under `style/anchors/`, may override anything here — except the non-negotiable floor in `STYLE_GUIDE.md` §0 and the PRIME DIRECTIVE in `roles/AGENTS.md`, which always hold. Nothing in this file relaxes them.
**How to use this file.** First pick a **length tier** in §1. Then follow that tier's recipe — §2 (note), §3 (mid), or §4 (long) — top to bottom; each recipe walks the whole paper in order. The recipes reference one shared block of conventions in §5 (front-matter, abstract rules, statement promotion, proofs, bibliography) that holds across tiers, so a writer who has chosen a tier reads one linear plan plus a common appendix.
---
1. First decide the length tier
The whole structure follows from this one early choice. Pick by the *shape of the verified content* — the number of headline results, the depth of the predecessor DAG of the load-bearing facts, and how much standing machinery the proofs share — **not** by a target page count.
| Tier | When | | --- | --- | | **note** (§2) | one headline result (or one result plus an immediate corollary); a shallow proof DAG; little shared machinery; the argument is short and self-contained. | | **mid** (§3) | one main theorem with several genuine supporting lemmas, or two related headline results; enough shared notation to deserve a preliminaries section; a proof that decomposes into a handful of body sections. **The default tier when in doubt.** | | **long** (§4) | several headline results (often lettered); a deep DAG; substantial shared machinery several sections inherit; reductions or intermediate frameworks that each earn a section. |
When two tiers seem equally plausible, choose the **smaller** one and let a section grow, rather than padding a short argument into a long skeleton. Record the chosen tier in the round summary.
---
2. Tier: a short note (top-to-bottom recipe)
A note is lean. It earns trust by reaching the result quickly and proving it without ceremony.
1. **Front-page elements** — §5.1.
2. **Abstract** — §5.2. One to three sentences. A single clean headline result can warrant **one sentence**. A three-paragraph abstract on a one-theorem note is a smell.
3. **Introduction — one short section, no subsections.** `\section{Introduction}` is one context paragraph that motivates the problem and places it against prior work (citing the standard reference(s) for the area), followed **immediately** by the main statement promoted to a numbered `\begin{thm}` (promotion rules, §5.3). A note usually needs no roadmap; if it runs to two body sections, one clause suffices.
4. **Notation, inline.** A note rarely needs a standalone preliminaries section. Fix the few standing conventions in a short paragraph at the start of the body (or at the end of the introduction), citing the standard reference(s) for the area for anything assumed. Promote to a real `\section{Preliminaries}` only if the conventions exceed a paragraph (then follow §3 step 4).
5. **The body — one or two sections.** State the result (or restate the promoted introduction theorem with the **same label**) and prove it (proof architecture, §5.4). A small supporting fact becomes an inline `Claim` proved on the spot; a supporting fact large enough to deserve its own statement becomes a `\begin{lem}` immediately before the main proof. Section openers, §5.6.
6. **Acknowledgements** — §5.7. Only if the operator supplied content; otherwise omit the section entirely.
7. **Bibliography** — §5.8.
---
3. Tier: a mid-length paper (top-to-bottom recipe)
The default tier: one main result with real supporting lemmas, or two related results, with shared machinery deserving its own section.
1. **Front-page elements** — §5.1.
2. **Abstract** — §5.2. Three to five sentences: the headline result(s) in words, one sentence of context, one on the shape of the proof or the new ingredient.
3. **Introduction — no formal subsections; bolded thematic block-headers.** Chunk the introduction with bolded headers, each followed by its discussion and the relevant statement, in this order:
\section{Introduction}
\medskip
\noindent\textbf{<Theme / context>}.
[Context and prior work; cite the standard reference(s) for the area as a
roll-call cluster (§5.8) where a framework is introduced, not a token cite.]
\medskip
\noindent\textbf{<Theme of the main result(s)>}.
[Discussion specific to the headline.]
\begin{thm}\label{thm:...} ... \end{thm} % promoted; see §5.3
\medskip
\noindent\textbf{Method.} % or "Outline of the proof"
[One short paragraph naming the main steps and key intermediate statements,
with forward Theorem~\ref{}/Lemma~\ref{} references.]With two co-equal results, state both (two numbered theorems, or the lettered convention if that reads cleaner; §5.3). Close with a one-paragraph roadmap, one sentence per section, when the paper has more than two body sections. Each introduction block opens with a reader-orienting sentence and, when multi-paragraph, closes with a signal sentence.
4. **Preliminaries / Notation
Read more
PAPER_STRUCTURE — the per-section content plan, organized by length tier
This is the **structure** companion to `STYLE_GUIDE.md` (which governs *voice*). It says **what each part of a paper contains** and **how the paper is organized**, as a function of the paper's length. It is deliberately **field-neutral**: it names no subject area, bakes in no area-specific notation or reference set, and uses placeholders (e.g. *"the standard reference(s) for the area"*) wherever a real paper would name something concrete. The LaTeX conventions it references (document class, theorem environments, bibliography form) are `STYLE_GUIDE.md`'s **configurable defaults for an AMS-style mathematics paper**, not universal requirements — a different venue or subfield may change them.
A `PROJECT_BRIEF.md` per-paper rule, or an operator-supplied anchor under `style/anchors/`, may override anything here — except the non-negotiable floor in `STYLE_GUIDE.md` §0 and the PRIME DIRECTIVE in `roles/AGENTS.md`, which always hold. Nothing in this file relaxes them.
**How to use this file.** First pick a **length tier** in §1. Then follow that tier's recipe — §2 (note), §3 (mid), or §4 (long) — top to bottom; each recipe walks the whole paper in order. The recipes reference one shared block of conventions in §5 (front-matter, abstract rules, statement promotion, proofs, bibliography) that holds across tiers, so a writer who has chosen a tier reads one linear plan plus a common appendix.
---
1. First decide the length tier
The whole structure follows from this one early choice. Pick by the *shape of the verified content* — the number of headline results, the depth of the predecessor DAG of the load-bearing facts, and how much standing machinery the proofs share — **not** by a target page count.
| Tier | When | | --- | --- | | **note** (§2) | one headline result (or one result plus an immediate corollary); a shallow proof DAG; little shared machinery; the argument is short and self-contained. | | **mid** (§3) | one main theorem with several genuine supporting lemmas, or two related headline results; enough shared notation to deserve a preliminaries section; a proof that decomposes into a handful of body sections. **The default tier when in doubt.** | | **long** (§4) | several headline results (often lettered); a deep DAG; substantial shared machinery several sections inherit; reductions or intermediate frameworks that each earn a section. |
When two tiers seem equally plausible, choose the **smaller** one and let a section grow, rather than padding a short argument into a long skeleton. Record the chosen tier in the round summary.
---
2. Tier: a short note (top-to-bottom recipe)
A note is lean. It earns trust by reaching the result quickly and proving it without ceremony.
1. **Front-page elements** — §5.1.
2. **Abstract** — §5.2. One to three sentences. A single clean headline result can warrant **one sentence**. A three-paragraph abstract on a one-theorem note is a smell.
3. **Introduction — one short section, no subsections.** `\section{Introduction}` is one context paragraph that motivates the problem and places it against prior work (citing the standard reference(s) for the area), followed **immediately** by the main statement promoted to a numbered `\begin{thm}` (promotion rules, §5.3). A note usually needs no roadmap; if it runs to two body sections, one clause suffices.
4. **Notation, inline.** A note rarely needs a standalone preliminaries section. Fix the few standing conventions in a short paragraph at the start of the body (or at the end of the introduction), citing the standard reference(s) for the area for anything assumed. Promote to a real `\section{Preliminaries}` only if the conventions exceed a paragraph (then follow §3 step 4).
5. **The body — one or two sections.** State the result (or restate the promoted introduction theorem with the **same label**) and prove it (proof architecture, §5.4). A small supporting fact becomes an inline `Claim` proved on the spot; a supporting fact large enough to deserve its own statement becomes a `\begin{lem}` immediately before the main proof. Section openers, §5.6.
6. **Acknowledgements** — §5.7. Only if the operator supplied content; otherwise omit the section entirely.
7. **Bibliography** — §5.8.
---
3. Tier: a mid-length paper (top-to-bottom recipe)
The default tier: one main result with real supporting lemmas, or two related results, with shared machinery deserving its own section.
1. **Front-page elements** — §5.1.
2. **Abstract** — §5.2. Three to five sentences: the headline result(s) in words, one sentence of context, one on the shape of the proof or the new ingredient.
3. **Introduction — no formal subsections; bolded thematic block-headers.** Chunk the introduction with bolded headers, each followed by its discussion and the relevant statement, in this order:
\section{Introduction}
\medskip
\noindent\textbf{<Theme / context>}.
[Context and prior work; cite the standard reference(s) for the area as a
roll-call cluster (§5.8) where a framework is introduced, not a token cite.]
\medskip
\noindent\textbf{<Theme of the main result(s)>}.
[Discussion specific to the headline.]
\begin{thm}\label{thm:...} ... \end{thm} % promoted; see §5.3
\medskip
\noindent\textbf{Method.} % or "Outline of the proof"
[One short paragraph naming the main steps and key intermediate statements,
with forward Theorem~\ref{}/Lemma~\ref{} references.]With two co-equal results, state both (two numbered theorems, or the lettered convention if that reads cleaner; §5.3). Close with a one-paragraph roadmap, one sentence per section, when the paper has more than two body sections. Each introduction block opens with a reader-orienting sentence and, when multi-paragraph, closes with a signal sentence.
4. **Preliminaries / Notation
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 agents on danus.
- main_agent
Read this at the top of every session before acting on Danus. It is the operating contract for the **main agent** that runs the Danus math system — everything Danus-specific: who you are, the data model, the strategic loop, the layer boundaries, and the honesty rule.
Open agent - verifier
This agent verifies the correctness of a mathematical proof provided in markdown format. It checks the logical flow, theorem applications, and external references to ensure the proof is valid. The agent produces a detailed verification report and a strict verdict on the proof's
Open agent - worker
You are a Danus **worker**: a codex session that solves a research-level math problem by a mathematician-style iterative process, alongside sibling workers and under a main agent that periodically steers you. You produce **findings** (shared awareness) and **facts** (verified
Open agent - REPORT_WRITER_PROMPT
You are the **report writer**. You produce a clean, human-facing mathematical progress report for a working mathematician — the person who posed the problem, or a colleague fluent in standard English mathematical terminology who knows **nothing** about how the work was produced.
Open agent - acknowledgement
Generic, operator-configurable acknowledgement boilerplate added to a produced paper: an automated-system disclosure (on by default), a funding line, and personal thanks. Funding and thanks are placeholders to fill; the disclosure is on by default and may be disabled. Invent
Open agent - PROBLEM
**Project:** `odd-sum` (toy example)
Open agent

