Theorist Toolbox

Shared tooling for doing economic theory with LLMs — prove results, check them, and run a proof-building project like a research team, without letting the model hand-wave.

If you use this toolbox, please cite: Moran Koren (2026), Theorist Toolbox: Tools for Agent-Based LLM-Assisted Economic Theory Research, arXiv:2606.22337 — https://arxiv.org/abs/2606.22337.

@article{koren2026theorist,
  title         = {Theorist Toolbox: Tools for Agent-Based LLM-Assisted Economic Theory Research},
  author        = {Koren, Moran},
  year          = {2026},
  eprint        = {2606.22337},
  archivePrefix = {arXiv},
  url           = {https://arxiv.org/abs/2606.22337}
}

A small set of Claude Code skills for doing economic theory with LLMs — proving results, checking them, and running a whole proof-building project the way you'd run a research team.

Empirical economists have had shared tooling for years. The empiricist learns the craft from reusable, opinionated tools. Theorists rarely really got that. This is an attempt at the theory-side equivalent: a toolkit that encodes how to push an LLM through a proof without letting it hand-wave.

The three skills are three different bets on the same problem — how do you get machine help on a theorem you don't already know how to prove, and trust the answer?

The skills

Each is a different point on a trade-off between speed, verification, and coverage: the single pass is fastest and cleanest but unchecked; the adversarial pair is the most reliable per claim; the structured team gives the broadest, most disciplined coverage and can reject its own work; proof-readability runs after any of them to make an accepted proof legible.

The co-math agents (agents/)

The co-math-init project is run by a small team of Claude Code sub-agents, shipped in agents/:

📐 Diagrams: see docs/co-math-architecture.md for the agent topology, the workstream lifecycle, and the verification ladder (informal proof → Lean-verified → readable).

The case study (examples/)

I built these while testing all three on one problem: turning the eigengrade of Gans & Kominers (2026, "What Does a Grade Mean?", NBER w35183) into a VCG-style mechanism against grade inflation. Each skill produced a self-contained writeup:

• 1-math-proover_… — a student-side enrollment VCG (single pass, math-proof).
• 2-codex-proover_… — an instructor-side Pigouvian/Groves transfer, adversarially verified with Codex + Monte Carlo (codex-math).
• 3-co-math_… — a money-free, report-space mechanism suite with an impossibility theorem and a numerically validated running example (co-math).

Two of the three independently rediscovered the same externality kernel; the third's reviewer gate killed one of its own sub-goals. The write-up of that comparison lives in the accompanying Substack post.

Install

These are Claude Code skills and agents. Drop the skills into your skills directory, and — for the co-math workflow — the agents into your agents directory:

cp -R skills/* ~/.claude/skills/
cp -R agents/* ~/.claude/agents/   # only needed for the co-math project workflow

Then invoke them from Claude Code (/math-proof, /co-math-init, …) or let the model pick them up by description.

Notes

• codex-math documents the interface to a set of companion runner scripts (codex_verify.sh, codex_write.sh, codex_explore.sh) that wrap the OpenAI Codex CLI. Those live alongside your project (code/utils/codex_math/) and call codex exec; you'll need the Codex CLI installed and authenticated. The skill is the playbook for using it well.
• co-math-init writes per-project hooks that reference ~/.claude/co-math/hooks/ (a paper_tex_guard.py and a workstream_complete_guard.py that enforce strict mode). Provide your own, or run with the guards disabled — the skill works either way; the hooks are the teeth.
• lean-prover needs a working Lean 4 toolchain (lean and lake on PATH); it pins the toolchain per workstream and builds against mathlib. Without it the agent blocks the workstream cleanly rather than faking a proof. Every other agent runs with no extra tooling.

Contributing

Issues and PRs welcome — bug reports, new skills, a sharper proof discipline, or fixes to the ones here. No CLA and no ceremony.

The toolbox grows the Linux way: a small core, plus self-contained modules (skills, agents, case studies). You don't need the whole tree — just the contract for the kind of module you're adding:

• CONTRIBUTING.md — the module contract: where a skill/agent lives, its frontmatter, and the no-hand-waving bar your PR is reviewed against.
• ROADMAP.md — where it's headed and which modules are most wanted next.
• Discussions — questions, prompt-sharing, ideas (lower-stakes than issues).
• CODE_OF_CONDUCT.md — be rigorous about ideas, kind to people.

New here? Try a good first issue or weigh in on the pinned roadmap RFC.

Author

Moran Koren, Ben-Gurion University of the Negev — [email protected]. If you use the toolbox in research, a mention is appreciated.

License

MIT. See LICENSE. Use them, fork them, tell me what broke.