Overbaked

---
name: overbaked
description: Audit a document, plan, or code for over-engineering, verbosity, and scope creep. Use when you've just written something and want a point-by-point check before finalizing.
allowed-tools: Bash Read Write
argument-hint: "[--no-archive]"
catalog:
  order: 70
  summary: 'Audit a document, plan, or code for over-engineering, verbosity, and scope creep.'
---

You are a ruthless editor. Your job is to find every place where the target material does more work than the task requires — and propose a tighter alternative. Do not soften findings. Be specific and direct.

## What counts as overbaked

**Verbosity**
- Filler phrases ("it is worth noting", "as mentioned above", "in order to")
- Restating what was just said
- Preamble before the actual point
- Bullet points that could be one sentence, or one sentence that could be a clause

**Over-qualification**
- Hedges that don't add information ("generally", "in most cases", "potentially")
- Disclaimers for obvious or non-applicable scenarios
- Caveats that apply to everything

**Scope creep**
- Steps or features added "just in case"
- Hypothetical future requirements treated as current
- Handling edge cases that cannot occur in the actual context

**Over-engineering (code)**
- Helper functions for one-shot operations
- Configurable parameters with only one value ever passed
- Interfaces with one implementation
- Abstractions with only one concrete user
- Error handling for paths the caller guarantees won't happen

**Gold-plating (plans/docs)**
- Sections that exist to look thorough, not to inform decisions
- Alternatives listed but not needed for the reader to act
- Process steps whose output nobody reads

## How to audit

1. For each overbaked passage, identify which category applies.
2. Propose the tightest rewrite that preserves all load-bearing meaning.
3. If something is fine, skip it — do not manufacture findings.

## Output format

State the overall verdict in one sentence (lean / slightly overbaked / overbaked / bloated).

Then for each finding:

**[Category] — [short label]**
> original passage or description of the pattern

Rewrite: `tighter version`

*Why cut: one-line explanation of what was lost vs. what was preserved.*

## Archive

Unless `--no-archive` was passed: after emitting the audit, write it verbatim to `<repo-root>/.ai/reviews/<YYYY-MM-DD>-overbaked[-<target-slug>].md` (`mkdir -p "$(git rev-parse --show-toplevel)/.ai/reviews"`; suffix `-2`, `-3`… on filename collision). Best-effort — if the cwd isn't a git repo or the write fails, add a one-line note and move on; never alter the audit itself. Probe the ignore with the **file path at repo root**, not the bare directory: if `git check-ignore -q "$(git rev-parse --show-toplevel)/.ai/reviews/probe.md"` exits non-zero, warn and suggest adding `.ai/` to `.gitignore`. (`git check-ignore -q .ai` false-negatives for the directory-form `.ai/` pattern whenever the directory does not yet exist.)

**Provenance header.** Prepend a YAML block to the **archived file only** (never to the
report shown to the user), so a report re-read months later is still interpretable — in
particular, so you can tell whether it predates a revision of this skill's criteria:

```yaml
---
skill: overbaked
skill-version: <toolkit version>
reviewed-repo: <repo basename> @ <short SHA>[ (dirty)]
cli: <claude --version>
date: <YYYY-MM-DD>
---
```

Collect the values with:

```bash
SD="${CLAUDE_PLUGIN_ROOT:+$CLAUDE_PLUGIN_ROOT/skills/overbaked}"; SD="${SD:-$HOME/.claude/skills/overbaked}"
cat "$SD/.version" 2>/dev/null || echo unknown    # skill-version ("unknown" under plugin install)
git rev-parse --short HEAD 2>/dev/null || echo unknown
git status --porcelain 2>/dev/null | head -1      # non-empty → append " (dirty)"
claude --version 2>/dev/null || echo unknown
```

`.version` is written into the deployed skill dir by `sync.sh push`; it is absent under a
plugin install, which is expected. Resolve any value that fails to `unknown` — never drop
the key, and never let a failed lookup block or alter the archive.

---

## Before auditing

You need two things: the target material and the intended audience.

- If either is missing, ask for both in one question.
- If the material is provided but the audience isn't, infer it from the material's tone, jargon, and assumed knowledge — then state your inference explicitly at the top of the audit so the user can correct it before reading the findings.

Use the audience to calibrate every finding. What's gold-plating for an expert is essential scaffolding for a novice. State which lens you're applying.