skills/research-program/SKILL.md

---
name: research-program
description: >-
  Pursue or close out a substantial mathematical research program across multiple proof, counterexample, literature, and computational routes. Use when the user asks for sustained investigation, several approaches, continuation until a goal is reached, or an authorized closeout of one named program or phase that compacts its live status and history. Coordinate successive attempts and preserve their evidence. Do not use for a single bounded lemma attempt, ordinary explanation, proofreading, a read-only project retrospective, or a repository-wide migration of instructions or a flat research log into program indexes.
---

# Sustained mathematical research

Own the user's mathematical objective across route changes. A route ending is
not the assignment ending. Produce mathematics, not a portfolio of unexecuted
suggestions. Do not promise a solution to an open problem or relabel an exhausted
attempt as one.
For a closeout-only request, reconcile recorded results and compact the handoff;
do not start new mathematical routes unless the user also requested research.
A closeout covers one named program or phase. Restructuring the repository's
history across programs, such as turning a flat research log into program
indexes, is a `research-init` migration; its closeouts follow this skill's
closeout contract.

## 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. Before starting a run, inspect live, stale, and
unreconciled runs of the same route. Recheck stale results that bear on the
decision and reconcile completed results before relying on them. Compare a
proposed run's work scope with live runs to avoid duplicate work. Distinct
parallel runs may proceed from an explicit base with disjoint write scopes
without closing existing live runs.
Initialize it only when useful and authorized; its 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 alternative mechanisms as a portfolio and jointly required lemmas as
claim dependencies. When a route is recorded under a parent goal but directly
advances a named sub-obligation, identify that obligation explicitly rather than
retargeting the route or duplicating the mechanism.
Run the decisive check, then pursue the promising route to a substantive
checkpoint using `research-attempt` if available. Its one-route boundary applies
to each work package, not to this whole program. Follow the user's breadth
requirement: if they ask to try every proposed route, execute each one.

When routes or runs execute in parallel, give each one an owner, base
checkpoint and disjoint write scope. Require returned artifacts to identify
that base and their actual inputs. Reconcile them against the common base; do
not infer chronology or supersession from response order, directory names or
wall-clock completion.
Preserve incompatible results as competing evidence until their mathematics is
resolved.

Allocate effort by expected information gain, relevance to the goal and cost.
Do not fabricate numerical success probabilities. Attack high-impact uncertain
dependencies before polishing their downstream consequences. Formulate auxiliary
lemmas that remove shared bottlenecks. Transfer techniques across fields only
after writing the actual source-to-target dictionary.

Use `literature-check` for source-dependent implications and `computation-audit`
for load-bearing experiments. If a specialist skill is unavailable, carry out
the relevant exact-source or finite-evidence check directly with available
tools and disclose its limits; an absent workflow package is not a mathematical
obstruction.

## Change direction on evidence

After a route checkpoint, ask what mathematical information changed. Preserve
the strongest surviving statement and distinguish a false lemma, a failed
method, an implementation bug, and an inaccessible source.

- On success, extract a structural mechanism and attack the remaining gap to
  the actual goal. Do not silently replace that goal with the weaker result.
- On failure, save a reusable obstruction and revise the portfolio. A failed
  proof route does not refute the target.
- On no progress, record the first unresolved implication and distinguish the
  attempt's limits from evidence against the mechanism. Try an untested
  continuation or identify a different input, construction, invariant or source.
  Repeating a mechanism with an established obstruction requires a change that
  addresses that obstruction. Resuming unfinished work needs no new premise,
  but it must change something at the recorded stuck step: a narrower sub-step,
  another method or tool, or more resources. Do not rerun a stalled step
  unchanged; when resumptions keep stalling there, record that step as the
  route's bottleneck and reprioritize the portfolio.
- Another finite case is useful only if it distinguishes alternatives, checks
  an independent invariant, or reaches a new regime.

An inconclusive attempt does not by itself close its route. Before closing an
unresolved route, account for the proposed continuations: what was tried, what
remains untried, what evidence rules one out, and what is deferred with a reason
and resumption condition. An obstruction to one construction closes only that
construction unless it applies to the whole mechanism. Keep a route open while a plausible
continuation remains; execute it within the authorized resources or preserve it
in the handoff. A continuation that awaits time, tools, access or priority is
deferred, not exhausted; keep its route open. Reserve terminal `inconclusive`
for a scoped route whose known continuations have all been tried or ruled out
by evidence, with no further plausible continuation identified; state the scope
and reason without claiming impossibility.

Continue successive cycles while there is an executable, plausible route within
the authorized resources. Do not stop just because the initial three failed.
Likewise, a substantial partial theorem is a checkpoint, not completion, when
the target contract still contains unresolved named implications.
Use checkpoints to preserve work while continuing. When the user specifies
time/resource bounds, honor them; otherwise choose bounded individual
experiments without imposing an arbitrary global attempt quota.

## Audit candidate breakthroughs

Before treating the goal as achieved, reconstruct the complete argument from
the current definitions and pinned evidence. Check every external leaf, range,
limiting argument and comparison map. Run `proof-audit` if available.

When fresh-agent review is available and delegation is authorized, give the
reviewer the exact claim, raw proof and required sources without the author's
verdict or route narrative. Request an independent derivation of the critical
step. Otherwise perform a separate adversarial pass and label it self-review.
Agreement between agents is not a proof certificate. Resolve disagreements by
the underlying mathematics. Use [the handoff contract](references/handoff.md)
when delegating or resuming.

## Persist and report

Keep proofs in durable mathematical files, finite runs in computation records,
failed mechanisms in linked route records, and current status in one live view.
When persistence is authorized but this host cannot execute or write, use the
`research-state` deferred-handoff contract for new durable artifacts, one
guarded index entry, and ledger proposals; state that ingest remains pending.
Update only state that actually changed; replace old dashboard checkpoint prose
with links only once it has a durable home and the project permits, and do not
rewrite indexed history.
User-authorized repository deliverables remain part of completion.

At a substantial program boundary, or when the user explicitly requests
compaction, follow [program closeout](references/program-closeout.md). Produce
one linked synthesis of decisive outcomes and a small current decision view;
keep route records and ledger events intact. Closeout is not required after
every session and does not close an unresolved mathematical goal. If the
history index has become a long flat list, use the project's hierarchical
program/route index policy rather than copying all routes into the live view.
For retrospective closeout, distinguish the historical cutoff from the later
assessment; do not attribute later evidence to the old program.

For a long or externally executed route, distinguish queued, running,
last-observed, completed, failed, timed out and abandoned states. Do not keep a
route marked running merely because a prior session launched it. Record the
last observation and execution identifier without treating process completion
as mathematical success.

Lead with whether the original goal was reached and the exact result. State the
proof/review status, decisive mechanism, files and meaningful checks. If it
remains open, distinguish partial results from the goal, list executed routes
with their precise obstructions, and preserve an executable next handoff.
When all presently available routes are exhausted, or tools/resources block
every remaining continuation, say so honestly; leave blocked routes open with
their deferred next steps. Never invent progress to satisfy “do not stop”.