Retrospective

SKILL.md preview

---
name: Retrospective
description: KALM retrospective grounded in objective metrics, with closed-loop tracking of prior actions and SMART next actions
var: ""
tags: [meta]
requires: [RESEND_API_KEY?]
---
<!-- autoresearch: variation B — sharper output: KALM frame + close-the-loop + SMART actions -->
> **${var}** — Optional area to focus on (e.g. `crypto`, `notifications`). If empty, covers the whole system.

If `${var}` is set, scope every section below to that area only. Skip findings that don't touch it.

## Why this skill exists

A retrospective is only valuable if (a) findings rest on objective data, not vibes, and (b) findings turn into **specific actions that get checked next week**. This skill enforces both: pull metrics from multiple sources, frame findings as KALM (Keep/Add/Less/More), and emit each action as SMART (specific, measurable, owner, deadline) so the next run can audit follow-through.

## Inputs (gather all before writing)

Read in this order. If any source is empty or missing, note it explicitly in the article — don't silently skip.

1. **Context** — `memory/MEMORY.md` for goals; `soul/SOUL.md` for voice (skip if empty).
2. **Activity logs** — every `memory/logs/YYYY-MM-DD.md` from the last 7 days.
3. **Objective skill metrics** — run `./scripts/skill-runs --hours 168 --json` and parse pass/fail counts per skill. If the script fails or the JSON is empty, fall back to `cat memory/cron-state.json` and note the degraded source.
4. **Open issues** — `memory/issues/INDEX.md` (treat any new `open` issues this week as findings).
5. **Code activity** — `git log --since="7 days ago" --pretty=format:"%h %s"` to see what shipped (skills added/changed, fixes, PRs merged).
6. **Prior review** — the most recent `articles/retrospective-*.md` (if none exists, fall back to the most recent legacy `articles/weekly-review-*.md`). Extract its "Next week priorities" section — you will audit those actions in step 1 below.

## Steps

### 1. Close the loop on last week's actions (do this FIRST)

For each action item in the prior retrospective's "Next week priorities":
- Did it ship? (Check git log + this week's logs for evidence.)
- If yes: note as **shipped** with the commit/log line that proves it.
- If no: classify as **slipped** (still relevant, carry over), **abandoned** (no longer needed, explain why), or **blocked** (needs unblocking — name the blocker).

If there is no prior retrospective, write `_No prior review to audit — this is the baseline._` and continue.

### 2. Compile objective metrics

A short table at the top of the article. Use exact numbers from step 3-5 inputs above.

| Metric | This week | Prior week (if known) | Δ |
|---|---|---|---|
| Skill runs | N | M | ±X |
| Successes / failures | N / M | — | — |
| Articles written | N | — | — |
| Notifications sent | N | — | — |
| New issues opened | N | — | — |
| Issues resolved | N | — | — |
| Commits / PRs merged | N | — | — |

If you can't compute prior-week numbers (no prior article, missing data), leave the column blank — don't fabricate.

### 3. KALM findings, prioritized

Group findings into four buckets. **Each finding must cite at least one log line, commit, or issue ID** as evidence — no unsupported claims.

- **Keep** — what's working and should continue unchanged.
- **Add** — capabilities or sources missing this week that would have helped.
- **Less** — things consuming time/runs/notifications without proportional value (noisy alerts, redundant skill runs, churn).
- **More** — things that worked but are under-invested (a skill producing high-signal output that only ran twice, an issue category that needs more attention).

After listing, score each finding by **Frequency × Impact ÷ Effort** (1-5 each). Compute the priority number; sort descending. Keep the top 5; drop the rest. Generic items ("improve documentation") fail the priority threshold and must be dropped or rewritten.

### 4. Translate top findings into SMART next-week actions

For each of the 

…