chore(skills): add sprint retrospective to sprint-start lifecycle

Insert A1b retrospective step between sprint close and version bump.
Covers: what shipped, what didn't, what we learned, process notes.
Process improvements are optional — only proposed when something was
actually broken.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

.claude/skills/sprint-start/SKILL.md

@@ -87,6 +87,48 @@ tooling/db/sprint stop
 This marks the active sprint as completed and lists carry-over candidates.
 Note the sprint number (N) from the output.
 
+#### A1b. Sprint retrospective and review
+
+Before bumping the version, run a brief retro. Present the following to
+the user:
+
+1. **What shipped** — list completed tickets with one-line summaries
+2. **What didn't ship** — carry-overs and why (blocked, cut, deprioritized)
+3. **What we learned** — open questions raised during the sprint (new Q-NNN
+   items), review findings that surfaced design gaps, and any assumptions
+   that turned out to be wrong
+4. **Process notes** — what worked well, what was friction (e.g. dependency
+   chains that blocked teams, specs that were over/under-specified,
+   review cycles that caught real issues vs busywork)
+
+5. **Process improvements** — this is the most important section. Do NOT
+   skip it. Look for:
+   - Dependency chains that blocked teams — could the sprint have been
+     structured differently to avoid the bottleneck?
+   - Specs that were over-specified (wasted planning) or under-specified
+     (wasted iteration) — what's the right level of detail for this
+     project's current stage?
+   - Review cycles — did they catch real issues or create busywork?
+   - Agent coordination — were agents stuck, duplicating work, or idle?
+   - **Dig into the deeper why.** Don't stop at "the dependency chain
+     blocked the copy team." Ask: why was there a dependency chain? Was
+     the sprint structured wrong, or was the work inherently sequential?
+     Could Phase 0 have been done pre-sprint? Should we change how we
+     plan sprints going forward?
+   - If something went rough, understand the root cause — not just what
+     happened, but why the process allowed it to happen.
+   - If a concrete process change follows naturally, propose it. But do
+     NOT force improvements. If nothing was broken, say so and move on.
+     Unnecessary process changes are worse than no changes.
+
+Keep each section concise — a few bullet points, not a document. The
+retro is a conversation checkpoint, not a report. Use `AskUserQuestion`
+to let the user add their own observations and push back before proceeding.
+
+If the user raises items that should be tracked, create Q-NNN entries
+or backlog tickets on the spot. If process changes are agreed, update
+the relevant skill files or CLAUDE.md immediately — don't defer them.
+
 #### A2. Bump the version
 
 The project version scheme is `v0.1.{sprint_number}`. After closing