# Better

> Quality upgrade pass on the current deliverable: scorecard, improve, review, verify with fresh evidence. Use when the user runs /better, /better deep, /better ship, /better <focus>, or asks to polish, harden, upgrade quality, or review-and-verify without adding features. Not for new scope. Not /scale (that is quality-at-scale). Not /reviewresults (that is review-results / sensory proof).

- Skill: `kayforkind/better` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kayforkind/better`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kayforkind/better/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Kayforkind (https://skillmd.com/u/kayforkind)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/kayforkind/better

---


# /better — Quality upgrade pass

**Slash:** `/better` (optional project command file)  
**Templates:** [reference.md](reference.md)

Improve the **current deliverable**. Review and verify along the way. Do not claim done without fresh evidence.

Say once: **“Running /better.”** Name the deliverable before editing.

## Modes

| Invocation | Behavior |
|------------|----------|
| `/better` | Scorecard → improve → review → verify |
| `/better deep` | Extra review wave, edge cases, second improve pass |
| `/better ship` | Ship bar: tests + typecheck + Bugbot (+ security when relevant) |
| `/better <focus>` | Narrow (`ui`, `api`, `tests`, `perf`, `a11y`, `copy`, …) |

## Hard contract

1. **Scope lock** — name the deliverable before editing.
2. **Baseline** — diff / screenshot / failing checks. Know what “before” was.
3. **Scorecard** — rank gaps; fix highest impact first (see reference).
4. **Resource fan-out** — load only what this pass needs: `deslop`, `verify-this`, `check-compiler-errors`, `control-ui`, Bugbot, Security Review, smoke tests. Swarm when independent slices exist; parent owns verify.
5. **Review mid-flight** — re-read / re-diff after change clusters.
6. **Verify with evidence** — typecheck, tests, screenshots, or a falsifiable `verify-this` verdict.
7. **No fake done** — report `BETTER: improved | partial | blocked`.
8. **Paid gate** — ask before paid models/APIs.
9. **No scope creep** — quality ≠ new features. No commit/push unless asked.

## Procedure

```
BETTER Progress:
- [ ] 0. Deliverable named + baseline captured
- [ ] 1. Scorecard ranked
- [ ] 2. Highest-impact fixes applied
- [ ] 3. Mid-flight re-read / re-diff
- [ ] 4. Verify (project path + extra bar if /better ship)
- [ ] 5. Report BETTER: improved | partial | blocked
```

### 0. Name and baseline

One sentence: what artifact, what “better” means for *this* pass. Capture the before state (diff, failing test, screenshot path). If there is no deliverable yet, stop — this is not `/goal` (no contract) and not greenfield build.

### 1. Scorecard

Rank 3–7 gaps. Fix top impact first. Do not polish P3 while P0 is open. Use the table in [reference.md](reference.md).

### 2. Improve

Smallest diff that moves the top gaps. Match the file. No drive-by refactors. `deslop` when the gap is mush.

### 3. Review

Re-read the changed region. Re-diff. If `/better deep`, do a second wave on edge cases. If `/better ship`, run Bugbot (and security-review when the change is auth, money, secrets, or user data).

### 4. Verify

Run the **project’s** verify path. Report exit codes verbatim. Sensory / UI: `/reviewresults` (`review-results`). A problem-fit pass is not proof.

### 5. Report

```
BETTER: improved | partial | blocked
Deliverable: <name>
Changed: <paths>
Verified: <commands + exit codes>
Remaining: <what still fails the scorecard>
```

## Compose

| Need | Command / skill |
|------|-----------------|
| Outcome contract | `/goal` (`goal` skill) |
| Autonomous until criteria | `/goal-loop` (mode of `goal`) |
| Parallel workers | `/swarm` — parent owns verify |
| Many unique items | `/scale` (`quality-at-scale`) |
| Sensory proof | `/reviewresults` (`review-results`) |

## Must not

- New features dressed as polish
- Fake done (“looks better”) with no baseline or verify
- Growing always-on skills or dumping the catalog
- Commit/push unless the user asked
- Skipping `/reviewresults` on user-facing / sensory because this pass “felt thorough”
- Using `/better` as a substitute for `/goal` when success criteria do not exist