flonat-research 0.1.0

package/skills/pre-submission-report/SKILL.md

@@ -0,0 +1,153 @@
+---
+name: pre-submission-report
+description: "Use when you need all quality checks run before submission, producing a single dated report."
+allowed-tools: Bash(latexmk*, mkdir*, ls*, wc*), Read, Write, Edit, Glob, Grep, Task, Skill
+argument-hint: "[path/to/main.tex or no arguments to auto-detect]"
+---
+
+# Pre-Submission Report
+
+> Aggregates all quality checks into one dated report. Run before submitting to a journal/conference or sharing with collaborators.
+
+## When to Use
+
+- Before submitting a paper to a venue
+- Before sharing a draft with supervisors or co-authors
+- When the user says "pre-submission check", "is this ready?", "run everything"
+
+## Input
+
+- A `.tex` file path, or auto-detect `paper/main.tex` in the current project
+
+## Critical Rule
+
+**Python:** Always use `uv run python` or `uv pip install`. Never bare `python`, `python3`, `pip`, or `pip3`. Include this in any sub-agent prompts.
+
+## Steps
+
+### 1. Locate the Paper
+
+If no argument provided, search for the main `.tex` file:
+1. Check `paper/main.tex`
+2. Check `paper/*.tex` for a file containing `\begin{document}`
+3. Ask the user if ambiguous
+
+### 2. Integrity Gate (hard gate — must pass before quality checks)
+
+Run these checks first. If any fail, stop and report — do not proceed to quality checks.
+
+1. **Placeholder scan** — grep the `.tex` file(s) for `TODO`, `FIXME`, `XXX`, `TBD`, `[INSERT`, `PLACEHOLDER`, `Lorem ipsum`. Any match is a FAIL.
+2. **Citation integrity** — invoke `/bib-validate` in verify mode. Every `\cite{}` key must resolve to a `.bib` entry. Any missing key is a FAIL.
+3. **Section completeness** — check that all standard sections exist and are non-empty (Abstract, Introduction, and at least one body section before Conclusion/References). An empty or missing section is a FAIL.
+4. **Broken references** — grep for `??` in the compiled PDF output or `.log` file (undefined `\ref{}` or `\cite{}`). Any `??` in output is a FAIL.
+
+**If any check fails:**
+```
+INTEGRITY GATE: FAIL
+
+Blockers (must fix before quality checks):
+  - [ ] 3 TODO placeholders found (lines 47, 112, 289)
+  - [ ] 2 undefined references (\ref{fig:missing}, \cite{nonexistent2024})
+  - [ ] Abstract section is empty
+
+Fix these and re-run /pre-submission-report.
+```
+
+**If all pass:** proceed to Step 3.
+
+### 3. Run Quality Checks
+
+Run these sequentially (each depends on a clean state):
+
+1. **Compilation** — invoke `/latex-autofix` on the main `.tex` file. Record pass/fail and any remaining warnings.
+2. **Citation audit** — invoke `/bib-validate` (full mode — deep verify). Record missing, unused, and suspect keys.
+3. **Adversarial review** — launch `paper-critic` agent (via Task tool). Capture the CRITIC-REPORT.md score and findings.
+
+### 4. Aggregate Report
+
+Save to `audits/quality-reports/YYYY-MM-DD_<project-name>.md`:
+
+```markdown
+# Pre-Submission Quality Report
+
+**Project:** <project name>
+**Date:** YYYY-MM-DD
+**File:** <path to main.tex>
+**Target:** <venue from project CLAUDE.md, or "not specified">
+
+---
+
+## Integrity Gate: PASS / FAIL
+
+- **Placeholders:** 0 found
+- **Citation integrity:** all keys resolved
+- **Section completeness:** all sections present
+- **Broken references:** none
+
+---
+
+## Overall Score: XX/100 — [Verdict]
+
+Verdict uses the quality scoring framework:
+- 90-100: Publication-ready
+- 80-89: Minor revisions needed
+- 70-79: Significant revisions needed
+- Below 70: Not ready
+
+---
+
+## Compilation
+
+- **Status:** PASS / FAIL
+- **Warnings:** <count>
+- **Details:** <brief summary of any issues>
+
+## Citations
+
+- **Missing keys:** <count> — <list>
+- **Unused keys:** <count> — <list>
+- **Suspect entries:** <count> — <list>
+
+## Adversarial Review
+
+- **Score:** XX/100
+- **Key findings:**
+  - <finding 1>
+  - <finding 2>
+  - ...
+
+## Research Quality Score
+
+Load `skills/shared/research-quality-rubric.md` and report the weighted aggregate (X.X / 5.0) with verdict.
+
+## Remaining Issues
+
+| # | Severity | Category | Issue |
+|---|----------|----------|-------|
+| 1 | High/Medium/Low | Compilation/Citation/Content | <description> |
+
+## Recommendation
+
+**[Submit / Revise / Not ready]**
+
+<1-2 sentence summary of what needs to happen before submission>
+```
+
+### 5. Present Summary
+
+Display the report path and the summary table to the user. If the recommendation is "Submit", congratulate. If "Revise", list the top 3 issues to fix first.
+
+## Error Handling
+
+- If compilation fails after `/latex-autofix`, still run the remaining checks. Mark compilation as FAIL in the report.
+- If `paper-critic` agent fails, note it in the report and base the overall score on compilation + citations only.
+- Always produce the report file, even if some checks failed.
+
+## Integration
+
+| Skill/Agent | Role in this workflow |
+|-------------|---------------------|
+| `/latex-autofix` | Compilation + auto-fix |
+| `/bib-validate` | Citation cross-reference |
+| `paper-critic` agent | Adversarial content review |
+| `quality-scoring.md` | Verdict thresholds |

package/skills/process-reviews/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: process-reviews
+description: "Use when you need to process referee comments from a reviews PDF into tracking files."
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir*), Bash(cp*), Bash(ls*), Bash(latexmk*), AskUserQuestion, Task
+argument-hint: "[path-to-reviews-pdf or no arguments for guided setup]"
+---
+
+# Process Referee Comments
+
+Read a reviews PDF and generate three standardised output files for managing an R&R response.
+
+## When to Use
+
+- Received reviewer reports for a paper (journal or conference)
+- Starting an R&R cycle and need to set up tracking infrastructure
+- Want to standardise an existing ad-hoc review response
+
+## When NOT to Use
+
+- Writing the actual response letter (use the generated `comment-tracker.md` response blocks as a starting point, then write the letter manually)
+- Reviewing someone else's paper (use `/proofread` or the `peer-reviewer` agent)
+
+## Inputs
+
+Gather via interview if not provided:
+
+1. **Reviews PDF path** — auto-discovered or user-provided (see below)
+2. **Project path** — root of the research project (auto-detect from cwd if possible)
+3. **Venue slug** — short identifier, e.g., `ejor`, `facct-2026`, `management-science`
+4. **Revision round** — integer, default 1
+5. **Response deadline** — date if known, otherwise "TBD"
+6. **Coordinating author** — who is leading the response
+
+### PDF Auto-Discovery
+
+Search for the reviews PDF in this order. Use the first match; if multiple PDFs found at a location, list them and ask the user to pick.
+
+1. `to-sort/*.pdf` — most likely landing spot after download
+2. `correspondence/referee-reviews/{venue}-round{n}/*.pdf`
+3. `correspondence/referee-reviews/*.pdf`
+4. Ask the user for the path if nothing found
+
+## Output Location
+
+Review correspondence goes under `correspondence/referee-reviews/`, with an `analysis/` subfolder for derived work:
+
+```
+correspondence/referee-reviews/{venue}-round{n}/
+├── reviews-original.pdf              (copy of input PDF — source is NEVER moved/deleted)
+├── rebuttal.md                       (empty — for response draft)
+├── reviews/                          (individual reviewer files)
+│   ├── reviewer-1.md
+│   ├── reviewer-2.md
+│   └── ...
+└── analysis/
+    ├── comment-tracker.md            (atomic comment matrix)
+    ├── review-analysis.md            (strategic overview)
+    └── reviewer-comments-verbatim.tex (LaTeX transcription)
+```
+
+**Source PDF preservation:** The original reviews PDF is only ever **copied** to `reviews-original.pdf`. Never move, rename, or delete the source file from its original location (e.g., `to-sort/`, Downloads, etc.). The user decides when to clean up the original.
+
+**Principle:** `correspondence/` holds exchanges with reviewers (their comments, your rebuttal). Internal review work (e.g., referee2 agent reports) goes in `docs/{venue}/internal-reviews/`.
+
+If the round directory already exists (e.g., from manual setup), do NOT overwrite existing files. Instead:
+- If `comment-tracker.md` already exists, name the new one `comment-tracker-v2.md` (or next version)
+- If `reviewer-comments-verbatim.tex` already exists, name the new one `reviewer-comments-verbatim-v2.tex`
+- Always flag existing files to the user before writing
+
+## Protocol
+
+### Phase 1: Setup
+
+1. Confirm inputs (PDF path, project path, venue, round, deadline, lead author)
+2. Create the directory structure under `correspondence/referee-reviews/{venue}-round{n}/`
+3. Copy the reviews PDF to `correspondence/referee-reviews/{venue}-round{n}/reviews-original.pdf`
+
+### Phase 2: Read the Reviews
+
+1. Read the reviews PDF using the Read tool (supports PDF natively)
+2. For large PDFs (>10 pages), read in page ranges (e.g., pages 1-10, then 11-20)
+3. Extract for each reviewer:
+   - Reviewer identifier (name, number, or anonymous ID)
+   - Recommendation / score (if provided)
+   - Whether revision is allowed
+   - General assessment text
+   - Individual comments (each as a separate item)
+
+### Phase 3: Generate Individual Review Markdown Files
+
+Create one markdown file per reviewer in `reviews/`:
+
+1. Create the `reviews/` subdirectory
+2. For each reviewer, write `reviews/reviewer-{n}.md` containing:
+   - **Header:** reviewer identifier, recommendation/score, whether revision is allowed
+   - **General Assessment:** full verbatim text of the reviewer's overall assessment
+   - **Individual Comments:** each comment as a numbered item with its assigned ID (`R{n}-C{m}`), verbatim text, and section/page reference if mentioned
+3. Use this template for each file:
+
+```markdown
+# Reviewer {N}
+
+**Recommendation:** {recommendation or score}
+**Revision allowed:** {Yes / No / Not stated}
+
+## General Assessment
+
+{verbatim general assessment text}
+
+## Comments
+
+### R{N}-C1 {optional: section/page reference}
+
+{verbatim comment text}
+
+### R{N}-C2 ...
+
+{verbatim comment text}
+```
+
+4. If files already exist in `reviews/`, follow the same versioning convention as other outputs (flag and version)
+
+### Phase 4: Generate LaTeX Verbatim Transcription
+
+Using the template from `templates/referee-comments/reviewer-comments-verbatim.tex`:
+
+1. Create one `\section{}` per reviewer with comment count and recommendation
+2. Place general assessment in a `genbox` environment
+3. For each specific comment:
+   - Assign an ID: `R{reviewer}-C{comment}` (sequential within each reviewer)
+   - Identify the section/page reference if the reviewer mentions one
+   - Place the full verbatim text in the comment table
+4. If a single reviewer paragraph contains multiple distinct concerns, split into separate IDs and add a `\textit{\footnotesize Split: ...}` note
+5. If any IDs are derived (split from a larger comment or inferred), add them to a Derived IDs appendix section
+6. Compile with `latexmk` to verify it builds cleanly
+
+### Phase 5: Generate Comment Tracker
+
+Using the template from `templates/referee-comments/comment-tracker.md`:
+
+1. Fill in the Triage Summary table
+2. Populate the Comment Matrix — one row per atomic comment:
+   - **ID:** matching the LaTeX verbatim IDs
+   - **Reviewer:** reviewer number
+   - **Comment:** short verbatim quote (first ~100 chars in quotes)
+   - **Type:** classify as Major / Minor / Editorial / Question / Praise
+   - **R&R Classification:** classify as NEW ANALYSIS / CLARIFICATION / DISAGREE / MINOR (see `references/rr-routing.md` for decision rules and signal words)
+   - **Priority:** assign Critical / High / Medium / Low based on:
+     - Critical = threatens acceptance if not addressed
+     - High = significant concern, must address
+     - Medium = reasonable concern, should address
+     - Low = minor or editorial
+   - **Action:** leave blank (for the user to fill)
+   - **Owner:** leave blank
+   - **Status:** set all to "Pending"
+   - **Section:** paper section referenced, if identifiable
+3. Fill in the Status Dashboard counts
+4. Generate a **Routing Summary** table grouping comments by R&R classification:
+   - NEW ANALYSIS: list IDs + brief description of required analysis
+   - CLARIFICATION: list IDs + target sections needing revision
+   - DISAGREE: list IDs + flag for user review
+   - MINOR: list IDs
+5. Identify **Cross-Cutting Themes** — concerns raised by 2+ reviewers, tagged T1, T2, etc.
+6. Leave Evidence Log, Patch Plan, Response Blocks, and Blockers empty (user fills during revision)
+
+### Phase 6: Generate Review Analysis
+
+Using the template from `templates/referee-comments/review-analysis.md`:
+
+1. Fill in Scores & Recommendations table
+2. Write a Reviewer Profile for each reviewer:
+   - **Posture:** hostile / sceptical / constructive / supportive (infer from tone)
+   - **What they liked:** bullet points
+   - **What they want revised:** numbered list
+   - **Assessment:** paragraph on how addressable their concerns are
+   - **Risk:** None / Low / Medium / High with explanation
+3. Identify Cross-Cutting Themes — concerns that appear across 2+ reviewers, tagged T1, T2, etc.
+4. Estimate Acceptance Probability with factors for/against
+5. Bucket comments into Priority 1/2/3 response categories
+6. List Vulnerabilities (weaknesses in the paper that reviewers exposed)
+7. Populate the Publication Strategy section:
+   - **Strategy A (minimal revision):** venues that would accept the paper's strengths as-is, despite the weaknesses reviewers identified. Look for venues that value the descriptive/empirical contribution without demanding the specific improvements the current reviewers want.
+   - **Strategy B (substantial revision):** venues worth targeting if the authors invest effort to address the major reviewer concerns. These should be equal or higher prestige than the current venue.
+   - For conferences: check CORE rankings via `.context/resources/venue-rankings.md` (and the CSV at `.context/resources/venue-rankings/core_2026.csv`). Note upcoming deadlines.
+   - For journals: check CABS AJG rankings via `.context/resources/venue-rankings.md` (and the CSV at `.context/resources/venue-rankings/abs_ajg_2024.csv`). For SJR score, query the Elsevier Serial Title API (see venue-rankings.md for snippet; requires `SCOPUS_API_KEY`). Flag journals below CABS 3 only if there's a strong fit rationale.
+   - **Recommendation table:** rank 3-5 venues in priority order with rationale. First option should always be "revise for current venue" if acceptance probability is above ~30%.
+   - **Key Decision:** frame the core trade-off the authors face (e.g., speed vs. impact, minimal vs. substantial revision effort).
+   - Consider the paper's discipline and methodology when suggesting venues — a qualitative policy analysis fits different outlets than a computational study.
+8. Leave Timeline empty (user fills)
+
+### Phase 6.5: Strategic Coaching (Interactive)
+
+For each **Major** or **Critical** comment, walk the user through a structured deliberation:
+
+1. **Understanding:** "What is this reviewer's core concern — methodology, theory, or framing?"
+2. **Position:** Classify as one of:
+   - **Agree** — will revise as suggested
+   - **Partially agree** — will address the spirit but not the exact suggestion. State which parts you accept and which you push back on.
+   - **Disagree** — will rebut with evidence. Draft the core rebuttal argument.
+3. **Risk assessment:** "If you push back on this, how likely is the reviewer to escalate? Is it worth the risk?"
+4. **Response sketch:** One-sentence draft of the response direction (not the full response — just the strategy).
+
+Record these in the Comment Matrix by adding two columns after `R&R Classification`:
+- **Position:** Agree / Partially / Disagree
+- **Strategy:** one-line response direction
+
+**Rules:**
+- Only Major and Critical comments get coaching. Minor/Editorial are auto-classified as "Agree" with no coaching.
+- the user can say "skip coaching" to bypass and classify all remaining as Agree.
+- Maximum 2 rounds of dialogue per comment — do not over-discuss.
+- Do not write the actual response letter — that remains the user's job.
+
+### Phase 7: Summary & Review
+
+Present to the user:
+- Total comments extracted (by reviewer)
+- Breakdown by type and priority
+- Key cross-cutting themes
+- Position summary: N Agree / N Partially / N Disagree
+- Any comments that were ambiguous or hard to classify
+- Ask for corrections before finalising
+
+## Critical Rules
+
+1. **Verbatim means verbatim.** Never paraphrase reviewer text in the LaTeX transcription. Copy exactly.
+2. **Every comment gets an ID.** No reviewer concern should be lost. If in doubt, give it its own ID.
+3. **Don't write actions.** The Comment Matrix `Action` column stays blank — that's the user's job.
+4. **Don't overwrite.** If files already exist at the target location, flag and version.
+5. **Compile the LaTeX.** The verbatim document must build without errors before the skill completes.
+
+## Templates
+
+Located in `templates/referee-comments/`:
+- `comment-tracker.md`
+- `review-analysis.md`
+- `reviewer-comments-verbatim.tex`
+
+## Cross-References
+
+- `/proofread` — for proofreading the response letter before submission
+- `/bib-validate` — run after revision to check bibliography
+- `/pre-submission-report` — full quality check before resubmission
+- `paper-critic` agent — for self-review of the revised paper
+- `references/rr-routing.md` — R&R classification system and routing logic for revision workflow

package/skills/process-reviews/references/rr-routing.md

@@ -0,0 +1,101 @@
+# R&R Comment Classification and Routing
+
+> Used during Phase 5 (Comment Tracker) to classify referee comments for efficient revision routing.
+> Adapted from Sant'Anna's clo-author revision protocol.
+
+## Classification System
+
+Every atomic referee comment is classified into one of four categories:
+
+| Classification | Definition | Signal Words | Routing |
+|---------------|------------|-------------|---------|
+| **NEW ANALYSIS** | Requires new estimation, data work, or robustness checks | "run", "test", "control for", "check", "estimate", "add specification", "heterogeneity" | Code changes → table/figure updates → paper text |
+| **CLARIFICATION** | Text revision sufficient — no new analysis needed | "explain", "clarify", "discuss", "motivate", "justify", "elaborate", "rewrite" | Paper text only |
+| **DISAGREE** | The reviewer asks for something the authors believe is wrong or infeasible | "fundamentally", "reject the premise", contradicts identification strategy | Flag for user — never auto-respond to disagreements |
+| **MINOR** | Typos, formatting, citation fixes, wording tweaks | "typo", "citation", "footnote", "spelling", "format" | Quick paper edits |
+
+## Classification Rules
+
+1. **When in doubt between NEW ANALYSIS and CLARIFICATION:** If the reviewer's concern *could* be addressed with better writing but would be *stronger* with additional evidence, classify as NEW ANALYSIS. Referees notice when you only clarify instead of substantiate.
+
+2. **DISAGREE is rare.** Most referee comments that feel wrong are actually CLARIFICATION requests — the reviewer misunderstood, and better exposition fixes it. Only classify as DISAGREE when:
+   - The reviewer asks for an analysis that would violate the identification strategy
+   - The reviewer's suggestion contradicts established methodology (e.g., "use naive TWFE for staggered treatment")
+   - The reviewer wants you to change the research question
+   - The request is infeasible given data limitations
+
+3. **Split compound comments.** A single referee paragraph may contain both a CLARIFICATION and a NEW ANALYSIS request. Split into separate IDs with cross-references.
+
+4. **Always classify praise.** Even positive comments should be logged (Type: Praise, Priority: Low) to reference in the response letter: "We thank the reviewer for noting..."
+
+## Priority Assignment
+
+| Priority | Definition | Classification Overlap |
+|----------|-----------|----------------------|
+| **Critical** | Threatens acceptance if not addressed | Usually NEW ANALYSIS or DISAGREE |
+| **High** | Significant concern, must address thoroughly | NEW ANALYSIS or CLARIFICATION |
+| **Medium** | Reasonable concern, should address | CLARIFICATION |
+| **Low** | Minor or editorial | MINOR or Praise |
+
+### Priority Heuristics
+
+- **Multiple reviewers raise the same concern** → bump to Critical
+- **Reviewer uses words like "fatal", "fundamental", "serious"** → Critical
+- **Concern about identification/causality** → at least High
+- **"Interesting but..."** → the "but" is the real concern, classify that
+- **Editor's letter highlights specific comments** → those are Critical regardless
+
+## Routing in the Response
+
+### NEW ANALYSIS workflow
+1. Identify the required analysis (new regression, robustness check, subsample)
+2. Write the estimation code → generate new table/figure
+3. Update paper text to discuss new results
+4. Reference new results in response letter with specific table/figure number
+
+### CLARIFICATION workflow
+1. Identify the section(s) that need revision
+2. Rewrite to address the concern
+3. Quote the changed passage in the response letter (before/after)
+
+### DISAGREE workflow
+1. **Flag for user** — Claude never autonomously pushes back on referees
+2. Draft a diplomatic response that:
+   - Acknowledges the reviewer's concern
+   - Explains why the current approach is preferred
+   - Offers a compromise if possible (e.g., mention in footnote, add to appendix)
+3. User reviews and approves before including in response
+
+### MINOR workflow
+1. Fix directly in the paper
+2. Brief acknowledgement in response letter: "We have corrected the typo on p.X"
+
+## Response Letter Structure
+
+For each referee comment:
+
+```markdown
+**[R1-C3]** Reviewer 1, Comment 3: "[first ~100 chars of comment]"
+
+**Classification:** NEW ANALYSIS
+**Action taken:** We estimated an additional specification controlling for X.
+The results, reported in Table A3 of the Online Appendix, confirm that our
+main findings are robust. Specifically, the coefficient on treatment changes
+from 0.045 (s.e. 0.012) to 0.042 (s.e. 0.013).
+
+**Changes:** Table A3 (new), Section 5.2 paragraph 3 (revised),
+Appendix B.1 (new subsection)
+```
+
+## Cross-Cutting Themes
+
+When the same concern appears across reviewers, create a theme entry:
+
+```markdown
+**Theme T1:** External validity concerns
+**Raised by:** R1-C5, R2-C2, R3-C8
+**Response strategy:** Address once comprehensively in Section 7 (Discussion),
+then cross-reference from each individual response.
+```
+
+This avoids repetitive responses and shows the authors took the concern seriously.

package/skills/project-deck/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: project-deck
+description: "Use when you need to create a presentation deck to communicate project status."
+allowed-tools: Bash(latexmk*), Bash(xelatex*), Bash(pdflatex*), Bash(mkdir*), Read, Write, Edit
+argument-hint: [project-name-or-path]
+---
+
+# Project Deck Skill
+
+> Create beautiful presentation decks to communicate project status to your future self and collaborators.
+
+## Purpose
+
+Based on Scott Cunningham's Part 7: "Making Beautiful Decks For My Future Self" - using decks not for public speaking but to efficiently communicate work status across time and to coauthors.
+
+## The Philosophy
+
+"I use decks to help me keep track of the work I was doing so that I can communicate it to my coauthors and myself later in the week when we meet to go over our projects."
+
+Claude has absorbed the "rhetoric of decks" - the tacit knowledge about what makes presentations effective:
+- One idea per slide
+- Titles are assertions, not labels
+- Lead with conclusions
+- Visual hierarchy signals importance
+- Repeat for retention
+- Transition explicitly
+
+## When to Use
+
+- Before a supervisor meeting
+- At the end of a research sprint
+- When handing off to a coauthor
+- When returning to a dormant project
+- Weekly project status updates
+
+## Workflow
+
+1. **Read project context** - Progress logs, current focus, recent work
+2. **Design deck structure**:
+   - Research question
+   - What's been done (with figures/tables)
+   - Key findings so far
+   - Current blockers
+   - Next steps
+3. **Create beautiful output** - Clean design, good typography, optimal cognitive density
+4. **Include visuals** - Figures, tables, diagrams that capture the work
+
+## Deck Rhetoric Principles
+
+```markdown
+## Principles for Effective Decks
+
+1. **One idea per slide** - Don't overload
+2. **Titles are assertions** - "Distance increases abortion rates" not "Results"
+3. **Lead with conclusions** - Don't bury the lede
+4. **Visual hierarchy** - Most important things stand out
+5. **Optimal cognitive density** - Smooth delivery, not overloaded
+6. **Beautiful figures and tables** - Data visualisation matters
+7. **Explicit transitions** - Guide the reader through the narrative
+```
+
+## Extended Rhetoric Principles
+
+### For Research Decks
+- **Motivation slides**: Why should anyone care? What's the gap?
+- **Methods slides**: Identification strategy in plain English, visualize variation
+- **Results slides**: Lead with main coefficient, visualize where possible
+- **Figures**: Clear titles, labeled axes, no chartjunk
+
+### For "Decks as Thinking Tools"
+When making decks for yourself/coauthors:
+1. **Document decisions** — Why did we choose this approach?
+2. **Visualize data** — Patterns you've discovered
+3. **Track progress** — What's done, what's next
+4. **Summarize code** — What scripts do what
+5. **Capture context** — So future-you remembers
+
+### Beamer Tips
+- Custom themes > recognizable templates
+- Metropolis or Madrid themes as starting points
+- Sans-serif fonts for readability
+- Generous margins and whitespace
+- Compile without warnings (fix overfull hboxes)
+
+## Example Prompt
+
+"Create a project deck for my Indifference Adjustments paper. Read my progress logs and the current state of the project, then make a 10-slide deck that I can use in my supervisor meeting next week. Include the key figures and a clear 'what's next' section."