jcdavis131 Recap On Long Session
A 48-minute session has a history no one can re-read efficiently. A recap is the compressed checkpoint that lets the conversation survive a context reset, a user stepping away, or a handoff.
When to recap
- ~30+ minutes of elapsed work, or a comparable turn count.
- The user re-engages after stepping away ("what's the status", "where are we", "continue").
- Before a context compaction / handoff.
- At a natural milestone (a board task just completed, a phase finished).
- Not every turn — a recap on every turn is noise.
The recap shape
Three lines, no more:
※ recap: <one-line what we're building>
Done: <what's verified complete>
In flight: <the one in-progress task + what it's waiting on>
Next: <the conditioned next action>
Optionally add Blockers: if anything's red.
Rules
- Compressed, not exhaustive. A recap that lists every micro-step is just the conversation re-typed. Surface the state, not the history.
- Done means verified — only list under "Done" what passed its validate gate (see
validate-gate). "I finished writing it" goes under "In flight" until the gate passes. - Name the wait condition. "In flight: dashboard install, waiting on pnpm" — not just "dashboard". The wait condition is the actionable part.
- Next is conditioned and concrete. "Next: finish pnpm install, then typecheck and final report" — not "Next: keep working".
When NOT to recap
- The session is short and the user is actively engaged turn-by-turn.
- Nothing has changed since the last recap. A recap that repeats the prior one is noise.
- The user is mid-sentence / mid-decision. Recap when the floor is open.
Pair with
progress-board— the board is the live view; the recap is the periodic compressed view. Both run together on long sessions.persist-learnings— the recap is the in-conversation checkpoint; memory files are the durable checkpoint. Different audiences, both needed.cost-transparency— elapsed time is the trigger.