home / skills / onekeyhq / app-monorepo / 1k-retrospective

1k-retrospective skill

This skill analyzes real bug fix cases to update self-testing rules, improving quality checks over time.

npx playbooks add skill onekeyhq/app-monorepo --skill 1k-retrospective

Review the files below or copy the command above to add this skill to your agents.

Files (2)

SKILL.md

2.1 KB

---
name: 1k-retrospective
description: >
  Analyze accumulated bug fix cases and propose updates to the self-testing checklist.
  Use periodically (weekly/monthly) to evolve quality checks based on real issues.
allowed-tools: Read, Grep, Glob, Write, StrReplace
---

# Retrospective: Evolve Self-Testing Rules from Real Cases

## Workflow

### Step 1: Read Cases

Read `.claude/skills/1k-retrospective/references/case-studies.md`. Count cases since the last `<!-- Retrospective completed -->` marker. If fewer than 3 new cases, report "Not enough new cases" and stop.

### Step 2: Analyze Patterns

For each case, extract root cause category and which self-testing section (1-8) could have caught it, or "NEW" if not covered. Aggregate counts per pattern.

### Step 3: Identify Gaps and Weak Spots

- **Gaps**: patterns appearing **2+ times** marked "NEW" → candidates for new check items
- **Weak spots**: patterns appearing **3+ times** already covered → check item needs stronger wording or more specificity

### Step 4: Propose Changes

Output a short report:

```
Retrospective — YYYY-MM-DD
Cases analyzed: N (date range: YYYY-MM-DD to YYYY-MM-DD)
Recurring patterns: [pattern] N (NEW/WEAK), [pattern] N (NEW/WEAK)
Proposed changes: Add [Section N] [one-line check] / Strengthen [Section N] [current → revised]
Housekeeping: archive candidates [list], zero-hit checks [list]
```

### Step 5: Apply Changes (after user confirmation)

Rules when modifying `self-testing.mdc`:
1. **Max 150 lines** — if exceeded, consolidate similar items or move details to `references/patterns.md`
2. **One-liner check items only** — no code examples in the rule file
3. **Keep 9-section structure** — new items go into existing sections, no new sections
4. **Never delete case entries** — mark archived with `[ARCHIVED]` prefix

### Step 6: Update Timestamp

Append to `case-studies.md`:
```
<!-- Retrospective completed: YYYY-MM-DD | Cases analyzed: N | Changes applied: N -->
```

## Example

5 cases: 3 BigNumber (NaN/precision/division), 1 cleanup, 1 stale closure.
→ BigNumber = NEW (3 hits) → Add one-line check to Section 1.

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.

FAQ

What if fewer than three new cases exist?

The skill reports "Not enough new cases" and stops; wait for more data or broaden the case window.

How are proposed changes formatted?

The output is a short report with counts, recurring patterns labeled NEW or WEAK, one-line add/strengthen proposals, and housekeeping lists.

Can the skill delete old checks?

No. It never deletes case entries and preserves the nine-section structure; obsolete items should be archived with an [ARCHIVED] prefix.