Update to Mathbox

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 328
    },
    {
      "relative_path": "assets/program-closeout.template.md",
      "size_in_bytes": 1247
    },
    {
      "relative_path": "evals/evals.json",
      "size_in_bytes": 12409
    },
    {
      "relative_path": "evals/trigger-evals.json",
      "size_in_bytes": 1952
    },
    {
      "relative_path": "references/handoff.md",
      "size_in_bytes": 2103
    },
    {
      "relative_path": "references/program-closeout.md",
      "size_in_bytes": 6264
    },
    {
      "relative_path": "references/program-protocol.md",
      "size_in_bytes": 3212
    }
  ],
  "name": "research-program",
  "skill_md_contents": "---\nname: research-program\ndescription: >-\n  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.\n---\n\n# Sustained mathematical research\n\nOwn the user's mathematical objective across route changes. A route ending is\nnot the assignment ending. Produce mathematics, not a portfolio of unexecuted\nsuggestions. Do not promise a solution to an open problem or relabel an exhausted\nattempt as one.\nFor a closeout-only request, reconcile recorded results and compact the handoff;\ndo not start new mathematical routes unless the user also requested research.\nA closeout covers one named program or phase. Restructuring the repository's\nhistory across programs, such as turning a flat research log into program\nindexes, is a `research-init` migration; its closeouts follow this skill's\ncloseout contract.\n\n## Establish the target once\n\nRead project instructions, exact target, current evidence and nearest relevant\nfailed routes. Separate the requested theorem from weaker useful results. Fix\nquantifiers, equivalence notion, coefficient regime, ranges, naturality and\nconventions in a target contract. If the supplied conjecture has several\nplausible meanings, work on common implications while resolving the material\nambiguity from sources or the user.\n\nRecord what would count as a proof or a counterexample and what would only be\npartial progress. Retain this contract after compaction and user status queries.\n“By any means” expands mathematical methods, not tool permissions or access.\nFor work that may cross sessions, branches or delegated agents, record a\ncheckpoint identifier and the exact Git revision or ledger event from which the\nwork starts. A timestamp or display order is not a reliable ancestry relation.\n\nUse existing project records, starting with the current summary and nearest\nrelevant records rather than the complete status/history archive. When an\nexecutable `.mathbox/` ledger is present, use the available `research-state`\nskill's brief goal handoff and freshness check; open full claim/review details\nonly for the active decision. Before starting a run, inspect live, stale, and\nunreconciled runs of the same route. Recheck stale results that bear on the\ndecision and reconcile completed results before relying on them. Compare a\nproposed run's work scope with live runs to avoid duplicate work. Distinct\nparallel runs may proceed from an explicit base with disjoint write scopes\nwithout closing existing live runs.\nInitialize it only when useful and authorized; its absence never blocks\nresearch. Read [program protocol](references/program-protocol.md) for\nroute selection and checkpoints when executing routes; for a closeout-only\nrequest, go to [program closeout](references/program-closeout.md).\n\n## Build and execute a diverse portfolio\n\nFor a broad unresolved goal, initially identify three plausible routes unless\nthe user specifies another number or the problem makes fewer meaningful.\nDifferent vocabulary for the same missing lemma is one route. Prefer routes\nwith different failure mechanisms; include a serious attempt to falsify the\ntarget when a counterexample would settle it.\n\nFor each route, state the central mathematical move, its first uncertain\nimplication, the cheapest discriminating check, and success/failure criteria.\nTreat alternative mechanisms as a portfolio and jointly required lemmas as\nclaim dependencies. When a route is recorded under a parent goal but directly\nadvances a named sub-obligation, identify that obligation explicitly rather than\nretargeting the route or duplicating the mechanism.\nRun the decisive check, then pursue the promising route to a substantive\ncheckpoint using `research-attempt` if available. Its one-route boundary applies\nto each work package, not to this whole program. Follow the user's breadth\nrequirement: if they ask to try every proposed route, execute each one.\n\nWhen routes or runs execute in parallel, give each one an owner, base\ncheckpoint and disjoint write scope. Require returned artifacts to identify\nthat base and their actual inputs. Reconcile them against the common base; do\nnot infer chronology or supersession from response order, directory names or\nwall-clock completion.\nPreserve incompatible results as competing evidence until their mathematics is\nresolved.\n\nAllocate effort by expected information gain, relevance to the goal and cost.\nDo not fabricate numerical success probabilities. Attack high-impact uncertain\ndependencies before polishing their downstream consequences. Formulate auxiliary\nlemmas that remove shared bottlenecks. Transfer techniques across fields only\nafter writing the actual source-to-target dictionary.\n\nUse `literature-check` for source-dependent implications and `computation-audit`\nfor load-bearing experiments. If a specialist skill is unavailable, carry out\nthe relevant exact-source or finite-evidence check directly with available\ntools and disclose its limits; an absent workflow package is not a mathematical\nobstruction.\n\n## Change direction on evidence\n\nAfter a route checkpoint, ask what mathematical information changed. Preserve\nthe strongest surviving statement and distinguish a false lemma, a failed\nmethod, an implementation bug, and an inaccessible source.\n\n- On success, extract a structural mechanism and attack the remaining gap to\n  the actual goal. Do not silently replace that goal with the weaker result.\n- On failure, save a reusable obstruction and revise the portfolio. A failed\n  proof route does not refute the target.\n- On no progress, record the first unresolved implication and distinguish the\n  attempt's limits from evidence against the mechanism. Try an untested\n  continuation or identify a different input, construction, invariant or source.\n  Repeating a mechanism with an established obstruction requires a change that\n  addresses that obstruction. Resuming unfinished work needs no new premise,\n  but it must change something at the recorded stuck step: a narrower sub-step,\n  another method or tool, or more resources. Do not rerun a stalled step\n  unchanged; when resumptions keep stalling there, record that step as the\n  route's bottleneck and reprioritize the portfolio.\n- Another finite case is useful only if it distinguishes alternatives, checks\n  an independent invariant, or reaches a new regime.\n\nAn inconclusive attempt does not by itself close its route. Before closing an\nunresolved route, account for the proposed continuations: what was tried, what\nremains untried, what evidence rules one out, and what is deferred with a reason\nand resumption condition. An obstruction to one construction closes only that\nconstruction unless it applies to the whole mechanism. Keep a route open while a plausible\ncontinuation remains; execute it within the authorized resources or preserve it\nin the handoff. A continuation that awaits time, tools, access or priority is\ndeferred, not exhausted; keep its route open. Reserve terminal `inconclusive`\nfor a scoped route whose known continuations have all been tried or ruled out\nby evidence, with no further plausible continuation identified; state the scope\nand reason without claiming impossibility.\n\nContinue successive cycles while there is an executable, plausible route within\nthe authorized resources. Do not stop just because the initial three failed.\nLikewise, a substantial partial theorem is a checkpoint, not completion, when\nthe target contract still contains unresolved named implications.\nUse checkpoints to preserve work while continuing. When the user specifies\ntime/resource bounds, honor them; otherwise choose bounded individual\nexperiments without imposing an arbitrary global attempt quota.\n\n## Audit candidate breakthroughs\n\nBefore treating the goal as achieved, reconstruct the complete argument from\nthe current definitions and pinned evidence. Check every external leaf, range,\nlimiting argument and comparison map. Run `proof-audit` if available.\n\nWhen fresh-agent review is available and delegation is authorized, give the\nreviewer the exact claim, raw proof and required sources without the author's\nverdict or route narrative. Request an independent derivation of the critical\nstep. Otherwise perform a separate adversarial pass and label it self-review.\nAgreement between agents is not a proof certificate. Resolve disagreements by\nthe underlying mathematics. Use [the handoff contract](references/handoff.md)\nwhen delegating or resuming.\n\n## Persist and report\n\nKeep proofs in durable mathematical files, finite runs in computation records,\nfailed mechanisms in linked route records, and current status in one live view.\nWhen persistence is authorized but this host cannot execute or write, use the\n`research-state` deferred-handoff contract for new durable artifacts, one\nguarded index entry, and ledger proposals; state that ingest remains pending.\nUpdate only state that actually changed; replace old dashboard checkpoint prose\nwith links only once it has a durable home and the project permits, and do not\nrewrite indexed history.\nUser-authorized repository deliverables remain part of completion.\n\nAt a substantial program boundary, or when the user explicitly requests\ncompaction, follow [program closeout](references/program-closeout.md). Produce\none linked synthesis of decisive outcomes and a small current decision view;\nkeep route records and ledger events intact. Closeout is not required after\nevery session and does not close an unresolved mathematical goal. If the\nhistory index has become a long flat list, use the project's hierarchical\nprogram/route index policy rather than copying all routes into the live view.\nFor retrospective closeout, distinguish the historical cutoff from the later\nassessment; do not attribute later evidence to the old program.\n\nFor a long or externally executed route, distinguish queued, running,\nlast-observed, completed, failed, timed out and abandoned states. Do not keep a\nroute marked running merely because a prior session launched it. Record the\nlast observation and execution identifier without treating process completion\nas mathematical success.\n\nLead with whether the original goal was reached and the exact result. State the\nproof/review status, decisive mechanism, files and meaningful checks. If it\nremains open, distinguish partial results from the goal, list executed routes\nwith their precise obstructions, and preserve an executable next handoff.\nWhen all presently available routes are exhausted, or tools/resources block\nevery remaining continuation, say so honestly; leave blocked routes open with\ntheir deferred next steps. Never invent progress to satisfy “do not stop”.\n"
}