---
name: casebook
description: Use when working in any project that contains a .casebook/ directory — keeps the kanban board honest against real commits and accretes an evidence-backed case study with human-voice slots. Also use when the user mentions Casebook, their board, or their case study.
---

# The Casebook Method

Casebook turns a working session into two artifacts at once: an honest kanban
board and a slowly accreting case study. Your job is to keep both grounded in
evidence — commits, board history, decisions actually made — and never to
fabricate.

The tracker CLI lives at "$CLAUDE_PLUGIN_ROOT/scripts/tracker". State lives at
`<git-root>/.casebook/state.json`; the case study at
`.casebook/case-study.md`.

## Board honesty rules

1. **Never invent work.** Only record what was actually committed, discussed,
   or decided.
2. **Done requires evidence.** A card moved to done gets its commit hashes
   linked (`tracker link <id> <hash>` or `--commits` on add).
3. **Blocked names its blocker.** Notes on a blocked card say specifically
   what is being waited on — a person, a dependency, a decision.
4. **Update, don't duplicate.** Prefer move / link / note --append on an
   existing card over adding a new one.
5. **Titles under 12 words; notes name specifics** — files, blockers,
   decisions. Not vague summaries.
6. **No churn.** A card that's already correct gets left alone.

## Session rhythm

- Open with `/casebook:check-work` — read-only board read, mismatch flags,
  proposed next move.
- During work, if scope shifts (something new starts, finishes, or blocks),
  update the board right then via the CLI rather than waiting for close-out.
- Close with `/casebook:end-work` — evidence-backed batch sync, then
  case-study accretion.
- `/casebook:view` any time to see where the case study stands, and
  `/casebook:export` for a dated PDF/HTML snapshot.
- `tracker prompt --copy` generates a kickoff prompt carrying full board
  context into a fresh session.

## Case-study accretion

The case study (`.casebook/case-study.md`) has narrative sections on top and
a **Running Log** at the bottom. The log is the raw feed; the sections are
the story.

- **Running Log entries** are dated, factual, and cite commit hashes. Append
  newest last. Draft them at session close (end-work step 6) or whenever the
  user asks.
- **Consolidation:** when the log exceeds ~10 entries since the last
  consolidation, offer to fold older entries into "Process" as phases, and
  distribute durable material into "Key Decisions", "Outcomes", "Reflections".
  Keep the consolidated log entries (mark them consolidated) or remove them
  if the user prefers — ask once, remember the preference in the doc.
- **The "› My take:" convention is inviolable.** Facts from evidence are
  written as prose. Anything subjective — how it felt, why it mattered
  personally, what they'd do differently — is left as a marked
  `**› My take:**` prompt for the human. Never ghost-write opinions, even if
  asked to "just fill it in"; instead offer questions that help them write it.
- **User-supplied words may fill "› My take:"; Claude-authored words never
  may.** The user's own account of a session — their words, their phrasing —
  is first-class evidence, not a paraphrase target. The end-work session-notes
  prompt (step 3) is where most "› My take:" material should come from: ask,
  then quote or lightly edit what they actually said into the slot. Anything
  Claude composes on its own stays out of that slot, no matter how well it
  guesses their opinion.

## Tone

Case-study prose is plain, specific, and verifiable — the reader should be
able to trace every claim to a commit or a board event. No superlatives the
evidence doesn't support.