backlog-retrospective

Closes GitHub issues with structured retrospective comments and validates shipped outcomes.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/chris-prener/dev-kit --skill backlog-retrospective-chris-prener
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: backlog-retrospective
Source: https://github.com/chris-prener/dev-kit/tree/main/dev-kit/skills/backlog-retrospective
Command: npx skills add https://github.com/chris-prener/dev-kit --skill backlog-retrospective-chris-prener

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Closing a GitHub issue often loses the context of what shipped, how it was implemented, and whether it actually worked. This Skill enforces a consistent close-time retrospective record on every completed issue and supports later outcome validation, so the issue tracker remains a durable source of project history. ## Core Features & Use Cases - Close+Retro Operation: Closes an issue and posts a structured ## Retrospective comment (Resolved by, What shipped, How, Tests, Follow-ups) in one transaction, with carve-outs for duplicate/wontfix/not-planned/invalid closes. - Outcome Validation: Posts a dated ## Outcome validation comment on already-closed issues, recording whether the change achieved its intent (achieved / partial / not-achieved / deferred) with a signal source and rationale. - Epic Close Detection: After closing a sub-issue, checks the parent epic via the GitHub sub-issues API and prompts an epic retrospective when the last open sub-issue closes. - Auto-Filed Remediation: For partial or not-achieved outcomes, files a deduplicated tech-debt follow-up issue with priority labels via the backlog skill's auto-file contract. - Use Case: When a PR with Closes #42 is about to merge, run close+retro to document the shipped change on issue #42; months later, run validate to confirm the fix actually resolved the reported behavior. ## Quick Start Close issue #42 with a retrospective comment documenting what shipped, how it was implemented, and which tests cover it.

Frequently Asked Questions about backlog-retrospective

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

FAQPage Schema
How do I close a GitHub issue with a retrospective comment?▼

Run the close+retro operation with the issue number and the resolving PR or commit SHA. It posts a structured Retrospective comment covering what shipped, how, and tests, then closes the issue with reason completed using the gh CLI.

How do I validate whether a closed GitHub issue actually achieved its goal?▼

Use the validate operation on an already-closed issue. It posts a dated Outcome validation comment with one of achieved, partial, not-achieved, or deferred, plus a signal source and rationale tied to the issue's acceptance criteria.

When should I not post a retrospective on issue close?▼

Skip the full retro for closes as duplicate, wontfix, not-planned, or invalid. Add the matching close-reason label first, leave a short rationale comment, then close. Also skip if the issue already has a retro from a prior close.

Does this work with GitHub epics and sub-issues?▼

Yes. After a successful close, it queries the parent epic via the GitHub sub-issues REST endpoint and counts remaining open sub-issues. When the last one closes, it prompts you to run an epic retrospective without auto-invoking it.

What happens when outcome validation finds a partial or failed result?▼

It auto-files a tech-debt follow-up issue with priority/medium for partial or priority/high for not-achieved. The filing is deduplicated by a stable marker so re-validations do not spam duplicate issues while a prior follow-up remains open.