Workflow for Agentic Mathematical Research and LaTeX Writing

Agentic Latex Template Repository (Github) ↗

Note: Currently I am working on revising the template to restrict the agents even harder, removing all write permissions for most prompts and handling writes using a deterministic agent wrapper. I will need to test the new version on my actual research before pushing it.

Overview

The workflow I am about to describe has a corresponding template repository that is linked at the top of this article. The agentic tools included have been developed with healthy use in mind and generally do not directly edit documents. In short, the repository treats LLM agents as somewhat delirious junior collaborators with a massive knowledge base but a high hallucinatory tendency. The prompts provided generally instruct the agent to make a separate .tex file containing a report with the relevant response, rather than telling it to edit academic material directly. Of course, all LLM reports should be scrutinized heavily before being integrated into the main paper. The LaTeX paper template included in the repo is also quite nice ( in my humble opinion >:D ), with some useful macros for incorporating todos and Preliminary Markers.

At a high level, this project aimed to improve the process of mathematical research using Codex / Claude Code style tools rather than the alternative of bashing one's head against a browser chatbot while stuck on a proof. Context awareness from the entire repository helps massively with research capacity, and the engineered prompts included have been refined through use to be effective at their goals. There are also meta-prompts included to improve the prompt engineering process.

This template was used extensively in my bachelor thesis with great results, and I believe it was a large part of what allowed me to learn the relevant background and work through the novel statements and proofs so efficiently. It in no way did the work for me, and it is not designed to do that for anyone, but it gave me the time saving resources that allowed me to invest my time into design choices, statement formulation, proof design, and writing quality rather than manual literature searching and manual edge-case testing, and prevented me from building on top of flawed results by providing extensive scrutiny to my proofs and statements.

I suppose that suffices for an introduction. Below I have included a suggested workflow for using the repository that also highlights what each of the major prompts do. I plan to eventually write a full specification document in a more formal tone to accompany the repository, but for now that is on my backburner.

Suggested Workflow

I do not think there is one universally correct way to use this repository, and in practice I jump around the prompts quite a bit depending on what I am working on. Still, there is a fairly natural workflow which I think gets most of the benefits while avoiding the temptation to simply throw one's entire paper at an agent and ask it to "make it good".

If you already have an existing LaTeX project, the first thing I would do is dump it into merge/ and run prompt_merge_tex.txt. This will convert the original project into the standard template setup of the repository. Of course, you may want to use a different template or organizational schema than I do, in which case the transfer work will be a little bit more manual. It is advised in this case to update the engineered prompts to fit the style that you want to use.

The merge prompt is mostly a mechanical migration prompt. It transfers the manuscript into the repository structure, attempting to preserve all mathematical content while splitting things between chapters, figures, elements, style files, etc. I would absolutely diff and manually inspect the result afterwards, but it saves a rather annoying amount of initial project setup.

If you are starting a paper from scratch you can skip this entirely. The paper/chapters/examples/ directory contains templates which can be copied into the actual chapter directory, and paper/main.tex is the main file. The examples directories are intentionally treated as immutable templates by most of the prompts, so you generally copy them rather than editing them directly.

Once there is actually a paper in the repository, I would run prompt_refine_tex_directory.txt. This does a mostly structural clean-up pass: splitting files where sensible, normalizing labels and references, organizing notation, and enforcing the chapter \to figure \to element dependency structure. Importantly, it is explicitly told not to alter the mathematical meaning of the manuscript. If you ran the merge prompt to get your paper in, it should have set it up according to the standards by default.

Next I would run prompt_detail_level_evaluator.txt. This reads the actual paper and produces a paper-specific style guide describing what level of exposition should be expected for different kinds of mathematical facts. I added this because "be rigorous" is a rather useless instruction in isolation. A paper aimed at probabilists does not need to prove elementary measure theory facts, while an unusual construction central to the paper probably deserves substantially more explanation. The generated guide gives later agents some context for making this distinction.

I would like to briefly note that the prompts themselves work pretty effectively without much care being given to the style guides or repo state management. If you just want to do math, you can mostly ignore these more advanced features as you likely won't need to squeeze out the extra 0.9% of agent effectiveness that comes from them. I often ignore them myself, which is why they are somewhat underdeveloped features compared to the engineered prompts themselves and the LaTeX template.

After this setup, I mostly just do mathematics and write normally.

During writing I make fairly liberal use of the \todo{...} and \prelim{...}{...} systems. The former is self explanatory. The latter is particularly useful for statements where I know that some background fact should be sourced, but I do not want to break my train of thought to spend twenty minutes digging through papers. I can write the mathematical argument first, mark the claim as needing a preliminary, and resolve the bibliography properly later. You can place a \previewtoggle somewhere in your main.tex to render a version of the paper without these markers.

For active mathematical work, I tend to use the prompts in 3 - Mathematical Tasks/ as targeted tools rather than general mathematical oracles. If I have formulated a statement but am not yet confident that it is even true, prompt_conjecture_evaluator.txt is a good first pass. It deliberately alternates between proof attempts and counterexample searches rather than spending its entire context window desperately trying to prove whatever nonsense I happened to conjecture five minutes earlier.

I plan to design a more concentrated "counter-example search" prompt for the case where you don't want the agent to waste tokens trying to prove the result, but that is again on the backburner. In general, I find that proofs that agents provide are wrong in the details, but provide decent insight into an overall angle of attack. This is of course why they should never be doing the writing directly.

For a statement which I have good reason to believe is true but whose proof is difficult, prompt-proof-engine.txt is the heavier tool. It recursively decomposes the desired result into lemmas, stress tests the intermediate lemmas, recursively attacks the remaining pieces, and writes out the resulting proof tree. The important thing here is that "failure" can still be extremely useful. If the agent cannot prove the theorem but reduces it to two precise technical lemmas, that is much more useful than a chatbot giving me six paragraphs of vague suggestions. Again, this proof is almost always wrong, but can reveal things about the proof strategy that can be incorporated when you prove it manually.

The reports produced by these tools go into paper/reports/. I read those manually and decide what, if anything, belongs in the real manuscript. This separation is probably the most important design choice in the whole repository. I want the agent to be able to spend a ridiculous amount of tokens exploring an idea, trying cases, decomposing arguments and making mistakes without simultaneously being allowed to rewrite the mathematical object that I am actually claiming authorship of. It is also great for parallelization using branches.

There is an important caveat here: telling an agent not to edit something does NOT mean that it definitely will not edit it. Prompt constraints are useful guardrails, not access controls. An agent may misunderstand an instruction, behave unexpectedly, or simply modify a file it was explicitly told to leave alone. I therefore strongly recommend checking the git diff after every agentic task which has write access to the repository, even when the prompt claims that the manuscript is read-only. The repository is designed to reduce the probability and impact of unwanted edits, not to make them impossible.

Once I have written a proof myself, prompt_proof_review.txt is useful as an adversarial second reader. This prompt is not allowed to silently repair the proof. It writes a separate review identifying hidden assumptions, invalid implications, missing cases, circular dependencies and other possible problems. I have found this use especially valuable because the cost of asking for another extremely pedantic review is effectively zero (besides the token cost). You should of course not confuse "the model found no issue" with a proof of correctness, but repeated adversarial review catches a lot of stupid mistakes.

There is also prompt_proof_revision.txt, which is useful in a slightly different situation. Suppose I have already proved a proposition, but three days later I change notation, slightly weaken an assumption, or reformulate the surrounding theorem. Rather than redoing the whole proof exploration process, the revision prompt checks whether the existing argument survives the changed context and produces a proposed adapted version while preserving the original proof strategy as much as possible.

Literature work is another place where repository awareness helps massively. prompt-literature-explorer.txt searches for sources corresponding to unresolved \prelim markers. It first checks the bibliography and any local reference PDFs, then searches externally where necessary, and is instructed not to accept a citation merely because the title or abstract looks vaguely relevant. It attempts to verify the actual statement and give an exact theorem, section or page locator. Unverified sources are supposed to remain unresolved rather than being hallucinated into the bibliography.

I usually store important reference PDFs in paper/references/ as well. This is especially useful for books, paywalled papers or references which an agent would otherwise have difficulty accessing consistently. They can be attached to entries in refs.bib, making the local source available as part of the repository context.

Towards the later stages of a paper I would run prompt_evaluate_references.txt. This is essentially a bibliography audit. It checks what every entry is actually being used to support, distinguishes broad citations from claims involving precise theorem/page locators, and gives each reference an evidence-based verification score. Again, the purpose is not to have an LLM certify a bibliography as correct. The purpose is to give the human author a fairly exhaustive list of places where attention is warranted.

I would then run prompt_todo_reviewer.txt. This reads the manuscript as a whole and is allowed to do exactly one substantive thing: insert reviewer todo of the form \todo{R: ...}. It looks for things like undefined notation, missing assumptions, unclear logical dependencies, suspicious proof jumps and exposition which is inappropriate for the intended reader. Since it cannot quietly rewrite the surrounding text, I can go through the todo list one by one and decide whether I agree.

Finally, once a substantial amount of work has accumulated, the maintenance prompts can be used to update the repository state files and README. This is more relevant for long-running projects than small papers, but having an agent-readable snapshot of the repository becomes increasingly useful once a project has accumulated a large number of chapters, experiments, reports, prompts and supporting files. For small-medium projects of just you and a few collaborators, you can probably ignore this.

If one of the supplied prompts does not quite do what you want, I would generally resist the urge to manually accumulate increasingly specific instructions inside it. The 0 - Meta/ directory contains tools for exactly this problem. If you have a new task in mind which is not already covered, you can give a rough description of the desired behaviour to prompt_engineer_prompt.txt. It will turn that rough specification into a more structured repository-aware prompt with explicit scope, inputs, outputs, validation steps and restrictions.

If an existing prompt is conceptually correct but repeatedly behaves in some annoying way, use prompt-revisor.txt instead. Give it the prompt together with examples or a description of what went wrong, and let it revise the control structure around that failure mode. I find this much better than endlessly appending things like "IMPORTANT: DO NOT DO X" every time the model finds a new creative interpretation of the instructions. The prompts in this repository should be treated as evolving tools rather than fixed artifacts: use them, inspect their outputs and diffs, notice systematic failure modes, and refine them around the way you actually work. This is also the meta-prompt I would use if you substantially change the organizational structure of the template and need new prompts which understand your version of the repository rather than mine.

So, very roughly, my recommended cycle is:

1. Get the paper into the repository structure.
2. Establish the paper-specific style/detail conventions.
3. Do the actual research and writing yourself.
4. Use agents for conjecture testing, proof decomposition, literature exploration and adversarial review.
5. Read their reports and manually integrate the useful parts.
6. Periodically run structural, todo, citation, and state audits.

The crucial point is that the agents generally operate around the manuscript rather than replacing the author. Repository-wide context gives them much more information than a browser chatbot, while the prompt constraints stop that increased capability from immediately turning into "please autonomously rewrite my mathematics".

That is the current workflow. I expect it to keep changing as I use the repository for actual work and discover new ways in which my prompts fail to deliver. The meta-prompting tools are included largely for this reason. I do not think there is much value in pretending that prompt engineering can be solved once in the abstract. The more useful process has been to use a prompt, observe recurring failures, identify what part of its control structure allowed those failures, and revise it accordingly.

There is also nothing particularly sacred about my exact workflow or prompts. The repository is a template, and I would strongly encourage anyone using it to gradually mutate the style guides and prompt collection around the kind of mathematics they actually do. The more general idea is simply to move from:

"Here is a theorem. Prove it."

towards something more like:

"Here is the complete research repository. Understand the surrounding definitions and results, try to break this statement, explore several proof strategies, keep explicit track of what is verified and what is speculative, and give me a report which I can interrogate before I change a single line of the actual paper."

That is, at least so far, where I have found these tools considerably more useful.