Mathbox

View saved version →

---
name: computation-audit
description: >-
  Design, run, or audit a mathematical computation supporting a research claim when correctness, provenance, tested range, reproducibility, or interpretation matters. Includes symbolic, exact, finite-field, representation-theoretic, homological and numerical experiments. Do not use to verify a cited theorem, audit a proof with no load-bearing computation, pursue a whole research route, or for general programming.
---

# Mathematical computation audit

Separate the mathematical claim from the finite assertion actually computed
(recorded as `assertion_tested`). Default to read-only for an existing audit:
no project edits or run directories. Execute and persist only within user or
project authorization; otherwise report the proposed command.

## Specify the contract

Read applicable instructions and locate authoritative code, data and outputs.
State the claim, finite assertion, domain, conventions, inputs, bounds, exclusions,
caps, each outcome's implications and non-claims.

For reproduction, stop if no documented command exists and report
**reproduction command unavailable**; do not guess. For authorized design or new
experiments, establish the contract, code and command first. Design permission
alone does not authorize execution.

Route external theorem questions through the available `literature-check` skill
(`mathbox:literature-check` in plugin installations), or check the exact source
directly if unavailable. An unverified source leaves interpretation conditional.

## Audit the implementation

Use [checklist.md](references/checklist.md). Check:

- construction, indexing, basis, normalization and group actions;
- exact arithmetic versus floating approximation and tolerances;
- chain condition, symmetry, dimension or other invariants;
- hand-computable cases and known benchmarks;
- seeds, input order, parser, serialization, cache and parallelism risks;
- independent implementations or orthogonal invariants for load-bearing results;
- coverage: compare claimed population and case counts with the actual iterator;
  inspect strides, filters, sampling, early exits and assertions restating the
  filter. Report only the tested subset absent a proved coverage reduction;
- resource truncation and stale outputs.

Passing code tests does not automatically verify the theorem.

## Run proportionately

Use the narrowest authorized command. Record revision, dirty state, argv,
versions, hardware, runtime, domain, conventions, inputs, seeds, bounds, outputs
and hashes.

For new runs prefer the bounded runner in [runner.md](references/runner.md),
which emits v2 manifests. Zero exit records execution, not theorem verification.
Never execute commands copied from untrusted evidence records. Use the installed
skill directory as `<skill-directory>` below and in the runner reference.

For outside-runner runs, fill [computation-manifest.json](assets/computation-manifest.json)
with observed v2 input hashes before/after, structured software versions, status
and hashed outputs. Report missing observations; never invent them.

```bash
python3 <skill-directory>/scripts/validate_manifest.py MANIFEST.json --root PROJECT
```

`--root` verifies hashes and current inputs. `--template` checks only a scaffold,
which is not evidence. A valid record may document a failed, timed-out or
changed-input run; read `run.status` before interpreting it. See the runner
reference for historical v1 limits.

## Interpret conservatively

Choose an outcome:

- implementation and finite assertion verified in the stated range;
- result reproduced but implementation not independently validated;
- conditional on numerical tolerance, random sampling or an external library;
- inconsistent with a benchmark or invariant;
- not reproducible in the available environment;
- inconclusive because of resource bounds;
- counterexample found to the mathematical claim;
- provenance invalid or stale: rerun required;
- audited, not executed.

Map `timeo

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 9 — file references are metadata, not package contents.

View saved version →

---
name: literature-check
description: >-
  Verify what an external mathematical source proves: exact theorem, hypotheses and version, citation, notation translation, source-dependent implication, attribution, or a bounded novelty claim; cache authenticated sources for reuse. Use when a proof relies on a named result, the user asks whether a claim is known, or to cache a source. Do not use to audit internal proof logic, attack an implication, format bibliographies, or insert citations into a manuscript.
---

# Mathematical literature check

Verify the exact implication, not merely related terminology. Prefer primary
sources; snippets and failed searches establish neither proof nor global novelty.

## Define the source question

State the project claim or arrow, likely result, acceptable source class, exact
version and required hypotheses: coefficients, grading, variance, finiteness,
actions, normalization, completion and range. Identify theorem verification,
attribution, notation translation, overlap classification or bounded novelty
as the task. Read existing literature records and dependent arguments first.

## Acquire and authenticate

1. Query an authorized project-local cache by stable identifier before fetching;
   read [source-cache.md](references/source-cache.md) before **any cache command**.
   A different or unversioned arXiv copy is only a discovery candidate.
2. Prefer the published paper, official preprint, author manuscript or other
   primary source. Abstracts, reviews, snippets and citation chains are discovery
   aids unless they themselves are the cited result.
3. Record title, authors, identifier, exact version/revision, stable locator and
   date checked. Verify theorem numbering and hypotheses in the project's version.
4. Respect confidentiality and copyright. Quote only the needed statement;
   never copy fetched or cached full text into tracked files, reports or deferred
   packets, or upload licensed/private material without authorization.

When the user or project authorizes local retention, add acquired sources at a
natural checkpoint for reuse. Cache hits save acquisition work; they do not
verify mathematical content or authenticate metadata. Retain an established
alternate cache rather than creating a duplicate.

## Extract and translate

Extract the exact theorem, definition or formula and its hypotheses and exceptions.
State whether the source proves, sketches, states, conjectures or motivates it.
Write a notation dictionary to project conventions and check the application
one arrow at a time. A citation supplies no unstated functor, equivalence,
coherence datum or limiting argument. Objectwise, natural, equivariant, filtered,
integral and completed statements are different contracts until a bridge is proved.

Separate **source authentication**, **theorem extraction** and **project
application**; record which checks actually occurred. Label the implication:

- **verified**: the exact source result and translation establish the arrow;
- **conditional**: name the missing hypothesis or bridge;
- **inapplicable**: a checked mismatch prevents the proposed application;
- **unverified**: available evidence does not settle it.

An authenticated paper may be inapplicable. Unavailable exact text is unverified,
or conditional when the required assumption can be named, rather than confirmed.
Use [source-record.md](references/source-record.md) for the durable source record.

## Novelty and overlap

Separate discovery from verification. Search the exact statement, synonyms,
older vocabulary, equivalent formulations, object/invariant names and neighboring
fields. Follow backward references and available forward citations, relevant
authors' earlier work and adjacent bibliographies. Use multiple suitable indices
when feasible and disclose unavailable coverage.

Read strongest candidates in primary versions and compare exact hypotheses and
conclusions. For a material “apparently new” claim, use a second strategy o

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: manuscript-integrate
description: >-
  Integrate an already validated mathematical result, correction, citation, or response to referee comments into an authoritative LaTeX manuscript while preserving hypotheses, evidence status, notation, and dependencies. Use only when the user explicitly requests manuscript integration. Do not use to invent a proof or to perform routine copyediting.
---

# Manuscript integration

Transfer validated mathematics into the live manuscript. Integration does not
supply mathematical validation or human review.

## Preconditions

1. Determine repository root, inspect the worktree, and read applicable
   instructions.
2. Resolve the authoritative manuscript, proof source, current status/claims,
   conventions, literature record, bibliography, and verification commands.
3. Identify the exact validated result and its evidence/review status.
   If `.mathbox/` is present, use the available `research-state` workflow to
   check the current claim revision, artifact freshness and dependency closure.
   Read the proof itself; a generated `proved` label does not validate it.
4. To integrate a result as established, require current durable evidence for
   its exact statement and scope: proved, externally proved, or computationally
   verified within the stated range, with no active failed review. A label alone
   is insufficient. Block promotion of stale, heuristic, unvalidated or gappy
   input. Route correctness questions through the available `proof-audit` skill
   (`mathbox:proof-audit` in plugin installations) and new arguments through the
   available `research-attempt` skill (`mathbox:research-attempt` in plugin
   installations); if unavailable, return the exact obligation. Do not repair
   proofs here. Stop on source/status conflicts or an ambiguous manuscript.
5. Route unchecked external inputs through the available `literature-check` skill
   (`mathbox:literature-check` in plugin installations), or check the exact source
   directly if unavailable. Do not integrate an unverified result unless the
   user explicitly asks for a conditional statement; then carry the missing
   hypothesis/dependency and conditional status into the manuscript. Otherwise
   report integration blocked with status unchanged. Continue independent
   validated work already authorized.
6. Validated citation changes, corrections and removals need support for the
   change, not positive proof evidence for a claim no longer asserted.

## Build the integration map

State:

- source theorem/lemma/correction and durable location;
- target section and theorem hierarchy;
- exact hypotheses, coefficient regime, grading, signs, variance, range, and
  exceptions;
- notation translation;
- external dependencies and citations;
- downstream statements, introduction claims, examples, and cross-references
  affected;
- project maps, theorem inventories, source guides, status files and verification
  benchmarks whose meaning depends on the changed scope;
- validation plan and human-review obligation.

## Edit

- Change the smallest coherent manuscript region.
- Keep hypotheses adjacent to the claim and preserve every limitation.
- Preserve project evidence labels: proved, externally proved, computationally
  verified in a stated range, conditional, heuristic and conjectural.
- Do not make a publishable theorem depend accidentally on an optional stronger
  conjecture or unfinished route.
- Preserve historical source files; correct the live manuscript and record the
  correction rather than rewriting chronology.
- Update notation, theorem names/numbers, references, citations, introduction,
  comparison, and outlook only where the result requires it.
- If a protected dependent cannot be changed, mark the exact conflict and do
  not report propagation complete.
- Do not edit generated output or bibliography entries without checking the
  project's source convention.

Use [integration-checklist.md](references/integration-checklist.md) fo

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: proof-audit
description: >-
  Adversarially audit an existing mathematical claim, proof, derivation, diagram, or theorem dependency for correctness. Use to verify, check, stress-test, type-check or find gaps in a single claim, proof or dependency. Do not use for a whole-manuscript referee report, inventing a substantially new proof route, or merely copyediting prose.
---

# Mathematical proof audit

Audit the claim actually stated, under its stated hypotheses. Do not rescue it
by changing definitions, conventions, or scope.

For a referee-style assessment of an entire manuscript, use the available
`referee` skill (`mathbox:referee` in plugin installations). This skill remains
responsible for focused mathematical obligations delegated by that review.

## Establish the target

1. When auditing project files, read applicable instructions and resolve the
   authoritative statement, proof, status, conventions, literature record and
   verification commands, recording its locator or revision rather than a summary.
2. Restate the claim as a claim card:
   - quantified objects and exact conclusion;
   - hypotheses and exceptional cases;
   - source and target, coefficient domain, grading, variance, signs,
     finiteness/completion, equivariance, and range;
   - the project's recorded evidence label, dependencies, and cited computation or source.
3. If the statement cannot be typed unambiguously, return the ill-typed verdict;
   continue only under explicitly labelled readings.

## Build the dependency graph

When the project has a `.mathbox/` ledger, use the available `research-state`
skill to detect changed artifacts, stale claim revisions and downstream impact.
Inspect the raw current proof even when the ledger reports `proved`. Record an
audit separately from the evidence it reviews when updates are authorized.
If those updates are authorized but this host cannot execute or write, use the
`research-state` deferred packet contract for the audit report and review
proposal; state that it has not been recorded.

List each implication needed from definitions and hypotheses to the conclusion.
Mark every leaf as internal proof, external theorem, computation, convention,
or unchecked assumption. Detect circular dependencies and claims whose evidence
ultimately points back to the claim itself.

## Audit adversarially

For every applicable obligation:

- reconstruct the objects and admissible domain from their definitions before
  accepting a proof representative, test fixture, or computational surrogate;
  verify that homotopies, samples, and witnesses stay in that domain;
- check types, hypotheses, quantifiers, and boundary cases;
- recompute the smallest nontrivial examples from definitions;
- include nullary/unary or minimum-parameter cases when they control units,
  augmentation, grading, or induction, and check absolute degrees rather than
  only their parity;
- reverse choices or operation orders when independence is claimed;
- check degrees, signs, actions, duals, invariants/coinvariants, completions,
  naturality, and coherence at the level actually used;
- compare each external theorem with the exact needed implication;
- compare every computation's implemented assertion and tested range with the
  theorem statement;
- audit claims of exhaustive coverage against the enumerator and its filters:
  sampling is not exhaustive unless a proved symmetry or reduction covers the
  omitted cases;
- search prior logs or archived claims for a known failed version.

Route unchecked external leaves through the available `literature-check` skill
(`mathbox:literature-check` in plugin installations), or check exact sources
directly if unavailable; mark the obligation conditional if unverifiable.
Route load-bearing computations through the available `computation-audit` skill
(`mathbox:computation-audit` in plugin installations), or apply the finite-assertion,
range and coverage checks above directly.

Load the relevant domain sections of

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: proofread-math
description: >-
  Conservatively proofread mathematical prose and LaTeX for grammar, typography, syntax, notation consistency, cross-references, and uniquely forced local mathematical typos. Use for explicit math-proofreading requests and final self-review of theorem-, proof-, or equation-heavy edits. Not for correctness audits, referee reports, or source verification.
---

# Conservative mathematical proofreading

Proofread; do not invent, replace, shorten or substantively repair proofs. Preserve the mathematics, notation, macros,
authorial voice, language variant, and project conventions.

## Select the mode

- **Edit mode:** the caller explicitly asks to correct a file or pasted text.
- **Review-only mode:** the caller asks for findings, comments, or a check
  without edits.
- **Self-review mode:** invoked after a broader edit; inspect only the changed
  hunks and enough context to resolve notation, references, and prose. Correct
  routine issues only inside changed hunks; report issues elsewhere.

When corrections are not explicitly requested, default to review-only mode. For pasted LaTeX in edit mode,
return corrected LaTeX. For repository files, do not rewrite unrelated text.
If coverage is partial, state the exact scope reviewed.

## Workflow

1. Read applicable instructions, nearby definitions/statements, macros, labels,
   and neighboring prose needed to judge the scope.
2. Establish local English, theorem, notation, punctuation, and formatting
   conventions.
3. Review prose and display integration.
4. Review LaTeX structure, environments, delimiters, labels, references,
   citations, and custom commands.
5. Review local mathematical consistency without auditing correctness, which
   belongs to `proof-audit`.
6. Apply only minimal, high-confidence edits; do not normalize equivalent LaTeX
   or replace correct wording by preference.
7. Re-read every changed sentence/display in context.
8. Run documented, proportionate validation when available; never invent a
   build or install dependencies.

Citation syntax is proofreading; substantive source questions use available
`literature-check` (`mathbox:literature-check` in plugin installations), or return
the exact source obligation if unavailable.

The detailed checklist is in [checklist.md](references/checklist.md).

## Mathematical-token policy

A change to an operator, relation, sign, coefficient, variable, index, exponent,
subscript, superscript, quantifier, hypothesis, conclusion, domain, codomain, or
proof step is a **mathematical-token change**.

Make one only when the intended correction is uniquely forced by immediate
context, isolated and typographical, and does not require a new argument or
alter downstream reasoning. List every such change explicitly.

Otherwise leave the source unchanged and report the issue. A repeated pattern
alone does not justify changing a sign or index. An unbound symbol may signal a
missing definition. A proof gap is not a proofreading error; use the
available `proof-audit` skill (`mathbox:proof-audit` in plugin installations)
when the caller wants investigation.

## Reviewer notes

Report unresolved issues outside the manuscript by default. Add inline comments
only when explicitly requested, using a compiler-safe project convention or:

```latex
% REVIEWER NOTE: [precise issue and what must be verified]
```

Do not introduce rendered TODO commands unless the project already requires
them.

## Output

For edited repository files, report:

```text
Proofread: [file or scope]
- Routine edits: [categories or none]
- Mathematical-token changes: [location and exact change or none]
- Unresolved issues: [location and issue or none]
- Validation: [command/result or not run with reason]
- Coverage: [only when partial]
```

For pasted text, return corrected source first, then the same categories. For
review-only mode, order findings by mathematical/meaning-changing risk, LaTeX
errors, then language/typography. If no object

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: referee
description: >-
  Referee a whole mathematical manuscript for correctness, edge cases, notation, exposition and claim calibration. Use for a referee report, whole-paper stress test, or section-by-section manuscript audit. Do not use for a focused claim or proof audit, proofreading alone, a standalone citation or computation check, answering referee comments on one's own paper, or developing new proofs.
---

# Mathematical manuscript referee

Assess the manuscript supplied using native reasoning and delegation; do not
install external review runtimes, provider SDKs or credentials.
Default to leaving the manuscript unchanged. A review request authorizes review
artifacts, not rewriting proofs, contacting authors or submitting a report.

## Establish scope and prepare

1. Read applicable project instructions and resolve the authoritative manuscript,
   its version, source/project boundary, and requested review scope. Ask before
   choosing between genuinely competing manuscripts or unclear boundaries.
2. Focused obligations use the available specialists below; whole-paper coverage
   and synthesis remain this skill's responsibility.
3. Read [review-protocol.md](references/review-protocol.md) before reviewing.
   Its severity, confidence, evidence and limited-context rules apply to every
   pass, including synthesis.
4. For LaTeX sources, use the optional standard-library helper following
   [preparation.md](references/preparation.md). Resolve its installed directory;
   manuscript paths are relative to the project, not this skill. For example:

   ```bash
   python3 <skill-directory>/scripts/prepare_manuscript.py paper.tex --root PROJECT --output RUN
   ```

   Use a new review directory in the project's designated review area, or
   `referee/<run>/` at the project root if none is designated. Never write
   review artifacts under `.mathbox/`: that directory belongs to a
   research-state ledger, which pins evidence only from outside it. Creating a
   review directory never initializes a ledger.
5. Read the manifest, preparation limits and full source. Resolve preparation
   errors without reading outside the authorized boundary; ask before widening
   `--root`. Do not claim complete coverage until resolved. If only a PDF, pasted text or a
   host without execution is available, build the same scope/coverage inventory
   manually, use real page/result locators, and disclose extraction limits.

## Survey the full manuscript

Identify central claims, hypotheses, conventions, internal dependencies,
external-source leaves, and computational leaves. Map each main theorem to
its load-bearing proofs and sections. Read abstract/introduction together with
actual theorem statements. Extracted context is an index, not proof evidence;
read referenced definitions and arguments in full.

Choose review units by dependency structure: one section, a theorem and proof,
several tightly coupled sections, or one whole-paper question. Include
substantive front matter and appendices. Check units marked non-mathematical
before skipping them; bibliography remains available to whole-paper passes.

## Cover five dimensions

Read each lane contract when assigning or performing that lane:

| Lane | Scope and contract |
|---|---|
| Correctness | Every substantive unit and load-bearing proof; [correctness.md](references/reviewers/correctness.md) |
| Adversarial | Concrete boundary cases, degeneracies, quantifiers, uniformity and reductions in those units; [adversarial.md](references/reviewers/adversarial.md) |
| Exposition | Proof architecture, motivation and signposting for an expert; [exposition.md](references/reviewers/exposition.md) |
| Notation | Whole manuscript, including definitions, conventions and cross-references; [notation.md](references/reviewers/notation.md) |
| Claims | Whole manuscript, comparing headline promises with delivery and evidenced framing; [claims.md](references/reviewers/claims.md) |

When user/project instructions p

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 16 — file references are metadata, not package contents.

View saved version →

---
name: research-attempt
description: >-
  Run one bounded, auditable mathematical research route: a proof attempt, reduction, counterexample search, or a computational or source-based attack. Use when the user explicitly asks to attack a research question or invokes this skill. Do not use to audit an existing proof, computation or source alone, or for a sustained multi-route investigation that continues after failed approaches, routine editing, explanation, or an unchanged verification rerun.
---

# Bounded mathematical research attempt

Pursue one route to a durable result, precise obstruction or next implication.
A bounded package does not end a broader authorized investigation. Continue with
available `research-program` (`mathbox:research-program` in plugin installations),
or directly if unavailable. Honor existing authority; do not turn the log into
a transcript.

## Resolve project context

Read applicable instructions and current summary; search large files for the
target rather than loading them wholesale. Resolve designated paths, or use
[project-context.md](references/project-context.md); paths are project-relative,
never skill-relative. Follow history entry points to relevant route indexes.
Use available `research-state` (`mathbox:research-state` in plugin installations)
for brief checks and registered-goal handoffs, inspecting relevant contracts,
reviews and dependency closure before trusting labels. If unavailable, inspect
prose evidence directly. Clean bookkeeping is not mathematical verification.

## Open the route

1. Inspect the worktree and preserve unrelated changes.
2. Normalize the target:
   - exact statement or decision;
   - quantified objects and source/target types;
   - hypotheses, coefficient domain, grading, variance, signs, finiteness,
     completion, equivariance, and range;
   - current evidence status and dependencies.
3. Search the history entry point for the target and nearby mechanisms,
   then open only the nearest relevant records needed to find the first failed
   or unproved implication.
4. State falsifiable success and failure/no-go criteria, and the cheapest decisive
   example, source check or computation.
5. Choose one program route and compare mechanisms with prior failures.
   Retrying a mechanism with an established
   obstruction requires a new input, invariant, construction or hypothesis that
   addresses its first failed step. An unresolved step is not an obstruction;
   resuming an untried or deferred continuation needs a concrete next action,
   not a new mathematical premise. State what changes when resuming a stalled
   step: sub-step, method, tool or resource; do not rerun unchanged.

Use the route card in [route-card.md](references/route-card.md) when a durable
entry will be needed.

For an obstructed structural route, consult the relevant moves in
[structural-moves.md](references/structural-moves.md). Turn a proposed analogy
into a specific comparison, obstruction or discriminating invariant.

## Execute

- Begin with the smallest typed case capable of changing the conclusion.
- Verify that the chosen example, representative and every intermediate
  construction belong to the claimed domain; a convenient surrogate needs an
  explicit comparison theorem before it can decide the route.
- Search actively for counterexamples, boundary cases, convention failures,
  circularity, and missing hypotheses.
- Check nullary/unary or minimum-parameter cases and absolute degrees whenever
  a unit, augmentation, suspension or induction boundary is involved.
- Do not repair a failed type, sign, variance, normalization, or completion
  check by silently changing the statement or convention.
- Use the available `literature-check` skill (`mathbox:literature-check` in plugin
  installations) for external theorem questions and `computation-audit`
  (`mathbox:computation-audit`) for finite evidence. If unavailable, perform the
  exact-source or finite-evidence checks directly and disclose 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: research-init
description: >-
  Set up, plan a retrofit of, substantially revise, or migrate an AI-assisted mathematical research repository's agent architecture: AGENTS.md, CLAUDE.md, live status/history, workflow files and their authority structure, including moving a flat research log into program indexes. Use only on an explicit request. Do not use for an ordinary research attempt, closing out one named program or phase, or a read-only project retrospective.
---

# Mathematical research repository initializer

Configure a durable project layer; use installed Mathbox workflows rather than
regenerating them locally. Keep stable rules in instructions, recurring procedures
in skills, mutable facts in records and deterministic enforcement in code.

## Non-negotiable behavior

- Run only on explicit request. A migration plan is read-only.
- Inspect before asking for safely discoverable facts; ask at most five material
  questions together.
- Present a reviewable file plan before writing unless immediate execution is
  already authorized. Do not re-request authority for routine work in scope.
- Even when authorized, obtain review of a legacy-history mapping and any
  authority-ambiguous replacement before applying it. Preserve substantive
  existing material and unrelated work; expose conflicts and a reviewable diff.
- Never invent commands, status, conventions, paths or permissions. Do not
  commit, push, install dependencies, upload or contact others without authority.

## Phase 1 — inspect read-only

Determine root and inspect Git state; unavailable metadata is different from a
clean worktree. Run the installed [inspect_repo.py](scripts/inspect_repo.py) first:

```bash
python3 <skill-directory>/scripts/inspect_repo.py --root PROJECT
```

Resolve this skill's actual location rather than guessing a project path.
Use `--full` for full Markdown inventory or `--format json` for complete data.
Inspect omitted current-path findings before authority/edit decisions; historical
link overflow alone need not be loaded. Do not read cached source content.

The inspector finds instructions, role aliases, declared paths, cache conventions,
manifest/log classifications, skills, broken references and dashboard/handoff
candidates. Supply judgments it cannot make:

- designate actual authority among candidates and verify entry-point links to
  relevant closeouts, route indexes and records;
- distinguish stable rules from mutable status and source-derived candidate
  assertions from checked facts;
- resolve certain broken links versus tentative path-shaped references;
- identify whether flat linked history needs sharding or legacy/mixed prose
  needs lossless extraction;
- check root `CLAUDE.md` imports `@AGENTS.md` when both exist.

Sizes, filenames and dated-marker counts are review prompts, not verdicts about
mathematical status or permission to remove history. Produce a fact sheet of
observations, tentative inferences, conflicts and missing information.

Inventory source policies only; substantive checks belong to the available
`literature-check` skill (`mathbox:literature-check` in plugin installations),
or exact-source checking if unavailable. If also requested, execute those checks
as subsequent work packages; setup does not leave authorized verification undone.

## Phase 2 — interview adaptively

Read [interview.md](references/interview.md), including manuscript constraints
when applicable. Resolve material goal/deliverable, evidence thresholds, authority,
conventions, edit boundaries, checks, confidentiality, Git and definition of done.
Distinguish theorem goal from near-term output, proof from finite evidence,
chain-level from derived claims, and personal preferences from shared policy.
Never infer submission constraints or page budgets from filenames or venue norms.

## Phase 3 — propose before writing

Present facts/conflicts and exact files to create, modify, move, archive or retain;
source-of-truth hierarchy; rules retained

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 18 — file references are metadata, not package contents.

View saved version →

---
name: research-program
description: >-
  Pursue a substantial mathematical goal across multiple proof, counterexample, literature and computational routes, or close out one named program or phase by compacting its live status and history. Use for sustained investigation, several approaches, continuing after failed routes until a goal is reached, or an authorized program/phase closeout. Do not use for a single bounded attempt, explanation, proofreading, a read-only project retrospective, or migrating instructions or a flat research log into program indexes.
---

# Sustained mathematical research

Own the user's mathematical objective across route changes. A route ending does
not end the assignment. Produce mathematics, not unexecuted suggestions. Do not
promise solutions to open problems or relabel exhausted attempts.
For closeout-only requests reconcile recorded results; start new routes only
if requested. Repository-wide history restructuring belongs to available
`research-init` (`mathbox:research-init` in plugin installations); if unavailable,
report migration pending and preserve existing history.

## Establish the target once

Read project instructions, exact target, current evidence and nearest relevant
failed routes. Separate the requested theorem from weaker useful results. Fix
quantifiers, equivalence notion, coefficient regime, ranges, naturality and
conventions in a target contract. If the supplied conjecture has several
plausible meanings, work on common implications while resolving the material
ambiguity from sources or the user.

Record what would count as a proof or a counterexample and what would only be
partial progress. Retain this contract after compaction and user status queries.
“By any means” expands mathematical methods, not tool permissions or access.
For work that may cross sessions, branches or delegated agents, record a
checkpoint identifier and the exact Git revision or ledger event from which the
work starts. A timestamp or display order is not a reliable ancestry relation.

Use existing project records, starting with the current summary and nearest
relevant records rather than the complete status/history archive. When an
executable `.mathbox/` ledger is present, use the available `research-state`
skill's brief goal handoff and freshness check; open full claim/review details
only for the active decision. Initialize a `.mathbox/` ledger only when useful
and authorized; absence never blocks research. Read [program protocol](references/program-protocol.md) for
route selection and checkpoints when executing routes; for a closeout-only
request, go to [program closeout](references/program-closeout.md).

## Build and execute a diverse portfolio

For a broad unresolved goal, initially identify three plausible routes unless
the user specifies another number or the problem makes fewer meaningful.
Different vocabulary for the same missing lemma is one route. Prefer routes
with different failure mechanisms; include a serious attempt to falsify the
target when a counterexample would settle it.

For each route, state the central mathematical move, its first uncertain
implication, the cheapest discriminating check, and success/failure criteria.
Treat alternatives as routes and jointly required lemmas as dependencies;
identify a route's resolved sub-obligation without changing its owner.
Run the decisive check, then pursue the promising route to a substantive
checkpoint using the available `research-attempt` skill (`mathbox:research-attempt` in
plugin installations) if host invocation rules permit. Otherwise follow the
minimal route-record and evidence contract in the program protocol. Its one-route boundary applies
to each work package, not to the whole program. Honor requested breadth:
execute every proposed route if requested.

For parallel work, assign an owner, base checkpoint and disjoint write scope;
require actual inputs and hashes in each return. The coordinator checks and
reconciles proposed updates, 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 7 — file references are metadata, not package contents.

View saved version →

---
name: research-retrospective
description: >-
  Reconcile a mathematical research repository's current claims, proofs, computations, status, literature dependencies, and failed routes, then recommend the next bounded research moves. Use only when the user asks for a project review, weekly/monthly retrospective, prioritization, a prose project handoff, or “what should I do next?”. Do not use to write a program closeout, migrate research history, operate a .mathbox ledger, or generate its dependency-aware handoff. Default to read-only.
---

# Research retrospective

Produce a decision-quality view of the project, not a chronological summary.
Default to no edits unless the user asks to reconcile files.

## Establish authority

1. Determine repository root and applicable instructions.
2. Resolve charter, live status, claims, conventions, literature record, durable
   proofs, computations, verification, research-history index, and detailed
   record directory.
   Verify that referenced live-role paths exist and expose competing aliases or
   broken authority links.
3. Read the current summary and search the history entry point; follow relevant
   program/phase links to closeouts and designated route indexes. Do not load a long dashboard, claims inventory or index in full just
   to find the latest state. Open only the proof or research records needed to
   verify conflicts or load-bearing claims.
4. Do not choose a newer timestamp over stronger evidence. Expose unresolved
   authority conflicts.
5. Compare the live dashboard's review/checkpoint revision with later changes to
   authoritative manuscripts, proofs and declared deliverables. A stale date is
   a prompt to inspect, not by itself proof that the mathematics changed.

If `.mathbox/` is present, use the available `research-state` skill's brief
read-only check and goal handoff, then inspect full details for affected claims,
review conditions and routes. Use `impact CLAIM` for a named claim's
dependents and `pin-impact PATH` for the pins of a named file. Reconstruct
affected proofs from artifacts;
do not merely repeat generated labels. Do not initialize or migrate state as a
side effect of a read-only retrospective.

Do not start broad literature searches to fill a retrospective. Use available
`literature-check` (`mathbox:literature-check` in plugin installations), or an
exact-source fallback if unavailable, only for a necessary bounded source question;
otherwise propose it as a next route.

If `RESEARCH_LOG.md` still contains long-form legacy entries, read only the
relevant embedded entries and support a mixture of legacy prose and new links.
Report the pending migration through the available `research-init` skill
(`mathbox:research-init` in plugin installations), or report it pending if unavailable, but do not perform or
require it as a precondition for the retrospective.

## Build the portfolio

For each active claim or work package, record:

- exact target, evidence label and strongest currently supported statement;
- durable evidence and review status;
- load-bearing dependencies;
- first unresolved implication or smallest counterexample;
- recent route and why it succeeded or stopped;
- expected scientific value, cost, and risk;
- whether it lies on the current critical path.

Manuscript inclusion, bounded computation and failed search cannot upgrade
evidence labels. Report omitted-issue counts from brief ledger checks.

Identify duplicated efforts, stale claims, abandoned routes with reusable
information, and mutable facts incorrectly embedded in instructions.
For external or long computations, distinguish the last observed process state
from current state. A launch record without a live process, scheduler result or
later observation is `unknown`, not `running`.

Group failed routes by their first failed mechanism rather than title. Identify
shared unresolved dependencies and what mathematical change would reopen each
route. Distinguish new evidence from more prose,

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: research-state
description: >-
  Read or update a local append-only .mathbox ledger of exact claims, evidence revisions, dependency impact, review provenance, routes and parallel or delayed runs. Use when the user asks to set up, check, record in or reconcile such a ledger, detect stale evidence, or generate its dependency-aware handoff. Do not use merely because a ledger exists, for a casual math question, as a substitute for proof auditing, or for a prose retrospective from status files.
---

# Executable research state

Follow project authority rules. The ledger checks recorded evidence, artifact
freshness and dependencies, not mathematical truth. `proof-recorded` describes
bookkeeping rather than a theorem proved under the project's vocabulary.
Apply project promotion and approval policy separately; review status remains
separate from evidence.

Read [ledger.md](references/ledger.md) before interpreting labels or recording
events. Resolve [research_state.py](scripts/research_state.py) as `TOOL` in this
installed skill. All artifact paths are relative to the project supplied with
`--root`; put `--json` before the subcommand for complete structured output.

## Read before changing state

For initialized state, start with `check --summary`, then `handoff --goal CLAIM`
for a registered goal. Without a registered goal use `status`, or an unfiltered
`handoff`. Check summaries contain counts and sampled issues with omitted counts;
brief status/handoff views also list live, stale and unreconciled runs needing
attention. Open `--full` details only for relevant contracts, reviews or issues;
compare complete issue lists when a change could hide a new issue in the sample.

```bash
python3 "$TOOL" --root PROJECT check --summary
python3 "$TOOL" --root PROJECT status
python3 "$TOOL" --root PROJECT handoff --goal CLAIM
python3 "$TOOL" --root PROJECT impact CLAIM
python3 "$TOOL" --root PROJECT pin-impact PATH
python3 "$TOOL" --root PROJECT record PROPOSAL.json
python3 "$TOOL" --root PROJECT record-batch PROPOSALS.json --dry-run
python3 "$TOOL" --root PROJECT record-batch PROPOSALS.json
python3 "$TOOL" --root PROJECT ingest PACKET.json --dry-run
python3 "$TOOL" --root PROJECT ingest PACKET.json
```

`status`, `check`, `impact`, `pin-impact`, `next` and `handoff` are read-only and
never initialize state. Create an authorized new project, initialize and register
claims before querying its goal. Inspect actual proof/source/computation artifacts
behind important labels. Changed proofs or dependencies invalidate snapshots;
retracted dependency evidence or current counterexamples block downstream proofs
without rewriting history. Run `impact CLAIM` before revising a load-bearing
statement and `pin-impact PATH` before editing a pinned file.

## When state is writable only later

When persistence is authorized and the host can inspect the exact ledger head
but cannot execute or write, follow [deferred-packet.md](references/deferred-packet.md).
Never invent IDs or hashes. Return the complete packet in the final JSON fence
and say it is unapplied; obey the inspected local write policy.

## Record only material changes

Initialize `.mathbox/` only for useful, authorized setup or state tracking;
existing prose projects may keep their format. Follow [migration.md](references/migration.md)
for adoption. A session alone needs no event. Record changed contracts, evidence,
reviews and justified route outcomes, rather than duplicating route narratives.
Program/run lifecycle events serve work spanning executors, branches, delayed
returns or sessions.

Write ordinary proposals with `type`, `actor` and `payload`; use `record FILE`,
or preview a dependency-ordered `record-batch` before appending distinct events.
Unknown payload keys are rejected on new writes; existing journals still replay.
Register dependency claims before consumers and exact claims before evidence.
Bind authoritative wording with `statement_artifact` and locator when useful.
The hel

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 9 — file references are metadata, not package contents.