Agent skill
code-simpler
코드 단순화, 복잡도 감소, 심플리파이, 가독성, KISS, 중첩 제거 - Simplifies overly complex code by reducing nesting, cyclomatic complexity, and unnecessary abstractions. Use when code exceeds complexity limits (nesting >3, function >50 lines) or after insight/review reports flag complexity. Do NOT use for full code reviews (use code-reviewer) or dead code removal (use refactor-cleaner).
Install this agent skill to your Project
npx add-skill https://github.com/aimskr/aims-claude-toolkit/tree/main/skills/code-simpler
Metadata
Additional technical details for this skill
- author
- jaehashin
- version
- 1.2.0
SKILL.md
Code Simpler - Complexity Reducer
Simplify overly complex code while preserving correctness.
When to Use
- Insight 리포트에서 복잡도 지적이 나왔을 때
- 중첩이 깊은 코드 (3단계 이상)
- 함수가 50줄을 초과할 때
- 불필요한 추상화가 감지될 때
- 조건문이 과도하게 복잡할 때
Simplification Techniques
1. Early Return (Guard Clause)
// Before: deeply nested
function process(data) {
if (data) {
if (data.isValid) {
if (data.items.length > 0) {
// actual logic
}
}
}
}
// After: flat
function process(data) {
if (!data) return;
if (!data.isValid) return;
if (data.items.length === 0) return;
// actual logic
}
2. Extract Method (Long Functions)
Split when a function does more than one thing:
- Each function = one responsibility
- Name describes WHAT, not HOW
- Max 50 lines per function
3. Remove Unnecessary Abstraction
// Before: premature abstraction
class UserValidatorFactory {
create(type) { return new UserValidator(type); }
}
// After: direct usage (if only one validator exists)
function validateUser(user) { ... }
4. Simplify Conditionals
// Before: complex boolean
if (user.age >= 18 && user.hasLicense && !user.isBanned && user.country === 'KR')
// After: named condition
const canDrive = user.age >= 18 && user.hasLicense && !user.isBanned;
const isKorean = user.country === 'KR';
if (canDrive && isKorean)
5. Replace Loop with Declarative
// Before: imperative
const results = [];
for (const item of items) {
if (item.active) {
results.push(item.name);
}
}
// After: declarative
const results = items.filter(i => i.active).map(i => i.name);
6. Flatten Callback Hell
Replace nested callbacks/promises with async/await or pipeline.
Process
1. Identify complexity (insight report or manual scan)
↓
2. Measure: nesting depth, function length, cyclomatic complexity
↓
3. Apply simplification technique (one at a time)
↓
4. Verify: behavior unchanged, tests still pass
↓
5. Repeat until within limits
Complexity Limits
| Metric | Limit | Action |
|---|---|---|
| Nesting depth | 3 levels | Apply early return |
| Function length | 50 lines | Extract method |
| Cyclomatic complexity | 10 | Split into smaller functions |
| File length | 200 lines | Split into modules |
| Parameters | 4 | Use object parameter |
Principles
- One change at a time - simplify incrementally
- Preserve behavior - never change what the code does
- Verify with tests - run tests after each simplification
- Don't over-simplify - 3 similar lines > premature abstraction
- KISS - the simplest correct solution is the best
문서화 (작업 완료 후 자동 실행)
작업 완료 시 auto-documenter를 호출하여 프로젝트 문서를 업데이트한다.
Completion
모든 복잡도 지표가 한도 이내이고 테스트가 통과하면 완료.
Troubleshooting
Simplification breaks tests: Revert immediately. The simplification changed behavior, not just structure. Re-analyze before retrying. Unclear if abstraction is "unnecessary": Check usage count. If used once → likely unnecessary. If used 3+ times → keep it. Team disagrees on complexity threshold: Defer to project’s existing conventions. If none exist, propose thresholds and get team consensus before applying.
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
build-error-resolver
빌드 에러, 빌드 오류, 컴파일 에러, 빌드 실패 해결, 의존성 에러 - Specialized in resolving build errors, compilation failures, and dependency issues. Use when build fails, compilation errors occur, or dependency conflicts arise. Do NOT use for runtime bugs or logic errors (use debug-specialist instead).
brainstorming
브레인스토밍, 아이디어, 기획, 구상, 아이디어회의, 설계, 요구사항 분석, 접근법 탐색 - Use before creating new features or significant changes to explore user intent, requirements, and design options. Collaborative brainstorming through step-by-step questioning. Do NOT use for simple bug fixes, config changes, or tasks with clear requirements already defined.
doc-coauthoring
문서 작성, 문서화, 문서, 스펙 작성, 기술 문서, 제안서, RFC, 설계 문서, 의사결정 문서 - Collaborative document co-authoring through 3 stages: context gathering, iterative refinement, and reader testing. Use when writing docs, proposals, tech specs, decision docs, or RFCs. Do NOT use for PRD/product requirements (use prd-strategist) or implementation plans (use writing-plans).
testing-strategy
테스트 전략, 테스팅 계획, QA 전략, 품질 보증, 테스트 피라미드, 테스트 시나리오, 커버리지 목표 - Designs test strategies including test pyramid ratios, scenario categories, and coverage targets. Use when planning how to test a feature, designing QA approach, or creating test plans. Do NOT use for TDD implementation (use tdd-workflow) or E2E test execution (use e2e-runner).
learning-research
학습 리서치, 학습 자료, 공부 자료, 학습, 공부, 스터디, 개념 정리, 이해 - 특정 주제를 깊이 이해하기 위한 학습 자료를 수집·정리한다. 병렬 전문가 서브에이전트로 개념, 원리, 실습, 심화 자료를 수집하고 이해도별로 체계화된 학습 노트를 생성한다. Obsidian vault에 자동 저장. 의사결정용 자료 조사는 research 스킬을, 시장조사는 market-research 스킬을 사용할 것.
devil-advocate
Didn't find tool you were looking for?