Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/int2t05/engineering-skills/simplifynpx skills add int2t05/engineering-skills --skill simplifygit clone --depth 1 https://github.com/int2t05/engineering-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/int2t05/engineering-skills/simplify)<a href="https://agentmods.dev/skills/int2t05/engineering-skills/simplify"><img src="https://agentmods.dev/badge/skills/int2t05/engineering-skills/simplify.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00090 | $0.01382 |
| Opus 5 | $0.00045 | $0.00691 |
| Sonnet 5 | $0.00018 | $0.00276 |
| Haiku 4.5 | $0.00009 | $0.00138 |
Grade A, and why
simplify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 83 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Simplification
Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines — it's code that is easier to read, understand, modify, and debug. Every simplification must pass one test: "Would a new team member understand this faster than the original?"
When to use
- After a feature works and tests pass, but the implementation feels heavier than it needs to be
- During code review when readability or complexity issues are flagged
- When you encounter deeply nested logic, long functions, or unclear names
- After merging changes that introduced duplication or inconsistency
- Triggers on "simplify", "too complex", "refactor for clarity"
Not for: code you don't fully understand yet — comprehend before you simplify. Performance-critical code where the "simpler" version would be measurably slower. Throwaway code about to be rewritten entirely. Cross-module structural changes — extracting/moving modules, redrawing dependency boundaries, splitting or merging files → use refactoring. Designing where a seam or deep module should go (producing an audit, not executing) → use codebase-design. Single-file clarity stays here: naming, nesting, dead code.
Steps
1. Understand before touching (Chesterton's Fence)
Before changing or removing anything, understand why it exists. If you see a fence across a road and don't understand why it's there, don't tear it down.
- What is this code's responsibility? What calls it, what does it call?
- What are the edge cases and error paths? Are there tests defining expected behavior?
- Why might it have been written this way — performance? platform constraint? historical reason? Check
git blamefor the original context.
If you can't answer these, you're not ready. Read more context first.
2. Identify simplification opportunities
Scan for concrete signals — each is a specific pattern, not a vague smell. The full tables (structural complexity, naming, redundancy) with examples are in references/opportunities.md. Summary:
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 83 lines · 90 tokens per session scan A ee4e9eb1e983
simplify is a skill published in the GitHub repository int2t05/engineering-skills (3 stars, last pushed 15d ago), licensed MIT. It adds 90 tokens to every session and 1,382 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
writing-skills
Use when creating new skills, editing existing skills, or verifying skills work before deployment.
finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation.
writing-plans
Use when you have a spec or requirements for a multi-step task, before touching code.