@texra-ai/cli 0.38.7 → 0.38.9

package/dist/resources/agents/correct.yaml

@@ -1,4 +1,5 @@
 name: correct
+displayName: Correct — typos, grammar & LaTeX
 description: Fixes typos, grammar, and LaTeX formatting without changing your writing style or content.
 
 settings:
@@ -9,13 +10,13 @@ settings:
 
 prompts:
   systemPrompt: |
-    You are a meticulous LaTeX proofreader. Your task is to correct typos, grammar, and formatting issues in a research paper while preserving the authors' intent and content.
+    You are a meticulous LaTeX proofreader. Your task is to correct typos, grammar, and formatting issues in a research paper while preserving the authors' intent and content. Do not rewrite mathematical content.
 
     When correcting a professional *.tex \LaTeX document, you must:
     {{ LATEX_STYLE_RULES }}
 
   userPrefix: |
-    I am going to give you a \LaTeX document of a research paper. You are about to correct the typos and mistakes in the document. So please read the document carefully.
+    I am going to give you a \LaTeX document of a research paper. You are about to correct typos, grammar, and formatting in the document. So please read the document carefully.
 
     Here is the \LaTeX document with input files (which may include appendix, and LaTeX auxiliary files that define the math commands you should use):
 
@@ -33,11 +34,13 @@ prompts:
     {% endif %}
 
   userRequest: |
-    Please carefully read through the entire document, looking for any typos, grammatical errors, formatting inconsistencies, incorrect math, or factual inaccuracies.
+    Please carefully read through the entire document, looking for typos, grammatical errors, and formatting inconsistencies that can be corrected without changing the paper's claims.
 
-    As you review the document, make the following corrections and improvements:
-    - Ensure that all mathematical equations are correct and all statements are factually accurate.
-    - Use consistent mathematical symbols and notations throughout the document.
+    As you review the document, make only proofreading corrections:
+    - Preserve every mathematical claim, equation, theorem statement, and factual assertion.
+    - Do not change math tokens inside inline math, display math, theorem statements, or derivations except for LaTeX syntax/formatting fixes such as spacing, delimiters, braces, or indentation.
+    - Do not replace a false or unsupported mathematical statement with a different true statement. For example, if the input says `(x+1)^2 = x^2 + 1`, keep that equation unchanged.
+    - Mathematical verification belongs to review-oriented agents; this agent only proofreads.
 
     Output one updated \LaTeX document for each input file, using the matching input filename as the document name.
 

package/dist/resources/agents/merge.yaml

@@ -1,4 +1,5 @@
 name: merge
+displayName: Merge — fold edits into original
 description: Merges partial edits back into the full original document.
 
 settings:

package/dist/resources/agents/ocr.yaml

@@ -1,4 +1,5 @@
 name: ocr
+displayName: OCR — PDF to LaTeX
 description: Converts handwritten mathematical content from images into LaTeX.
 
 settings:

package/dist/resources/agents/polish.yaml

@@ -1,4 +1,5 @@
 name: polish
+displayName: Polish — instruction-driven rewrite
 description: Rewrites and restructures text to improve clarity, flow, and readability based on your instructions.
 
 settings:

package/dist/resources/agents/transcribe_audio.yaml

@@ -1,4 +1,5 @@
 name: transcribe_audio
+displayName: Transcribe Audio — speech to LaTeX
 description: Transcribes audio with speaker identification and LaTeX math formatting.
 
 settings:

package/dist/resources/skills/inline-paper-critic/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: inline-paper-critic
+description: Critically annotate technical papers with inline comments about mathematical gaps, unjustified steps, risky assumptions, and verified results. Use when Codex needs to leave compile-safe review comments directly in a LaTeX manuscript, especially in a `\\criticize{comment}{severity}{confidence}` style for derivation-heavy papers where appendices and hidden calculations must be checked carefully.
+---
+
+# Inline Paper Critic
+
+## When to use this skill
+
+Use this skill for inline technical review of mathematical or derivation-heavy papers when the output should be comments embedded in the manuscript rather than a separate review memo.
+
+## Workflow
+
+1. Read the entire manuscript, including appendices and auxiliary files, before deciding that a step is missing or unjustified.
+2. Expand important derivations mentally or on scratch paper before commenting. A good inline critique should come from actual verification, not surface-level suspicion.
+3. Prioritize issues that affect validity: broken proofs, missing essential steps, unjustified coefficients, hidden assumptions, incorrect limits, or inconsistent claims.
+4. If a derivation is already handled in an appendix, say so and adjust severity accordingly rather than treating the main text as simply wrong.
+5. When the document already uses a `\criticize{comment}{severity}{confidence}`-style macro, preserve that format. Otherwise adapt to the local inline annotation convention without losing the same discipline.
+6. If the macro is missing, provide a minimal command definition before inserting annotations:
+
+   ```latex
+   \newcommand{\criticize}[3]{\textcolor{red}{\textbf{[#2|#3]} #1}}
+   ```
+
+   Keep the document's existing color/theme conventions when present.
+
+7. Use inline comments strategically. Group related minor issues and reserve the harshest comments for problems that really threaten the result.
+8. When a calculation checks out, leave explicit verification comments when that helps the author distinguish true problems from confirmed material.
+9. Ensure every inline comment is valid LaTeX and can remain in the document without breaking compilation.
+
+## Quality Bar
+
+- Check appendices before accusing the paper of omission.
+- Base comments on actual mathematical verification whenever possible.
+- Use severity and confidence consistently; do not inflate comments just to sound forceful.
+- Treat severity as impact on validity and confidence as certainty of the diagnosis, not as two versions of the same number.
+- A compile-safe inline review comment is better than a sharper comment that breaks the document.
+- If you verified something as correct, say what you checked.
+
+For a deeper pass over severity discipline, appendix-first review, and compile-safe comment writing, use [references/critique-checklist.md](references/critique-checklist.md).

package/dist/resources/skills/inline-paper-critic/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Inline Paper Critic'
+  short_description: 'Annotate math papers with technical critique'
+  default_prompt: 'Use $inline-paper-critic to leave compile-safe inline comments on the technical problems and verified results in this manuscript.'

package/dist/resources/skills/inline-paper-critic/references/critique-checklist.md

@@ -0,0 +1,40 @@
+# Critique Checklist
+
+Use this checklist for inline technical criticism of a manuscript.
+
+## Verification before criticism
+
+- Check appendices and supplementary derivations before claiming something is missing.
+- Work through the calculation or proof enough to know whether the issue is real.
+- Distinguish a missing explanation from an actual mathematical error.
+
+## What to comment on
+
+- Broken proofs or unjustified logical steps
+- Missing derivation steps that matter for validity
+- Unjustified coefficients, assumptions, or approximations
+- Contradictions between text, equations, and claimed results
+- Verified calculations that are worth marking as checked
+
+## Severity and confidence
+
+- Reserve the highest severity for issues that endanger the main claim.
+- Use lower severity for exposition or local cleanup.
+- Keep confidence separate from severity; an alarming but uncertain issue should say so.
+- If using a `\criticize{...}{severity}{confidence}` scheme, keep the comment text self-contained and specific enough to survive outside the conversation.
+
+## Typical scale
+
+- Severity 5: invalidates a central claim or proof
+- Severity 4: seriously weakens a major argument
+- Severity 3: important but not fatal gap or inconsistency
+- Severity 2: local but worthwhile fix
+- Severity 1: cosmetic or low-impact cleanup
+
+## LaTeX safety
+
+- Write inline comments that compile cleanly.
+- Use proper math mode, escaped special characters, and reference syntax.
+- If `\criticize` is undefined, add a minimal macro such as
+  `\newcommand{\criticize}[3]{\textcolor{red}{\textbf{[#2|#3]} #1}}` and match local style conventions.
+- Prefer fewer precise comments over many noisy ones.

package/dist/resources/skills/lean-blueprint/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: lean-blueprint
+description: Create and maintain Lean blueprint documents that connect informal mathematics to Lean 4 formalization. Use when Codex needs to draft or sync blueprint entries, map paper results to Lean declarations, track dependencies between statements, or keep blueprint prose aligned with a changing Lean codebase.
+---
+
+# Lean Blueprint
+
+## When to use this skill
+
+Use this skill for blueprint authoring and maintenance: writing new dependency-tracked blueprint content, syncing an existing blueprint with Lean declarations, or translating Lean formalization progress into human-readable mathematical prose.
+
+## Workflow
+
+1. Survey the Lean project and the existing blueprint files before writing anything. Understand the mathematical architecture and the current formalization status first.
+2. Build or repair the dependency graph from the main results backward. Each node should be a meaningful unit of work for a contributor.
+3. Use the blueprint macros deliberately:
+   - `\lean{Namespace.decl}` to link to Lean declarations
+   - `\leanok` only when the declaration is actually formalized and clean
+   - `\uses{label1,label2}` for dependency tracking
+   - `\notready` for items that still need blueprint work
+   - `\proves{label}` when a proof block is separated from its statement
+4. Write blueprint prose as mathematics, not as disguised Lean syntax. Use conventional notation and let the Lean linkage live in the explicit blueprint macros.
+5. When a declaration exists, verify its name, status, and statement before marking blueprint entries as formalized.
+6. Keep blueprint statements, proof sketches, and dependency annotations synchronized with the real Lean codebase.
+7. Check for drift in both directions: Lean declarations missing from the blueprint, and blueprint entries that no longer match Lean.
+8. Treat the blueprint as a human coordination document first and a status mirror second.
+
+## Quality Bar
+
+- Blueprint prose should read like normal mathematical writing.
+- Never let Lean identifiers leak into the prose body when standard notation exists.
+- Dependencies should be explicit and accurate enough to support parallel work.
+- Formalized status markers should reflect reality, not aspiration.
+- Statement mismatches between blueprint and Lean are real bugs, not cosmetic issues.
+- A reader should be able to understand the mathematical roadmap without reading Lean source first.
+
+For new blueprint skeletons or drift audits, use [references/blueprint-checklist.md](references/blueprint-checklist.md) to check dependency tracking, statement syncing, and notation translation.

package/dist/resources/skills/lean-blueprint/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Lean Blueprint'
+  short_description: 'Write and sync Lean blueprints'
+  default_prompt: 'Use $lean-blueprint to draft or sync this blueprint against the current Lean project.'

package/dist/resources/skills/lean-blueprint/references/blueprint-checklist.md

@@ -0,0 +1,28 @@
+# Lean Blueprint Checklist
+
+Use this checklist when authoring or syncing a blueprint against a Lean project.
+
+## Project survey
+
+- Read both the blueprint files and the Lean declarations they reference.
+- Identify the main results, the dependency DAG, and the current formalization status.
+
+## Writing
+
+- Write the prose as standard mathematics, not as Lean syntax with punctuation.
+- Use conventional notation whenever possible.
+- Keep proof sketches strategic and human-readable.
+- Use the explicit blueprint macros consistently: `\lean`, `\leanok`, `\uses`, `\notready`, and `\proves` when appropriate.
+
+## Syncing
+
+- Verify each linked Lean declaration still exists and still states the same mathematics.
+- Update formalization-status markers only after checking the real code.
+- Check for declaration drift in both directions: missing blueprint entries and stale references.
+- Check that the informal blueprint statement still matches the Lean theorem mathematically, not just by name.
+
+## Dependencies
+
+- Keep dependency annotations explicit and accurate.
+- Remove spurious dependencies that hide parallelism.
+- Flag circular mathematical dependencies, not just syntactic graph issues.

package/dist/resources/skills/lean-proof-assistant/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: lean-proof-assistant
+description: Develop and debug Lean 4 proofs in project context. Use when Codex needs to understand a theorem, inspect goals, search for supporting lemmas, write or repair Lean proof terms or tactic scripts, and iterate with diagnostics until the file is clean.
+---
+
+# Lean Proof Assistant
+
+## When to use this skill
+
+Use this skill for day-to-day Lean 4 proof development: proving lemmas, debugging errors, filling gaps, inspecting goals, or turning an informal proof outline into working Lean code.
+
+## Workflow
+
+1. Read the target file and surrounding declarations before editing. Understand the theorem statement, available hypotheses, and local notation.
+2. Check the current diagnostics first. Let the elaborator tell you what is actually wrong before you guess.
+3. Outline the proof strategy informally before writing code when the theorem is nontrivial.
+4. Search for existing lemmas and APIs before inventing helper lemmas or long tactic scripts.
+5. Work in small iterations: edit one proof step, recheck, inspect the new goal state, and continue.
+6. Prefer clear proof structure over brittle wizardry. Use the tactic or term style that makes the mathematical idea easiest to review.
+7. Finish by making the file clean: no broken goals, no stale debugging commands, no accidental scaffolding left behind.
+
+## Quality Bar
+
+- Do not fight the goal blindly. Inspect the precise goal and local context after each meaningful step.
+- Prefer existing Mathlib lemmas over reproving folklore.
+- Keep proofs readable enough that another formalizer can maintain them.
+- Treat diagnostics as ground truth.
+- If a proof attempt becomes opaque or fragile, back up and choose a clearer route.
+
+For stuck proofs or longer debugging sessions, use [references/proof-workflow.md](references/proof-workflow.md) for a stricter loop around search, inspection, iteration, and cleanup.

package/dist/resources/skills/lean-proof-assistant/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Lean Proof Assistant'
+  short_description: 'Develop and debug Lean proofs'
+  default_prompt: 'Use $lean-proof-assistant to prove or repair this Lean theorem and iterate until the file is clean.'

package/dist/resources/skills/lean-proof-assistant/references/proof-workflow.md

@@ -0,0 +1,23 @@
+# Lean Proof Workflow
+
+Use this checklist when proof development is stuck or the file needs a disciplined debugging loop.
+
+## Core loop
+
+- Read the theorem statement and nearby lemmas first.
+- Check diagnostics before guessing.
+- Inspect the exact goal and local hypotheses after each meaningful step.
+- Edit in small increments and recheck immediately.
+
+## Search and proof strategy
+
+- Search for existing lemmas before proving helpers.
+- Try both type-shape and name-based searches.
+- Prefer clear proof structure over long fragile tactic chains.
+- Use the tactic family that matches the goal shape instead of forcing one hammer everywhere.
+
+## Cleanup
+
+- Remove stale debugging commands and temporary scaffolding.
+- Keep the final proof readable enough for another contributor to maintain.
+- Leave the file with clean diagnostics.

package/dist/resources/skills/lean-search/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: lean-search
+description: Find existing Lean 4 and Mathlib lemmas, APIs, imports, and formalization patterns. Use when Codex needs to answer whether a result already exists, locate the right theorem or module, understand how Mathlib formalizes a concept, or avoid duplicate formalization work.
+---
+
+# Lean Search
+
+## When to use this skill
+
+Use this skill when the main job is discovery rather than proving: find the right lemma, import, namespace, declaration name, or formalization pattern before writing code.
+
+## Workflow
+
+1. Start from the mathematical content, not from a guessed theorem name.
+2. Search broadly and iteratively. Try multiple surfaces before concluding something is missing: type-shape search, name-pattern search, source grep, module-path discovery, and docs or community references.
+3. Read the actual source around promising hits. The surrounding lemmas and proof patterns often matter more than the first exact match.
+4. Distinguish exact matches, adaptable near-matches, and genuinely missing API.
+5. When something appears missing, say where it would likely belong and what the most general statement should be.
+6. Report enough metadata to make the result usable immediately: full name, import path, statement shape, and any caveats.
+7. Show your search process briefly so another formalizer can trust the conclusion and continue from it.
+
+## Quality Bar
+
+- Prevent duplicate work whenever possible.
+- Do not stop after one search method fails.
+- Prefer Mathlib's general result over a project-specific reproving of the same fact.
+- Show what you searched and what you found so the answer is auditable.
+- When uncertain, provide the best nearby API and explain the gap.
+
+For hard-to-find results, use [references/search-playbook.md](references/search-playbook.md) to run a more disciplined search across theorem names, type shapes, source files, and import paths.

package/dist/resources/skills/lean-search/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Lean Search'
+  short_description: 'Find Mathlib lemmas and imports'
+  default_prompt: 'Use $lean-search to find the right Mathlib lemmas, imports, and formalization pattern for this statement.'

package/dist/resources/skills/lean-search/references/search-playbook.md

@@ -0,0 +1,23 @@
+# Lean Search Playbook
+
+Use this playbook when the first obvious search attempt does not find the right API.
+
+## Search order
+
+- Start with type-shape or theorem-name search.
+- Search Mathlib source directly when local packages are available.
+- Read surrounding source, not just isolated hits.
+- Check docs or community references when the local codebase is inconclusive.
+- Do not conclude “missing” after a single failed query; reformulate the statement and search again.
+
+## Reporting results
+
+- Distinguish exact match, near match, and missing result.
+- Include the full declaration name and import path.
+- Explain how a near match needs to be adapted.
+
+## Missing-lemma cases
+
+- Say why the result appears absent.
+- Suggest the likely general statement.
+- Suggest where such a lemma would naturally live.

package/dist/resources/skills/lean-simplifier/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: lean-simplifier
+description: Refactor Lean 4 code and proofs toward Mathlib-quality style without changing theorem statements or computational meaning. Use when Codex needs to simplify tactic scripts, generalize declarations, improve naming and organization, remove duplication, or make Lean code cleaner and more upstream-ready.
+---
+
+# Lean Simplifier
+
+## When to use this skill
+
+Use this skill when Lean code already works or nearly works, but it is noisy, repetitive, overly specialized, poorly named, or farther from Mathlib style than it should be.
+
+## Workflow
+
+1. Read the file as a whole before changing local proofs. Many style and generality problems only make sense at file scope.
+2. Check diagnostics first so you know whether you are simplifying a clean file or repairing active breakage.
+3. Preserve meaning exactly: theorem statements, definitions, and computed behavior should not change.
+4. Improve the file in the order that usually pays off most: naming and organization, import hygiene, docstrings, proof cleanup, then generalization and deduplication.
+5. Replace brittle tactic chains with clearer arguments when that actually improves reviewability.
+6. Search Mathlib before keeping local lemmas that smell standard.
+7. Recheck after each logical edit and revert any “simplification” that makes the code harder to trust.
+
+## Quality Bar
+
+- Target Mathlib-quality readability, not just shorter code.
+- Prefer the weakest useful assumptions and the most general reusable statement.
+- Do not over-generalize just for aesthetics.
+- Remove debugging leftovers, dead code, and sorry-driven scaffolding.
+- A shorter proof is worse if it becomes opaque.
+
+For serious cleanup or upstream preparation, use [references/simplifier-checklist.md](references/simplifier-checklist.md) to review style, generality, proof cleanup, and lint-facing details.

package/dist/resources/skills/lean-simplifier/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Lean Simplifier'
+  short_description: 'Refactor Lean code toward Mathlib style'
+  default_prompt: 'Use $lean-simplifier to clean up this Lean file without changing what its declarations mean.'

package/dist/resources/skills/lean-simplifier/references/simplifier-checklist.md

@@ -0,0 +1,27 @@
+# Lean Simplifier Checklist
+
+Use this checklist for deeper cleanup passes aimed at Mathlib-quality code.
+
+## Style and organization
+
+- Keep imports minimal and organized.
+- Use consistent naming that follows Mathlib patterns.
+- Add or improve docstrings for public declarations.
+- Group related declarations and remove dead fragments.
+
+## Proof cleanup
+
+- Replace brittle chains with clearer arguments when possible.
+- Prefer `calc`, well-scoped `simp`, and direct structure over clutter.
+- Avoid shortening proofs at the cost of readability.
+
+## Generality and reuse
+
+- Use the weakest useful assumptions.
+- Merge true duplicates through generalization when it simplifies the API.
+- Search Mathlib before retaining project-local copies of standard results.
+
+## Verification
+
+- Re-run diagnostics after each logical edit.
+- Revert any refactor that introduces new breakage or obscures the argument.

package/dist/resources/skills/literature-search/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: literature-search
+description: Discover, verify, and synthesize academic literature and web sources for research tasks. Use when Codex needs to find recent papers, trace citations, compare preprints with published versions, verify attributed claims, or build a source-backed literature summary with primary references.
+---
+
+# Literature Search
+
+## When to use this skill
+
+Use this skill for related-work searches, citation verification, research briefings, source-backed summaries, and claim checking across papers, arXiv, DOIs, and the open web.
+
+## Workflow
+
+1. Start from the actual question. Identify the topic, time window, field, and whether the user wants breadth, depth, recency, or verification.
+2. Prefer primary sources. Use publisher pages, DOI metadata, arXiv records, official project pages, and original papers before secondary summaries.
+3. Distinguish source types clearly: peer-reviewed publication, preprint, project page, documentation, benchmark site, or news coverage.
+4. Capture bibliographic facts while searching: title, authors, venue, year, DOI, arXiv ID, and URL.
+5. Cross-check important claims across more than one source when possible, especially for dates, quantitative results, and priority claims.
+6. For literature reviews, group findings by theme or method rather than presenting an unstructured list.
+7. When the user needs a recommendation or synthesis, explain the tradeoffs and evidence rather than only listing papers.
+
+## Quality Bar
+
+- Do not present unverified claims as settled fact.
+- Prefer the latest authoritative version when preprint and journal versions differ.
+- Keep citation details precise enough that a researcher can find the source immediately.
+- Separate what a paper claims from what you infer from it.
+- Note recency explicitly when the topic is moving quickly.
+
+For a deeper evaluation pass, use [references/source-evaluation.md](references/source-evaluation.md) when comparing conflicting sources, building a formal literature review, or checking whether a citation really supports a claim.

package/dist/resources/skills/literature-search/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Literature Search'
+  short_description: 'Find and verify research sources'
+  default_prompt: 'Use $literature-search to find the most relevant papers and verify the key claims for this topic.'

package/dist/resources/skills/literature-search/references/source-evaluation.md

@@ -0,0 +1,25 @@
+# Source Evaluation Checklist
+
+Use this file when the search result needs to be rigorous, citable, or recommendation-grade.
+
+## Source hierarchy
+
+- Prefer original papers, publisher pages, official documentation, and project pages.
+- Treat news posts, blogs, and summaries as secondary context unless the user explicitly wants them.
+
+## Verification
+
+- Confirm title, authors, year, venue, DOI, and arXiv ID.
+- Check whether the paper version you cite is a preprint or a peer-reviewed publication.
+- When a claim matters, verify that the cited source really supports it.
+
+## Synthesis
+
+- Group papers by method, question, or result rather than listing them chronologically.
+- Separate what the source states from your own inference.
+- Note disagreement, uncertainty, or version drift explicitly.
+
+## Recency
+
+- State dates for fast-moving topics.
+- Prefer the most recent authoritative source when multiple versions exist.

package/dist/resources/skills/manuscript-review/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: manuscript-review
+description: Audit technical manuscripts for mathematical correctness, logical soundness, notation consistency, evidence quality, and figure or code alignment. Use when Codex needs to review a paper, verify derivations, prioritize findings, or produce a rigorous findings-first assessment instead of rewriting prose blindly.
+---
+
+# Manuscript Review
+
+## When to use this skill
+
+Use this skill for serious review passes on papers, notes, appendices, or technical drafts where the main job is to find problems, verify important claims, and report actionable findings.
+
+## Workflow
+
+1. Read the full manuscript context first, including appendices, bibliography, macros, figures, and any supporting code that drives results.
+2. Identify the main claims and the highest-risk derivations, proofs, experiments, and references before going broad.
+3. Verify critical calculations independently when feasible. Check limiting cases, dimensions, signs, factors, boundary conditions, and whether stated results follow from the setup.
+4. Use computational verification tools when available for symbolic algebra, identities, spot checks, and code-backed results. If you verify something numerically or symbolically, say so explicitly in the findings.
+5. Trace notation across the document. Confirm symbols are defined before use and stay stable across sections, figures, and code.
+6. Check code-manuscript consistency when the paper depends on scripts, notebooks, generated figures, or implemented algorithms.
+7. Check whether the manuscript actually delivers the goals stated in the abstract and introduction.
+8. Produce findings first. Order them by severity and point to exact locations.
+9. Distinguish confirmed errors, likely issues, and open questions. Do not blur them together.
+
+## Quality Bar
+
+- Check appendices before claiming a derivation is missing.
+- Focus on issues that affect validity, interpretation, reproducibility, or reader comprehension.
+- Be specific about what you verified and how.
+- Prefer a short list of high-signal findings over a noisy dump of minor edits.
+- If no major issues are found, say that explicitly and note any residual uncertainty or untested areas.
+
+For a formal audit pass, use [references/review-checklist.md](references/review-checklist.md) when the manuscript is mathematically dense, has code-backed figures or computations, or needs a full findings report.

package/dist/resources/skills/manuscript-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Manuscript Review'
+  short_description: 'Audit manuscripts for technical issues'
+  default_prompt: 'Use $manuscript-review to review this paper and report the highest-priority technical findings first.'

package/dist/resources/skills/manuscript-review/references/review-checklist.md

@@ -0,0 +1,34 @@
+# Review Checklist
+
+Use this file when the manuscript needs a formal technical review rather than a quick read.
+
+## Main claims
+
+- Identify the paper's stated goals from the abstract and introduction.
+- Check whether the main body actually delivers each goal.
+
+## Mathematical verification
+
+- Reproduce key derivations independently when feasible.
+- Check signs, factors, dimensions, limits, and boundary conditions.
+- Verify that solutions satisfy the equations they claim to solve.
+- Use symbolic or numerical checks when useful, and report what was checked.
+
+## Appendices and notation
+
+- Check appendices before claiming detail is missing.
+- Confirm every important symbol is defined before use.
+- Track notation consistency across text, equations, figures, captions, and code.
+
+## Figures, code, and references
+
+- Check that figures match the text and that labels are consistent.
+- Compare code-backed claims with the actual implementation when code is available.
+- Verify that cited sources support the specific claims attached to them.
+- Check that quantitative claims in prose match tables, code outputs, and plotted data.
+
+## Findings format
+
+- Lead with findings, ordered by severity.
+- Include exact locations and short explanations of impact.
+- Separate confirmed errors, likely issues, and open questions.

package/dist/resources/skills/math-ocr/SKILL.md

@@ -0,0 +1,29 @@
+---
+name: math-ocr
+description: Convert handwritten or image-based mathematical content into notation-consistent LaTeX. Use when Codex needs to transcribe equations from notes, screenshots, whiteboards, or scans, reconcile ambiguous symbols against an existing document, or clean up OCR output into compilable mathematical LaTeX.
+---
+
+# Math OCR
+
+## When to use this skill
+
+Use this skill when the input is handwritten math, a screenshot of equations, or rough symbolic content that must become clean LaTeX matching an existing paper, note set, or slide deck.
+
+## Workflow
+
+1. Read the surrounding LaTeX context first when it exists. Reuse the document's notation, macro names, environment style, and equation conventions.
+2. Inspect the image carefully before transcribing. Identify ambiguous glyphs, line breaks, superscripts, subscripts, delimiters, and alignment structure.
+3. Translate math into the simplest correct LaTeX that matches the target document's style.
+4. Mark uncertainty mentally and resolve it against context instead of guessing in isolation.
+5. If the expression belongs inside a larger derivation, preserve the intended structure rather than producing a flat symbol dump.
+6. Review the transcription once for likely OCR confusions such as similar letters, missing braces, swapped indices, or incorrect nesting.
+
+## Quality Bar
+
+- Notation consistency beats literal shape matching when the handwriting is ambiguous.
+- Preserve mathematical structure, not just token order.
+- Ensure delimiters, fractions, and indices are syntactically sound and compile cleanly.
+- Prefer standard LaTeX environments already used by the target document.
+- Call out unresolved ambiguity instead of silently inventing a precise symbol.
+
+For ambiguity-heavy input, use [references/ocr-checklist.md](references/ocr-checklist.md) when the handwriting is messy, symbols are overloaded, or the result must fit strict manuscript notation.

package/dist/resources/skills/math-ocr/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: 'Math OCR'
+  short_description: 'Transcribe handwritten math to LaTeX'
+  default_prompt: 'Use $math-ocr to convert this handwritten mathematics into notation-consistent LaTeX.'

package/dist/resources/skills/math-ocr/references/ocr-checklist.md

@@ -0,0 +1,21 @@
+# OCR Checklist
+
+Use this file when the handwriting or scan quality makes transcription error-prone.
+
+## Context matching
+
+- Reuse the target document's notation, macros, and environment style.
+- Resolve ambiguous symbols against nearby equations or definitions first.
+
+## Common OCR traps
+
+- Similar letters such as `x` and `\chi`, `v` and `\nu`, `l` and `1`
+- Misread superscripts, subscripts, and nested braces
+- Dropped delimiters, alignment markers, or fraction structure
+- Swapped indices or incorrect ordering in tensor-like notation
+
+## Final checks
+
+- Ensure the LaTeX is syntactically valid.
+- Preserve the intended structure of multi-line derivations.
+- Flag unresolved ambiguity instead of inventing precision that is not supported by the image.