@texra-ai/cli 0.38.8 → 0.38.9
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/bin/texra.js +1070 -1046
- package/dist/resources/agents/correct.yaml +8 -6
- package/dist/resources/skills/inline-paper-critic/SKILL.md +40 -0
- package/dist/resources/skills/inline-paper-critic/agents/openai.yaml +4 -0
- package/dist/resources/skills/inline-paper-critic/references/critique-checklist.md +40 -0
- package/dist/resources/skills/lean-blueprint/SKILL.md +37 -0
- package/dist/resources/skills/lean-blueprint/agents/openai.yaml +4 -0
- package/dist/resources/skills/lean-blueprint/references/blueprint-checklist.md +28 -0
- package/dist/resources/skills/lean-proof-assistant/SKILL.md +30 -0
- package/dist/resources/skills/lean-proof-assistant/agents/openai.yaml +4 -0
- package/dist/resources/skills/lean-proof-assistant/references/proof-workflow.md +23 -0
- package/dist/resources/skills/lean-search/SKILL.md +30 -0
- package/dist/resources/skills/lean-search/agents/openai.yaml +4 -0
- package/dist/resources/skills/lean-search/references/search-playbook.md +23 -0
- package/dist/resources/skills/lean-simplifier/SKILL.md +30 -0
- package/dist/resources/skills/lean-simplifier/agents/openai.yaml +4 -0
- package/dist/resources/skills/lean-simplifier/references/simplifier-checklist.md +27 -0
- package/dist/resources/skills/literature-search/SKILL.md +30 -0
- package/dist/resources/skills/literature-search/agents/openai.yaml +4 -0
- package/dist/resources/skills/literature-search/references/source-evaluation.md +25 -0
- package/dist/resources/skills/manuscript-review/SKILL.md +32 -0
- package/dist/resources/skills/manuscript-review/agents/openai.yaml +4 -0
- package/dist/resources/skills/manuscript-review/references/review-checklist.md +34 -0
- package/dist/resources/skills/math-ocr/SKILL.md +29 -0
- package/dist/resources/skills/math-ocr/agents/openai.yaml +4 -0
- package/dist/resources/skills/math-ocr/references/ocr-checklist.md +21 -0
- package/dist/resources/skills/mathematical-enhancer/SKILL.md +32 -0
- package/dist/resources/skills/mathematical-enhancer/agents/openai.yaml +4 -0
- package/dist/resources/skills/mathematical-enhancer/references/enhancement-checklist.md +30 -0
- package/dist/resources/skills/scientific-presenter/SKILL.md +30 -0
- package/dist/resources/skills/scientific-presenter/agents/openai.yaml +4 -0
- package/dist/resources/skills/scientific-presenter/references/slide-quality-checklist.md +34 -0
- package/dist/resources/skills/scientific-simplifier/SKILL.md +30 -0
- package/dist/resources/skills/scientific-simplifier/agents/openai.yaml +4 -0
- package/dist/resources/skills/scientific-simplifier/references/simplification-checklist.md +23 -0
- package/dist/resources/skills/tikz-figure-builder/SKILL.md +31 -0
- package/dist/resources/skills/tikz-figure-builder/agents/openai.yaml +4 -0
- package/dist/resources/skills/tikz-figure-builder/references/figure-checklist.md +25 -0
- package/dist/resources/skills/writing-commenter/SKILL.md +35 -0
- package/dist/resources/skills/writing-commenter/agents/openai.yaml +4 -0
- package/dist/resources/skills/writing-commenter/references/commenting-checklist.md +33 -0
- package/dist/resources/tool_use_agents/review.yaml +3 -3
- package/package.json +2 -1
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Enhancement Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist when trying to improve a paper's mathematics rather than just its exposition.
|
|
4
|
+
|
|
5
|
+
## Look for
|
|
6
|
+
|
|
7
|
+
- Brute-force proofs that could be replaced by a cleaner idea
|
|
8
|
+
- Standard results that could shorten or strengthen the argument
|
|
9
|
+
- Generalizations that preserve the paper's point while broadening scope
|
|
10
|
+
- Tighter bounds, sharper constants, or cleaner structural statements
|
|
11
|
+
- Loose ends or assumptions that can actually be resolved
|
|
12
|
+
|
|
13
|
+
## Separate two classes of ideas
|
|
14
|
+
|
|
15
|
+
- Tractable improvements: implement them fully and verify them
|
|
16
|
+
- Speculative improvements: leave them as explicit suggestions with rationale
|
|
17
|
+
|
|
18
|
+
## Impact and confidence
|
|
19
|
+
|
|
20
|
+
- High impact, high confidence: implement
|
|
21
|
+
- High impact, low confidence: annotate as a substantial suggestion
|
|
22
|
+
- Moderate impact, high confidence: implement if it clarifies or strengthens the paper cleanly
|
|
23
|
+
- Low impact: avoid churn unless it unlocks something more important
|
|
24
|
+
|
|
25
|
+
## Quality control
|
|
26
|
+
|
|
27
|
+
- Do not claim a stronger result unless you have actually justified it.
|
|
28
|
+
- Keep the improved mathematics readable and trustworthy.
|
|
29
|
+
- Prefer substantial gains over decorative cleverness.
|
|
30
|
+
- Fall back to the original route cleanly if the enhancement does not survive scrutiny.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scientific-presenter
|
|
3
|
+
description: Build or revise scientific talks, posters, and Beamer slide decks from papers, codebases, figures, or LaTeX templates. Use when Codex needs to turn technical research into a clear presentation, preserve an existing slide theme, generate or improve figures, or iteratively compile and visually check presentation output.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Scientific Presenter
|
|
7
|
+
|
|
8
|
+
## When to use this skill
|
|
9
|
+
|
|
10
|
+
Use this skill for research talks, posters, code walkthrough decks, paper-to-slides conversions, and presentation revisions where visual quality matters as much as technical accuracy.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
1. Read any provided `.tex`, `.sty`, poster template, or slide template before planning content. Preserve the existing theme, typography, colors, macros, and structure unless the user asks for a redesign.
|
|
15
|
+
2. Survey the workspace before editing. Identify the core claims, algorithms, figures, tables, equations, and code artifacts that actually belong in the presentation.
|
|
16
|
+
3. Plan the deck around a story rather than around the paper's section order. Make each slide answer one question or advance one idea.
|
|
17
|
+
4. Prefer visual communication. Turn architecture, pipelines, derivations, and comparisons into diagrams, tables, overlays, or compact equations instead of dense prose blocks.
|
|
18
|
+
5. Keep code excerpts short and purposeful. Show only the lines needed to explain the mechanism, result, or design decision.
|
|
19
|
+
6. Compile early and often. After each substantial change, inspect the rendered output and fix layout, overflow, readability, and figure quality issues before continuing.
|
|
20
|
+
7. If figures or plots are generated from code, rerun the code when feasible and verify the resulting assets instead of mocking them by description.
|
|
21
|
+
|
|
22
|
+
## Quality Bar
|
|
23
|
+
|
|
24
|
+
- Keep body text readable at presentation scale. Split crowded slides instead of shrinking everything.
|
|
25
|
+
- Use equations sparingly and only when they clarify the argument. Define notation before using it on slides.
|
|
26
|
+
- Keep aspect ratios intact for figures and ensure axes, legends, and units are visible.
|
|
27
|
+
- Use progressive disclosure when the audience must absorb a derivation, algorithm, or workflow in stages.
|
|
28
|
+
- Treat visual QA as mandatory. A slide that compiles but clips, overlaps, or hides labels is not done.
|
|
29
|
+
|
|
30
|
+
For a stricter final pass, use [references/slide-quality-checklist.md](references/slide-quality-checklist.md) to review slide density, figure quality, poster layout, and Beamer-specific issues.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Slide Quality Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist when a deck or poster is mostly complete and needs a rigorous visual pass.
|
|
4
|
+
|
|
5
|
+
## Story and structure
|
|
6
|
+
|
|
7
|
+
- Make each slide answer one concrete question.
|
|
8
|
+
- Put the thesis, method, result, and takeaway in a visible narrative order.
|
|
9
|
+
- Split slides that mix too many jobs.
|
|
10
|
+
|
|
11
|
+
## Visual QA
|
|
12
|
+
|
|
13
|
+
- Check for overflow, clipping, overlapping elements, and unreadably small text.
|
|
14
|
+
- Keep figure aspect ratios intact.
|
|
15
|
+
- Confirm axes, legends, units, and captions are visible.
|
|
16
|
+
- Balance whitespace across slides and poster columns.
|
|
17
|
+
|
|
18
|
+
## Code and equations
|
|
19
|
+
|
|
20
|
+
- Show only the lines or formulas needed for the point being made.
|
|
21
|
+
- Prefer pseudocode, overlays, or side-by-side explanation over raw dumps.
|
|
22
|
+
- Define notation before using it on a slide.
|
|
23
|
+
|
|
24
|
+
## Figures and generated assets
|
|
25
|
+
|
|
26
|
+
- Regenerate plots from source code when feasible.
|
|
27
|
+
- Inspect generated images or PDFs directly after compilation.
|
|
28
|
+
- Fix missing labels, cropped legends, and poor contrast before moving on.
|
|
29
|
+
|
|
30
|
+
## Beamer and poster specifics
|
|
31
|
+
|
|
32
|
+
- Use slide titles consistently.
|
|
33
|
+
- Keep navigation, sectioning, and slide numbers coherent with the chosen template.
|
|
34
|
+
- For posters, check column balance, block boundaries, and header/footer clipping.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: scientific-simplifier
|
|
3
|
+
description: Simplify scientific code, LaTeX, and technical prose while preserving exact behavior, results, and meaning. Use when Codex needs to remove duplication, reduce unnecessary abstraction, clean up AI-generated bloat, or make a research codebase or manuscript clearer without changing its substance.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Scientific Simplifier
|
|
7
|
+
|
|
8
|
+
## When to use this skill
|
|
9
|
+
|
|
10
|
+
Use this skill when a scientific project feels bloated, repetitive, over-abstracted, or harder to read than it should be, but the underlying behavior and mathematics must remain unchanged.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
1. Inspect the target area before editing. Identify what is duplicated, indirect, dead, formulaic, or misleadingly complex.
|
|
15
|
+
2. Preserve outputs and meaning. Treat simplification as an expression change, not a behavior change.
|
|
16
|
+
3. Remove duplication only after verifying the repeated pieces serve the same purpose, not merely a similar shape.
|
|
17
|
+
4. Prefer direct, idiomatic language and native constructs over custom wrappers or ornamental abstractions.
|
|
18
|
+
5. Tighten scientific prose aggressively: delete filler openings, redundant transitions, vague significance claims, and conversation leakage.
|
|
19
|
+
6. Simplify one logical piece at a time and verify after each change with tests, compilation, or equivalent checks.
|
|
20
|
+
7. Stop when the code or prose reads like a deliberate design, not a pile of edits.
|
|
21
|
+
|
|
22
|
+
## Quality Bar
|
|
23
|
+
|
|
24
|
+
- Do not collapse distinct scientific regimes or assumptions into one helper just to save lines.
|
|
25
|
+
- Do not replace clear control flow with clever one-liners.
|
|
26
|
+
- Do not remove notation, equations, or comments that carry real meaning.
|
|
27
|
+
- Prefer smaller, safer edits over sweeping rewrites when the verification surface is large.
|
|
28
|
+
- If a simplification changes results, semantics, or narrative emphasis, revert it.
|
|
29
|
+
|
|
30
|
+
For a broader cleanup pass, use [references/simplification-checklist.md](references/simplification-checklist.md) when the codebase is large, the prose shows obvious AI artifacts, or you need a more systematic review of duplication and abstraction.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Simplification Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist for a deeper pass when a codebase or manuscript has accumulated obvious complexity.
|
|
4
|
+
|
|
5
|
+
## Code structure
|
|
6
|
+
|
|
7
|
+
- Find wrappers, dispatch layers, and factories that add no real abstraction.
|
|
8
|
+
- Remove dead code, unreachable branches, and commented-out blocks.
|
|
9
|
+
- Consolidate true duplicates only after checking semantics.
|
|
10
|
+
- Replace hand-rolled utilities with clear native constructs when that improves readability.
|
|
11
|
+
|
|
12
|
+
## Scientific prose
|
|
13
|
+
|
|
14
|
+
- Delete filler openings, repetitive transitions, and empty significance claims.
|
|
15
|
+
- Remove conversation leakage such as change notes or assistant-style narration.
|
|
16
|
+
- Replace vague claims with specific statements or cut them.
|
|
17
|
+
- Introduce notation once and stop re-explaining it.
|
|
18
|
+
|
|
19
|
+
## Safety checks
|
|
20
|
+
|
|
21
|
+
- Run tests, compile, or otherwise verify after each logical change.
|
|
22
|
+
- Revert any simplification that changes behavior, results, or scientific meaning.
|
|
23
|
+
- Prefer the smallest edit that materially improves clarity.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tikz-figure-builder
|
|
3
|
+
description: Create or refine TikZ figures for technical papers and slides. Use when Codex needs to add a new diagram, improve an existing figure, align a visual with manuscript notation, or iteratively compile and visually read the rendered output until the figure is correct and readable.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# TikZ Figure Builder
|
|
7
|
+
|
|
8
|
+
## When to use this skill
|
|
9
|
+
|
|
10
|
+
Use this skill for architecture diagrams, workflows, commutative diagrams, tensor-network sketches, algorithm schematics, annotated plots, and figure cleanups where the final output should be TikZ or closely integrated with LaTeX.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
1. Read the surrounding manuscript or slide context before drawing. Match the figure to the notation, vocabulary, and mathematical meaning already in use.
|
|
15
|
+
2. Decide what the figure must communicate. Reduce the diagram to the essential objects, relationships, flow, or geometry.
|
|
16
|
+
3. Prefer reusable styles and compact structure over copy-pasted node formatting.
|
|
17
|
+
4. Compile every substantial TikZ change and visually read the rendered image or PDF, not just the source code. Treat this as an automatic loop: edit, build, read, fix, and rebuild until the figure is stable.
|
|
18
|
+
5. Fix clipping, crowding, label collisions, uneven spacing, unreadable labels, and style drift immediately instead of deferring them.
|
|
19
|
+
6. For mathematically meaningful diagrams, verify that topology, arrow direction, labels, and adjacency actually match the equations or constructions they represent.
|
|
20
|
+
7. Keep captions and in-text references synchronized with the final figure.
|
|
21
|
+
|
|
22
|
+
## Quality Bar
|
|
23
|
+
|
|
24
|
+
- A pretty but mathematically wrong diagram is a failure.
|
|
25
|
+
- Labels must be legible and consistent with manuscript notation.
|
|
26
|
+
- Spacing should make structure obvious without decorative clutter.
|
|
27
|
+
- Avoid duplicated style definitions across multiple figures when a shared style can live in the preamble or a common file.
|
|
28
|
+
- Do not stop at source edits alone when a build is possible; the default is to compile, visually read the rendered result, and refine until it is clean.
|
|
29
|
+
- Ensure the figure integrates cleanly into the surrounding text and layout.
|
|
30
|
+
|
|
31
|
+
For dense or math-sensitive figures, use [references/figure-checklist.md](references/figure-checklist.md) to run a stricter pass over layout, consistency, and rendered correctness.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Figure Checklist
|
|
2
|
+
|
|
3
|
+
Use this file when a TikZ figure needs a stricter validation pass.
|
|
4
|
+
|
|
5
|
+
## Technical correctness
|
|
6
|
+
|
|
7
|
+
- Check that node relationships, arrows, labels, and topology match the underlying math or algorithm.
|
|
8
|
+
- Confirm the figure uses the same notation as the surrounding document.
|
|
9
|
+
|
|
10
|
+
## Layout
|
|
11
|
+
|
|
12
|
+
- Check for clipped edges, overlapping labels, uneven spacing, and hard-to-follow routing.
|
|
13
|
+
- Make the visual hierarchy obvious without decorative clutter.
|
|
14
|
+
|
|
15
|
+
## Reuse and consistency
|
|
16
|
+
|
|
17
|
+
- Factor repeated styles into shared definitions when multiple figures use the same look.
|
|
18
|
+
- Keep captions and in-text references aligned with the final figure.
|
|
19
|
+
|
|
20
|
+
## Compile-and-inspect loop
|
|
21
|
+
|
|
22
|
+
- Recompile after meaningful edits.
|
|
23
|
+
- Visually read the rendered figure, not just the source.
|
|
24
|
+
- Fix layout defects immediately instead of stacking more edits on top.
|
|
25
|
+
- Repeat the loop until clipping, collisions, spacing defects, and notation mismatches are gone rather than stopping after the first successful build.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: writing-commenter
|
|
3
|
+
description: Review research writing by leaving inline comments on logic, notation, narrative flow, positioning, and editorial impact. Use when Codex needs to annotate a paper or draft with reader-facing comments instead of silently rewriting it, especially for argument structure, symbol consistency, and publication-oriented presentation.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Writing Commenter
|
|
7
|
+
|
|
8
|
+
## When to use this skill
|
|
9
|
+
|
|
10
|
+
Use this skill when the main job is to comment on a manuscript rather than to silently edit it. It is suited to three distinct review modes: logical-flow review, notation review, and editorial elevation where the author should see the reasoning behind suggested changes.
|
|
11
|
+
|
|
12
|
+
## Workflow
|
|
13
|
+
|
|
14
|
+
1. Read the full manuscript before commenting. Understand the paper's argument, notation, structure, and current maturity level.
|
|
15
|
+
2. Choose the review mode up front unless the user explicitly asks for a mixed pass:
|
|
16
|
+
- logical flow: structure, transitions, narrative coherence, balance of explanation
|
|
17
|
+
- notation: symbol consistency, definition order, convention conflicts, graceful renaming
|
|
18
|
+
- editorial elevation: title, abstract, framing, audience fit, rhetorical rhythm, figure-caption storytelling
|
|
19
|
+
3. Keep strict scope within the chosen mode. Do not drift into mathematical correctness, generic line edits, or copyediting unless the user asked for that.
|
|
20
|
+
4. Prefer inline comments that point to concrete issues and propose actionable fixes. If the document already has an annotation convention, preserve it.
|
|
21
|
+
5. In logic mode, comment where the reader loses the thread: weak transitions, misplaced paragraphs, unsupported jumps, and broken narrative arc.
|
|
22
|
+
6. In notation mode, comment where symbols are inconsistent, reused confusingly, or introduced too late, and prefer graceful solutions that minimize document-wide churn.
|
|
23
|
+
7. In editorial mode, comment where the paper undersells its contribution, flattens important ideas, fails to position itself for likely reviewers, or misuses figures, tables, and captions as mere decoration.
|
|
24
|
+
8. Keep the comments self-contained and compile-safe when they live inside LaTeX. The document should remain readable and buildable with the comments present.
|
|
25
|
+
|
|
26
|
+
## Quality Bar
|
|
27
|
+
|
|
28
|
+
- Comments should be specific enough that an author can act on them immediately.
|
|
29
|
+
- Prefer fewer, higher-signal comments over annotating every sentence.
|
|
30
|
+
- Distinguish local fixes from systemic issues. Do not pretend a document-wide reorganization is a one-line tweak.
|
|
31
|
+
- Preserve the author's voice and technical content; the goal is to diagnose and guide, not to overwrite reflexively.
|
|
32
|
+
- If the document already uses an inline comment macro, match its style and syntax correctly.
|
|
33
|
+
- For a mixed-mode review, still label the issue mentally by mode so the feedback does not blur into generic “make it better” commentary.
|
|
34
|
+
|
|
35
|
+
For a stricter pass over comment discipline, issue selection, and compile-safe inline annotations, use [references/commenting-checklist.md](references/commenting-checklist.md).
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Commenting Checklist
|
|
2
|
+
|
|
3
|
+
Use this checklist when annotating a paper directly instead of silently rewriting it.
|
|
4
|
+
|
|
5
|
+
## Focus
|
|
6
|
+
|
|
7
|
+
- Choose one primary mode unless the user explicitly wants a combined pass.
|
|
8
|
+
- Separate structural issues, notation issues, and editorial-impact issues.
|
|
9
|
+
- Comment on the strongest problems first.
|
|
10
|
+
- Avoid flooding the manuscript with low-value marginal notes.
|
|
11
|
+
|
|
12
|
+
## Logic and structure
|
|
13
|
+
|
|
14
|
+
- Flag weak transitions, abrupt jumps, misplaced content, and broken section-to-section flow.
|
|
15
|
+
- Mark concepts used before they are introduced.
|
|
16
|
+
- Distinguish local fixes from problems that require real reorganization.
|
|
17
|
+
|
|
18
|
+
## Notation
|
|
19
|
+
|
|
20
|
+
- Track conflicting symbols, reused notation, and undefined quantities.
|
|
21
|
+
- Prefer graceful solutions that minimize unnecessary document-wide renaming.
|
|
22
|
+
|
|
23
|
+
## Editorial impact
|
|
24
|
+
|
|
25
|
+
- Mark titles, abstracts, introductions, captions, and claims that undersell or overstate the contribution.
|
|
26
|
+
- Comment from the reader's perspective: what would confuse, bore, or trigger skepticism?
|
|
27
|
+
- Calibrate to audience: editor, expert reviewer, broad peer, or outsider.
|
|
28
|
+
|
|
29
|
+
## Inline comment discipline
|
|
30
|
+
|
|
31
|
+
- Keep comments actionable and brief.
|
|
32
|
+
- If the comments live inside LaTeX, keep them compile-safe.
|
|
33
|
+
- Match the document's existing annotation convention when one already exists.
|
|
@@ -36,11 +36,11 @@ prompts:
|
|
|
36
36
|
(1) For every key derivation, reproduce it step-by-step. Check that each step follows logically from the previous one. When a step is nontrivial, write out the intermediate algebra explicitly.
|
|
37
37
|
(2) Verify limiting cases and special cases of results. Does the general formula reduce correctly when a parameter vanishes or diverges?
|
|
38
38
|
(3) Check dimensional consistency of equations.
|
|
39
|
-
(4) Verify numerical values, coefficients, and prefactors by independent computation.
|
|
39
|
+
(4) Verify numerical values, coefficients, and prefactors by independent computation when they are substantive or not easily checked by inspection.
|
|
40
40
|
(5) For inequalities or bounds, test with concrete examples to confirm they hold.
|
|
41
41
|
(6) For differential equations, verify that stated solutions satisfy the original equation.
|
|
42
|
-
(7) Use the wolfram tool
|
|
43
|
-
(8) If wolfram is unavailable, fall back to bash with short Python/SymPy scripts for the same
|
|
42
|
+
(7) Prefer direct mathematical review when a claim can be checked by hand. Use the wolfram tool only when computation adds real evidence for nontrivial symbolic algebra, integrals, identities, or numerical spot-checks; do not request external computation for elementary facts such as nonnegativity of squares or $x^2 = 0$ over the reals. Sessions do NOT persist between wolfram tool calls — each execution starts fresh. For multi-step verifications needing persistence, write to a .wl file and run via bash.
|
|
43
|
+
(8) If computational verification is warranted and wolfram is unavailable, fall back to bash with short Python/SymPy scripts for the same checks.
|
|
44
44
|
|
|
45
45
|
Notation Consistency:
|
|
46
46
|
(1) Use grep to find all occurrences of key symbols and variables across the manuscript.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@texra-ai/cli",
|
|
3
|
-
"version": "0.38.
|
|
3
|
+
"version": "0.38.9",
|
|
4
4
|
"description": "TeXRA CLI — your AI theorist in the terminal.",
|
|
5
5
|
"license": "SEE LICENSE IN LICENSE.txt",
|
|
6
6
|
"author": "TeXRA.ai",
|
|
@@ -77,6 +77,7 @@
|
|
|
77
77
|
"react": "^19.2.7",
|
|
78
78
|
"semver": "^7.8.4",
|
|
79
79
|
"string-width": "^8.0.0",
|
|
80
|
+
"strip-ansi": "^7.2.0",
|
|
80
81
|
"typescript": "^6.0.3",
|
|
81
82
|
"wrap-ansi": "^10.0.0"
|
|
82
83
|
}
|