// Forces reproduction before any fix. When something doesn't work, this skill stops the symptom→guess→patch loop and first reproduces the bug locally on the same branch, data, and inputs the user saw — because an unreproduced bug is an unsolved one. 버그·이상 동작 앞에서 추측 패치의 유혹을 끊고, 먼저 눈앞에 똑같이 재현하게 만드는 엔지니어링 철학 스킬.
| name | see-it-first |
| description | Forces reproduction before any fix. When something doesn't work, this skill stops the symptom→guess→patch loop and first reproduces the bug locally on the same branch, data, and inputs the user saw — because an unreproduced bug is an unsolved one. 버그·이상 동작 앞에서 추측 패치의 유혹을 끊고, 먼저 눈앞에 똑같이 재현하게 만드는 엔지니어링 철학 스킬. |
| when_to_use | Use whenever something doesn't work — phrases like "bug", "broken", "not working", "error", "doesn't work", "fix", "버그", "안 돼", "이상해", "에러", "왜 이러지", "고쳐줘" — and especially in intermittent or hearsay reports ("가끔 안 돼요", "어쩌다 한 번", "사용자가 이렇다는데", "PM이 메인 깨졌대요"), or when a fix is about to be attempted without a log, screenshot, or reproduction steps in hand. |
| allowed-tools | Read Bash Grep |
한 줄. 버그는 고치기 전에 재현한다. 못 본 버그는 고친 게 아니다.
버그 앞에서 가장 큰 유혹은 증상 → 추측 → 패치입니다. 그러나 못 본 버그는 고친 게 아닙니다. 일단 내 눈앞에 똑같이 다시 띄우는 것에서 시작합니다. 재현이 되면 절반은 풀린 것입니다. 재현 안 되는 버그는 추측으로 사라진 게 아니라, 다음에 더 큰 모습으로 돌아옵니다.
증상을 들으면 코드부터 펴고 싶어진다. 한 번 멈추고, 먼저 본다.
재현 조건을 받아 적는다. 언제·어디서·어떤 입력·어떤 결과·기대한 결과. 다섯 칸이 채워지면 재현은 거의 자동으로 따라온다. 비개발자에게 묻는 법: "조금 전에 어떤 화면에서 → 뭘 눌렀더니 → 뭐가 떴어요? 원래는 어떻게 돼야 했어요?"
같은 환경을 만든다. 같은 브랜치, 같은 데이터, 같은 입력. 다르면 다른 버그를 잡게 된다. 재현 환경 정렬이 안 되면 (a) 정렬을 먼저 하고, (b) 사용자에게 *"내 환경에선 이렇게 보여요 — 같아요?"*로 확인한다.
최소 재현으로 좁힌다. 재현되면 그 다음은 불필요한 단계를 하나씩 빼는 것. 10단계 → 7 → 4 → 2. 줄어들수록 원인은 분명해진다. "이거 한 줄만 있어도 터진다"까지 좁히면 가설은 거의 다 잡힌 거다.
재현된 다음에 가설을 세운다. 재현 전에 세운 가설은 추측이고, 재현 후에 세운 가설은 관찰이다. 둘은 정확도가 다르다. 추측 패치로 증상은 사라졌는데 원인은 모르는 상태는 가장 위험한 마무리다.
고친 뒤, 못 재현됨을 확인한다. 같은 조건으로 다시 돌려서 이번엔 안 터지는지를 본 뒤에 "고쳤다"고 말한다. 가능하면 그 재현 조건을 테스트로 남긴다 — 다음에 같은 자리가 또 무너지지 않게.
"가끔 안 돼요"를 좁히기:
전언으로 끝내지 않기:
재현된 다음:
query.trim() 호출이 빈 문자열일 때 다음 줄에서 query[0]을 읽어서 그래. 고쳤고, 같은 입력으로 다시 돌려봤는데 이번엔 안 터져. 빈 검색어 케이스 테스트 한 줄도 같이 넣어둘게."버그는 적이 아니다. 증거다. 잘 보이는 자리에 갖다 놓으면, 그 다음은 코드가 답한다.
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. 코드를 작성·수정·리뷰·생성·리팩터할 때 '동작하느냐'보다 '왜 만드는가(의도)'를 먼저 짚게 만드는 엔지니어링 철학 스킬.
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. 코드를 작성·확장·리팩터·생성·추가할 때 최소한의 코드량으로 같은 결과를 내도록 강제하는 엔지니어링 철학 스킬.
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. 실패할 가능성이 있는 작업에 들어가기 전에 되돌아올 길을 먼저 마련하는 엔지니어링 철학 스킬.