# Continuous Improvement

> Audit a codebase for improvements, implement the best ones as PRs with auto-review and merge safety analysis. Loops in user for approval at key moments.

- Skill: `dylanpulver/continuous-improvement` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add dylanpulver/continuous-improvement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/dylanpulver/continuous-improvement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: dylanpulver (https://skillmd.com/u/dylanpulver)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/dylanpulver/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:**

| Category | What to Look For |
|---|---|
| **Security** | Empty catch blocks hiding errors, SQL/injection risks, auth gaps, hardcoded secrets, missing input validation at boundaries |
| **Performance** | N+1 queries, unnecessary re-renders, missing indexes hinted at by query patterns, synchronous I/O in hot paths |
| **Tech debt** | TODOs/FIXMEs older than 3 months, commented-out code, dead exports, duplicated logic, mixed patterns in same directory |
| **Dependencies** | Major version bumps available, deprecated packages, unused dependencies |
| **Tests** | Skipped tests, missing error path coverage, test files that import modules that no longer exist |

**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:

| Tier | Criteria | Action |
|---|---|---|
| **Do now** | Quick win: <15 lines, high confidence, clear improvement, no risk | Implement automatically if `--auto-pr` |
| **Propose** | Real issue but bigger change, needs discussion, or moderate risk | Present to user for decision |
| **Note** | Valid but low urgency, or context-dependent | List briefly, don't act |
| **Skip** | Noise, intentional, or linter territory | Don't mention |

**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.