GitHub 저장소 ayghri/i-have-adhd는 스스로를 “코딩 에이전트가 답을 묻어 버리지 않게 하는 스킬”이라고 소개한다. 5월에 만들어졌고, 7월 중순 GitHub 트렌딩 1위에 한 번 올랐다. 9월 8일 Hacker News 첫 페이지에 오른 뒤로 다시 크게 주목받았다. 이 글타래는 542점, 댓글 371개를 받았다. 9월 9일 약 3만 1천 개였던 스타는 9월 24일 5만 730개가 됐다.
스킬의 내용은 단순하다. 첫 줄에 독자가 할 일을 쓰고, 여러 단계는 번호를 붙이고, 서론과 요약과 맺음말을 빼라는 것이다. 이렇게 단순한 규칙이 이만큼 주목받았다면 사람들이 무엇에 불편을 느끼고 있었는지 보여 준다. 그리고 이 규칙들이 실제로 효과가 있는지, 어디에 두어야 제대로 동작하는지는 따로 따져 볼 문제다.
이 글은 저장소의 코드와 커밋 이력, 이슈, Hacker News 댓글, 그리고 Anthropic의 공식 문서를 바탕으로 정리했다. 스킬을 직접 설치해 측정하지는 않았다. 효과에 대한 수치는 작성자의 측정과 외부 측정을 인용한다.
142줄짜리 스킬이 하는 일
저장소에는 파일 72개, 약 1만 3천 줄이 있다. 스킬 본체는 skills/i-have-adhd/SKILL.md 142줄이고 토큰으로는 약 1,700개다. 나머지 절반 이상은 설치 안내와 10개 언어 번역이고, 평가 스크립트와 테스트가 그다음이다. 작성자도 Hacker News에서 “저장소 대부분은 평가·벤치마크 코드와 번역”이라고 설명했다.
SKILL.md는 ADHD가 있는 독자를 전제로 다섯 가지를 먼저 적는다. 작업 기억이 작아서 화면에 없는 것은 잊는다, 답을 아는 것과 실행하는 것은 다르다, 시작이 가장 어렵다, 시간 감각이 균일하게 느껴진다, 진행이 눈에 보여야 힘이 난다. 이 전제에서 규칙 10개가 나온다.
- 첫 줄에 다음 행동을 쓴다. 맥락이나 계획이 아니라 독자가 할 수 있는 일이다.
- 여러 단계는 번호를 붙이고, 한 단계에 한 가지 일만 넣는다.
- 2분 안에 할 수 있는 다음 행동 하나로 끝낸다.
- 곁가지는 쓰지 않는다.
- 매 턴 진행 상태를 다시 적는다. 하네스에 작업 목록 도구가 있으면 그것을 쓴다.
- 구체적인 시간 추정을 준다.
- 끝낸 일을 보이게 한다.
- 오류는 담담하게 원인과 해결책으로 보고한다.
- 목록은 한 묶음에 5개 정도로 제한한다.
- 서론, 요약, 맺음말을 쓰지 않는다. “Let me…”, “I’ll…” 같은 시작을 쓰지 않는다.
여기에 규칙을 깨도 되는 경우 6가지와 보내기 전 점검이 붙는다. 점검의 마지막 질문은 “독자가 첫 줄과 마지막 줄만 읽어도 다음에 할 일과 방금 일어난 일을 아는가”다.
스타가 몰린 시점
스타 증가는 Claude Opus 5 출시와 겹친다. Opus 5는 7월 24일에 나왔고, Anthropic 공식 문서는 “Opus 5의 기본 응답은 이전 Opus 모델보다 길다”고 적었다. 9월 8일 Hacker News 글타래의 댓글도 상당수가 스킬 자체보다 Opus 5의 문체에 대한 불만이었다. “Opus 5에서 가장 많이 하는 후속 요청은 ’한 번에 하나씩’과 ‘글이 너무 길다’“라는 댓글이 있었고, “스킬을 설치했는데 별로 도움이 안 됐다”는 댓글도 있었다.
댓글에서 나온 대안도 비슷한 방향이었다. CLAUDE.md에 “요약 메시지 끝에 찾은 것, 권하는 것, 나에게 필요한 것을 TLDR로 적어라” 한 줄을 넣는다는 사람, “간결하게”만 쓰면 된다는 사람, 그건 덜 일관되고 이유를 같이 주는 편이 낫다고 반박하는 사람이 있었다. 사람들이 원한 것은 대체로 같다. 답이나 결과가 첫 줄에 오는 것이다. 스타 5만 개는 이 요구가 그만큼 널리 퍼져 있었다는 표시로 읽는 게 맞다.
이름에 대한 반응은 갈렸다. 실제로 ADHD 진단을 받은 사람 중에도 유용하다는 사람과 불쾌하다는 사람이 모두 있었다. 이 글에서는 이름보다 규칙의 효과를 본다.
규칙은 대부분 예외 조항으로 바뀌었다
커밋 이력을 보면 규칙 10개 자체보다 예외와 우선순위 조항이 더 많이 늘었다.
항상 켜짐에서 호출형으로. 5월 첫 버전은 모든 메시지에 발동하도록 설명이 쓰여 있었다. 7월 21일 작성자는 이를 disable-model-invocation: true로 바꿔 /i-have-adhd를 입력해야만 켜지게 했다. 지금 Claude Code에서 항상 켜 두려면 플래그 파일을 만들어 세션 시작 훅이 SKILL.md를 주입하게 해야 한다. Codex나 Copilot에서 항상 켜 두는 방법은 10줄짜리 요약본을 설정 파일에 붙여 넣는 것이다. 같은 이름의 스킬이 런타임마다 다른 규칙 세트로 동작하는 셈이다.
하네스와의 충돌. 7월 22일 올라온 이슈 #43은 규칙 10이 “Let me…”, “I’ll…“로 시작하는 문장을 금지하는데, Claude Code 시스템 프롬프트는 첫 도구 호출 전에 할 일을 한 문장으로 말하라고 요구한다고 지적했다. 둘이 충돌하면 턴마다 번갈아 가며 한쪽을 따르는 현상이 생긴다고 했다. 작성자는 “하네스 안에서는 시스템 프롬프트가 이 스킬보다 우선한다”는 조항을 추가했다.
목록 5개 제한. 이슈 #96에서 한 사용자가 5개 제한 때문에 중요한 발견이 목록에서 빠진다고 보고했다. 규칙 9는 이후 세 번 고쳐졌다. 지금은 “보여 주는 방식만 정하는 규칙이고, 분석이나 검색 결과를 제한해서는 안 된다”, “나머지는 요청할 때까지 보관한다”는 문구가 붙어 있다. 하지만 모델이 대화 밖에 무언가를 보관할 곳은 없다. 이 사용자는 “더 있다는 사실조차 못 들은 적이 있다”고 적었다.
오류 보고 규칙의 부작용. 규칙 8은 오류를 원인과 해결책 순서로 보고하라고 한다. 작성자의 평가에서 이 규칙은 근거 없이 원인을 단정하게 만들었다. 이 문제는 이슈 #99로 등록돼 아직 열려 있다. 아래 측정 절에서 자세히 본다.
작성자도 이슈에서 “구조만으로는 충분하지 않았고, 추가하는 내용이 계속 보내기 전 점검 쪽에 들어간다”고 썼다. 말투 규칙을 스킬 하나에 담으면 다른 규칙, 다른 지시, 작업 자체와 부딪치는 지점이 계속 생긴다는 것을 이 이력이 보여 준다.
작성자의 측정이 보여 주는 것
작성자는 8월 2일 한 번 평가를 돌렸다. 조건은 Claude Opus 4.8, 사례 14개, 사례마다 3회, 스킬 있음과 없음 두 조건이다. 같은 계열 모델이 블라인드로 채점했다. 가중 점수는 4.05에서 4.47로 올랐다.
이득은 고르게 나오지 않았다. 여러 단계 진행 보고 사례가 +2.53, 오류 보고 사례가 +2.40이었다. 코드를 답하는 사례와 긴 글을 요청한 사례는 변화가 없었다. 원래 출력 형식이 정해진 작업에서는 스킬이 할 일이 없었다는 뜻이다.
회귀도 하나 있었다. 일부만 성공한 작업을 보고하는 사례에서 -0.63이 나왔다. 채점 메모는 “근거 없이 ’auth 헤더 누락’을 원인으로 단정하고 특정 해결책을 처방했다”였다. 평가 결과 문서도 규칙 8이 원인을 확인하지 못한 상황에서도 원인을 말하도록 압박한다고 해석했다.
이 평가에는 한계가 분명하다. 도구를 끈 채로 돌렸기 때문에 에이전트 작업이 아니라 단발 응답을 잰 것이다. 작성자가 정한 릴리스 기준(차단 이슈 0개)도 통과하지 못했다. 출력 토큰 수는 기록되지 않았다. 작성자는 “토큰 사용량을 줄이는 것은 목표가 아니다”라고 밝혔다.
비슷한 스킬에 대한 외부 측정은 하나 있다. 말을 극도로 짧게 줄이는 스킬 caveman(스타 약 10만 7천 개)은 출력 토큰을 65% 줄인다고 주장한다. JetBrains가 실제 에이전트 과제 86개로 측정한 결과는 -8.5%였고 품질 차이는 없었다. JetBrains는 “도구 호출 사이의 설명만 줄어드는데, 그 양이 원래 많지 않다”고 설명했다. 에이전트 작업에서는 토큰 대부분이 도구 호출과 결과, 코드에 들어가기 때문에 말투 규칙으로 줄일 수 있는 양에 한계가 있다.
Anthropic은 같은 불만에 어떻게 답했나
Anthropic 문서와 제품에는 이 스킬과 같은 방향의 장치가 이미 들어와 있다. 다만 위치가 스킬이 아니다.
Opus 5 프롬프팅 가이드. “effort는 모델이 얼마나 생각하는지를 조절하지 얼마나 말하는지를 조절하지 않는다. 응답 길이를 조절하려면 프롬프트로 명시하라”고 적혀 있다. 짧은 간결성 지시가 효과적이라며 예시 문장을 준다. 에이전트 작업에는 “끝나면 결과부터 말하라. 첫 문장은 무슨 일이 있었는지, 무엇을 찾았는지에 답해야 한다”는 한 문장을 권한다. 스킬의 규칙 1과 거의 같다. 금지 목록보다 원하는 문체의 예시를 주는 편이 효과적이라는 조언도 있다. 스킬의 규칙 10과는 반대 방식이다.
Claude Code의 Concise 출력 스타일. 공식 문서는 이 스타일을 이렇게 설명한다. 첫 문장에 무슨 일이 있었는지나 답을 쓰고, 도입부와 단계별 설명과 마무리 요약을 뺀다. 엔지니어링 작업 자체는 기본 스타일만큼 철저하게 한다. 그리고 오류 보고, 실패한 테스트 출력, 보안 경고, 파괴적 작업의 확인은 전체 내용을 유지한다. 출력 스타일은 매 요청마다 함께 전송된다. 스킬이 세션 시작이나 호출 때 한 번 주입되는 것과 다르다. 같은 문서의 기능 선택표에는 “모든 응답에 적용할 말투, 길이, 형식”은 출력 스타일, “특정 작업에만 필요한 지시”는 스킬, “예외 없이 매번 일어나야 하는 일”은 훅으로 구분돼 있다. 이 기준으로 보면 i-have-adhd의 용도는 출력 스타일에 가깝다. Hacker News와 이슈 #187에서도 같은 지적이 나왔다.
Opus 5.5의 응답 구조. 9월 22일 나온 Opus 5.5에 대해 Anthropic은 “가장 중요한 정보를 앞에 두고”, “전문 용어나 특이한 표현을 덜 쓰고, 사용자가 준 글쓰기 규칙을 따른다”고 발표했다. 고객사 Box는 “Opus 5보다 토큰을 3분의 1만 쓰고 답이 40% 덜 장황했다”고 했다. 이건 고객 사례 인용이다. 구조적인 변화도 있다. #75에서 다뤘듯 Opus 5.5는 도구 호출 사이에 쓰는 짧은 설명을 일반 텍스트가 아니라 진행 업데이트용 thinking 블록으로 돌려준다. 기본 설정에서는 그 내용이 비어 있다. 스킬의 규칙 10이 없애려던 “Let me…” 류의 문장이 API 수준에서 다른 칸으로 옮겨 간 것이다.
한 가지 충돌도 있다. Anthropic의 Opus 5.5 가이드는 사람이 지켜보지 않는 에이전트 실행용 예시 프롬프트에서, 다음 단계를 예고하고 도구 호출 없이 끝나는 턴과 “원하시면 이어서 하겠다”는 제안으로 끝나는 턴을 금지한다. 스킬의 예시가 권하는 끝맺음(“Next: run npm test”, “Want me to handle that next?”)과 겹친다. Anthropic은 이 지시를 사람이 참여하는 대화에는 넣지 말라고 범위를 한정했다. 그러니 이 충돌은 무인 실행에서만 문제가 된다.
규칙을 어디에 둘까
이 스킬의 규칙을 기능별로 나눠 보면 대부분 스킬보다 더 적합한 자리가 있다. 아래는 이 글에서 정리한 제안이다.
| 규칙 | 적합한 자리 | 이유 |
|---|---|---|
| 첫 줄에 결과나 다음 행동 | 출력 스타일, 시스템 프롬프트 | 모든 응답에 적용할 규칙이고 매 요청 전송되는 곳이 유지가 잘 된다. 공식 문서에 한 문장 예시가 있다 |
| 서론·맺음말 금지 | 출력 스타일, 모델 | Concise 스타일이 이미 한다. Opus 5.5에서는 도구 호출 사이 설명이 thinking 블록으로 빠졌다 |
| 여러 단계 번호, 진행 상태 재진술 | 하네스의 작업 목록 도구 | 스킬도 작업 목록 도구가 있으면 그것을 쓰라고 한다. 도구가 상태를 들고 있어야 모델이 잊지 않는다 |
| 목록 길이 제한 | UI | 많으면 접어서 보여 주는 건 화면의 일이다. 모델에게 제한을 걸면 항목이 빠진다(#96) |
| 오류를 원인과 해결책으로 | 빼거나 조건을 건다 | 원인을 확인했을 때만 원인을 쓰게 해야 한다(#99). Concise 스타일은 오류 보고를 전체 유지한다 |
| 완료 보고의 검증 증거 | 훅, 하네스 검사 | “요약을 빼라”는 규칙이 실행한 명령과 결과까지 지울 수 있다. 증거가 있는지는 모델에게 맡기지 말고 종료 훅 등으로 확인한다 |
| 특정 작업용 보고 형식 | 스킬(호출형) | 긴 마이그레이션의 “5단계 중 3단계 완료” 같은 형식처럼 특정 작업에만 필요한 형식은 스킬이 맞다. 작성자 평가에서 이득이 난 곳도 진행·오류 보고였다 |
정리하면 스킬로 남길 만한 것은 특정 작업용 보고 형식 정도다. 나머지는 출력 스타일, 하네스, UI가 더 확실하게 처리한다.
효과를 재는 방법
말투 규칙의 효과를 “짧아졌다”로만 재면 중요한 부분을 놓친다. 아래는 제안하는 비교 방법이다. 직접 돌려 보지는 않았다.
비교 조건을 셋으로 둔다. 아무 지시 없음, 공식 문서의 한 줄 간결성 지시, i-have-adhd 전체. 가능하면 Claude Code의 Concise 스타일도 넣는다. 작성자의 평가처럼 “스킬 대 아무것도 없음”만 비교하면 한 줄짜리 지시로도 얻을 수 있는 효과까지 스킬의 효과로 계산하게 된다.
도구를 켠 실제 작업으로 잰다. 작성자의 평가는 도구를 끈 단발 응답이었다. 자기 저장소에서 버그 수정, 리팩터링, 조사 같은 과제를 10개에서 20개 정도 골라 실제 에이전트 작업으로 돌린다.
잴 지표는 다음과 같다.
- 최종 메시지의 보이는 출력 토큰
- thinking을 포함한 전체 출력 토큰. 두 값은 반대로 움직일 수 있다
- 스킬이 매 턴 더하는 입력 토큰(약 1,700개)과 캐시 적중 여부
- 첫 줄에 실행할 수 있는 행동이나 결과가 있는지
- 과제 성공률
- 완료 보고에 실행한 명령과 결과가 붙어 있는지. 검증 증거가 빠진 비율을 센다
- 근거 없이 원인을 단정한 비율. 규칙 8의 회귀를 확인하는 지표다
세션이 길어질 때를 따로 본다. 작성자와 Hacker News 댓글 모두 대화가 길어지면 모델이 규칙을 잊는다고 했다. 1턴, 10턴, 컨텍스트 압축 뒤에 규칙을 지키는 비율을 따로 센다. 출력 스타일(매 요청 전송)과 스킬(한 번 주입)의 차이가 여기서 드러날 것이다.
정리
i-have-adhd에 5만 명이 스타를 누른 이유는 코딩 에이전트의 답이 길고 결론이 뒤에 있다는 불만이었다. 스타가 몰린 시점은 Opus 5 출시 뒤였고, Hacker News 댓글도 상당수가 그 이야기였다. 사람들이 원한 것은 첫 줄에 결과나 다음 행동이 오는 것이었다.
규칙 10개는 이력에서 보듯 하네스 지시와 충돌하고, 목록에서 항목을 빠뜨리고, 근거 없는 원인 단정을 만들면서 예외 조항이 계속 붙었다. 작성자의 측정에서 이득은 진행과 오류 보고에 몰렸고, 에이전트 작업이나 토큰 수는 측정되지 않았다. 같은 요구에 Anthropic은 매 요청 전송되는 Concise 출력 스타일과, 도구 호출 사이 설명을 별도 블록으로 빼는 Opus 5.5의 응답 구조로 답했다.
에이전트의 답이 길어서 불편하다면 순서를 이렇게 잡는 게 좋겠다. 먼저 출력 스타일이나 시스템 프롬프트에 “첫 문장에 결과를 쓴다”를 넣는다. 진행 상태는 작업 목록 도구에 맡기고, 완료 보고의 검증 증거는 훅으로 확인한다. 스킬은 특정 작업의 보고 형식이 필요할 때 쓴다. #52에서 본 Archify는 스킬 본문보다 검증기가 훨씬 컸다. 이번 사례도 규칙을 문장으로 늘리는 것보다 도구와 설정에 옮기는 쪽이 더 확실하다는 점을 보여 준다.
참고: ayghri/i-have-adhd (GitHub), Hacker News 토론 (2026-09-08), 이슈 #43 하네스 충돌, 이슈 #96 목록 제한, 이슈 #99 원인 단정, 이슈 #187 출력 스타일 제안, Prompting Claude Opus 5 (Anthropic 문서), Claude Code 출력 스타일 문서, Introducing Claude Opus 5.5 (Anthropic), Prompting Claude Opus 5.5 (Anthropic 문서), JetBrains: caveman 측정. 스타 수는 2026-09-24 GitHub API 기준이다. 저장소 분석은 커밋 839872f(2026-09-19) 기준이다. 평가 수치는 작성자의 evals/RESULTS.md(2026-08-02 실행)를 인용했다. Box의 “40% 덜 장황” 수치는 Anthropic 발표문의 고객 인용이다. 규칙 배치 표와 측정 방법은 이 글의 제안이며 직접 검증하지 않았다.