Update to Mathbox

SKILL.md text changes

− removed · + added

--- before
+++ after
@@ -1,294 +1,166 @@
 ---
 name: research-init
 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.
+  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 the repository as a durable research environment. Do not regenerate
-skills supplied by the `mathbox` plugin inside it.
+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 after an explicit request.
-- A request for a migration plan is read-only; a plugin upgrade alone does not
-  authorize rewriting an existing project's files.
-- Inspect before asking questions; do not ask for facts safely available in the
-  repository.
-- Ask at most five material questions at a time.
-- Present a proposed file/migration plan before writing unless the user already
-  authorized immediate execution.
-- Apply the user's existing authorization to coherent setup/retrofit changes;
-  do not ask again for routine edits already in scope. Preserve substantive
-  existing material and show a reviewable diff. Resolve genuine ambiguity before
-  replacing an authoritative proof, convention, or historical record.
-- Do not invent commands, proof status, conventions, repository paths, or
-  permissions.
-- Preserve unrelated work. Do not commit, push, install dependencies, upload
-  content, or contact third parties without authorization.
-- Keep stable rules in instructions, recurring procedures in `mathbox` plugin
-  skills, mutable facts in research records, and deterministic enforcement in
-  code.
+- 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
 
-1. Determine repository root and inspect `git status --short`. Distinguish a
-   clean Git worktree from unavailable Git metadata; do not report both as an
-   empty status.
-2. Locate root/nested `AGENTS.md`, Claude memory/rules, current skill folders,
-   and any unrecognized `skills/` folders. If root `CLAUDE.md` exists alongside
-   `AGENTS.md`, check whether it imports `@AGENTS.md`. A missing `CLAUDE.md` is
-   expected when Claude Code loads `AGENTS.md` directly.
-3. Locate likely charter, status, claims, conventions, proof/manuscript,
-   literature, log, computation, tests, CI, and build artifacts. Recognize
-   semantic aliases and variants, including `PLAN`, `STATUS`, `OUTLINE`,
-   `MANIFEST`, theorem/fact inventories and dated or qualified `HANDOFF` files;
-   names are candidates, not authority decisions. Inventory computation
-   manifests separately from build manifests. Detect project-declared path maps
-   and source-cache locations, and recognizable alternate cache conventions,
-   without reading cached source content or proposing a second cache by default.
-   Treat theorem/fact inventory entries derived from literature as candidate
-   assertions until their exact source records are checked; schedule that
-   verification before dependent proof or manuscript work treats them as facts.
-4. Classify the designated history entry point, often `RESEARCH_LOG.md`, as a
-   compact flat index, a program-level index, long-form legacy history, or a
-   mixture. Locate any program/phase route indexes and standalone records;
-   check that the entry point reaches them.
-   Detect `.mathbox/config.json` without replaying all history during inventory.
-5. Detect duplicate `mathbox` plugin skill names and paths hard-coded relative
-   to a skill installation. Report multiple dashboard or handoff candidates for
-   authority review. Conservatively check relative Markdown links and
-   path-shaped backtick references; distinguish certain broken links from
-   tentative path candidates and ignore code fences, URLs and shell examples.
-6. Run the bundled read-only inspector when available:
+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 <mathbox-research-init-directory>/scripts/inspect_repo.py --root <repo>
+python3 <skill-directory>/scripts/inspect_repo.py --root PROJECT
 ```
 
-Locate the installed `mathbox:research-init` plugin skill directory (or its
-standalone installation); do not substitute a guessed relative path. The
-default report is a brief inventory with counts and current-path examples,
-including research-log and computation-manifest classifications, project and
-misplaced root skills, and build manifests. Use `--full` for the complete
-Markdown report or `--format json` for complete structured data. Broken links
-under archive, import, legacy, migration, or quarantine paths are counted as
-historical and listed only in those full views; do not treat their location
-alone as a live broken link. Links in current route records stay current. A dated
-checkpoint-marker count is a prompt to inspect a long live file, not a verdict
-about mathematical status or whether its history can be removed.
-If current-path findings are omitted, inspect those findings in the full view
-before making authority or edit decisions; a historical-only overflow need not
-be loaded into the working context.
-
-Produce a fact sheet with observed facts, tentative inferences, conflicts, and
-missing information. Preserve confidence distinctions: a filename, directory
-name or path-shaped code span is not proof of its semantic role.
-
-Initialization may inventory literature records and cache policy, but it does
-not establish what cited mathematics proves. Do not perform substantive source
-lookups during setup; record them as follow-up work for the available
-`literature-check` skill (`mathbox:literature-check` in plugin installations).
-If the user also requested those source checks, execute them as a subsequent
-work package within the same assignment. The setup boundary does not authorize
-leaving an explicitly requested verification task unfinished.
+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
 
-Use [interview.md](references/interview.md). Resolve only material ambiguity:
-research goal, current deliverable, evidence thresholds, source authority,
-fragile conventions, edit boundaries, verification, confidentiality/network,
-Git policy, and definition of done.
-
-If a manuscript or submission is the current deliverable, also resolve its
-venue/template, language, audience, deadline and timezone, page-count rule and
-page budget. The budget must account explicitly for front matter, bibliography,
-figures/tables and contingency. Never infer these constraints from a filename,
-an old draft, a generic venue norm or an approximate current page count.
-
-Distinguish theorem goal from near-term output, proof from computation,
-chain-level from derived/homology/topological claims, stable rules from mutable
-status, and personal preferences from team-shared policy.
+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:
-
-1. repository facts and unresolved questions;
-2. proposed instruction hierarchy and source-of-truth order;
-3. exact files to create, modify, move, archive, or leave untouched;
-4. rules to retain, shorten, move, automate, or remove;
-5. protected paths and approval boundaries;
-6. verified fast, targeted, full, and manuscript checks;
-7. migration risks and stale/conflicting instructions;
-8. skill-layer decision from [skill-layer.md](references/skill-layer.md).
-9. whether authorized literature retention needs a project-local cache and a
-   tracked ignore rule, or should retain a safely identified project-declared
-   alternate cache rather than creating a duplicate.
-10. for a manuscript deliverable, the confirmed submission constraints and a
-   complete page budget, with every unresolved item left explicitly unknown.
-11. source-dependent inventory entries that remain unverified, and a literature-
-    check work package ordered before any dependent claim is promoted or used.
-12. for existing live-file migration, a section inventory and proposed content
-    crosswalk, current ledger/pin baseline where present, and unresolved
-    authority conflicts. Complete the mapping before replacing old content.
-
-When this explicitly requested setup, retrofit, or refresh finds route-level
-prose in `RESEARCH_LOG.md`, the proposed plan must include the legacy migration
-below. Trigger on the log's structure, not its line count. Detection does not
-authorize the rewrite.
-
-## Existing instruction and live-state migration
-
-For an explicit request to plan or perform migration of an existing repository's
-large `AGENTS.md`, dashboard, or handoff, follow
-[existing-repo-migration.md](references/existing-repo-migration.md). It defines
-the baseline, content crosswalk, pin-aware edits, and before/after checks. A
-plan-only request stops at the reviewed plan. Do not treat a plugin update as a
-reason to rewrite a ledger, refresh hashes, or import confident prose as proof.
-Use the separate legacy research-log process below if that log contains
-route-level prose; use the available `research-state` skill for any optional
-ledger adoption or claim/evidence revision.
-
-## Legacy research-log migration
-
-Make the mapping and file plan reviewable. An ordinary research attempt or
-retrospective does not trigger migration. Before creating the compact index,
-present a source-span-to-destination mapping to the user or designated project
-owner and obtain its review. Broad retrofit authorization permits preparation
-of the mapping and files, but it does not substitute for review of route
-relevance or ambiguous provenance.
-
-1. Compare each prospective entry with the repository's explicit mission,
-   current target and scope. Classify it as mission-relevant, foreign, or
-   ambiguous, citing the text that supports the classification. Do not infer
-   relevance from a filename, topic keyword or apparent mathematical quality.
-2. Map every recognizable mission-relevant route-level entry to a standalone
-   record under the project-designated directory, or `research/records/` by
-   default. Preserve its substantive text and chronological order; do not
-   strengthen its evidence label or status.
-3. Preserve foreign and ambiguous material under a project-designated
-   quarantine, or `research/quarantine/legacy/` by default, with its original
-   provenance and the reason it was not classified as live project history.
-   Quarantine is preservation, not a mathematical verdict. Do not link this
-   material from the live research index unless a reviewed mapping later
-   classifies it as mission-relevant.
-4. Use an entry's recorded date when available. Otherwise infer the earliest
-   date from Git history that contains the entry and mark `Date provenance:
-   inferred from Git history`. If Git cannot supply a date, use the migration
-   date and mark that the original date was unavailable.
-5. Put unmatched preamble or unstructured historical material in quarantine as
-   a dated `legacy-context` record rather than discarding it. Classify it as
-   mission-relevant only after review.
-6. For mapping review, show source boundaries, original/inferred date, proposed
-   filename, relevance class, evidence label carried forward, and any unresolved
-   provenance or authority question. Revise the mapping in response to review.
-7. Only after that mapping is reviewed, build a compact history entry point.
-   A small project may use one chronological linked line per approved route;
-   sustained programs should keep a short program/phase entry point with
-   route-level indexes below it. Preserve the original flat index and its
-   working links through a reviewed migration; see
-   [existing-repo-migration.md](references/existing-repo-migration.md).
-   Verify that every substantive part of the old log is represented in an
-   indexed record, a linked unclassified-route inventory, or quarantine before
-   replacing its body or changing the designated entry point. Retrospective
-   closeouts distinguish the historical cutoff from their later assessment.
-8. After migration, treat records and index entries as immutable. Append a new
-   correction record and index entry instead of rewriting history.
-
-## Phase 4 — write the approved project layer
-
-Use the assets selectively; delete unused sections and replace every
-placeholder. A normal setup has:
-
-- concise root `AGENTS.md`;
-- a charter stating the main question, current deliverable, success criterion,
-  valuable fallback, and out-of-scope boundaries; a small project may state
-  them in root `AGENTS.md` instead, but never leaves them unrecorded;
-- optional `CLAUDE.md` importing `@AGENTS.md` for sessions that cannot load
-  `AGENTS.md` directly or need genuine Claude-specific additions;
-- at most one live dashboard;
-- optional claims, conventions, literature, one compact history entry point,
-  program/phase route indexes when useful, and immutable standalone records;
-- when local source retention is authorized, a documented
-  `.research-cache/literature/` convention and tracked Git ignore rule;
-- nested instructions only for genuinely local invariants;
-- documented verification commands and benchmark cases.
-
-Do not duplicate mutable state in persistent instructions. For new setup, put
-the deliverable, success criterion and fallback in the charter, and current
-evidence, blocker and next action in the live dashboard. Root instructions
-should point to those files and contain only stable local rules, authorization
-boundaries and checks. During migration, respect existing artifact pins and
-authority before moving any mutable fact. Avoid standing instructions to load
-entire growing records; search for relevant contracts and history as needed.
-Preserve old checkpoint material before replacing live narratives with current
-state and links. Inspector size and dated-marker counts are prompts, not
-authority or mathematical verdicts.
-For a sustained program, keep the top-level history navigational; route lines
-belong in its designated program/phase index. Project-specific size budgets
-are advisory review triggers, not permission to truncate current conditions.
-
-For a project whose claim dependencies and evidence frequently change, consider
-the available `research-state` skill and its optional `.mathbox/` ledger. Use its
-conservative migration workflow: import exact claims and checked artifacts,
-preserve existing IDs and records, and designate a single live generated view.
-Do not initialize it for a small project that does not benefit. The ledger
-checks bookkeeping; it neither certifies mathematics nor replaces proof files.
-
-For sustained multi-route work, make `research-program` discoverable as the
-coordinator of successive attempts, without copying its workflow into AGENTS.
+Present facts/conflicts and exact files to create, modify, move, archive or retain;
+source-of-truth hierarchy; rules retained/moved/automated; protected paths and
+approval boundaries; verified fast/targeted/full/manuscript checks; migration
+risks; and the [skill-layer decision](references/skill-layer.md).
+
+Include cache retention/ignore policy, retaining a safely identified alternate
+cache rather than creating a duplicate. Identify unverified source-derived
+inventories and the verification package required before promotion. For a
+manuscript deliverable give confirmed constraints and a complete page budget
+with unknowns explicit. Existing live-file migrations need a source/destination
+crosswalk, pin baseline and unresolved authority conflicts before replacement.
+
+## Existing-file and history migration
+
+Follow [existing-repo-migration.md](references/existing-repo-migration.md) for all
+baseline, crosswalk, pin-aware editing and history migration mechanics. Route by
+inspector class: `long-form-legacy`/`mixed` needs reviewed extraction;
+`compact-linked-index` may need reviewed sharding if the flat index is too large;
+`unstructured` needs manual inventory before classification. Detection alone
+never authorizes rewriting. A plan-only request ends at the reviewable plan.
+A plugin upgrade alone does not authorize a project migration or hash refresh.
+
+Use available `research-state` (`mathbox:research-state` in plugin installations)
+for optional ledger adoption or evidence revisions; if unavailable preserve
+prose records and report the limitation. Never import confident prose as proof.
+
+## Phase 4 — write the authorized project layer
+
+Read [output-contract.md](references/output-contract.md) **before writing**.
+Use assets selectively, delete unused sections and replace scaffolding values:
+
+| Asset | Default destination |
+|---|---|
+| [AGENTS.template.md](assets/AGENTS.template.md) | `AGENTS.md` |
+| [CLAUDE.template.md](assets/CLAUDE.template.md) | optional `CLAUDE.md` |
+| [PROJECT_CHARTER.template.md](assets/PROJECT_CHARTER.template.md) | `PROJECT_CHARTER.md` |
+| [RESEARCH_STATUS.template.md](assets/RESEARCH_STATUS.template.md) | one of `RESEARCH_STATUS.md` / `HANDOFF.md` |
+| [PROOF_OBLIGATIONS.template.md](assets/PROOF_OBLIGATIONS.template.md) | `PROOF_OBLIGATIONS.md` / `CLAIMS.md` |
+| [CONVENTIONS.template.md](assets/CONVENTIONS.template.md) | `CONVENTION_REGISTRY.md` / `CONVENTIONS.md` |
+| [LITERATURE.template.md](assets/LITERATURE.template.md) | `LITERATURE_LEDGER.md` / `LITERATURE.md` |
+| [RESEARCH_LOG.template.md](assets/RESEARCH_LOG.template.md) | `RESEARCH_LOG.md` |
+| [VERIFICATION.template.md](assets/VERIFICATION.template.md) | `VERIFICATION.md` |
+
+Explicit project-designated paths override these defaults. Exactly one designated
+live dashboard states current evidence, blocker and next action. Record mission,
+deliverable, success, fallback and exclusions in the charter, or an `AGENTS.md`
+*Mission* section when there is no charter. Other root instructions contain
+stable local rules, authority/edit boundaries, checks and pointers rather than
+mutable facts. `CLAUDE.md` is optional when sessions load `AGENTS.md` directly;
+otherwise it imports that file and holds only genuine host additions.
+
+Use optional claims, conventions and literature records as needed. Define
+**history entry point**, **route index** and **route record** as navigation,
+compact outcome links and immutable standalone route detail respectively. A
+small project can combine entry point/index; sustained programs link through
+program/phase indexes. Keep exactly one live view and search growing history
+instead of imposing full loads. Preserve checkpoint material and active pins
+before replacing live narratives; migration reference gives these rules.
+
+Authorized retention needs a documented cache convention and tracked ignore
+rule. Nested instructions serve only genuinely local invariants. Verification
+commands and mathematical benchmarks must be concrete and discovered/supplied.
+
+For frequently changing dependencies consider optional ledger adoption, with
+one generated live view and only checked artifacts. It does not certify proofs.
+For sustained work make `research-program` discoverable without copying its
+workflow into root instructions.
 
 ## Skill-layer rule
 
-The default output is **no project skills**: use the installed `mathbox` plugin
-for its canonical research workflows.
-
-Never synthesize local copies of the `mathbox` plugin components
-`research-attempt`, `proof-audit`, `literature-check`, `computation-audit`,
-`manuscript-integrate`, `proofread-math`, `research-retrospective`, or
-`research-init`, `research-program`, or `research-state`.
-Never write a skill to a root `skills/` directory.
-
-A repository skill is allowed only after explicit approval and only if its
-procedure is genuinely project-specific, recurring, distinct from the canonical
-catalog, and given a project-qualified name. Project facts, file paths,
-mathematical hazards, and benchmark examples belong in project files instead.
-If remote/team portability requires common workflows, install and pin the
-`mathbox` plugin. If that host cannot load plugins, vendor exact versioned
-component skills rather than rewriting them.
-
-## Phase 5 — validate
-
-1. Remove every placeholder.
-2. Confirm each referenced path exists or is explicitly planned.
-3. Confirm every command was discovered or supplied.
-4. Check authority, evidence labels, Git/network rules, and edit boundaries for
-   contradictions.
-5. Confirm that no `mathbox` plugin skill was duplicated locally and no skill
-   was put under `skills/`.
-6. Check instruction size and static links/paths.
-7. Review every reported dashboard/handoff candidate and broken relative path;
-   do not silently choose authority or rewrite a tentative backtick candidate.
-8. Confirm that any literature cache is excluded from inspection and ignored
-   by a tracked project rule rather than only by the cache's own internal
-   rule; do not open its source content during repository initialization.
-9. Run the cheapest verified project check when authorized.
-10. Inspect `git diff --check` and the full diff.
-11. Tell the user how to verify loaded instructions and skills in a fresh session.
-12. For a migration, reconcile the content crosswalk and compare relevant
-    ledger issues, pins, claims, links, and protected instructions to baseline.
-
-Do not commit unless explicitly authorized.
-
-## Final report
-
-Report files changed, hierarchy rationale, rules moved and destinations,
-validation, unresolved questions/commands, `mathbox` plugin availability, any
-archived duplicate skills, and one recommended namespaced plugin invocation.
-For a migration, also report preserved history, unresolved authority conflicts,
-and any pre-existing versus newly introduced freshness issues.
-
-Use [output-contract.md](references/output-contract.md) as the acceptance
-checklist.
+Default to **no project skills**. Never synthesize local copies of canonical
+Mathbox skills or write skills under root `skills/`. The inspector's `CANONICAL`
+set defines the catalog; read the skill-layer reference for approved project
+skills and exact versioned vendoring when the host cannot load plugins.
+
+## Phase 5 — validate and report
+
+Remove placeholders outside intentional fenced format examples; verify paths
+exist or are explicitly planned and commands were discovered/supplied. Check
+authority, evidence/review/freshness, Git/network and edit boundaries for conflicts.
+Review all live-view candidates and broken paths without silently choosing
+an authority. Keep instructions limited to stable rules and pointers; detailed
+procedures and repeated mutable facts signal excess load.
+
+Confirm no duplicated canonical or root skills, and caches are excluded from
+inspection and ignored by a tracked project rule. Run the cheapest verified
+project check when authorized, then inspect the full diff and `git diff --check`.
+For migrations compare the complete crosswalk, pins, issues, claims, protected
+rules and links with baseline; distinguish old issues from introduced ones.
+
+Report files/hierarchy, moved rules and destinations, checks and skipped reasons,
+remaining conflicts/commands, plugin availability and archived skills. Give one
+recommended invocation and how to verify instruction/skill loading in a fresh
+session. Migration reports also identify preserved history and freshness issues.