retrospective

Generates KPT retrospectives and records qualified Try items as GitHub Issues.

Updated Aug 17, 2026
One-click install
npx skills add https://github.com/kai-kou/gem-hunter --skill retrospective-kai-kou
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: retrospective
Source: https://github.com/kai-kou/gem-hunter/tree/main/.claude/skills/retrospective
Command: npx skills add https://github.com/kai-kou/gem-hunter --skill retrospective-kai-kou

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? After each automated workflow or pipeline run, teams need a consistent way to capture what worked, what failed, and what to improve—without flooding the issue tracker with one-off ideas. This Skill automates post-workflow retrospectives: it runs three parallel review sub-agents, merges their KPT (Keep/Problem/Try) findings, and only promotes Try items to GitHub Issues when they meet qualification rules (blocker urgency or repeated observation with available WIP capacity). ## Core Features & Use Cases - Parallel KPT Review: Launches three haiku sub-agents (artifact quality, process/automation, tech/tooling reviewers) simultaneously to evaluate a completed pipeline run. - PULL-type Issue Promotion: Records all Try items in a candidate ledger Issue, and only creates or reopens type:retro-try Issues when eligibility criteria are met, preventing tracker noise. - Failure-triggered Retros: Automatically runs on circuit-breaker activation, repeated errors, or quality gate failures so root-cause prevention measures accumulate without manual requests. - Use Case: After a content-generation pipeline finishes (or fails twice with the same error), invoke the retrospective to get a KPT summary, Slack notification, ledger updates, and deduplicated improvement Issues with priority escalation on recurrence. ## Quick Start Ask the AI to run a retrospective on the latest pipeline execution, for example by saying "レトロスペクティブして" or "/retrospective {pipeline} {ID}".

Frequently Asked Questions about retrospective

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run an automated retrospective after a workflow completes?▼

Invoke the skill manually with "/retrospective {pipeline} {ID}" or phrases like "レトロスペクティブして". Pipelines also call it automatically as their final step, passing pipeline name, entity ID, PR URL, and execution summary.

How does the skill decide which Try items become GitHub Issues?▼

Try items are promoted only if they are urgency:blocker, or observed at least twice within the observation window while open non-blocker issues are under the WIP limit. All other Try items are recorded in a candidate ledger Issue instead of creating new Issues.

Does the retrospective run automatically on pipeline failures?▼

Yes. It auto-triggers on circuit-breaker activation, the same error occurring twice or more, quality gate misses, and unresolved self-review errors. One-off minor errors resolved by retry can be skipped.

Can I use gh CLI commands with this skill in cloud environments?▼

No. In cloud environments the gh CLI is blocked by an egress proxy, so all GitHub operations must go through GitHub MCP tools (mcp__github__*). The gh command examples in the skill are local-environment alternatives only.

What happens when the same problem recurs in later retrospectives?▼

The skill adds a recurrence comment to the existing Issue instead of creating a duplicate, and escalates its priority label to priority:high after more than three recurrences. Closed not_planned Issues are reopened on recurrence.

What are the limitations of the candidate ledger approach?▼

The ledger relies on exact key matching, so semantically identical issues phrased differently may be undercounted. Concurrent sessions can lose at most one observation between read and write, which is recovered from the audit-log comments on the next run.