Structure a long Claude Code session with TodoWrite instead of losing track of what's left

This task is long enough that tracking it in a TodoWrite list from the start matters more than it would for a quick change — the list is not a status report written after the fact, it is the actual working plan this session follows.

TASK
Migrate all 40 prompt-library category files to the new tier field, verifying each file individually against the updated schema.

HOW GRANULAR EACH TODO ITEM SHOULD BE
One todo item per category file, not one item for the whole migration and not one item per individual prompt entry.

WHAT COUNTS AS VERIFIABLE EVIDENCE AN ITEM IS ACTUALLY DONE
A category file counts as done only once tsc --noEmit passes with no errors in that file and the prompt count matches the target stated for that category.

DEFINITION OF DONE FOR THE WHOLE TASK
Every category file has the tier field, tsc is clean repo-wide, and the full test suite still passes.

RISK OF THIS SESSION BEING INTERRUPTED PARTWAY
This will likely run across a context compaction given the number of files involved, and may also be paused and resumed manually.

BEFORE STARTING
Write the full TodoWrite list up front, broken down per One todo item per category file, not one item for the whole migration and not one item per individual prompt entry. — not so coarse that one item silently contains four days of hidden sub-steps, and not so fine that the list itself becomes more overhead than the work it tracks.

WHILE WORKING
- Keep exactly one item marked in_progress at any given moment. Do not mark a second item in_progress before the first is either completed or explicitly abandoned with a stated reason — a list with two simultaneous in-progress items has stopped functioning as a record of what is actually happening right now.
- Update an item's status the moment its real state changes, not in a batch at the end of a work stretch — a todo list updated after the fact is a summary, not a tracker, and provides none of the mid-session recovery value a live list gives if the session is interrupted.
- Do not mark an item completed unless it meets A category file counts as done only once tsc --noEmit passes with no errors in that file and the prompt count matches the target stated for that category. for that specific item — a step that looks finished because the code was written is not the same as a step confirmed against its actual verification bar, and marking it done regardless quietly lowers the bar for every item after it.
- If a new sub-step is discovered mid-task that the original list did not anticipate, add it to the list explicitly rather than folding it silently into whichever item is currently in progress, so the list continues to reflect the actual scope of remaining work rather than a stale plan from before the discovery.

IF THIS SESSION IS INTERRUPTED
Given This will likely run across a context compaction given the number of files involved, and may also be paused and resumed manually., the list itself should be detailed enough that a fresh session, or a compacted continuation of this one, can reconstruct exactly what remains without re-deriving it from scratch — a todo item's own text should name enough specifics that its current state is obvious from reading it cold.

AT THE END
Compare the completed list against Every category file has the tier field, tsc is clean repo-wide, and the full test suite still passes. explicitly — a list where every individual item shows completed is not automatically proof the overall task is done if the original definition of done named something the list never captured as its own item.