Update to Mathbox

{
  "description": "Initialize or migrate an AI-assisted mathematical research repository's agent architecture. Use only when the user explicitly asks to set up, plan a retrofit, or substantially revise AGENTS.md, CLAUDE.md, live research status/history, workflow files, or their authority structure, including migrating a flat research log across programs into program indexes. Inspect first, propose a reviewable file plan, and default to no repository-local skills. Do not use for an ordinary research attempt, a closeout of one named program or phase, or a read-only project retrospective.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 274
    },
    {
      "relative_path": "assets/AGENTS.template.md",
      "size_in_bytes": 4040
    },
    {
      "relative_path": "assets/CLAUDE.md",
      "size_in_bytes": 89
    },
    {
      "relative_path": "assets/CONVENTIONS.template.md",
      "size_in_bytes": 265
    },
    {
      "relative_path": "assets/LITERATURE.template.md",
      "size_in_bytes": 254
    },
    {
      "relative_path": "assets/PROJECT_CHARTER.template.md",
      "size_in_bytes": 1087
    },
    {
      "relative_path": "assets/PROOF_OBLIGATIONS.template.md",
      "size_in_bytes": 195
    },
    {
      "relative_path": "assets/RESEARCH_LOG.template.md",
      "size_in_bytes": 1178
    },
    {
      "relative_path": "assets/RESEARCH_STATUS.template.md",
      "size_in_bytes": 551
    },
    {
      "relative_path": "assets/VERIFICATION.template.md",
      "size_in_bytes": 335
    },
    {
      "relative_path": "evals/evals.json",
      "size_in_bytes": 12632
    },
    {
      "relative_path": "evals/trigger-evals.json",
      "size_in_bytes": 2010
    },
    {
      "relative_path": "references/existing-repo-migration.md",
      "size_in_bytes": 8200
    },
    {
      "relative_path": "references/interview.md",
      "size_in_bytes": 3576
    },
    {
      "relative_path": "references/output-contract.md",
      "size_in_bytes": 6963
    },
    {
      "relative_path": "references/skill-layer.md",
      "size_in_bytes": 1175
    },
    {
      "relative_path": "scripts/inspect_repo.py",
      "size_in_bytes": 37035
    },
    {
      "relative_path": "scripts/test_inspect_repo.py",
      "size_in_bytes": 9486
    }
  ],
  "name": "research-init",
  "skill_md_contents": "---\nname: research-init\ndescription: >-\n  Initialize or migrate an AI-assisted mathematical research repository's agent architecture. Use only when the user explicitly asks to set up, plan a retrofit, or substantially revise AGENTS.md, CLAUDE.md, live research status/history, workflow files, or their authority structure, including migrating a flat research log across programs into program indexes. Inspect first, propose a reviewable file plan, and default to no repository-local skills. Do not use for an ordinary research attempt, a closeout of one named program or phase, or a read-only project retrospective.\n---\n\n# Mathematical research repository initializer\n\nConfigure the repository as a durable research environment. Do not regenerate\nskills supplied by the `mathbox` plugin inside it.\n\n## Non-negotiable behavior\n\n- Run only after an explicit request.\n- A request for a migration plan is read-only; a plugin upgrade alone does not\n  authorize rewriting an existing project's files.\n- Inspect before asking questions; do not ask for facts safely available in the\n  repository.\n- Ask at most five material questions at a time.\n- Present a proposed file/migration plan before writing unless the user already\n  authorized immediate execution.\n- Apply the user's existing authorization to coherent setup/retrofit changes;\n  do not ask again for routine edits already in scope. Preserve substantive\n  existing material and show a reviewable diff. Resolve genuine ambiguity before\n  replacing an authoritative proof, convention, or historical record.\n- Do not invent commands, proof status, conventions, repository paths, or\n  permissions.\n- Preserve unrelated work. Do not commit, push, install dependencies, upload\n  content, or contact third parties without authorization.\n- Keep stable rules in instructions, recurring procedures in `mathbox` plugin\n  skills, mutable facts in research records, and deterministic enforcement in\n  code.\n\n## Phase 1 — inspect read-only\n\n1. Determine repository root and inspect `git status --short`. Distinguish a\n   clean Git worktree from unavailable Git metadata; do not report both as an\n   empty status.\n2. Locate root/nested `AGENTS.md`, Claude memory/rules, current skill folders,\n   and any unrecognized `skills/` folders. If root `CLAUDE.md` exists alongside\n   `AGENTS.md`, check whether it imports `@AGENTS.md`. A missing `CLAUDE.md` is\n   expected when Claude Code loads `AGENTS.md` directly.\n3. Locate likely charter, status, claims, conventions, proof/manuscript,\n   literature, log, computation, tests, CI, and build artifacts. Recognize\n   semantic aliases and variants, including `PLAN`, `STATUS`, `OUTLINE`,\n   `MANIFEST`, theorem/fact inventories and dated or qualified `HANDOFF` files;\n   names are candidates, not authority decisions. Inventory computation\n   manifests separately from build manifests. Detect project-declared path maps\n   and source-cache locations, and recognizable alternate cache conventions,\n   without reading cached source content or proposing a second cache by default.\n   Treat theorem/fact inventory entries derived from literature as candidate\n   assertions until their exact source records are checked; schedule that\n   verification before dependent proof or manuscript work treats them as facts.\n4. Classify the designated history entry point, often `RESEARCH_LOG.md`, as a\n   compact flat index, a program-level index, long-form legacy history, or a\n   mixture. Locate any program/phase route indexes and standalone records;\n   check that the entry point reaches them.\n   Detect `.mathbox/config.json` without replaying all history during inventory.\n5. Detect duplicate `mathbox` plugin skill names and paths hard-coded relative\n   to a skill installation. Report multiple dashboard or handoff candidates for\n   authority review. Conservatively check relative Markdown links and\n   path-shaped backtick references; distinguish certain broken links from\n   tentative path candidates and ignore code fences, URLs and shell examples.\n6. Run the bundled read-only inspector when available:\n\n```bash\npython3 <mathbox-research-init-directory>/scripts/inspect_repo.py --root <repo>\n```\n\nLocate the installed `mathbox:research-init` plugin skill directory (or its\nstandalone installation); do not substitute a guessed relative path. The\ndefault report is a brief inventory with counts and current-path examples,\nincluding research-log and computation-manifest classifications, project and\nmisplaced root skills, and build manifests. Use `--full` for the complete\nMarkdown report or `--format json` for complete structured data. Broken links\nunder archive, import, legacy, migration, or quarantine paths are counted as\nhistorical and listed only in those full views; do not treat their location\nalone as a live broken link. Links in current route records stay current. A dated\ncheckpoint-marker count is a prompt to inspect a long live file, not a verdict\nabout mathematical status or whether its history can be removed.\nIf current-path findings are omitted, inspect those findings in the full view\nbefore making authority or edit decisions; a historical-only overflow need not\nbe loaded into the working context.\n\nProduce a fact sheet with observed facts, tentative inferences, conflicts, and\nmissing information. Preserve confidence distinctions: a filename, directory\nname or path-shaped code span is not proof of its semantic role.\n\nInitialization may inventory literature records and cache policy, but it does\nnot establish what cited mathematics proves. Do not perform substantive source\nlookups during setup; record them as follow-up work for the available\n`literature-check` skill (`mathbox:literature-check` in plugin installations).\nIf the user also requested those source checks, execute them as a subsequent\nwork package within the same assignment. The setup boundary does not authorize\nleaving an explicitly requested verification task unfinished.\n\n## Phase 2 — interview adaptively\n\nUse [interview.md](references/interview.md). Resolve only material ambiguity:\nresearch goal, current deliverable, evidence thresholds, source authority,\nfragile conventions, edit boundaries, verification, confidentiality/network,\nGit policy, and definition of done.\n\nIf a manuscript or submission is the current deliverable, also resolve its\nvenue/template, language, audience, deadline and timezone, page-count rule and\npage budget. The budget must account explicitly for front matter, bibliography,\nfigures/tables and contingency. Never infer these constraints from a filename,\nan old draft, a generic venue norm or an approximate current page count.\n\nDistinguish theorem goal from near-term output, proof from computation,\nchain-level from derived/homology/topological claims, stable rules from mutable\nstatus, and personal preferences from team-shared policy.\n\n## Phase 3 — propose before writing\n\nPresent:\n\n1. repository facts and unresolved questions;\n2. proposed instruction hierarchy and source-of-truth order;\n3. exact files to create, modify, move, archive, or leave untouched;\n4. rules to retain, shorten, move, automate, or remove;\n5. protected paths and approval boundaries;\n6. verified fast, targeted, full, and manuscript checks;\n7. migration risks and stale/conflicting instructions;\n8. skill-layer decision from [skill-layer.md](references/skill-layer.md).\n9. whether authorized literature retention needs a project-local cache and a\n   tracked ignore rule, or should retain a safely identified project-declared\n   alternate cache rather than creating a duplicate.\n10. for a manuscript deliverable, the confirmed submission constraints and a\n   complete page budget, with every unresolved item left explicitly unknown.\n11. source-dependent inventory entries that remain unverified, and a literature-\n    check work package ordered before any dependent claim is promoted or used.\n12. for existing live-file migration, a section inventory and proposed content\n    crosswalk, current ledger/pin baseline where present, and unresolved\n    authority conflicts. Complete the mapping before replacing old content.\n\nWhen this explicitly requested setup, retrofit, or refresh finds route-level\nprose in `RESEARCH_LOG.md`, the proposed plan must include the legacy migration\nbelow. Trigger on the log's structure, not its line count. Detection does not\nauthorize the rewrite.\n\n## Existing instruction and live-state migration\n\nFor an explicit request to plan or perform migration of an existing repository's\nlarge `AGENTS.md`, dashboard, or handoff, follow\n[existing-repo-migration.md](references/existing-repo-migration.md). It defines\nthe baseline, content crosswalk, pin-aware edits, and before/after checks. A\nplan-only request stops at the reviewed plan. Do not treat a plugin update as a\nreason to rewrite a ledger, refresh hashes, or import confident prose as proof.\nUse the separate legacy research-log process below if that log contains\nroute-level prose; use the available `research-state` skill for any optional\nledger adoption or claim/evidence revision.\n\n## Legacy research-log migration\n\nMake the mapping and file plan reviewable. An ordinary research attempt or\nretrospective does not trigger migration. Before creating the compact index,\npresent a source-span-to-destination mapping to the user or designated project\nowner and obtain its review. Broad retrofit authorization permits preparation\nof the mapping and files, but it does not substitute for review of route\nrelevance or ambiguous provenance.\n\n1. Compare each prospective entry with the repository's explicit mission,\n   current target and scope. Classify it as mission-relevant, foreign, or\n   ambiguous, citing the text that supports the classification. Do not infer\n   relevance from a filename, topic keyword or apparent mathematical quality.\n2. Map every recognizable mission-relevant route-level entry to a standalone\n   record under the project-designated directory, or `research/records/` by\n   default. Preserve its substantive text and chronological order; do not\n   strengthen its evidence label or status.\n3. Preserve foreign and ambiguous material under a project-designated\n   quarantine, or `research/quarantine/legacy/` by default, with its original\n   provenance and the reason it was not classified as live project history.\n   Quarantine is preservation, not a mathematical verdict. Do not link this\n   material from the live research index unless a reviewed mapping later\n   classifies it as mission-relevant.\n4. Use an entry's recorded date when available. Otherwise infer the earliest\n   date from Git history that contains the entry and mark `Date provenance:\n   inferred from Git history`. If Git cannot supply a date, use the migration\n   date and mark that the original date was unavailable.\n5. Put unmatched preamble or unstructured historical material in quarantine as\n   a dated `legacy-context` record rather than discarding it. Classify it as\n   mission-relevant only after review.\n6. For mapping review, show source boundaries, original/inferred date, proposed\n   filename, relevance class, evidence label carried forward, and any unresolved\n   provenance or authority question. Revise the mapping in response to review.\n7. Only after that mapping is reviewed, build a compact history entry point.\n   A small project may use one chronological linked line per approved route;\n   sustained programs should keep a short program/phase entry point with\n   route-level indexes below it. Preserve the original flat index and its\n   working links through a reviewed migration; see\n   [existing-repo-migration.md](references/existing-repo-migration.md).\n   Verify that every substantive part of the old log is represented in an\n   indexed record, a linked unclassified-route inventory, or quarantine before\n   replacing its body or changing the designated entry point. Retrospective\n   closeouts distinguish the historical cutoff from their later assessment.\n8. After migration, treat records and index entries as immutable. Append a new\n   correction record and index entry instead of rewriting history.\n\n## Phase 4 — write the approved project layer\n\nUse the assets selectively; delete unused sections and replace every\nplaceholder. A normal setup has:\n\n- concise root `AGENTS.md`;\n- a charter stating the main question, current deliverable, success criterion,\n  valuable fallback, and out-of-scope boundaries; a small project may state\n  them in root `AGENTS.md` instead, but never leaves them unrecorded;\n- optional `CLAUDE.md` importing `@AGENTS.md` for sessions that cannot load\n  `AGENTS.md` directly or need genuine Claude-specific additions;\n- at most one live dashboard;\n- optional claims, conventions, literature, one compact history entry point,\n  program/phase route indexes when useful, and immutable standalone records;\n- when local source retention is authorized, a documented\n  `.research-cache/literature/` convention and tracked Git ignore rule;\n- nested instructions only for genuinely local invariants;\n- documented verification commands and benchmark cases.\n\nDo not duplicate mutable state in persistent instructions. For new setup, put\nthe deliverable, success criterion and fallback in the charter, and current\nevidence, blocker and next action in the live dashboard. Root instructions\nshould point to those files and contain only stable local rules, authorization\nboundaries and checks. During migration, respect existing artifact pins and\nauthority before moving any mutable fact. Avoid standing instructions to load\nentire growing records; search for relevant contracts and history as needed.\nPreserve old checkpoint material before replacing live narratives with current\nstate and links. Inspector size and dated-marker counts are prompts, not\nauthority or mathematical verdicts.\nFor a sustained program, keep the top-level history navigational; route lines\nbelong in its designated program/phase index. Project-specific size budgets\nare advisory review triggers, not permission to truncate current conditions.\n\nFor a project whose claim dependencies and evidence frequently change, consider\nthe available `research-state` skill and its optional `.mathbox/` ledger. Use its\nconservative migration workflow: import exact claims and checked artifacts,\npreserve existing IDs and records, and designate a single live generated view.\nDo not initialize it for a small project that does not benefit. The ledger\nchecks bookkeeping; it neither certifies mathematics nor replaces proof files.\n\nFor sustained multi-route work, make `research-program` discoverable as the\ncoordinator of successive attempts, without copying its workflow into AGENTS.\n\n## Skill-layer rule\n\nThe default output is **no project skills**: use the installed `mathbox` plugin\nfor its canonical research workflows.\n\nNever synthesize local copies of the `mathbox` plugin components\n`research-attempt`, `proof-audit`, `literature-check`, `computation-audit`,\n`manuscript-integrate`, `proofread-math`, `research-retrospective`, or\n`research-init`, `research-program`, or `research-state`.\nNever write a skill to a root `skills/` directory.\n\nA repository skill is allowed only after explicit approval and only if its\nprocedure is genuinely project-specific, recurring, distinct from the canonical\ncatalog, and given a project-qualified name. Project facts, file paths,\nmathematical hazards, and benchmark examples belong in project files instead.\nIf remote/team portability requires common workflows, install and pin the\n`mathbox` plugin. If that host cannot load plugins, vendor exact versioned\ncomponent skills rather than rewriting them.\n\n## Phase 5 — validate\n\n1. Remove every placeholder.\n2. Confirm each referenced path exists or is explicitly planned.\n3. Confirm every command was discovered or supplied.\n4. Check authority, evidence labels, Git/network rules, and edit boundaries for\n   contradictions.\n5. Confirm that no `mathbox` plugin skill was duplicated locally and no skill\n   was put under `skills/`.\n6. Check instruction size and static links/paths.\n7. Review every reported dashboard/handoff candidate and broken relative path;\n   do not silently choose authority or rewrite a tentative backtick candidate.\n8. Confirm that any literature cache is excluded from inspection and ignored\n   by a tracked project rule rather than only by the cache's own internal\n   rule; do not open its source content during repository initialization.\n9. Run the cheapest verified project check when authorized.\n10. Inspect `git diff --check` and the full diff.\n11. Tell the user how to verify loaded instructions and skills in a fresh session.\n12. For a migration, reconcile the content crosswalk and compare relevant\n    ledger issues, pins, claims, links, and protected instructions to baseline.\n\nDo not commit unless explicitly authorized.\n\n## Final report\n\nReport files changed, hierarchy rationale, rules moved and destinations,\nvalidation, unresolved questions/commands, `mathbox` plugin availability, any\narchived duplicate skills, and one recommended namespaced plugin invocation.\nFor a migration, also report preserved history, unresolved authority conflicts,\nand any pre-existing versus newly introduced freshness issues.\n\nUse [output-contract.md](references/output-contract.md) as the acceptance\nchecklist.\n"
}