Skip to content
Agent Orchestration
Agent

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

From plugin
danus
16020 skills20 agents3 MCP
Install
$ npx -y skills add frenzymath/Danus --agent claude-code

How 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.md

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

Read more
Ships withdanus

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.

Get the whole plugin

Other agents on danus.