Skip to content

Bonbon Dino — Session Retrospective Ritual

This is the canonical end-of-session prompt for any client-site project. Run it at the end of every working session to keep the shared checklist files growing.

The checklist files live in the checklists/ folder:

  • checklists/website-checklist.md — frontend marketing patterns
  • checklists/admin-panel-checklist.md — single-admin auth, settings, dashboard
  • checklists/qa-board-checklist.md — public Q&A / contact-thread feature
  • checklists/email-checklist.md — Resend transactional email
  • checklists/db-and-deploy-checklist.md — Turso + Drizzle + Cloudflare Workers deploy
  • checklists/debugging-lessons.md — cross-cutting bug log

How to invoke

Paste this into the session you're closing out:

Read every file in /Users/ja58968/Projects/bonbondino_company/wiki/playbooks (the agency checklist + its companions). Then follow the steps in RETROSPECTIVE.md and propose appends or in-place edits.

The agent should then walk through the steps below and produce a diff for each affected file. Nothing is written until the user approves the diff.

Steps the Agent Follows

1. Skim every checklist file

Read all six checklist files end-to-end. Don't skip — knowing what's already documented prevents duplicate entries.

2. Reconstruct what happened this session

Use these sources, in order: - The current conversation context - git log -30 --oneline and git diff since the last release tag - ls /Users/ja58968/.claude/projects/<project-slug>/memory/ — read any new session memory files - claude-mem search for the project — surface anything that didn't make it into the memory folder

3. Identify what is transferable

For each thing that happened this session, ask:

If it's… Then…
Project-specific (a particular client's brand color, a hardcoded number, copy specific to one business) Skip — don't pollute the checklist
A new pattern that worked well and could apply to the next client site Rewrite the relevant section in place when one already covers the same area. Append a new section only when the topic is genuinely new. The default is in-place, not append.
A bug you fixed, with a non-obvious root cause Rewrite the existing entry in place when one already covers the same symptom/area. Append only when this is a new symptom.
A behavior the user clarified that the agent had gotten wrong Rewrite the relevant section in place. If it's about agent collaboration, add to the project's CLAUDE.md (NOT here).
A deploy / DB / auth gotcha that wasted >10 minutes Always write it down — rewrite in place if a related entry exists, else append.
Stale content in a checklist (a "Fix" that no longer matches the current default, an env-var doc that still says Pages when the project moved to OpenNext, a cookie-name that's been renamed) Rewrite in place. Outdated content is worse than no content. If the section is fully superseded, rewrite the whole thing; if the existing one is still partly right, edit the stale parts and add a date stamp noting the update.

If nothing is transferable, say so explicitly: "No retrospective updates this session — work was project-specific." Don't invent updates to feel productive.

4. Propose the diff

For each file you want to change, show the diff. Format:

## Proposed update: <file>

<new content as a quoted block, or the before/after of an in-place edit>

If updating debugging-lessons.md, find the right category (UI / Deploy / Auth / Data / Email / Process / Forms / Third-party API Integration / Migrations / Refactors) and either append at the bottom of that category or rewrite the relevant existing entry.

5. Wait for approval

Do NOT write the files until the user says "yes" or proposes edits. The "rewrite in place when stale" policy is in effect — outdated content is worse than no content — but the user must still approve every change.

6. Apply and commit

After approval: - Apply each diff (append new sections; rewrite existing sections in place when stale). - Stage and commit with docs(checklists): retrospective updates from <project-slug> <YYYY-MM-DD>. - Use the agent's name as committer (per ~/.claude/rules/git-workflow.md).

Hard rules

  1. Rewrite in place when stale. The old "append only" rule has been retired. If a section's "Fix" no longer matches the default deploy mechanism, or a class of bug now has a better solution, update the existing entry. Outdated fixes are worse than no fix.
  2. Match the house style. Numbered section, What it does / Why / How to implement, code snippet where useful. Debugging entries use Symptom → Root cause → Fix → File. Use <domain>, <project>, <repo>, etc. as placeholders — do not embed a real client domain or project name in the body of a section. Project names belong in **File:** paths and Source: provenance lines only.
  3. No project-specific content in the body. "Client X's primary color is #A52550" is project-specific. "Brand color should be a defined constant in one file" is transferable. If you can't strip the project name and the lesson still applies, it's not transferable.
  4. Cross-reference, don't duplicate. If the pattern is already in another file, link to it: "see admin-panel-checklist.md §3".
  5. One concrete improvement per section — don't bundle three loosely-related lessons into one §.

Optional: per-project CLAUDE.md hook

Add this line to any new client-site project's CLAUDE.md so future agents discover the ritual:

At end of session, follow /Users/ja58968/Projects/bonbondino_company/wiki/playbooks/RETROSPECTIVE.md and propose checklist updates.

How to extend this file

If the retrospective process itself needs updating (a new source to mine, a new category, a different commit format), edit this file directly — this is the process doc, not a content file. Keep it short.