simplify
Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.
Best use case
simplify is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.
Teams using simplify should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/simplify/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How simplify Compares
| Feature / Agent | simplify | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Simplify recently changed code — inline one-off abstractions, remove speculative code, reduce nesting, replace cleverness with clarity. Run after implementing a feature.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Simplify Post-implementation simplification pass. Review recently changed code and actively simplify it while preserving all behavior. The best code is code you don't have to write. The second best is code anyone can read. ## Available skills and subagents - **`verify` subagent** — Run after simplifications to ensure all tests, lints, and typechecks still pass. ## Steps ### 1. Identify what to simplify Run `git diff --name-only` (or `git diff origin/<base>...HEAD --name-only` for a branch) to get the changed files. Read each one. ### 2. Apply simplifications Work through each changed file. For each simplification, verify tests still pass before moving on. **Inline one-off abstractions:** - Helper functions with a single call site — inline them - Wrapper types that add no behavior — remove the wrapper - Interfaces with a single implementation and no test mock — remove the interface **Remove speculative code:** - Unused function parameters or return values - Config options that are parsed but never read - "Reserved for future" scaffolding, empty extension points - Feature flags with no toggle mechanism **Reduce nesting:** - Replace nested if/else with early returns (guard clauses) - Replace nested ternaries with if/else or switch - Extract deeply nested blocks into named functions **Replace cleverness with clarity:** - Dense one-liners that hide intent — expand to readable multi-line - Overly generic code where a concrete implementation is simpler - Abstractions that add indirection without reducing duplication **Remove noise:** - Comments that restate code (`// increment counter` above `counter++`) - Redundant type annotations where inference works - Empty error handlers, unused catch variables - Leftover debug logging ### 3. Verify Delegate to the **`verify` sub-agent** to ensure all tests, lints, and typechecks still pass. If anything breaks, the simplification changed behavior — revert it. ### 4. Summary Report what was simplified: - Files modified - What was removed/inlined/simplified - Lines removed (net)
Related Skills
verify
Run format, typecheck, test, and lint across the monorepo. Use after implementing changes.
tdd
Implement changes using Test-Driven Development (Red-Green-Refactor). Use for bug fixes, new features, or any code change that should have test coverage.
spec
Write a feature spec — the "what & why" of a kandev product feature, before coding. Use when the user says "let's spec X" or starts a new product feature.
record
Record an architectural decision (ADR) or save an implementation plan. Use after making significant design choices or completing features.
qa
Verify a feature works after implementation. Actively try to break it — edge cases, error paths, integration wiring, and real usage flows.
push
Commit and push to the current branch. Use --fixup to also wait for CI/CodeRabbit and fix issues.
pr
Commit, push, and create a PR. Default is ready-for-review with auto-fixup. Use --draft to skip review/fixup.
pr-fixup
Wait for CI checks and automated reviews (CodeRabbit, Greptile, Claude) on a PR, fix failures and address comments, then push.
playwright-cli
Automate browser interactions, test web pages and work with Playwright tests.
fix
Fix bugs and issues — reproduce, find root cause, minimal fix with regression test. Use when something is broken.
feature
Guided feature development — brainstorm, explore codebase, design architecture, implement with TDD, and review. Use for new features or significant changes.
e2e
Write and run web E2E tests (Playwright) using TDD — locations, patterns, commands, and debugging.