heyeuca/less

What does less do?

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:

1. Preamble, restated question, and greetings you added ("Great question!").
2. Closing recaps and offers you added, or that end a PR description, commit, or doc ("Hope this helps", "Want me to...").
3. Hedges and filler that change nothing.
4. Duplicate points (keep the clearest).
5. Unrequested caveats and alternatives that don't change what the reader does.
6. Decoration on answers under ~5 sentences: headers, bold, bullets.
7. Merge and shorten the rest, keeping complete sentences. When editing the user's text, do not merge or rephrase sentences; only repair grammar directly affected by a deletion.

Code:

1. Comments that restate the code.
2. Unnecessary abstractions: helpers, wrappers, interfaces, factories. Single use alone is not evidence that an abstraction is unnecessary.
3. Unrequested options, flags, config.
4. Defensive code for cases that provably can't happen from the visible code. Otherwise keep it.

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. Remove only after checking references/design.md (removal order and never-remove list). 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

• Correctness: numbers, units, dates, conditions, exceptions, negations.
• 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.
• Needed context: what the reader needs to act (prerequisites, steps, versions).
• Safety: data-loss, security, money, legal, irreversible-action warnings.
• The user's ask: requested content, format, length, constraints.
• Attribution and citations.
• The user's voice when editing their text. Don't rewrite style.
• 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.
• Politeness register: 존댓말/敬語 forms, 様, greetings, sign-offs. Stacked softeners and intensifiers inside it (정말, 혹시, 大変, 誠に, 何卒) are candidates only: keep them when they carry uncertainty or social intent.
• 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.
• 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.