Tidy as you go

Skill kwakseongjae/some-engineer-mind/tidy-as-you-go

비전공 바이브 코더를 위한 11개의 엔지니어 사고방식 스킬.

Install

npx -y skills add kwakseongjae/some-engineer-mind --skill tidy-as-you-go

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Small grooming each time code is finished, named, reviewed, or committed — removing unused imports, variables, and dead code; tightening identifier names to expose intent; and leaving the file one notch cleaner than it was found. Never expands into unrelated refactors that bloat the PR. 코드를 작성·수정·리뷰·커밋·완료할 때마다 작은 정돈을 습관화하는 엔지니어링 철학 스킬.

SKILL.md

4.5 KB, as published. Nobody here has run it

한 줄. 떠나기 전에, 들어왔을 때보다 한 단계 깨끗하게.

Why this mindset

항상 정돈하는 습관을 들이자. 사용하지 않는 변수, import를 정리하자. 의도가 드러나는 변수명을 지을 수 있도록 노력하자. 그 이외에도 어떻게 하면 코드를 깨끗하게 관리할 수 있을지에 대해 고민하자.

Instructions

정돈은 따로 잡는 큰 행사가 아니다. 코드를 만질 때마다 곁들이는 작은 동작이다.

마무리 직전, 한 번 훑는다. 기능을 다 짠 뒤·커밋 직전·"이제 됐다" 시점에 파일을 한 번 더 위에서 아래로 본다. 안 쓰는 import, 안 쓰는 변수, 디버그용 print/console.log, 주석 처리만 해놓은 죽은 코드 — 보이면 그 자리에서 지운다.
이름은 한 번 더 의심한다. 변수·함수·파일 이름이 "이게 뭐 하는 건지" 한눈에 드러나는지 다시 본다.
- data, temp, result, handle, doStuff 같은 이름은 거의 항상 더 좋은 이름이 있다.
- 좋은 이름의 기준: 읽는 사람이 함수 본문을 안 봐도 의도를 짐작할 수 있는가.
- 떠오르지 않으면 "이 함수 한 문장으로 설명해줘"를 자기 자신한테 묻고, 그 문장에서 동사·명사를 뽑는다.
보이스카우트 룰. 원래 작업과 무관해도, 같은 파일에서 명백히 잘못된 작은 것이 보이면 지나가는 김에 고친다. 단, 별건 손대지 않는다 — "지나가는 김에"가 리팩터링 폭주가 되면 그건 정돈이 아니라 새 작업이다.
포맷·정렬은 도구에 맡긴다. prettier, eslint --fix, black, gofmt 같은 게 깔려 있으면 그걸 돌린다. 손으로 들여쓰기·따옴표·세미콜론을 다투지 않는다. 도구가 없는 프로젝트면 한 번 깔자고 제안만 하고, 본업을 멈추진 않는다.
정돈한 만큼만 정돈했다고 말한다. 사용자에게 마무리를 보고할 때 "이번에 정리한 것"을 짧게 한 줄 적는다. "안 쓰는 import 3개, 디버그 로그 2줄 제거. tmpData → parsedRows로 이름 변경." 이게 다음에 누가 봤을 때의 이정표다.

Examples

기능 끝낸 직후:

사용자: "검색 기능 다 만들었어."
Claude: "마무리 전에 한 번 훑었어 — useState에서 안 쓰던 loading, 위에 디버그 console.log 한 줄, 그리고 data를 users로 바꿨어. 지금이 더 읽기 좋아. 커밋해도 될 것 같아."

이름이 안 떠오를 때:

사용자: "이 함수 이름 뭐로 하지?"
Claude: "이 함수 한 문장으로 풀면 '이메일 형식이 맞는지 검사해서 true/false 돌려준다'야. 그럼 isValidEmail 정도가 자연스러워. checkEmail은 검사 후 뭘 하는지 모호해서 한 단계 약해."

선 긋는 흐름:

사용자: 기능 작업 중인데 옆 파일에 거대한 함수가 보임.
Claude: "이 옆 파일에 100줄짜리 함수가 좀 어수선해 보이긴 해. 다만 지금 작업 범위 밖이라, 표시만 해두고 손은 안 댈게. 따로 정리할 일감으로 빼두면 좋겠어."

Pitfalls

"나중에 한꺼번에 정리하지" → 그 "나중"은 거의 오지 않는다.
의미 없는 이름 (data1, temp, foo, value)이 마이그레이션 없이 살아남는 일.
안 쓰는 import·변수가 누적되면서 파일이 무거워 보이는 일.
정돈한답시고 작업 범위 밖까지 파헤쳐 PR이 거대해지는 일.

정돈은 완벽주의가 아니다. "내가 떠난 자리가 들어왔을 때보다 한 단계만 깨끗하면 된다." 그 한 단계가 매번 쌓이는 게 깨끗한 코드베이스다.