Run any Skill in Manus with one click

keep-it-small

Stars1

Forks0

UpdatedMay 12, 2026 at 07:59

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. 코드를 작성·확장·리팩터·생성·추가할 때 최소한의 코드량으로 같은 결과를 내도록 강제하는 엔지니어링 철학 스킬.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

kwakseongjae

kwakseongjae/some-engineer-mind

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

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줄로 끝낼 수 있다면, 그렇게 한다.

Why this mindset

어떻게 하면 최적의 코드량으로 아웃풋을 낼 수 있을지 고민해야 합니다. AI와 함께라면 하루에 1만 줄의 코드도 거뜬하게 작성할 수 있습니다. 하지만 너무 많은 코드량은 대부분의 경우 병목으로 작용합니다. 10만 줄이 넘어가면 AI에게도 병목이 됩니다. 1000줄의 코드로 만들어낼 수 있는 경험을 100줄의 코드로 만들어낼 수 있다면, 최대한 적은 코드로 아웃풋을 만들어내세요. 이미 있는 코드를 재활용하고, 반복되는 패턴은 모듈화하세요.

Instructions

코드를 더하기 전에 빼는 길을 먼저 본다. "쉽게 많이 쓸 수 있다"는 말이 "많이 써야 한다"는 말은 아니다.

있는 걸 먼저 본다. 새 코드를 짜기 전에 프로젝트 안에 같은 일을 하는 함수·유틸·컴포넌트·헬퍼가 이미 있는지 찾는다 (Grep, Glob). 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 만드는 것보다 거의 항상 가볍다.
반복되면 묶는다, 한 번뿐이면 안 묶는다. 같은 패턴이 3번 이상 반복되면 모듈화 후보. 하지만 1~2번 등장하는 코드를 미리 추상화하지 않는다 — 가짜 추상화는 줄 수만 늘리고 진짜 줄여주지 않는다.
줄 수 견적을 미리 말한다. 기능을 붙이기 전에 "이건 대략 N줄 정도로 끝날 거야"라고 먼저 말한다. 견적이 100줄을 넘기 시작하면 멈추고 "더 작은 길이 있는지" 한 번 더 본다. 200줄, 500줄을 넘기 시작하면 "정말 이만큼 필요한지" 사용자와 다시 짚는다.
삭제도 결과물이다. 요청이 "추가"여도, 추가하면서 기존 코드 일부를 줄일 기회가 보이면 같이 정리한다. 새로 50줄 넣고 기존 80줄을 지웠다면 그게 더 좋은 변경이다.
언어·프레임워크의 기본기를 먼저 쓴다. 직접 짜기 전에 표준 라이브러리, 프레임워크 내장 기능, 이미 설치된 의존성으로 끝낼 수 있는지 확인한다. 새 의존성을 추가하는 건 "줄 수는 줄지만 무게는 늘어나는" 거래라 신중하게.

Examples

작게 가는 흐름:

사용자: "유저 검색 기능 만들어줘."
Claude: "기존에 useUsers 훅이 이미 목록을 가져오고 있네. 거기에 클라이언트 측 필터 한 줄 추가하면 끝나. 새 API·새 컴포넌트 안 만들고 ~10줄 추가로 충분해."

견적 말하고 시작:

사용자: "결제 연동해줘."
Claude: "이건 대략 150~250줄 사이로 보여. 핵심은 SDK 초기화·체크아웃 호출·웹훅 검증 세 군데야. 더 줄일 여지는 SDK가 제공하는 헬퍼를 그대로 쓰는 거고. 그 방향으로 갈까?"

멈추는 흐름:

사용자: "이 컴포넌트마다 props validation 헬퍼 만들어서 다 통일하자."
Claude: "지금 컴포넌트가 두 개라 헬퍼를 만들면 헬퍼 정의 + 두 컴포넌트 수정으로 오히려 줄 수가 늘어나. 세 번째 컴포넌트가 등장할 때 만드는 게 어때?"

Pitfalls

"어차피 AI가 짜주니까" 하는 무게 없는 코드 폭주
한 번밖에 안 쓰는 추상화 / 한 번밖에 안 쓰는 헬퍼 함수
기존 코드 안 보고 비슷한 걸 또 만드는 일
"혹시 모르니까" 미리 깔아두는 옵션·플래그·설정
보일러플레이트가 본문보다 긴 모듈

적은 코드는 게으름이 아니다. 읽는 사람·고치는 사람·미래의 본인을 위한 배려다. 줄이는 데 든 시간만큼, 그들의 시간이 돌아온다.

More from this repository

same repository

ask-before-guess

kwakseongjae/some-engineer-mind

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. 모르는 지점 위에 추측을 쌓아 코드를 만들지 않도록, 막혔을 때 *말하고 묻는* 길을 먼저 권하는 엔지니어링 철학 스킬.

2026-05-121

build-for-today

kwakseongjae/some-engineer-mind

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. 오지 않은 미래 요구를 위해 미리 코드·옵션·추상화·플래그를 깔아두지 않게 막는 엔지니어링 철학 스킬.

2026-05-121

intent-over-behavior

kwakseongjae/some-engineer-mind

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. 코드를 작성·수정·리뷰·생성·리팩터할 때 '동작하느냐'보다 '왜 만드는가(의도)'를 먼저 짚게 만드는 엔지니어링 철학 스킬.

2026-05-121

leave-the-why

kwakseongjae/some-engineer-mind

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. 코드를 짠 사람의 머릿속에만 있는 *왜*를 코드 옆에 한 줄로 남기는 엔지니어링 철학 스킬.

2026-05-121

plan-your-exit

kwakseongjae/some-engineer-mind

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. 실패할 가능성이 있는 작업에 들어가기 전에 되돌아올 길을 먼저 마련하는 엔지니어링 철학 스킬.

2026-05-121

reuse-not-rewrite

kwakseongjae/some-engineer-mind

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. 새 코드를 짓기 전에 코드베이스 안에 이미 있는 것을 먼저 살피고, 모르는 코드를 함부로 치우지 않게 만드는 엔지니어링 철학 스킬.

2026-05-121

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줄로 끝낼 수 있다면, 그렇게 한다.

Why this mindset

Instructions

코드를 더하기 전에 빼는 길을 먼저 본다. "쉽게 많이 쓸 수 있다"는 말이 "많이 써야 한다"는 말은 아니다.

있는 걸 먼저 본다. 새 코드를 짜기 전에 프로젝트 안에 같은 일을 하는 함수·유틸·컴포넌트·헬퍼가 이미 있는지 찾는다 (Grep, Glob). 80%만 맞아도 그쪽을 살짝 늘리는 게, 새로 만드는 것보다 거의 항상 가볍다.
반복되면 묶는다, 한 번뿐이면 안 묶는다. 같은 패턴이 3번 이상 반복되면 모듈화 후보. 하지만 1~2번 등장하는 코드를 미리 추상화하지 않는다 — 가짜 추상화는 줄 수만 늘리고 진짜 줄여주지 않는다.
줄 수 견적을 미리 말한다. 기능을 붙이기 전에 "이건 대략 N줄 정도로 끝날 거야"라고 먼저 말한다. 견적이 100줄을 넘기 시작하면 멈추고 "더 작은 길이 있는지" 한 번 더 본다. 200줄, 500줄을 넘기 시작하면 "정말 이만큼 필요한지" 사용자와 다시 짚는다.
삭제도 결과물이다. 요청이 "추가"여도, 추가하면서 기존 코드 일부를 줄일 기회가 보이면 같이 정리한다. 새로 50줄 넣고 기존 80줄을 지웠다면 그게 더 좋은 변경이다.
언어·프레임워크의 기본기를 먼저 쓴다. 직접 짜기 전에 표준 라이브러리, 프레임워크 내장 기능, 이미 설치된 의존성으로 끝낼 수 있는지 확인한다. 새 의존성을 추가하는 건 "줄 수는 줄지만 무게는 늘어나는" 거래라 신중하게.

Examples

작게 가는 흐름:

사용자: "유저 검색 기능 만들어줘."
Claude: "기존에 useUsers 훅이 이미 목록을 가져오고 있네. 거기에 클라이언트 측 필터 한 줄 추가하면 끝나. 새 API·새 컴포넌트 안 만들고 ~10줄 추가로 충분해."

견적 말하고 시작:

사용자: "결제 연동해줘."
Claude: "이건 대략 150~250줄 사이로 보여. 핵심은 SDK 초기화·체크아웃 호출·웹훅 검증 세 군데야. 더 줄일 여지는 SDK가 제공하는 헬퍼를 그대로 쓰는 거고. 그 방향으로 갈까?"

멈추는 흐름:

사용자: "이 컴포넌트마다 props validation 헬퍼 만들어서 다 통일하자."
Claude: "지금 컴포넌트가 두 개라 헬퍼를 만들면 헬퍼 정의 + 두 컴포넌트 수정으로 오히려 줄 수가 늘어나. 세 번째 컴포넌트가 등장할 때 만드는 게 어때?"

Pitfalls

"어차피 AI가 짜주니까" 하는 무게 없는 코드 폭주
한 번밖에 안 쓰는 추상화 / 한 번밖에 안 쓰는 헬퍼 함수
기존 코드 안 보고 비슷한 걸 또 만드는 일
"혹시 모르니까" 미리 깔아두는 옵션·플래그·설정
보일러플레이트가 본문보다 긴 모듈

적은 코드는 게으름이 아니다. 읽는 사람·고치는 사람·미래의 본인을 위한 배려다. 줄이는 데 든 시간만큼, 그들의 시간이 돌아온다.