retrospective

Record process improvements and recover unfiled issues after a change is released.

1|Updated Apr 21, 2026
One-click install
npx skills add https://github.com/devbasex/ai-plugins --skill retrospective-devbasex
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: retrospective
Source: https://github.com/devbasex/ai-plugins/tree/main/plugins/ndf/skills/retrospective
Command: npx skills add https://github.com/devbasex/ai-plugins --skill retrospective-devbasex

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a change is merged and verified, teams often skip reflecting on how the work was done, losing lessons learned and forgetting issues that were noticed but never filed. This Skill ensures every released change produces a retrospective record and that no out-of-scope findings fall through the cracks. ## Core Features & Use Cases - Dropped-issue recovery: Searches GitHub issues by origin (source issue and PR numbers) and cross-checks against quality-gate reports, review comments, and plan files to find findings that were never filed, then files them via the out-of-scope workflow. - Fact-based reflection: Collects evidence from specs, review rounds, release verification results, and plan files across five dimensions (acceptance criteria, rework, oversights, scope, process) instead of relying on memory. - Actionable outcomes: Requires at least one concrete change classified as a Skill procedure update, a project convention update (AGENTS.md/CLAUDE.md), or a filed follow-up issue. - Structured recording: Posts a single retrospective comment to the correct issue or PR (resolved via a three-stage branch/PR lookup), and adds a traceability link line to the source issue body. - Use Case: After merging and verifying a feature PR, run the retrospective to confirm all review findings were filed, decide to add a verification step to the release Skill, and post the retrospective comment to the originating issue. ## Quick Start Run the retrospective for the change that was just released and verified, and record what to change in how the work was done.

Frequently Asked Questions about retrospective

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

FAQPage Schema
How do I run a project retrospective after merging a pull request?▼

Run this retrospective Skill after release verification completes, or after post-merge cleanup if no release testing was done. It gathers facts from specs, reviews, and plans, decides at least one process change, and posts a retrospective comment to the source issue or PR.

How do I find issues that were noticed but never filed during development?▼

Search GitHub issues with gh issue list using both the source issue number and PR number as origin keywords, then cross-check against quality-gate reports, resolved review comments, and the plan file's out-of-scope list. Any item without an issue number is a dropped finding to file.

When is a retrospective required versus skippable?▼

Standard-mode changes always require a retrospective because they pass through implementation review. Operation-mode changes only need one when the execution procedure itself changed; a single config value change does not qualify.

How does the retrospective find the right pull request to comment on?▼

It resolves the PR in three stages: read the base branch from .ndf/worktree.json, determine the record base branch (development base or distribution channel branch), then query the GitHub API for merged PRs containing the base branch head commit. If the result is not exactly one PR, it asks the user.

What should not be included in a retrospective record?▼

Do not include evaluations of individual performance, judgments of deliverable quality (handled by code review), or chronological event timelines already preserved in git history and pull requests. Record only process decisions, their rationale, and measured evidence.