Projects · Tooling
Working with Claude Code
I graduated with a BSc, and most of my time goes to research and writing. Claude Code is a command-line coding assistant and one of the tools I use for that work. Here I explain how I run it.
Where it fits
The prose engine takes my economic argument kernels and raw answers and renders them into public prose. I review the revised text for my voice and meaning, then decide what to publish.
How I run it
I write specifications and track the work against them. From there, I assign tasks such as mapping files or writing code, with separate checks of the results.
Each repository has written rules and assigned roles. The surveyor reads files and the implementer writes code, which the verifier checks. A design critic reviews the visual work, while a security reviewer looks for risks. Hooks give reminders at selected points, and consequential changes need my approval. These tests and reviews give limited evidence of quality and security. They can't guarantee either.
Different tasks get different-sized Claude models. I use bigger models for harder assignments, including planning and review, while smaller models handle reading and listing files.
Reusable skills
By a skill, I mean a written workflow for a recurring task. I focus on how the task should be done, independently of which agent gets the assignment.
Each agent gets a limited assignment, such as reading, writing, or verifying. Its responsibility is to complete that task. It isn't responsible for the correctness of the whole artifact.
A hook runs when a specified event happens during a session or tool use. Depending on the hook, it can block an action or prompt a review.
When the work needs a plan, I use plan-pack to put the strategy and specifications into writing and set up a tracker. For analysis checks, I use analysis-audit to check the data and trace claims back to scripts. It looks for problems such as errors being silently ignored, incorrect joins or sample leakage. Those checks don't establish that the results are valid.
Plan items have two routes. Automatic items start once their prerequisites are met, with technical steps reviewed separately. Items marked for me wait for a decision about direction, scope or money. So work that is ready can continue without waiting for my input on every step.
Between sessions
Each project has a tracker file recording where the work stands and what comes next. I rewrite that state at every stop, so the next session can read it and continue where I left off. Git commits are automatic, and I keep memory records of decisions and corrections. Scheduled checks also compare the trackers with the actual files. I review any mismatches they flag.
In the research
I keep track of my notes, sources, data, and code together with my writing so others can follow the economic analysis. I use reproducible pipelines in R and Python, with researcher and reviewer roles checking claims independently. When those checks disagree, I resolve the discrepancies as I go.
The researcher role gathers sources and checks them. I then use a tribune to compare independent judgments and challenge claims, before I reconcile the evidence.
I have published the mechanical checks from this setup as research-kit, an open-source tool under MIT license, allowing quote and citation checks against source pages.
Adversarial review
I also use a tribunal to review research designs. The reviewers take different perspectives and argue with each other through a shared transcript until the objections repeat. I read their report. In a recent review of my negative-income-tax paper, they concluded that the design needed fixing before I analyzed the data. I used the main objections to improve the design.
Still a tool
I change the setup constantly, so none of these rules are fixed. Some have gotten in the way more than they've helped, which is why I've loosened them. I treat the setup as a tool, since the research is what matters to me.