| name | workflow-retrospective |
| description | Run a retrospective analysis on completed work to identify process improvement opportunities. Use when the user wants to review a completed batch or item run, or invoke on-demand with a PR number, branch, or date as scope hint. |
Workflow Retrospective
Recommended model tier: balanced
Meta-Retrospective: If the user invokes this skill with a meta scope (e.g., "run meta-retro", "periodic verification", or similar phrasing indicating trend analysis of prior improvements), follow docs/workflow/development-workflow/protocols/06b-meta-retrospective-protocol.md instead of the regular retrospective flow below. The meta-retrospective includes a platform evaluation step (Step 2b) that reads docs/workflow/retro-metrics-platforms.md and reports the running exclusive-block rate for each review platform against the graduation criteria. When fewer than 30 compare-mode runs are logged, Step 2b explicitly states data is insufficient for a graduation decision.
- Read
AGENTS.md for repository-wide rules.
- Read
docs/workflow/development-workflow/protocols/06-retrospective-protocol.md.
- Resolve scope from the user's request (PR number, branch name, batch date) or default to recent PRs in the repository.
- Gather GitHub PR metadata (review cycles, finding types, labels, merge conflicts) and git history (commit patterns, fix-commit ratio) using
gh. When conversation context is available, also analyze manual interventions, human corrections, and agent deviations from the current session.
- Synthesize findings into a categorized list using the fixed taxonomy and severity signals defined in the protocol.
- After synthesizing findings, populate the required metrics block (see Step 3d
in the protocol): batch identifier, human interventions count, Step 5.2
violations count, automated-reviewer retry loops count, escalations count,
prior action item recurrence assessment. For automated-reviewer retry loops,
parse
reviewer_loop_history.v1 from the latest script-owned reviewer-loop
summary comment first and calculate max(entries.length - 1, 0) when
history_status is available; otherwise record unavailable (<reason>)
before falling back to legacy timestamp heuristics. Record unavailable for
any field that cannot be reliably determined.
- Present findings to the human, including the metrics block alongside improvement opportunities. For each opportunity, accept the human's choice of "Address now", "Add to backlog", or "Skip" — then execute the chosen action.
- "Address now": apply simple fix on a
fix/[slug] branch, open a PR to develop, and proceed through normal review/CI gates — do not push directly to shared branches. "Add to backlog": create GitHub issue directly via gh issue create. "Skip": move on.
- After all opportunities are acted on, append the finalized metrics block to
docs/workflow/retro-metrics.md as a new table row.
- Post a confirmation summary table.
