Continuous Improvement

Continuous Improvement

Audit a codebase, find real improvements, implement the best ones as PRs, self-review, and assess merge safety. This is a journey skill — it orchestrates a full workflow from audit to PR-ready.

Input: "$ARGUMENTS"

Before Starting

1. Read the repo's CLAUDE.md for conventions (commit format, branch naming, style rules)
2. Read this skill's feedback.md if it exists — apply all rules from prior feedback before proceeding
3. Check git status — must be on a clean working tree. If there are uncommitted changes, stop and tell the user.

Phase 1: AUDIT

Scan the codebase for improvements. Use the same methodology as the codebase-tasks skill:

Scope: If a path is provided, scan that area. If --focus is set, narrow to that category. Otherwise scan the full repo.

Categories to scan:

How to scan:

• Use Grep for explicit markers (TODO, FIXME, HACK, skip, xdescribe)
• Use Read on key files to find implicit issues (empty catches, dead code, consistency gaps)
• Use Bash for git log to find areas that change frequently (fragile code)
• Check package.json / pyproject.toml for dependency issues

Phase 2: PRIORITIZE

Score each finding on two axes:

• Impact (1-5): How much does fixing this improve the codebase?
• Confidence (0-100): How sure are you this is a real issue, not intentional?

Drop anything below 80 confidence. When in doubt, leave it out.

Categorize:

Present findings as a TLDR:

## Continuous Improvement — [repo name]

**Found:** X items (Y do-now, Z propose, W note)

### Do Now (quick wins)
| # | File:Line | Issue | Fix | Impact |
|---|---|---|---|---|
| 1 | src/api.ts:42 | Empty catch swallows auth error | Add error logging | Reliability |

### Propose (needs discussion)
| # | File:Line | Issue | Why Discuss | Impact |
|---|---|---|---|---|
| 1 | lib/db.ts:80 | N+1 query in user listing | Requires schema understanding | Performance |

### Notes
- [Lower priority items, one line each]

If --dry-run was passed, stop here. Present findings and exit.

Phase 3: IMPLEMENT

For each "do now" item (if --auto-pr is passed, or user approves):

1. Branch: Create fix/<scope>/<description> from the current base branch
2. Fix: Apply targeted changes using Edit. Fix the issue, don't refactor the neighborhood.
3. Verify:
   • If the repo has a type checker configured, run it: npx tsc --noEmit or equivalent
   • If the repo has tests, run relevant ones: npm test or equivalent
   • If verification fails: revert the change, move the item to "propose" tier, note why
4. Commit: Follow the repo's CLAUDE.md commit format. One commit per logical fix or group of related fixes.

Group related fixes into one PR when they're in the same area (e.g., 3 empty catches in the same file → one PR). Don't create 15 single-line PRs.

Phase 4: PR + SELF-REVIEW

For each branch with changes:

1. Create PR: gh pr create --title "..." --body "..." with:

   • Clear title following repo conventions
   • Body listing what was found and fixed, with file:line references
   • Label if the repo uses labels

2. Self-review (apply the pr-fix methodology):

   • Re-read every changed file in full (not just the diff)
   • Check: did the fix introduce a new bug? Miss an edge case? Break an import?
   • Score each concern 0-100 confidence. Fix anything above 80.
   • If self-review finds issues, fix them and push.

Phase 5: MERGE SAFETY

For each PR created, assess merge safety (apply the pr-safety methodology):

• Rate: blast radius, regression potential, data safety, rollback difficulty
• Check for red flags (migrations, API changes, auth changes)
• Add the assessment to the PR description (not as a separate comment)

Phase 6: REPORT

Summarize everything done:

## Continuous Improvement — Complete

### PRs Created
| PR | Title | Risk | Changes |
|---|---|---|---|
| #42 | fix(api): add error logging to auth catch blocks | LOW | 3 files, +12/-3 |
| #43 | fix(deps): update deprecated uuid package | LOW | 1 file, +1/-1 |

### Proposed (needs your input)
| # | Issue | Why It Needs Discussion |
|---|---|---|
| 1 | N+1 query in user listing | Multiple valid approaches, need to pick one |

### Summary
- Scanned: [X] files across [Y] directories
- Found: [A] items total, [B] implemented, [C] proposed, [D] noted
- PRs: [E] created, all LOW/MEDIUM risk

Feedback

After the user responds to the results (approves, rejects, modifies, or gives verbal feedback):

• Record the feedback in this skill's feedback.md
• Format: date, what the feedback was, how to apply it going forward
• Keep feedback.md under 50 lines — distill old entries into concise rules

Rules

• Read the repo's CLAUDE.md — every repo has its own conventions. Respect them.
• High confidence only — drop findings below 80 confidence. A false positive wastes more time than a missed true positive.
• Minimal fixes — fix the issue, not the file. Don't refactor surrounding code.
• Group, don't spam — related fixes go in one PR. Don't create 15 PRs for 15 one-line changes.
• Verify before pushing — run type checker and tests. If they fail, revert.
• No style nits — skip anything a linter or formatter would catch.
• No speculative improvements — only fix things that are objectively wrong or clearly improvable.
• Clean tree required — don't start if there are uncommitted changes.
• Never force-push, never push to main — always branch, always PR.