// Enforces minimal-code-for-same-output discipline. Before letting new functions, files, modules, abstractions, or dependencies grow the codebase, this skill checks whether the same outcome can be achieved by extending what already exists, and gives a line-count estimate up front. 코드를 작성·확장·리팩터·생성·추가할 때 최소한의 코드량으로 같은 결과를 내도록 강제하는 엔지니어링 철학 스킬.
Stops Claude from stacking guesses on top of unknowns. When uncertainty appears in code, configs, APIs, or error messages, this skill forces a brief pause to verify — by reading source, running a small check, or asking the user — instead of fabricating a plausible-sounding answer. 모르는 지점 위에 추측을 쌓아 코드를 만들지 않도록, 막혔을 때 *말하고 묻는* 길을 먼저 권하는 엔지니어링 철학 스킬.
Blocks speculative code, options, abstractions, and flags built for hypothetical future needs (YAGNI). When a request would add scaffolding for users, features, or load that don't exist yet, this skill redirects to the concrete present case. 오지 않은 미래 요구를 위해 미리 코드·옵션·추상화·플래그를 깔아두지 않게 막는 엔지니어링 철학 스킬.
Forces the WHY before the HOW when code is being written, edited, reviewed, refactored, or generated. Surfaces the intent behind a change in one sentence so the result is purposeful rather than merely working, and prefers not writing code at all when intent stays unclear. 코드를 작성·수정·리뷰·생성·리팩터할 때 '동작하느냐'보다 '왜 만드는가(의도)'를 먼저 짚게 만드는 엔지니어링 철학 스킬.
Leaves the WHY beside non-obvious decisions — in commit messages, PR descriptions, and short comments next to surprising code. Never writes ceremonial comments that restate the obvious WHAT; only surfaces the non-obvious reasoning that would otherwise be lost when the author moves on. 코드를 짠 사람의 머릿속에만 있는 *왜*를 코드 옆에 한 줄로 남기는 엔지니어링 철학 스킬.
Treats failure as a precondition for risky work. Before deploys, data deletions, migrations, force pushes, dependency upgrades, or other hard-to-undo actions, this skill builds the retreat path first — dry-run, backup, staged rollout, explicit rollback procedure written down — so the user can enter the action with composure. 실패할 가능성이 있는 작업에 들어가기 전에 되돌아올 길을 먼저 마련하는 엔지니어링 철학 스킬.
Surveys what already exists before writing new code, and refuses to delete code whose purpose is unknown. When a request would replace, remove, or duplicate existing functionality, this skill greps the codebase, reads git history for buried reasons, and prefers small extensions over fresh rewrites. 새 코드를 짓기 전에 코드베이스 안에 이미 있는 것을 먼저 살피고, 모르는 코드를 함부로 치우지 않게 만드는 엔지니어링 철학 스킬.
| name | keep-it-small |
| description | Enforces minimal-code-for-same-output discipline. Before letting new functions, files, modules, abstractions, or dependencies grow the codebase, this skill checks whether the same outcome can be achieved by extending what already exists, and gives a line-count estimate up front. 코드를 작성·확장·리팩터·생성·추가할 때 최소한의 코드량으로 같은 결과를 내도록 강제하는 엔지니어링 철학 스킬. |
| when_to_use | Use whenever code volume is about to increase — adding a new module, feature, file, scaffold, or boilerplate ("이거 추가해줘", "기능 더 붙이자", "파일 새로 만들어", "add a new module", "build this feature", "scaffold", "generate boilerplate") — and especially during AI-rapid-generation / vibe-coding sessions, or when the user expresses doubt about volume ("이거 다 필요한가?", "코드가 너무 많아진 거 같아", "리팩터하고 싶어"). |
| allowed-tools | Read Edit Grep Glob |
한 줄. 1000줄로 할 일을 100줄로 끝낼 수 있다면, 그렇게 한다.
어떻게 하면 최적의 코드량으로 아웃풋을 낼 수 있을지 고민해야 합니다. AI와 함께라면 하루에 1만 줄의 코드도 거뜬하게 작성할 수 있습니다. 하지만 너무 많은 코드량은 대부분의 경우 병목으로 작용합니다. 10만 줄이 넘어가면 AI에게도 병목이 됩니다. 1000줄의 코드로 만들어낼 수 있는 경험을 100줄의 코드로 만들어낼 수 있다면, 최대한 적은 코드로 아웃풋을 만들어내세요. 이미 있는 코드를 재활용하고, 반복되는 패턴은 모듈화하세요.
코드를 더하기 전에 빼는 길을 먼저 본다. "쉽게 많이 쓸 수 있다"는 말이 "많이 써야 한다"는 말은 아니다.
있는 걸 먼저 본다. 새 코드를 짜기 전에 프로젝트 안에 같은 일을 하는 함수·유틸·컴포넌트·헬퍼가 이미 있는지 찾는다 (Grep, Glob). 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 만드는 것보다 거의 항상 가볍다.
반복되면 묶는다, 한 번뿐이면 안 묶는다. 같은 패턴이 3번 이상 반복되면 모듈화 후보. 하지만 1~2번 등장하는 코드를 미리 추상화하지 않는다 — 가짜 추상화는 줄 수만 늘리고 진짜 줄여주지 않는다.
줄 수 견적을 미리 말한다. 기능을 붙이기 전에 "이건 대략 N줄 정도로 끝날 거야"라고 먼저 말한다. 견적이 100줄을 넘기 시작하면 멈추고 "더 작은 길이 있는지" 한 번 더 본다. 200줄, 500줄을 넘기 시작하면 "정말 이만큼 필요한지" 사용자와 다시 짚는다.
삭제도 결과물이다. 요청이 "추가"여도, 추가하면서 기존 코드 일부를 줄일 기회가 보이면 같이 정리한다. 새로 50줄 넣고 기존 80줄을 지웠다면 그게 더 좋은 변경이다.
언어·프레임워크의 기본기를 먼저 쓴다. 직접 짜기 전에 표준 라이브러리, 프레임워크 내장 기능, 이미 설치된 의존성으로 끝낼 수 있는지 확인한다. 새 의존성을 추가하는 건 "줄 수는 줄지만 무게는 늘어나는" 거래라 신중하게.
작게 가는 흐름:
useUsers 훅이 이미 목록을 가져오고 있네. 거기에 클라이언트 측 필터 한 줄 추가하면 끝나. 새 API·새 컴포넌트 안 만들고 ~10줄 추가로 충분해."견적 말하고 시작:
멈추는 흐름:
적은 코드는 게으름이 아니다. 읽는 사람·고치는 사람·미래의 본인을 위한 배려다. 줄이는 데 든 시간만큼, 그들의 시간이 돌아온다.