1k-retrospective_skill

Overview

This skill analyzes accumulated bug-fix cases and evolves the project's self-testing checklist based on real-world failures. It reads recent case entries, identifies recurring root causes and coverage gaps, and proposes concise checklist updates so tests and reviews catch the same classes of issues going forward.

How this skill works

The skill scans the case-studies file and counts new cases since the last retrospective marker. It classifies each case by root cause and maps it to one of the nine self-testing sections or marks it NEW when uncovered. It then aggregates patterns, flags gaps (NEW ≥ 2) and weak spots (covered ≥ 3), and generates a short, actionable retrospective report with proposed one-line checklist changes and housekeeping actions.

When to use it

• Run weekly or monthly to keep checks aligned with production failures.
• After a cluster of related bug fixes to extract repeatable causes.
• Before a release cycle to ensure recent regressions are prevented.
• When onboarding new contributors to prioritize common pitfalls.
• When increasing platform support or adding complex integrations.

Best practices

• Require at least 3 new cases to trigger a retrospective run; otherwise report "Not enough new cases."
• Map each case to a root cause and to a specific self-testing section or mark it NEW.
• Treat patterns appearing 2+ times as candidates for new checks; 3+ covered occurrences mean strengthening wording.
• Keep proposed changes to one-line checks and maintain the nine-section structure; do not add sections.
• If self-testing.mdc exceeds 150 lines, consolidate similar items or move details to a patterns reference file.

Example use cases

• Find that NaN/precision BigNumber bugs occurred three times and add a one-line check to Section 1.
• Detect repeated cleanup regressions and strengthen the existing checklist phrasing to require explicit resource teardown.
• Spot a NEW pattern in mobile serialization errors with 2+ hits and propose adding a coverage item to the relevant section.
• Regularly archive low-value or obsolete case entries by marking them [ARCHIVED] rather than deleting.