less

---
name: less
description: Removes elements without a clear reason to exist from writing, code, and UI code (HTML/CSS, JSX, Tailwind), keeping correctness, needed context, safety, accessibility, and everything the user asked for. Use when the user asks to cut, trim, remove, strip, simplify, tighten, shorten, or declutter something, says it is "too long", "too busy", or "looks cluttered", or asks to clean up AI-written output. Not for building or adding UI features, accessibility audits, or performance refactors.
license: MIT
---

# less

Less, but better. Keep only what has a reason to exist.

## The test

For each element (sentence, caveat, heading, bullet, comment, function,
parameter, option), ask: **Does this have a clear reason to exist?**
If not, remove it. Clarity beats brevity. When unsure, keep it.
Judge what a passage does in context, not whether it matches a stock phrase.
Read the surrounding text: a qualifier may govern later sentences.
Leave sentences and code regions outside confirmed removal targets unchanged;
allow only the local repairs needed by those removals.

## When

Only on request or a clear cue, not when merely writing a draft or new code.
Remove unnecessary material; allow only the local edits needed to keep the
result grammatical or executable (such as inlining a redundant helper). No
independent style or voice rewrites, translation, fixed-length summaries,
fact-checking, algorithm substitutions, or performance work.

## Don't apply

Return the input unchanged plus one line naming the reason for:
- Legal, contractual, or other verbatim text; quotations and transcripts.
- Code, config, or commands the user didn't point at.

Change only the code the user pointed at. A user-set length or format is not
an exclusion: work inside it.

## Removal order

Check every candidate against "Never remove" first, especially the user's own
greetings and closings.

Writing:
- W1. Preamble, restated question, and greetings you added ("Great question!").
- W2. Closing recaps and offers you added, or that end a PR description, commit,
  or doc ("Hope this helps", "Want me to...").
- W3. Hedges and filler that change nothing, including sentences that could
  appear unchanged in any other document.
- W4. Duplicate points (keep the clearest).
- W5. Unrequested caveats and alternatives that don't change what the reader does.
- W6. Decoration on answers under ~5 sentences: headers, bold, bullets. At any
  length: emoji and separator lines (`───`) you added, unless they mark status.
- W7. Merge and shorten the rest, keeping complete sentences: no arrows,
  fragments, or dropped articles. When editing the user's text, do not merge or
  rephrase sentences; only repair grammar directly affected by a deletion.

Code:
- S1. Comments that restate the code.
- S2. Unnecessary abstractions: helpers, wrappers, interfaces, factories.
  Single use alone is not evidence that an abstraction is unnecessary.
- S3. Unrequested options, flags, config.
- S4. Defensive code for cases that provably can't happen from the visible code.
  Otherwise keep it.
Keep the code you don't remove as written: don't inline its variables,
rename, or reformat.

Before removing code or options, inspect available callers, exports, and
relevant tests. Preserve externally used signatures and behavior unless the
user explicitly requests that change. Run relevant existing checks after code
edits; if usage or behavior cannot be established, keep the candidate.

Documents: apply the test section by section. Keep the structure readers
navigate by: headings, TOC and anchors, numbered steps referenced elsewhere,
tables that carry data. Remove a whole section only when it fails the test.
Keep every heading and its TOC entry unless the whole section is cut; never
merge a section into the intro.

Design: for UI code the user points at, apply the test to elements and
styles. Act only after checking [references/design.md](references/design.md)
(order and never-remove list), which also allows consolidating styles and
repairing layout that removals broke. Unrequested content there means what
the agent added, not what the user wrote. Change markup and styles only; no new
aesthetic. Not for building new UI, screenshots, or Figma files.

## Never remove

- M1. Correctness: numbers, units, dates, conditions, exceptions, negations.
- M2. Claim strength: uncertainty, approximation, scope, causal relationships, and
  obligation. Keep meaning-bearing qualifiers such as "about", "some", "at
  most", "may", and "must"; shortening must not strengthen or weaken a claim.
- M3. Needed context: what the reader needs to act (prerequisites, steps, versions).
- M4. Safety: data-loss, security, money, legal, irreversible-action warnings.
- M5. The user's ask: requested content, format, length, constraints.
- M6. Attribution and citations.
- M7. The user's voice when editing their text. Don't rewrite style.
- M8. In a message to people (email, chat, letter) the user wrote: greetings,
  sign-offs, and lines asking for a reply or questions ("Let me know if...").
  E.g. "Do reach out anytime if anything is still unclear." stays; you may trim
  "anytime" and "still". Only greetings and closings are protected: other
  filler in the user's text ("basically", "literally", "just") is still cut,
  keeping their voice.
- M9. Politeness register: 존댓말/敬語 forms, 様, greetings, sign-offs. Stacked
  softeners and intensifiers inside it (정말, 혹시, 大変, 誠に, 何卒) are
  candidates only: keep them when they carry uncertainty or social intent.
- M10. Code: behavior (output, side effects, errors); error handling at real
  boundaries (I/O, network, user input); "why" comments, constraints, safety
  notes; public API and signatures unless asked; type annotations that affect
  checking or runtime; test-only hooks and seams.
- M11. Anything whose purpose you can't determine.

## Stop

Stop when every element passes the test, or when the next cut would cost
meaning or require guessing. Compare the result with the source for changed
claim strength and unintended edits to good surrounding material.
Never cut to hit a length. If the user asked to
shorten their text, filler that fails the test goes; unchanged needs a reason.

## Output

The reduced text or code only, in the same format and language. Exception:
the one-line reason under Don't apply. Don't comment on what was cut unless
the user asks; then list it. If nothing should change, return it unchanged.

• SKILL.md 6 KB
• references/design.md 5 KB