Skip to content
Agent Orchestration
Agent

STYLE_GUIDE

This is the **generic baseline** house style the `write-paper` pipeline writes to. It contains no author-specific anchors and quotes no specific paper.

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 **generic baseline** house style the `write-paper` pipeline writes to. It contains no author-specific anchors and quotes no specific paper.

Agent definition

STYLE_GUIDE.md

STYLE_GUIDE — house style for a mathematics paper

This is the **generic baseline** house style the `write-paper` pipeline writes to. It contains no author-specific anchors and quotes no specific paper.

Read it in two layers:

  • **§0 is the non-negotiable floor** — the integrity rules (preserve the

mathematics, cite honestly, never fabricate a reference, leak no pipeline metadata). These live in the role contract (`roles/AGENTS.md`, the PRIME DIRECTIVE) and **always** hold, independent of any field, venue, or preference; §0 below only points there.

  • **§1 onward are the default house style for a mathematics paper** — concrete

typographic and structural conventions (document class, macros, theorem/proof shape, citation form). They are sensible **defaults**, not universal law: they assume an AMS-style mathematics article, and a different venue or subfield may legitimately want others. They are **configurable** — edit this file, or override per paper.

The operator may edit this file to encode their own preferences, and may drop gold-standard exemplar papers under `style/anchors/` for the writer to imitate (see `style/README.md`). Where an anchor or a `PROJECT_BRIEF.md` per-paper rule is more specific than a default here, the more specific one wins — except the §0 floor, which always holds.

---

0. Non-negotiable floor

The integrity floor — **preserve all mathematics and invent nothing; preserve and properly `\cite` every reference; fabricate no bibliography; leak no internal pipeline identifier** (the automated-system disclosure in `boilerplate/acknowledgement.md` is the one intended exception) — is the **PRIME DIRECTIVE in `roles/AGENTS.md` (items 1–6)**, binding on every role. It always holds, even against an anchor or a per-paper override. It is stated once, there, and not repeated in full here so the two cannot drift.

---

1. Document class and preamble

These are the defaults for an AMS-style mathematics article; a `PROJECT_BRIEF.md` override or a different venue's class may replace them (the §0 floor still holds).

  • `\documentclass{amsart}` by default (11pt or 12pt acceptable). A `geometry` block

for margins is fine. Use the venue's class when the brief names one.

  • Preserve every package and macro already present in the input preamble

(`hyperref`, `\definecolor`, custom `\newcommand`, `\theoremstyle`, `\DeclareMathOperator`, package options). You may ADD a missing package; never silently DROP one.

  • Theorem environments via `amsthm`: a shared counter

(`\newtheorem{thm}{Theorem}[section]`, then `\newtheorem{lem}[thm]{Lemma}`, `prop`, `cor`, `defn`, `rem`, `conj`, etc.). Use `\theoremstyle{plain}` for results and `\theoremstyle{definition}`/`remark` where appropriate.

  • First-page elements: `\subjclass[2020]{...}` and `\keywords{...}` present;

`\date{}` left empty unless the operator wants a date.

2. Macro architecture

  • Define a canonical macro set in the preamble and use it consistently:

`\mathbb`, `\mathcal`, `\mathbf`, `\mathfrak` shorthands and `\operatorname{}` / `\DeclareMathOperator` for multi-letter operators. Do not hand-typeset a multi-letter operator in plain italics.

  • `\epsilon` always; never `\varepsilon`.
  • `\colon` for the colon in a map `f\colon X\to Y`; `\mid` for the bar in

set-builder notation; `\setminus` for set difference.

  • Editorial macros are neutral and locked: `\edit{}`, `\note{}`, `\todo{}` for

in-draft annotations. Define them in the preamble; never drop them and never define them as no-ops. Do not invent person-named editorial macros.

3. Theorem statements

  • A theorem statement is fully quantified and self-contained: every symbol it

uses is defined before it, defined inline right after, or forward-referenced. No naked symbols.

  • Use `Let`, `Suppose`, and `Assume` for distinct roles, consistently: `Let $X$ be ...` introduces a fresh object (variable, space, map); `Suppose that ...` opens a proof by contradiction or a case-split assumption; `Assume that ...` states a standing hypothesis inside a theorem statement or a side hypothesis inside a proof.
  • Theorem titles (the bracketed `[...]` argument) are in accessible English,

with no symbol-only prefix. When restating a known result, the title cites the predecessor.

  • Use lettered statements (`\begin{thm}` labelled A, B, ...) for headline

results in the introduction when the paper has several; number ordinary body results.

  • State hypotheses and conclusions as displayed lists (`enumerate`) when there

are several; keep one logical clause per item.

4. Proofs

  • Choose deliberately between a cohesive prose proof, a multi-step proof, or an

extracted-lemma cluster, by the length and structure of the argument.

  • Do not dispatch a proof with `by the same arguments`, `by similar arguments`, or `by standard arguments`. Either spell the argument out or extract the shared content as a lemma. A pointer of the form `the proof is similar to that of [Cite], with the substitution: ...` is acceptable only when the argument is verbatim after a single explicit substitution and reproducing it would require copying a long external proof; the substitution must be made explicit.
  • For a multi-step proof, open with a one-paragraph setup, then

`\noindent\textbf{Step N.}` steps; each step opens with a one-sentence preview of what it establishes.

  • Prove an embedded `Claim` immediately where it is stated; do not defer it.
  • Reductions read `Possibly replacing $X$ with $Y$, we may assume that ...`,

with the equivalence stated first. Do not write "WLOG" or "without loss of generality".

  • One mathematical claim per sentence. Each non-obvious assertion is justified

by a formula, an internal `\ref`, or a `\cite` — never by an unsupported adverb.

  • `Note that` / `Notice that` / `Observe that` may draw attention to a fact, but the fact must still be justified — it is an immediate consequence of something already stated or cited, is followed
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.