Most retros are about the team. This one is about you, and it does not rely on your memory of the week; it reads the actual record and hands back three things worth practicing.
The idea is not mine. Harshit Pandey built the first version and made the case that matters: a self-retro should stay focused on the work you actually did, weighted to where your time went, and end in concrete next steps rather than generic advice. I have been running my own version weekly since May, and it has become the most useful recurring prompt I have.
Two ways to run it
The hard part of a personal retro is data. There are two places that data lives, so the skill auto-detects which one it can reach and runs the right way:
Local: pull session data directly
- When your Claude Code session files are present, the retro is built from your own transcripts: how you framed problems, where you pushed back, where you accepted too fast.
- This is the richest signal, and it runs offline. A bundled parser flattens the week's real sessions into the analysis; nothing leaves the machine.
Cloud: a web routine over your shipped work
- A scheduled Claude web routine cannot see your local sessions, so it reads what it can: GitHub PRs authored and reviewed, Jira touches, and optionally Glean docs you wrote.
- This was one of the first web routines I ran. It pairs with an LLM wiki (a git-backed Obsidian vault), so each run commits a durable, reviewable report and DMs it to me on Slack.
If neither is reachable (a cloud run with no vault and no connected accounts), the skill says it needs data rather than inventing a report. Same idea, two environments; --local or --signals forces a mode.
What running it weekly actually changed
The point of a learning plan is that you do the items. Across the weekly runs since May, each retro's ranked plan turned into a specific piece of follow-up work. This is the honest record, pulled from my own session notes:
| Week | Top learning-plan item | What it turned into |
|---|---|---|
| Jun 15 | Document which invocation surfaces carry ZDR eligibility | A ZDR-eligible-surfaces note in the vault's references.md, written before the next infra decision that depended on it |
| Jun 29 | Add failure-mode and rollback notes to skills that write | A "Risks & rollback" block added to write-path skills, plus a vault runbook for the native-vs-waterfall enrichment flow |
| Jul 13 | Reconcile MTTR from PagerDuty + BetterStack + the Slack sev channel | An MTTR reconciliation step scoped to wire into the create-rca skill, plus a Redis/Sidekiq capacity model |
| Jul 16 | Write up the polling-vs-event-driven trade-off from a live incident | The item I flagged as the most valuable of the run: a one-page design note comparing cost, failure modes, and migration risk, analysis that otherwise would have died in the incident channel |
The Jul 16 run is the one I shared with Harshit: its third learning-plan item took something I had spitballed mid-incident and turned it into a design note I could actually circulate. That is the test: the report does not need to flatter me, it needs to give me one item a week worth doing.
Design guardrails
The same posture as the rest of this repo, because it is why I trust the output:
The retro is reflective, never punitive: the reports are banned from the words "gap", "missed", "failed", and "lacking", and every claim has to cite specific session or PR evidence, not vibes. It is report-only: it generates the plan and, on approval, saves it; it does not touch tickets, memory, or code on its own. It is honest about an empty week or an unreachable signal, saying so in one line instead of padding. And it keeps the analysis weighted to where you spent your time (Harshit's original point), so a week that was 90% backend does not get a report obsessing over the 10% that was frontend.
Honest limitations
The cloud routine is only as good as the signals it can reach: no GitHub or Jira access, and it falls back to a thin report or asks for data. It infers your primary work area from directory and repository paths, which is a heuristic, not ground truth. Local mode depends on Claude Code's session files being where it expects them. Scheduling is best-supported on the clients I use daily; elsewhere the setup skill hands you the exact manual command rather than installing a cron job behind your back. And like everything here, it is tested primarily on macOS.
The practical test: if this is working, once a week you get a report that names one real thing worth practicing, cites where the evidence came from, and gives you an exercise concrete enough to start that afternoon.
Install the plugin
Add the public marketplace once, install, then run setup to schedule the weekly run.
Claude Code
claude plugin marketplace add adzuci/claude-plugins
claude plugin install learning@adzuci-plugins
/learning:learning-setupCodex
codex plugin marketplace add adzuci/claude-plugins
codex plugin add learning@adzuci-plugins
/learning-setupRun /self-retro any time for an on-demand retro. Setup asks before it schedules anything or writes outside the current project. Pairs best with the memory plugin's vault as the place reports land.