agentleFS
epicsagasepicsagas/epic-harness/skills/simplify/SKILL.md

simplify

Skill20 starsChanged 2 months agoApache-2.0View on GitHub

Code simplification for high-complexity files. Targets deep nesting, copy-paste patterns, and god functions.

119 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use codex-system, design-tracker and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • gaebalaiSkill

    codex-system

    PROACTIVELY consult Codex CLI, your highly capable supporter with exceptional reasoning and task completion abilities. Codex is a trusted expert you should ALWAYS consult BEFORE making decisions on: design choices, implementation approaches, debugging strategies, refactoring plans, or any non-trivial problem. When uncertain, consult Codex. Don't hesitate - Codex provides better analysis. Explicit triggers: "think deeper", "analyze", "second opinion", "consult codex".

    Also in 3 projects that use this

  • gaebalaiSkill

    design-tracker

    PROACTIVELY track and document project design decisions without being asked. Activate automatically when detecting architecture discussions, implementation decisions, pattern choices, library selections, or any technical decisions. Also use when user explicitly says "記録して", "設計どうなってる", "record this". Do NOT wait for user to ask - record important decisions immediately.

    Also in 3 projects that use this

  • mike22890Skill

    clonedeps

    将项目依赖的第三方库源码克隆到本地,便于深入阅读和调试。当需要查看库的实现细节、阅读源码、调试第三方依赖、理解 SDK/framework 内部机制、查看 node_modules 之外的原始代码、分析开源库架构、学习他人代码、查看依赖的 TypeScript 类型定义时使用。

    Also in 3 projects that use this

  • mdrubelamin2Skill

    verification-planning

    Plans how to prove a change works or broke nothing: frames the claim, designs an evidence path from the system itself, and requires every check to be able to fail.

    Also in 3 projects that use this

  • devbrother2024Skill

    artifact-design

    단독 self-contained HTML 산출물(랜딩 페이지, 정적 문서·리포트, 독립 대시보드, 데모·게임, 개발 전 UX/UI 대안 비교 목업)을 만들 때 팔레트·타이포그래피·레이아웃을 의도적으로 설계하고 템플릿·AI스러운 디자인을 피하도록 돕는 디자인 가이드. HTML/CSS를 쓰기 전에 로드한다. "랜딩 만들어줘", "이 내용 단일 HTML로 예쁘게", "UX 대안 HTML로 비교해줘", "디자인 잡아줘"처럼 단독 HTML 아티팩트를 만들거나 비교하는 요청에 활성화하고, 기존 앱(React·Vue 등)의 인앱 컴포넌트 수정이나 순수 백엔드·로직 작업에는 쓰지 않는다.

    Also in 3 projects that use this

  • codebycoreySkill

    batch

    Create multiple proposals from free-form feature descriptions. Use when planning several features at once, batch creating proposals, or setting up related changes.

    Also in 4 projects that use this

  • +3 more from gaebalai

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 6 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 111 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Remove dead code (unused imports, unreachable branches)

    line 38
  2. Distinctive:

    Why: Every line of code is a line someone must read, understand, and maintain.

    line 42
  3. Distinctive:

    All tests still pass after simplification

    line 45
  4. Distinctive:

    No behavior changes — only structural improvements

    line 46
  5. Distinctive:

    Never simplify and add features in the same change

    line 52
  6. Distinctive:

    Before claiming simplification is done, show ALL of these:

    line 64

“Common” is measured: kept by at least 6 in 10 of the 111 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Simplify — Code Simplification

When to Trigger

  • File exceeds 500 lines
  • Function exceeds 40 lines or nesting exceeds 3 levels of control flow
  • Repeated copy-paste blocks (same shape, 2+ sites)
  • "This is getting hard to follow" feeling

Process

1. Measure

  • Line count, function count, nesting depth
  • Identify the longest/most complex function

Why: You cannot improve what you cannot quantify. Baseline metrics prove simplification actually happened and prevent subjective "it feels cleaner" claims.

2. Extract

  • Extract function: Turn a code block into a named function
  • Extract constant: Replace magic numbers/strings
  • Extract module: Split large files by responsibility

Why: Named abstractions replace "what does this block do?" with "what does this function promise?" — reducing cognitive load per reading unit.

3. Rename

  • Variables: describe what it holds, not how it's computed
  • Functions: describe what it does, not how
  • Files: match the primary export/class

Why: Precise names eliminate the need for comments and make wrong code look wrong. A reader should understand intent from names alone.

4. Reduce

  • Remove dead code (unused imports, unreachable branches)
  • Replace imperative loops with declarative (map, filter, reduce)
  • Merge duplicate logic into shared utility

Why: Every line of code is a line someone must read, understand, and maintain. Fewer lines with the same behavior means lower lifetime cost.

5. Verify

  • All tests still pass after simplification
  • No behavior changes — only structural improvements

Why: Simplification that breaks behavior is not simplification — it is a regression. Tests are the safety net that makes structural changes safe.

Constraints

  • One simplification at a time — verify between each
  • Never simplify and add features in the same change

Anti-Rationalization

ExcuseRebuttalWhat to do instead
"We might need this later"YAGNI. Code you don't need is code you maintain for free. Add it when you need it.Delete it. When the need arises, write it with current context — not stale assumptions.
"This abstraction makes it more flexible"Flexibility without a concrete use case is complexity. Simple code is flexible code.Abstract only after you see the second use case. Two concrete examples beat one imagined future.
"It's already working, don't touch it"Chesterton's Fence: understand why it exists first. But if it's needlessly complex, simplify it.Understand it, write tests for it, then simplify it. Working code that nobody can read is a ticking bomb.

Evidence Required

Before claiming simplification is done, show ALL of these:

  • Before/after metrics: line count, function count, or nesting depth reduced
  • All tests pass after change (show output)
  • No behavior change: same inputs produce same outputs
  • Each extraction is independently justified (not "because it felt cleaner")

"I cleaned it up" without metrics = opinion, not simplification.

Red Flags

  • Simplifying code you don't understand
  • Over-abstracting (3 files for a 10-line utility)
  • Mixing simplification with feature additions

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.