Develops formal game-theoretic and political-economy models for this project's manuscript (paper/paper.typ). TRIGGER this skill whenever the user does ANY of the following: write a formal model, draft a game-theoretic setup, define players and strategies, write assumptions, derive equilibrium, state a proposition, write a proof, check mathematical logic, verify a derivation, debug an equation, add or revise a theory section, formalize an argument, translate an intuition into a model, write comparative statics, check consistency of notation, or anything that touches formal theory, propositions, lemmas, proofs, or mathematical reasoning in the paper. Also trigger when the user says "formalize this", "write the model", "check the math", "is this proof correct", "derive the equilibrium", "add assumptions", or "what are the comparative statics". If the task involves formal modeling, game theory, proofs, or mathematical derivations in any way, this skill applies
Build models that illuminate mechanisms. Every assumption earns its place; every proposition has a proof.
All modeling rules derive from three principles: clarity, rigor, and parsimony. Internalize the reasoning behind each.
A model exists to sharpen an argument, not to display technical facility. The reader should understand the economic intuition behind every assumption, every equilibrium, and every comparative static without needing to work through the algebra. If the math is correct but the intuition is opaque, the model has failed.
Why this matters: This paper is a political science manuscript aimed at a general audience of comparativists and Americanists, not a theory journal. The formal theory section must be accessible to readers who are comfortable with game trees and equilibrium concepts but do not regularly write proofs. Dense notation without verbal guidance will cause reviewers to skip the section entirely.
Every proposition must have a valid proof. Every proof must follow from the stated assumptions---no hidden steps, no hand-waving, no "it is straightforward to show." If a step is genuinely obvious, it takes one line to write; if it is not obvious, it takes longer, and that is fine.
Why this matters: A formal model with an incorrect proof is worse than no model at all. It signals either sloppiness or that the author does not fully understand the mechanism. Reviewers who catch an error in a proof will distrust the entire paper.
Include only the moving parts necessary to generate the result. If an assumption can be dropped without changing the equilibrium characterization, drop it. If a player can be removed without losing the mechanism, remove them. The model should be the simplest structure that produces the key comparative static---the insight that economic distress combined with strong party gatekeeping increases backsliding risk through the extraparliamentary channel.
Why this matters: Overbuilt models obscure the mechanism. Reviewers ask "which of these 12 assumptions is doing the work?" and if you cannot answer cleanly, the model is too complex. The goal is a clean, portable result that other scholars can cite and extend.
Before writing any model, read the paper's introduction, empirical strategy, and existing theory discussion in paper/paper.typ. The model must formalize the argument the paper already makes---it should not introduce mechanisms that the empirics cannot speak to. Also read the relevant literature notes in library/lit/ to understand the theoretical positioning.
Define the model in this order:
State each element as a formal assumption. Number assumptions sequentially (Assumption 1, Assumption 2, ...).
Work backward from the last mover (backward induction / subgame perfection) or apply the appropriate equilibrium concept. For each step:
Document every algebraic step. Do not skip intermediate steps even if they seem routine---write them out, then decide in the editing phase whether to relegate some to an appendix.
Proposition format:
Every proposition must:
Proof format:
Every proof must:
Typst conventions for this paper:
#prop[Title][Statement]#proof[Content]#lem[Title][Statement]#rem[Title][Content]#asp[Title][Statement]#nneq($ ... $) for numbered display equations$...$After characterizing equilibrium, derive how the equilibrium changes with respect to key parameters. For each comparative static:
The key comparative static for this paper should be: how does backsliding risk (probability of extraparliamentary action) change as (a) economic distress increases, (b) party gatekeeping capacity increases, and (c) both increase simultaneously.
Before finalizing, run this checklist on every proposition and proof:
Logical consistency:
Algebraic correctness:
Internal consistency:
paper/paper.typ?Common errors to watch for:
After the model is complete, write a short subsection mapping model predictions to empirical tests:
This mapping is what makes the model worth including in the paper rather than being a standalone theory exercise.
Read paper/paper.typ (especially the introduction and theory sections) to understand the paper's core argument before building any formal model. The model should capture:
Derive this context from the manuscript, not from assumptions.
.claude/scripts/zotero_add.py for missing references. Never edit ref.bib directly.Load references/notation-standards.md when writing or editing any formal content. Consistency in notation across the model, the empirical sections, and the appendix is non-negotiable.
Overbuilding --- If you need more than 3-4 players or more than 2 stages to generate the result, the model is probably too complex. Strip it back and check whether a simpler structure delivers the same insight.
Missing intuition --- Every proposition needs a paragraph (before or after the proof) explaining in plain language why the result holds. "The proof is the intuition" is almost never true for a political science audience.
Notation drift --- The same quantity must have the same symbol everywhere. If organizational density is $D$ in the theory section, it cannot be "OrgDensity" in the empirical section without an explicit mapping.
Proof by intimidation --- Packing a proof with unnecessary generality or abstraction to make it look more impressive. This backfires with reviewers. State the result at the level of generality needed and no more.
Unverified claims --- Never write "it can be shown that" or "it is easy to verify." Either show it or put it in the appendix. If it truly is trivial, showing it takes one line.