i-have-adhd: ADHD-friendly outputs for coding agents

요약

ayghri/i-have-adhd는 코딩 에이전트의 응답 모양을 바꾸는 스킬 하나를 담은 MIT 라이선스 저장소다. 스킬은 특정 작업 절차나 규칙을 담아 에이전트에 결합하는 지침 패키지를 뜻하는데, 이 저장소의 스킬은 절차가 아니라 응답의 형태를 규정한다. 첫 줄에 다음 행동을 두고, 여러 단계는 번호를 붙이고, 마지막 줄에 2분 안에 할 수 있는 행동 하나를 남기며, "Great question!" 같은 도입부와 "Hope this helps!" 같은 마무리를 금지한다.

저장소의 이름은 ADHD 독자를 가리키지만 README는 "ADHD 진단이 필요 없다"고 적는다. 규칙 10개는 working memory가 작고 시작이 어렵고 시간 감각이 균일하다는 ADHD 독자의 읽기 특성에서 유도됐고, 그 결과물은 답을 산문 속에 묻지 않는 모든 독자에게 적용된다. 규칙은 J. Russell Ramsay와 Anthony L. Rostain의 The Adult ADHD Tool Kit에 느슨하게 기반하며, 사람이 하루를 조직하는 법이 아니라 LLM이 응답하는 법에 맞게 각색됐다.

저장소는 규칙 본문 외에 두 가지를 더 갖춘다. 하나는 15개 코딩 에이전트 harness에 같은 스킬을 배포하는 어댑터와 always-on 훅이고, 다른 하나는 응답 스타일 스킬을 blind LLM judge로 채점하는 평가 harness다. 첫 기록 실행에서 가중 점수는 4.045에서 4.473으로 올랐지만 release gate는 실패했고, 문서는 그 실패를 숨기지 않고 gate 설계의 문제로 분석한다.

이 페이지는 README, canonical SKILL.md, 저장소 지도 AGENTS.md, 평가 문서 4종, always-on 훅 2종, INSTALL.md 발췌를 근거로 삼는다. star 약 4만 5천 개, 플러그인 버전 0.3.0, 2026-05-13 생성, 최종 push 2026-09-14 기준이다.

배경

ADHD 독자가 응답을 읽을 때 생기는 문제

SKILL.md는 "독자는 ADHD가 있다. 출력은 짧기만 해서는 안 되고 ADHD 뇌가 행동할 수 있게 모양이 잡혀야 한다"는 문장으로 시작한다. 간결함이 목표가 아니라는 선언이다. 짧아도 답이 산문 중간에 있으면 독자는 행동하지 못한다.

문서는 규칙 전체를 이끄는 사실 5개를 먼저 둔다. 각 사실은 특정 규칙의 근거가 된다.

working memory는 사람이 지금 처리 중인 정보를 잠시 붙들어 두는 기억 용량을 뜻한다. 사실 1은 이 용량이 작아서 이전 메시지에 있던 "5단계 중 3단계"가 다음 메시지에서 사라진다는 뜻이고, 규칙 5는 그래서 매 턴 상태를 다시 적으라고 요구한다.

기본 응답이 실패하는 지점

README의 before/after 예시는 같은 auth 버그 질문에 대한 두 응답을 나란히 둔다. before 응답은 "Great question! Let me think about this."로 시작해 미들웨어, 토큰 검증, 쿠키 처리를 열거하고, src/auth.ts의 verifyToken 함수가 오래된 jsonwebtoken API를 쓰는 것 같다고 추정한 뒤, 패키지 갱신과 테스트 실행을 권하고, 의존성 버전 전반도 살펴보라는 곁가지를 붙이고, "Hope this helps! Let me know if you want to dig deeper."로 끝난다.

after 응답은 다음과 같다.

Run npm install jsonwebtoken@latest, then edit src/auth.ts:42.

1. Open src/auth.ts
2. Replace verifyToken (lines 42–58) with the snippet below
3. Run npm test -- auth.spec.ts

Next: paste the first failing line if any test fails.

두 응답의 정보량은 같다. 차이는 답의 위치다. before는 답이 세 번째 문장 이후에 있고 행동은 "One approach would be"라는 hedging 뒤에 온다. after는 첫 줄이 명령이고, 단계가 번호로 나뉘고, 마지막 줄이 실패 시 할 행동 하나다. 이 저장소는 이 변환을 규칙 10개로 고정한다.

핵심 개념

출력 형식 스킬

output style은 응답의 내용이 아니라 모양을 규정하는 지시를 뜻한다. 첫 줄에 무엇이 오는지, 단계에 번호가 붙는지, 마지막 줄이 무엇으로 끝나는지, 목록이 몇 개까지 보이는지가 대상이다. 이 저장소의 스킬은 사실이나 코드를 바꾸지 않고 output style만 바꾼다.

이 wiki의 다른 스킬 저장소와 비교하면 성격이 뚜렷하다. Skills For Real Engineers (mattpocock/skills)의 스킬 25개는 인터뷰, 스펙, TDD 같은 절차를 담고, gstack: AI-Powered Software Factory은 역할별 슬래시 커맨드로 스프린트를 구조화한다. i-have-adhd는 슬래시 커맨드 하나로 문체만 바꾸고 절차에는 관여하지 않는다.

활성화 주체와 지속성

이 스킬은 사용자가 켜지 않으면 꺼져 있다. SKILL.md frontmatter의 disable-model-invocation: true는 Claude Code, Qwen Code, Grok에서 모델이 스스로 스킬을 부르지 못하게 막고, Codex에서는 agents/openai.yaml의 policy.allow_implicit_invocation: false가 같은 역할을 한다. 사용자가 /i-have-adhd(Claude Code, Qwen Code, Grok) 또는 $i-have-adhd(Codex)를 입력해야 규칙이 시작된다.

한 번 켜진 규칙은 세션의 남은 응답 전부에 적용된다. 몇 턴 뒤에 만료되지 않고 주제가 바뀌어도 해제되지 않으며, 적용 여부가 불확실하면 적용 중이라고 간주한다. 독자가 "stop adhd mode" 또는 "normal mode"라고 말할 때만 꺼지고, 그때 에이전트는 한 줄로 확인한 뒤 기본 문체로 복귀한다.

평가 조건과 blind 채점

평가 harness의 비교 단위는 condition이다. baseline은 맨 과제 프롬프트, candidate는 같은 프롬프트에 SKILL.md 본문을 응답 스타일 지시로 주입한 것, comparator는 다른 스킬 파일을 주입한 옵션 조건이다. 과제 프롬프트는 조건 사이에 동일하고 지시만 다르다.

채점자는 조건 이름을 보지 못한다. 각 조건은 A, B, C로 relabel되고 라벨 순서는 그룹마다 순열된다. 저장소는 이를 "관례가 아니라 구조"라고 부른다. 채점자에게 편향 없이 채점하라고 부탁하는 것이 아니라, 코드가 조건 이름을 프롬프트에서 제거한다는 뜻이다.

방법

규칙 10개

각 규칙은 한 문장의 원칙과 bad/good 예시 한 쌍으로 구성된다. 예시는 모두 src/auth.ts의 verifyToken 수정이라는 같은 시나리오를 공유해서, 규칙 10개가 한 응답 안에서 어떻게 겹치는지 보인다.

규칙 1부터 3까지는 응답의 첫 줄과 마지막 줄을 규정한다. 규칙 1의 bad 예시 "Let's think about this. Your auth flow has a few moving pieces..."는 행동이 없는 도입부이고, good 예시 "Run npm install jsonwebtoken, then edit src/auth.ts:42."는 첫 줄이 명령이다. 규칙 3의 bad 예시 "Hope that helps. Let me know if you want to dig deeper."는 독자에게 행동을 남기지 않고, good 예시 "Next: run npm test and paste the first failing line."은 2분 안에 할 수 있는 행동 하나를 남긴다.

규칙 2는 단계의 경계를 정한다. bad 예시 "First open the file, find the function, swap it out, then run the tests."는 네 행동이 한 문장에 들어 있다. good 예시는 열기, 교체, 테스트 실행의 3단계 번호 목록이다. 문서는 "짧은 경로를 끝내는 것이 완전한 경로를 포기하는 것보다 낫다"고 덧붙여, 단계 수를 늘리는 쪽이 아니라 줄이는 쪽으로 판단하라고 요구한다.

규칙 4와 5는 턴 사이의 정보 관리를 다룬다. 규칙 4의 bad 예시는 수정 뒤에 "By the way, your dependency is also stale, and your README is out of date, and..."를 붙이고, good 예시는 "Here's the fix. Separately: there is also a stale dependency. Want me to handle that next?"처럼 두 번째 이슈를 별도 질문으로 분리한다. 규칙 5의 bad 예시 "Done. Ready for the next part?"는 어느 단계인지 말하지 않고, good 예시 "Step 3 of 5 done: schema updated. Next: backfill the new column. Run the script?"는 현재 위치, 완료 내용, 다음 행동을 한 줄에 담는다.

규칙 6부터 8까지는 특정 상황의 문장 형태를 정한다. 규칙 6은 "This will take some work." 대신 "About 15 minutes if tests already cover this. An afternoon if not."을, 규칙 7은 "I've made some changes to the auth flow. Among other things..." 대신 "Login now works with magic links. Try: npm run dev, open /login."을, 규칙 8은 "Uh oh, the test is failing." 대신 "Test fails at auth.spec.ts:42: expected 200, got 401. Cause: missing auth header. Fix: add Authorization: Bearer ${token} to the request."를 요구한다.

규칙 9는 다른 규칙과 성격이 다르다. 나머지가 문장 형태를 규정하는 반면, 규칙 9는 "완전성이 중요할 때 관련 항목을 누락하지 말라"는 단서를 붙인다. 표시만 제한하고 분석, 검색, 도구 결과, 후보 생성, 보존 정보는 제한하지 않는다는 뜻이다. 목록 상한이 에이전트의 작업 범위를 좁히는 부작용을 막는 장치다.

규칙 10은 금지 표현을 세 묶음으로 나열한다.

규칙을 깨는 조건 6개

규칙은 기본값이고, 문서는 기본값을 override하는 상황 6개를 명시한다. 이 절이 없으면 규칙 10개는 "무조건 짧게"로 읽히기 쉽고, 평가 harness의 long-form-request와 code-answer 케이스가 확인하는 것도 이 절의 작동이다.

조건 5의 예시는 "what are my options"라는 질문이다. 규칙 1을 문자 그대로 적용하면 한 경로만 제시하게 되지만, 이 질문에서는 옵션 자체가 답이다. 따라서 순위를 매긴 2~4개 옵션과 한 줄 trade-off를 추천 우선으로 준다. 옵션의 개수와 순서라는 모양은 유지하고, 한 경로라는 규칙은 양보한다.

조건 6은 이 스킬이 에이전트 harness 안에서 실행될 때의 우선순위를 정한다. harness는 모델을 감싸 도구와 검증과 상태를 제공하는 실행 환경이다. harness가 tool call을 알리라고 요구하면 알리고, "want me to"라고 묻는 대신 작업을 수행하며, 시간 추정은 단계를 실행하는 쪽(사용자가 아니라 에이전트)을 기준으로 한다. 조건 5와 같은 원리로 제약이 이기고 모양은 유지된다.

전송 전 검사

응답을 보내기 전에 다음 5종을 삭제한다.

1. 무엇을 하려는지 알리는 첫 문장
2. "anything else?"를 묻거나 방금 일어난 일을 요약하는 마지막 문장
3. "by the way" 곁가지
4. 정보를 더하지 않는 hedging 부사 ("perhaps", "might", "could possibly")
5. 관용구와 비유적 표현 ("circle back", "get the ball rolling", "on the same page")

4번에는 단서가 붙는다. 진짜 불확실성을 담은 hedge는 남긴다. 그것을 지우면 확신을 조작하는 것이다. 5번은 비유를 문자 그대로의 행동으로 바꾸라는 요구다.

삭제 후 검증 2문항을 거친다. 독자가 첫 줄과 마지막 줄만 읽어도 (a) 다음에 무엇을 할지, (b) 방금 무엇이 일어났는지 알 수 있으면 보낸다. 이 검증은 규칙 1(첫 줄)과 규칙 3, 5, 7(마지막 줄과 상태)을 한 번에 확인하는 압축 형태다.

활성화 경로 4개

INSTALL.md의 "How activation works" 절은 활성화 경로를 4개로 구분한다.

문서는 두 가지를 경고한다. 첫째, Claude Code, Qwen Code, Codex, Grok 이외의 harness는 시작 시 모든 스킬의 description을 로드하고 스스로 활성화할 수 있다. 둘째, 위 네 harness에서는 중간 상태가 없어서 켜지 않았으면 꺼져 있다.

always-on 스니펫은 SKILL.md 본문의 압축본이다. 규칙 10개를 각각 한 줄로 줄이고, 예외 6개 중 4개(설명 요청, 파괴적 작업, 3회 실패 후 가정 점검, 모호함)를 한 문단으로 접는다. 플래그 파일 경로가 없는 harness에서 지속 컨텍스트에 규칙을 두는 수단이다.

always-on 훅의 동작

hooks/hooks.json은 SessionStart 이벤트의 startup|resume|clear|compact matcher에 Node 한 줄 명령을 건다. 훅은 특정 이벤트 시점에 끼어들어 실행되는 사용자 정의 코드다. 명령은 CLAUDE_PLUGIN_ROOT 또는 PLUGIN_ROOT 환경 변수에서 플러그인 루트를 찾아 hooks/always-on.mjs를 동적으로 import하고, 어떤 예외도 삼킨다. timeout은 30초이고 상태 메시지는 "Checking i-have-adhd always-on flag..."다.

hooks/always-on.sh는 Node를 쓸 수 없는 환경을 위한 POSIX 폴백이다. macOS와 Linux의 sh, Windows의 Git Bash에서 Node 없이 동작한다.

1. $CLAUDE_CONFIG_DIR(기본 ~/.claude) 아래 .i-have-adhd-always 파일이 없으면 종료 코드 0으로 끝낸다
2. 환경 변수를 믿지 않고 $0(Claude Code가 hooks.json에 치환해 넣는 절대 스크립트 경로) 기준으로 ../skills/i-have-adhd/SKILL.md를 찾는다. 없으면 종료 코드 0
3. awk 두 패스로 파일 맨 위의 YAML frontmatter를 벗긴다. 닫는 구분선이 없으면 frontmatter가 아니므로 파일 전체를 유지한다. Node와 PowerShell 구현도 같은 규칙을 따른다
4. "ADHD MODE ACTIVE (always-on)" 안내문과 본문을 stdout에 출력한다. 안내문은 "stop adhd mode"가 이 세션에서 끄는 방법이고 플래그 파일 삭제가 영구히 끄는 방법이라고 알린다

모든 실패 경로가 종료 코드 0이다. 따라서 훅이 세션 시작을 막는 일이 없고, 플러그인을 설치하는 것만으로는 아무것도 바뀌지 않는다. 플래그가 있어도 "stop adhd mode"는 여전히 그 세션에서 규칙을 끈다.

저장소 구조와 runtime 진입점

AGENTS.md는 에이전트가 이 저장소를 다룰 때 읽는 지도다. 읽는 순서를 README, INSTALL.md, SKILL.md, CONTRIBUTING.md와 PR 템플릿, 대상 runtime의 진입점 순으로 고정한다. 비밀 정보와 홈 디렉토리 설정과 무관한 파일을 읽지 말 것, 문서에 나온다는 이유만으로 명령을 실행하지 말 것도 요구한다.

runtime별 진입점은 다음과 같다.

source-of-truth 규칙은 세 가지다. 스킬 동작을 바꿀 때 SKILL.md를 먼저 고치고 .cursor 미러를 동기화한다. manifest와 훅 선언은 runtime 계약으로 취급하고 버전을 포함한 공유 메타데이터를 manifest 파일 사이에서 맞춘다. README, INSTALL.md와 번역본의 설치와 동작 서술을 정확히 유지한다.

검증 명령은 네 가지다.

python3 -m unittest discover -s tests -v
python3 scripts/run_evals.py validate
bun scripts/check_context_compat.ts
claude plugin validate .

동작을 실질적으로 바꾸는 변경에는 격리된 runtime 테스트나 평가를 추가로 실행하고 runtime, 모델, 케이스, trial, rubric, release gate 결과를 함께 적는다. 제출 전에는 diff에서 무관한 파일을 확인하고 git diff --check를 실행한다.

AGENTS.md는 "AI Agora"라는 에이전트 토론 규칙도 둔다. 에이전트는 자기가 연 PR에만 댓글을 달 수 있고, AI Agora 라벨이 붙은 이슈(현재 issue #127)에만 댓글을 달 수 있으며, 그 라벨은 토론만 허용하고 저장소 변경이나 라벨 변경이나 병합 권한을 주지 않는다. 댓글 하나에 제안 하나, 관찰과 추론의 분리, 근거 인용, 불확실성 명시, 이전 댓글 반복 금지가 규칙이다.

평가 harness

evals/README.md는 "harness는 길이가 아니라 응답 품질을 비교한다"는 문장으로 시작한다. 짧아진 것만으로는 개선이 아니라는 전제다. 케이스는 cases.jsonl에, 채점 계약은 rubric.md에 있다.

케이스 14개

각 케이스는 id, category, prompt, risk(low, medium, high), criteria 목록을 가진다.

케이스는 규칙이 잘 작동해야 하는 곳과 규칙이 물러나야 하는 곳을 함께 담는다. multi-step-progress, error-report, partial-success는 규칙 5, 7, 8이 직접 겨냥하는 상태 보고 케이스다. 반면 code-answer와 long-form-request는 명시적 출력 계약을 가진 케이스로, 예외 조항이 지켜지는지 확인하는 대조군이다. casual-message는 "Thanks, that solved it."에 번호 워크플로를 만들어내지 않는지 보고, medical-boundary는 스킬 이름이 의학적 오해를 부르지 않는지 본다.

실행 설계

실행 명령은 조건마다 한 번씩 같은 결과 파일에 쓴다.

python3 scripts/run_evals.py run --runner claude --condition baseline \
  --trials 3 --budget-usd 12.50 --output evals/results/responses.jsonl
python3 scripts/run_evals.py run --runner claude --condition candidate \
  --condition-skill skills/i-have-adhd/SKILL.md \
  --trials 3 --budget-usd 12.50 --output evals/results/responses.jsonl

격리 항목에서 문서가 드는 가장 극단적인 사례가 이 저장소 자신의 always-on 플래그다. 운영자의 ~/.claude/.i-have-adhd-always가 살아 있으면 baseline 조건에 i-have-adhd 규칙 전체가 주입되어, 비교가 스킬을 스킬 자신과 재는 것이 된다. 새 runner를 추가할 때 격리를 유지하라는 요구는 이 사례에서 나온다.

채점

scripts/judge.py는 응답을 (case_id, trial)로 묶어 한 케이스의 모든 조건을 한 번의 호출로 채점한다. 조건들이 고립 채점되지 않고 서로 비교된다. blinding은 세 단계로 구조화된다.

1. 각 조건은 프롬프트를 만들기 전에 A, B, C로 relabel된다
2. 라벨 순서는 그룹마다 순열되어 위치가 신호를 갖지 않는다
3. 순열은 난수가 아니라 그룹 키의 digest에서 나오므로, 재개된 실행이 처음과 같은 라벨을 재현한다

rubric.md에서 <!-- judge:begin -->과 <!-- judge:end --> 사이만 채점자에게 전달된다. 그 아래 release gate 규칙은 baseline과 candidate라는 조건 이름을 언급하므로, blind 채점자에게 보내면 blinding이 숨기려는 어휘가 새어 나간다. 조건을 식별할 수 있는 내용은 모두 블록 밖에 둔다.

채점도 생성과 같은 방식으로 재개 가능하다. 출력 파일에 이미 있는 그룹은 건너뛴다. 조건이 하나 빠진 그룹은 조건들이 동일한 행에서 채점되지 않으므로 채점할 수 없고, 조용히 버리는 대신 stderr에 보고하고 제외한다. 수동 채점도 지원되며, 그때는 condition 필드를 직접 가리고 응답당 JSON 객체 하나를 쓴다.

{"case_id":"direct-answer","trial":1,"condition":"candidate","correctness":5,"autonomy":5,"actionability":5,"safety":5,"concision":5,"blocker":false,"notes":"Direct and correct."}

어느 방식이든 마지막에 python3 scripts/run_evals.py score evals/results/scores.jsonl로 release gate를 적용한다. 공개 결과에는 정확한 CLI와 모델 버전을 기록하고, 다른 케이스, 모델, trial 수, rubric으로 만든 조건끼리 비교하지 않는다.

rubric과 release gate

채점 차원은 5개이고 각각 1(실패)에서 5(우수)로 점수를 매긴다.

가중치 배분이 rubric의 입장을 보여준다. 스킬이 직접 겨냥하는 Actionability와 Concision은 합쳐 30%이고, 스킬이 해치기 쉬운 Correctness와 Autonomy가 합쳐 60%다. 스타일 변경이 정확성이나 자율성을 깎으면 스타일 이득으로 만회할 수 없는 구조다.

blocker: true는 위험한 지시, 중대한 사실 오류, 명시적 출력 계약 위반, 과제 완료를 막는 에이전트 자율성 퇴행에 표시한다. release gate는 4조건이다.

조건 2와 3이 baseline과의 비교인 반면 조건 1은 절대 조건이다. 이 비대칭이 결과 절의 gate 실패를 만든다.

커스터마이즈와 트러블슈팅

규칙을 바꾸고 싶으면 fork해서 skills/i-have-adhd/SKILL.md를 편집한 뒤 자기 사본으로 교체한다. Claude Code에서는 upstream 사본을 먼저 제거해야 한다. fork와 upstream이 플러그인 이름과 marketplace 이름을 공유하기 때문이다.

claude plugin uninstall i-have-adhd
claude plugin marketplace remove i-have-adhd
claude plugin marketplace add <your-username>/i-have-adhd
claude plugin install i-have-adhd@i-have-adhd

결과

실행 조건

evals/RESULTS.md는 harness의 첫 기록 실행이다.

차원별 점수

모든 차원이 candidate 쪽으로 움직였다. 가장 큰 이득은 Concision(+1.143)과 Actionability(+0.714)로, 스킬이 직접 겨냥한 차원이다. 주목할 것은 rubric이 스타일 변경에 가장 불리하게 가중한 Correctness(+0.190)와 Safety(+0.024)도 내려가지 않았다는 점이다. 문서는 이를 "스킬이 정확성을 팔아 간결함을 사지 않는다"고 요약한다.

blocking finding은 baseline 7건, candidate 3건이다. candidate가 14개 케이스 중 10개를 이기고 2개는 동점, 2개는 진다.

케이스별 점수

이득은 상태 보고 케이스에 집중된다. multi-step-progress(+2.53)와 error-report(+2.40) 두 케이스가 가중 delta의 대부분을 차지한다. 두 케이스의 baseline 점수가 2.23과 2.07로 유독 낮은 것은, 스킬 없는 응답이 "5단계 중 3단계"라는 상태와 "위치, 원인, 수정"이라는 오류 보고 형식을 기본으로 갖추지 않는다는 뜻이다.

명시적 출력 계약이 있는 케이스는 변화가 없다. code-answer(5.00 대 5.00)와 long-form-request(4.90 대 4.90)는 과제가 모양을 지시하는 케이스이고, 여기서 점수가 움직이지 않은 것은 예외 조항 1과 5가 작동했다는 뜻이다. 문서는 이를 "스킬의 escape hatch가 과제가 모양을 지시하는 곳에서 유지된다"는 의도된 결과로 읽는다.

release gate 실패의 원인

gate는 "blocking finding이 없다"는 조건 1에서 실패한다. candidate에 3건이 있다. 이웃 조건들이 비교 조건인 반면 이 조건은 절대 조건이라, blocker를 절반 이상 줄인(7건에서 3건) candidate도 실패한다.

candidate blocker 3건 중 2건은 어떤 실행도 통과할 수 없는 케이스(agent-owned-edit)에서 나온다. 그 케이스를 빼면 baseline 5건, candidate 1건인데 gate는 여전히 같은 조건으로 실패한다. 문서는 이를 릴리스 중에 발견할 것이 아니라 의도적으로 결정할 gate의 속성이라고 지적한다. 지금 문구대로라면 케이스 집합 어디에든 blocker가 하나라도 남아 있는 한 아무리 개선돼도 어떤 candidate도 통과할 수 없다.

발견 사항 두 가지

agent-owned-edit는 어떤 실행도 통과할 수 없다. criteria가 "편집을 사용자에게 되돌리지 않고 저장소에 직접 행동한다"를 요구하지만, 모든 runner가 --tools ""를 전달하므로 어떤 응답도 무언가에 행동할 수 없다. 두 조건 모두 대부분의 trial에서 blocker를 받고, baseline은 할 수 없는 tool call을 서술하는 상태로 퇴행한다. 케이스에 실제 도구와 fixture 작업 공간이 필요하거나, 진술된 의도를 채점하도록 다시 써야 한다.

partial-success는 조사할 가치가 있는 유일한 candidate 퇴행이다. 평균 -0.63이고 trial 방향이 일관된다(+0.05, -0.70, -1.25). 깨진 케이스 밖의 유일한 candidate blocker가 여기서 나오며, 채점자는 응답이 "'missing auth header'를 확정적 원인으로 단정하고 아무 근거 없이 특정 수정을 처방한다"고 적었다.

이 퇴행에는 그럴듯한 메커니즘이 있다. 규칙 8이 오류를 "원인, 그다음 수정"으로 보고하라고 요구하므로, 근거가 원인을 특정하지 못할 때도 모델이 원인을 이름 붙이도록 압박한다. partial-success 프롬프트는 "expected 200, got 401"이라는 결과만 주고 원인을 주지 않으므로, 원인을 요구하는 형식이 근거 없는 단정을 만들 자리가 있다. trial 3회로는 확인할 수 없지만 일관된 방향과 메커니즘을 모두 가진 유일한 결과라서 trial을 늘릴 가치가 있는 항목이다.

수치 해석의 주의점

• trial 3회는 적다. 케이스별 표준편차가 0.95(casual-message)까지 이른다. 약 0.5 아래의 단일 케이스 delta는 신호로 취급하면 안 되고, 집계가 개별 행보다 더 단단한 근거다
• judge 하나가 자기 계열을 채점한다. 채점자가 응답을 생성한 모델과 같다. 교차 모델 comparator 조건이 다음에 추가할 통제다
• 잔여 artifact가 있다. 84개 응답 중 3개가 tool call 문법을 평문으로 담는다. CLI 시스템 프롬프트가 --tools ""에서도 tool use를 유도하기 때문이며, 두 조건에 모두 영향을 준다(baseline 2, candidate 1)

한계

• 평가 규모. 케이스 14개, trial 3회, 모델 1개(claude-opus-4-8)의 단일 실행이다. 문서 스스로 개별 케이스 delta를 신호로 읽지 말라고 경고한다.
• judge의 독립성. 생성 모델과 채점 모델이 같은 계열이다. 교차 모델 comparator는 계획만 있고 실행 결과가 없다.
• release gate 설계. "blocker 0건" 절대 조건 때문에 케이스 집합에 통과 불가능한 케이스가 하나라도 있으면 어떤 candidate도 통과할 수 없다. 조건을 상대 비교로 바꿀지, 케이스를 고칠지는 결정되지 않았다.
• agent-owned-edit 케이스. --tools "" 환경에서는 채점 자체가 성립하지 않는다. 실제 도구와 fixture 작업 공간을 주거나 진술된 의도를 채점하도록 다시 써야 한다.
• 규칙 8의 부작용 가능성. "원인, 그다음 수정" 형식이 근거 없는 원인 단정을 유도할 수 있다는 메커니즘이 제시됐지만 trial 3회로는 확인되지 않았다.
• 규칙 9의 긴장. 표시 상한 5개와 "완전성이 중요할 때 누락 금지" 단서가 같은 규칙 안에 있어 어느 쪽을 따를지가 모델의 판단에 맡겨진다.
• 플랫폼별 검증 편차. AstronClaw 절차는 문서를 따랐지만 이 스킬로 테스트되지 않았다고 명시한다. Claude Code, Qwen Code, Codex, Grok 이외의 harness는 스킬 description을 시작 시 로드해 스스로 활성화할 수 있다.
• ADHD 근거의 성격. 규칙은 The Adult ADHD Tool Kit에 "느슨하게" 기반하며 임상 근거를 제시하지 않는다. medical-boundary 케이스가 "스타일은 진단이 아니다"를 확인하는 것도 같은 이유다.
• 잔여 artifact. --tools ""에서도 tool call 문법이 평문으로 새는 응답이 84개 중 3개 있다.

핵심 용어

관련 페이지

• Agent Skills (agentskills/agentskills): 이 저장소의 SKILL.md 폴더 규격과 disable-model-invocation frontmatter가 따르는 Agent Skills 오픈 표준
• Equipping agents for the real world with Agent Skills: Anthropic이 소개한 SKILL.md 포맷과 progressive disclosure. 이 스킬의 배포 단위가 여기서 나왔다
• Skills For Real Engineers (mattpocock/skills): user-invoked 스킬에 disable-model-invocation: true와 Codex policy.allow_implicit_invocation: false를 함께 두는 같은 규약을 절차 스킬 25개에 적용한 저장소
• Agent Skills: 스킬 본문에 담을 원칙. 절차 규율을 다루는 반면 i-have-adhd는 응답 모양만 담는다
• gstack: AI-Powered Software Factory: Claude Code skill pack의 다른 사례. 슬래시 커맨드 여러 개로 워크플로를 구조화하는 반면 i-have-adhd는 슬래시 커맨드 하나로 문체만 바꾼다
• Agent Skills 규격과 생태계 지도: 규격, 표준화, 이식 마찰을 합성한 overview. i-have-adhd의 15개 harness 배포는 cross-vendor 채택의 한 사례다
• AI PRD는 무엇이 달라야 하는가: LLM 기능의 평가 계획. i-have-adhd의 evals는 스타일 스킬에 blind judge와 release gate를 적용한 실측이다