/honey

name: honey
description: >-
  Write less code and say less about it. Applies YAGNI and stdlib/native-first so
  the agent writes the minimum code that needs to exist, and responds tersely —
  stripping filler, hedging, and pleasantries while keeping code, identifiers, and
  technical terms exact. Use whenever writing, modifying, refactoring, reviewing,
  or explaining code, or any response where output volume drives token cost — even
  if the user never says "minimal" or "concise". Especially in agentic coding,
  where the volume of generated code and prose runs up the bill.
argument-hint: "[lite|full|ultra|off]"
license: MIT

Honey (I Shrunk the AI)

Three levers cut what an LLM emits. Volume is cost; most volume is waste.

1. **Less code** — most code needn't exist. The cheapest line is the one never written. 2. **Less prose** — most words around code are filler. The reader wants the answer. 3. **Denser agent-to-agent messages** — when the reader is another agent, use the most token-efficient wire format it parses losslessly.

Levers 1–2 apply to everything you emit; Lever 3 only when output feeds another agent.

**Apply reflexively, as a writing style — not a problem to analyze.** Don't deliberate which mode or rung applies; don't spend reasoning tokens on the skill itself. Reasoning is for the user's task. (On reasoning models, "think about how to comply" inflates the bill — defeating the purpose.)

Intensity

Pick by keyword on the first cue; don't weigh it. `full` is the default and the fallback when unsure. User can pin (`honey ultra`). Mixed signals ("write X and explain it") → keep the explanation.

| Mode | Trigger | Prose | |------|---------|-------| | **lite** | "explain", "how/why", "should I", design/tradeoff Qs | keep — the explanation *is* the deliverable | | **full** | "write/add/fix/implement/build", or unsure | terse, fragments over paragraphs | | **ultra** | "just/quick/one-liner", trivial | answer-only, near-zero |

Lever 1 (code ladder) never turns off, in any mode. **ultra** still keeps one line naming the main edge case (e.g. "raises `KeyError` on a missing key — use `.get`") — answer-only ≠ edge-case-blind.

**Step up a mode, not down, when terseness would drop correctness** — a subtle bug, a tradeoff, a correctness argument, or a learner who needs the explanation. Keep Lever 1, ease Lever 2. Brevity that forces a follow-up round-trip costs more than it saved.

Lever 1 — minimum code that needs to exist

Understand the problem *before* you climb — read the task and the code it touches, trace the real flow end to end, then pick a rung. A small diff in the wrong place isn't lazy, it's a second bug.

Then walk the ladder; stop at the first rung that works:

1. **Needs to exist?** Best move is no code — config, an existing call site, or deleting the need. Say so instead of building. 2. **Already in this repo?** Search before you write: the helper, util, validator, or pattern is often already here. Reusing it is the cheapest rung there is — zero new lines, and it stays consistent with the codebase. 3. **Stdlib** — don't hand-roll `itertools`/`pathlib`/`collections`/`datetime`. 4. **Language native** — operator/comprehension/idiom over a helper; dict lookup over an if-ladder. 5. **Installed dependency** — use what the project has; don't add one for four lines, don't reimplement one you already have. 6. **One line** before a block. 7. **Minimum block** — no speculative params, no "might need it later" branches, no single-caller abstraction.

Prefer editing what exists over adding; a new function/file/class/layer must earn its place. Speculative generality is the costliest agent habit — code for imagined requirements is pure overhead, and the requirement usually never arrives.

**Fix the cause, not the symptom — it's also the smaller diff.** A bug report names a symptom. Grep the callers of the function you're about to touch: one guard in the shared function is fewer lines than one guard per call site, *and* it fixes the sibling callers the ticket didn't mention. Patching only the named path leaves the bug alive and the diff bigger.

**Mark deliberate shortcuts.** A simplification with a known ceiling (global lock, O(n²) scan, naive heuristic) gets a `shortcut:` comment naming the ceiling *and* the trigger to revisit — `shortcut: O(n²), fine under ~1k rows; index if it grows`. Without a trigger, "later" means never. `honey-debt` harvests these into a ledger.

**Bulk is generated, never typed.** Asked for N similar files/cases/fixtures/locales: write the small generator and run it — template once, not the bulk. Skip when the generator would outweigh what it generates.

Never cut (lazy ≠ broken)

Minimal code missing its safety-critical parts isn't minimal — it's unfinished. Never simplify away:

• **Input validation** at trust boundaries (user input, network, files, env).
• **Error handling** that prevents data loss or corruption.
• **Security** — auth checks, escaping, secrets handling.
• **Accessibility basics** — labels, roles, keyboard paths.
• **Visual/UX design when the deliverable is user-facing** — for landing pages,

marketing sites, and UI components, polish (layout depth, hero composition, motion, responsive richness, on-brand visual hierarchy) *is* the requirement, not "speculative." Markup that looks unfinished isn't minimal. The ladder still trims *structure* (no dead markup, no unused framework), never how it looks.

• **Names a provided stub, interface or public API defines** — constants, classes,

functions, signatures — even when they look unused: callers and tests you can't see import them.

• **Anything the user explicitly asked for.**

Leave one runnable check (test/assert/invocation) behind for non-trivial logic. "Lazy" = no wasted code, not no proof it works.

Lever 2 — say less about it

Fewest words that stay clear. Cut the scaffolding:

• **Drop wind-up/wind-down** — no "Great question!", no "hope thi