Disclosure: AI tools helped draft and edit this article. A human publisher reviewed the final text and workflow before publication.
Putting four tools in a list does not make a workflow. The difficult part is
deciding which tool owns each artifact, what the next tool may change, and what
must still be checked by a person.
This recipe uses four bounded roles:
- Obsidian keeps the source ledger, claim status, notes, and open questions in readable Markdown.
- Claude Code works across the outline and manuscript files while material factual claims remain tied to ledger IDs.
- LaTeX owns the versionable manuscript, bibliography, equations, and build warnings.
- Codex acts as a separate critic of the ledger, manuscript diff, and build log. It is not treated as evidence.
The objective is not automatic authorship. It is a manuscript whose claims,
sources, build, and review trail remain inspectable.
Start with files, not a blank chat
paper-project/
├── sources/ # permitted PDFs, links, and notes
├── brief.md # question, audience, scope, deadline, rules
├── source-ledger.md # claim -> citekey -> verification status
├── outline.md
├── manuscript.tex
├── library.bib
└── review-findings.md
You can clone the starter repository:
git clone https://github.com/Software-Sausage/recipes.git sausage-recipes
cd sausage-recipes/recipes/research-paper
Work in a private copy when the paper or source set is not public. The
sources/ directory is ignored by Git, but an ignore rule is not a substitute
for checking what your agent, sync service, and plugins can access.
1. Write the brief yourself
Fill in brief.md before asking a model to draft anything. State the research
question, audience or venue, thesis, permitted sources, citation style,
deadline, institutional AI-use rules, exclusions, and claims that require
specialist review.
If those decisions are missing, fluent prose only hides the ambiguity.
2. Make the source ledger the control surface
Create one row for every material claim:
| ID | Claim | Citekey | Page/section | Status | Notes |
| --- | --- | --- | --- | --- | --- |
| C-001 | ... | ... | ... | UNVERIFIED | ... |
The author—not the agent—changes UNVERIFIED to VERIFIED after opening the
source and checking the cited passage. An abstract, metadata record, search
snippet, or model summary is not source verification.
3. Hand the ledger and outline to the drafting agent
Ask Claude Code to inventory only the permitted source files, build the ledger,
and draft the argument in outline.md before editing prose. Require ledger IDs
beside material claims. Unsupported claims stay visible as questions; they do
not get smoothed into confident paragraphs.
The starter AGENTS.md also tells the agent not to browse, download, upload,
publish, or contact anyone unless the author explicitly authorizes it.
4. Keep the build evidence
Draft manuscript.tex and library.bib from the checked outline. Run:
./verify.sh
The script checks that the required artifacts exist and builds the manuscript
when latexmk is available. Before review, run:
./verify.sh --final
The final check rejects remaining TODO, UNVERIFIED, and UNRESOLVED
markers. Do not weaken the check to make a run green.
5. Use a different model as a critic
Give Codex the brief, source ledger, manuscript diff, bibliography, and build
output. Ask it to record unsupported claims, broken references, logical gaps,
and reproducibility failures in review-findings.md.
This is a critique, not independent fact verification. Two model families can
repeat the same error. The author still opens every cited source and resolves
each material finding.
Definition of done
The paper is ready for author review when:
- the manuscript compiles;
- bibliography links and build warnings have been reviewed;
- no material claim remains unverified;
- the review log shows each finding and resolution; and
- the author has confirmed the venue's authorship and AI-use rules.
Open-source substitutions
LaTeX and the recipe itself are open source. If proprietary tools are a bad fit,
test Zettlr or Logseq for Markdown notes and Aider or OpenHands for repository
work. Treat these as substitutions to verify, not drop-in compatibility claims;
the same fixture and final checks should be rerun after changing a tool.
If you try the recipe, report the first confusing or broken step in the
starter repository.
Failures are the useful part of this stage.
