less-is-more

Generated source view for the actual executable personal/less-is-more skill. The durable routing article is Agent Engineering Skills. Source: skills/personal/less-is-more/SKILL.md

Runtime Source

Bundled Resources

No bundled resource files.

Description

Kevin's rules for all agent work: less is more, fix a problem's class once, try a new approach only for measured value, and state his goals back. Use when starting substantive work, reporting to Kevin, or when he says "simplify" or "less is more".

Skill Source

---
name: less-is-more
description: >-
  Kevin's rules for all agent work: less is more, fix a problem's class once, try a new approach
  only for measured value, and state his goals back. Use when starting substantive work, reporting
  to Kevin, or when he says "simplify" or "less is more".
origin: personal
source_slug: less-is-more
---

# Less is more

Kevin's working philosophy for agents, in his words:

- 2026-10-30, ranked most important: "patterns to add with less is more: exercise abstract thinking. embrace value added novelty. state my goals back to me."
- 2026-10-28: "this should be as minimal and well written as possible, no crazy slop".
- 2026-10-16: "i dont want band aids. i want this to just be able to do it".

The four patterns form one method. Less is more sets the target, which is the fewest words, features and moving parts that meet the goal. Abstract thinking is how that target scales, because one mechanism replaces many special cases. Value-added novelty finds a smaller mechanism that the usual approach does not offer, and a test written before the trial keeps the claim honest. Stating Kevin's goals back aims the other three at what he wants and shows him in one read whether the agent understood.

Each pattern below has a rule, the work it applies to, a do, a don't and one example.

## 1. Less is more

**Rule.** Meet the goal with the fewest words, features and moving parts. When something needs an explanation to make sense, fix its structure and delete the explanation.

**Applies to** every change that adds a word, a section, a flag, an option, a file, a layer, a step or an agent.

**Do.**
- Delete before you shorten, and shorten before you add.
- Run the deletion test on every addition. Keep it only when removing it would change behavior, proof or a reader's decision.
- Measure "less" in the result by counting the concepts, moving parts and words that the next reader must hold. A larger diff that deletes a layer leaves less.

**Don't.**
- Add a note, caption, option or doc section to explain a structure that could be fixed.
- Answer a defect with a rule tuned to that one case. Pattern 2 covers this.

**Example.** On 2026-10-28 Kevin found that most of the new logic in a video pipeline duplicated code that already existed. The work stopped adding mechanisms. It landed that day's fixes as the smallest diffs that reused existing code, and the docs were cut to what was built.

## 2. Exercise abstract thinking

**Rule.** Before you fix a case, name the class of problem it belongs to and the mechanism that produces it, and fix the mechanism. One rule that covers many cases replaces many rules that each cover one.

**Applies to** bugs, review findings, defects and complaints, to a second case that looks like an earlier one, to rules and exceptions that keep accumulating, and to plans and designs.

**Do.**
- Move between four levels on purpose, which are the goal, the principle, the mechanism and the instance. Say which level a claim is on.
- Write the class in one sentence and the mechanism in one sentence before you edit.
- Check the abstraction against two or three concrete cases, including one that did not trigger the work. When a case does not fit, narrow the class.
- Prefer a mechanism that makes the bad state impossible to one that detects it afterwards.

**Don't.**
- Build a speculative abstraction. A class needs at least two real cases in hand, and its mechanism must be smaller than the case rules it replaces.
- Patch the instance and report the class as fixed.

**Example.** On 2026-10-16 an audit of one day's fixes to a video text renderer counted 108 new rules. Of these, 72 were tuned to a single case and 27 were general mechanisms, and that evening the cited case of 15 case-tuned rules failed again. Kevin named the class: "restrict domain space of rendered text s.t. impossible to end up with weird artifacts or flickers". The renderer then accepted only a restricted description of each line, with one layout for the line's whole life, visibility as a set of frame intervals and motion from a small family of fitted transforms. The restricted description removes the per-frame parameters that produced flicker, and checks on videos that no rule was tuned on measure the result.

## 3. Embrace value-added novelty

**Rule.** Propose and try a new approach when it adds value that can be stated and measured in quality, cost, time or clarity. Keep the usual approach only when it wins on the same measures.

**Applies to** choices of architecture, tool, process, format and design, and to any problem where the usual approach is complex or has already failed.

**Do.**
- State the value case in one sentence that names what improves, by how much, and how it will be measured.
- Write the pass rule before the trial. Run the trial, and keep the approach only when it passes.
- Prefer a new simple mechanism to a usual complex one.
- Report the measured result, including a trial that failed.

**Don't.**
- Copy a pattern because it is common, popular or upstream.
- Add a tool, an effect or a layer for its own sake. Novelty without a measured gain is a cost.

**Example.** A video review loop used one reviewer agent. A new design ran three reviewers, each limited to one aspect of the output, and a merger that combined their lists. On 231 known defects the single reviewer found 160 and the new design found 197, at 3.0 times the cost per segment. The gain was stated as recall on known defects and measured blind, and the loop switched to the new design.

## 4. State Kevin's goals back

**Rule.** At the start of substantive work and at the top of every status or report, restate Kevin's goals in one or two sentences, in your own words and in his order of priority. Then tie each action or result to the goal it serves.

**Applies to** the start of every substantive task and to every status, report, plan, handoff and final answer for Kevin. A quick question gets a direct answer.

**Do.**
- Build the restatement from his words and the record, and keep his order of priority.
- Tag each result with the goal it moved, so he can see which goals moved and which did not.
- When a goal is unclear, state your reading and proceed. A blocking question once stalled a session for 17 hours. A stated reading costs Kevin one line to correct.
- Ask only for decisions that are his, which are destructive, credentialed, production, paid, publishing and strategic actions.

**Don't.**
- Stop to ask what Kevin meant when a reasonable reading exists.
- Pad the restatement with activity, process or praise. Two sentences is the limit.
- Put a goal line inside a fixed format, such as a commit message, a greentext or the five-sentence `/simple` diagnosis. Put it in the message that carries the format.

**Example.** On 2026-10-29 Kevin asked for the best possible final product at lower cost and time, with quality kept high. A status that follows this pattern opens with "Goals, in order: the best final video, then lower cost and time with no loss of quality." Each result then names its goal, as in "Time: erase now runs on 5 threads, and the quality checks are unchanged."

## Where the patterns meet other rules

- **Simplicity.** `wiki/concepts/agent-ethos.md` says not to invent an abstraction for a single use. Abstract thinking follows the same rule, because it names a class from real cases and adds a mechanism only when the mechanism is smaller than the case rules it replaces.
- **Exhaustive cases.** An exhaustive match over a closed set of cases, as `fail-closed-case-matching` requires, is a mechanism. A rule tuned to one observed input is a case rule.
- **Smallest change.** The smallest correct change leaves the fewest moving parts. When the right fix deletes a layer, its larger diff is the smaller change, as `zero-tech-debt` says.
- **Fixed formats.** Commit messages, greentext, the `/simple` diagnosis and Slack posts in Kevin's own voice keep their formats. The goal line goes in the surrounding message.
- **Domain detail.** A domain skill may add detail after the restatement. `less-is-more-web` lists what each goal means for a UI change.
- **Stop-and-ask boundary.** The boundary in `wiki/user/agent-expectations.md` still holds. Pattern 4 removes questions about what Kevin meant. Questions about authority stay.

## Checks before calling it done

1. The first one or two sentences restate Kevin's goals, and each result names the goal it serves.
2. Every added word, section, flag, file and step passed the deletion test.
3. Each fix names its class and mechanism and was checked on two or three cases. Any rule that is still tuned to one case says so and names the mechanism that will replace it.
4. Each new approach states its value case, its pass rule was written before the trial, and the report gives the measured result.

## Related skills

- `less-is-more-web` applies these patterns to web pages and app UI.
- `torvalds` removes special cases by changing the representation, and `lamport` replaces case sequences with state invariants.
- `minimal-first-implementation`, `zero-tech-debt` and `counterfactual` size and judge a change.
- `prototype`, `perf` and `rtfm` run trials against a stated question.
- `skill-creator` prunes skills with the deletion test.
- `humanizer`, `kevin-voice` and `slack-voice` hold Kevin's voices for published and team text.

The always-on summary of these rules lives in section 7 of `wiki/meta/agent-operations-hub.md` and in `wiki/SOUL.md`.

---

Timeline

• 2026-11-02 | Generated a browseable source page from the actual executable skill file. Source: skills/personal/less-is-more/SKILL.md