SKILL.md)로, "첫 줄에 바로 실행할 것을 놓아라, 여러 단계는 번호를 매겨라, 사족·인사말·요약을 없애라" 같은 출력 셰이핑(output shaping) 규칙을 모델에게 주입한다.
이 프로젝트가 재미있는 이유는, 그 자체가 "프롬프트 엔지니어링을 하나의 설치형 제품으로 패키징한" 살아있는 사례라는 점이다. 성인 ADHD 심리학 책의 전략을 "사람이 하루를 조직하는 법"이 아니라 "LLM이 답하는 법"으로 번역했고, 같은 스킬 폴더 하나를 5가지 매니페스트로 감싸 Claude Code·Codex·Antigravity·npx skills 생태계 어디에나 설치되게 만들었다.
ayghri/i-have-adhd · 순수 마크다운/설정 스킬(코드 0줄, GitHub 감지 언어 없음) · 규칙 10개 · 핵심 파일 SKILL.md 1개 · Claude Code·Codex·Antigravity·npx skills 멀티 하네스 · disable-model-invocation:true로 명시 호출 전엔 잠듦 · 기반: The Adult ADHD Tool Kit · MIT · 약 1,233★ · 클론 소스 직접 분석)
/i-have-adhd 한 번으로 코딩 에이전트의 출력 스타일을 통째로 갈아끼우는 스킬설치는 두 줄이다. claude plugin marketplace add ayghri/i-have-adhd → claude plugin install i-have-adhd@i-have-adhd. 그리고 세션에서 /i-have-adhd를 치면, 그때부터 모든 답변이 첫 줄에 명령/경로/코드부터 나오고, 여러 단계는 번호가 매겨지며, "Great question!"·"Hope this helps!" 같은 사족이 사라진다. 끄려면 "stop adhd mode"라고 말하면 된다.
놀라운 건 그 안에 프로그램이 없다는 것이다. 훅(hook)도, 백그라운드 프로세스도, 파서도 없다. GitHub이 감지한 프로그래밍 언어조차 없음(null)이다. 전부 지시문(instruction) — 즉 잘 쓰인 프롬프트다. "코드 없이 마크다운만으로 도구가 될 수 있다"는 걸 보여주는 표본이다.
이 프로젝트가 겨냥하는 문제는 코딩 에이전트를 써 본 사람이라면 다 안다. "이 인증 버그 어떻게 고쳐?"라고 물으면 AI가 "좋은 질문이에요! 한번 생각해볼게요..."로 시작해 세 문단을 늘어놓는다. 정작 실행할 명령어는 저 아래 파묻혀 있고, 거기까지 스크롤하는 사이 원래 뭘 하려 했는지 잊어버린다. 저자 Ayoub Ghriss는 이 경험을 ADHD 뇌가 겪는 "아는 것과 실제로 하는 것 사이의 마찰"로 규정하고, 그 마찰을 없애도록 출력의 모양 자체를 규칙으로 강제한다.
SKILL.md라는 마크다운 파일 하나로, 맨 위 프론트매터(frontmatter)에 "언제 발동할지"를, 본문에 "무엇을 할지"를 적는다. i-have-adhd는 코드가 전혀 없는 순수 지시문 스킬 — 모델의 행동(=답변 문체)만 바꾼다. 반대로 코드를 실행하는 스킬(예: 파일을 파싱하는 스킬)도 있다.규모는 작지만 반향은 크다. 저장소 전체가 텍스트 파일 12개 + 로고 이미지 1개, 총 121KB에 불과한데도 별이 약 1,233개 달렸고 TrendShift 데일리 #12에 올랐다. "코드가 아니라 잘 벼려진 프롬프트가 오픈소스 스타를 모을 수 있다"는, 요즘 AI 생태계의 단면을 보여주는 프로젝트다.
"AI 답변을 짧게 만드는" 방법은 널려 있다. CLAUDE.md에 "간결하게 답해"라고 한 줄 적을 수도 있다. i-have-adhd가 그 무리에서 눈에 띄는 이유는 "짧게"가 아니라 "ADHD 뇌가 행동으로 옮길 수 있는 모양으로"를 겨냥하고, 그것을 심리학 근거·구체 규칙·재사용 패키지로 완성했기 때문이다. 저자 스스로 FAQ에서 못박는다 — "이거 그냥 terse 아니냐? 아니다. terse는 분위기고, 이건 ADHD 뇌가 읽고·시작하고·도파민이 떨어지는 방식에 맞춘 10개 규칙이다."
README가 내세우는 대표 예시다. 인증 흐름을 고치라는 같은 질문에, 내용은 동일하지만 모양이 다르다.
"좋은 질문이에요! 한번 생각해봅시다. 당신의 인증 흐름에는 여러 조각이 얽혀 있어요 — 미들웨어, 토큰 검증, 쿠키 처리요. src/auth.ts를 보면 verifyToken 함수(42~58줄쯤)가 옛 API를 쓰는 것 같네요. 한 가지 방법은 패키지를 업데이트하고 그 함수를 다시 쓰는 거예요. 그다음 테스트를 돌려보면 좋고요. 그나저나 의존성 버전도 전반적으로 한번 보시는 게... 도움이 됐길 바라요! 더 파보고 싶으면 알려주세요."
→ 독자의 속마음: "그래서 어디를 누르라는 거지?"
npm install jsonwebtoken@latest 실행 후 src/auth.ts:42를 편집하세요.
1. src/auth.ts 열기 2. verifyToken(42~58줄)을 아래 스니펫으로 교체 3. npm test -- auth.spec.ts 실행
다음: 테스트가 실패하면 첫 실패 줄을 붙여넣기.
→ 독자의 속마음: "아. 오케이." (그리고 실제로 실행한다)
차이의 핵심은 "정보량"이 아니라 "행동 가능성"이다. Before도 정답을 담고 있다. 하지만 ADHD 뇌에게 저 형식은 실행으로 이어지지 않는다. After는 첫 줄에 명령을 놓고, 단계를 번호로 끊고, 다음 할 일 하나로 닫는다 — "알았다"에서 "했다"까지의 거리를 최소화한 것이다.
① 근거가 있는 규칙. 10개 규칙은 즉흥이 아니다. SKILL.md 맨 위에 "ADHD 뇌가 읽기에서 무엇이 다른가"라는 5가지 사실(작은 작업기억, 앎≠함, 시작이 가장 어려움, 시간 감각의 균일함, 희소한 도파민)을 먼저 깔고, 각 규칙을 그 사실에서 끌어낸다. 심리학 책 The Adult ADHD Tool Kit(J. Russell Ramsay & Anthony L. Rostain)의 전략을 LLM 문체로 번역했다.
② "제약이 곧 기능". 대부분의 도구는 기능을 더해 가치를 만든다. 이 스킬은 기능을 빼서 가치를 만든다 — 사족·요약·인사말을 "금지어"로 지정한다. "Great question", "Let me...", "Hope this helps!"는 이 모드에서 불법이다. 덜어냄으로 제품이 된 사례다.
③ 과잉교정을 막는 안전장치. 무작정 짧게만 하면 설명이 필요할 때 망가진다. 그래서 규칙을 깨야 할 때 절(when to break the rules)을 따로 뒀다 — "설명해줘/차근차근"이라고 하면 길게, 파괴적 명령(rm -rf·강제 푸시) 앞에선 먼저 확인, 3턴째 안 풀리는 디버그 나선에선 코드 반복을 멈추고 가정을 의심. 규칙에 메타 규칙을 얹은 성숙함이 신뢰를 샀다.
④ 한 번 쓰고 어디에나 설치. 같은 skills/ 폴더 하나를 5개의 매니페스트가 감싸, Claude Code·Codex·Antigravity·npx skills(Cursor·OpenCode·Amp·Pi)까지 한 저장소로 커버한다. "프롬프트 하나를 생태계 전체에 배포하는 패키징 전략"은 그 자체로 배울 거리다.
보통의 AI 답변이 "요점을 맨 마지막에 말하는 장황한 회의 발표"라면, i-have-adhd는 "결론부터 말하고 근거는 뒤에 붙이는 잘 훈련된 참모"다. 회의 발표자는 배경 설명을 3분 하고서야 "그래서 결론은..."을 꺼낸다. 그사이 청중의 절반은 딴생각에 빠진다. 참모는 반대다 — "A안으로 가시죠. 이유는 세 가지입니다"로 시작한다. 듣는 사람이 첫 문장만 들어도 무엇을 해야 할지 안다. 이 스킬은 AI를 발표자에서 참모로 바꾸는 한 장짜리 훈련 매뉴얼이다.
이 저장소엔 백엔드도 프론트엔드도 없다. 대신 배울 "스택"은 에이전트 스킬 생태계 그 자체다 — 하나의 마크다운 지시문을 서로 다른 코딩 도구들이 각자의 방식으로 읽어 설치하게 만드는 패키징 레이어. 핵심은 "내용(SKILL.md)은 하나, 포장(매니페스트)은 여럿"이라는 구조다.
SKILL.md와 YAML 프론트매터모든 것의 중심엔 skills/i-have-adhd/SKILL.md 파일 하나가 있다. 맨 위 프론트매터(---로 감싼 YAML)가 스킬의 메타데이터이자 발동 조건이다.
disable-model-invocation--- 사이에 넣는 메타데이터 블록(YAML)이다. 스킬에서 name은 식별자, description은 "모델이 이 스킬을 언제 쓸지 판단하는 근거"다. 그런데 i-have-adhd는 disable-model-invocation: true를 켜서 모델의 자동 발동을 아예 막는다. 즉 사용자가 /i-have-adhd라고 명시적으로 부르기 전까지 스킬은 잠들어(dormant) 있다. "설치 = 켜짐"이 아니라 "설치 후에도 내가 부를 때만 켜짐" — 문체를 바꾸는 스킬이 원치 않게 상시 발동하는 걸 막는 신중한 선택이다.이 프로젝트의 진짜 영리함은 여기 있다. 같은 skills/ 폴더를 5가지 다른 매니페스트가 각자 감싼다. 각 생태계는 자기 규격의 파일만 읽고, 그 파일이 전부 같은 SKILL.md를 가리킨다.
| 파일 | 대상 하네스 | 역할 |
|---|---|---|
.claude-plugin/plugin.json | Claude Code | "이건 플러그인이다" 선언 |
.claude-plugin/marketplace.json | Claude Code | marketplace add로 설치 가능하게 등록(category: productivity) |
.codex-plugin/plugin.json | Codex(OpenAI) | 버전·키워드·브랜드색(#2563EB)·아이콘까지 담은 상세 매니페스트 |
.agents/plugins/marketplace.json | 범용 agent-skills | URL 소스·설치 정책(AVAILABLE) 지정 |
plugin.json(루트) | Antigravity(agy) | Google Antigravity용 스키마 매니페스트 |
skills/.../agents/openai.yaml | Codex 인터페이스 | 표시명·기본 프롬프트 + allow_implicit_invocation:true |
흥미로운 비대칭이 있다. Claude Code·Antigravity 쪽은 disable-model-invocation:true로 자동 발동을 막지만, Codex용 openai.yaml은 allow_implicit_invocation: true로 은근한 자동 발동을 허용한다. 같은 스킬이라도 하네스마다 "얼마나 알아서 켜질지"를 다르게 설정한 것 — 각 생태계의 관례와 사용자 기대에 맞춘 세심한 조율이다.
npx skills설치 경로도 하네스마다 다르다. Claude Code는 claude plugin marketplace add ayghri/i-have-adhd, Codex는 codex plugin marketplace add ... --ref main, Antigravity는 agy plugin install <URL>, 나머지(Cursor·OpenCode·Amp·Pi)는 범용 CLI npx skills add ayghri/i-have-adhd로 넣는다. CLI 없이도 skills/i-have-adhd 폴더를 에이전트가 스캔하는 경로(예: ~/.cursor/skills/)에 복사만 하면 동작한다. "저장소 = 배포 단위"라, 포크해서 규칙을 고친 뒤 내 저장소를 add 하면 그게 곧 내 커스텀 버전이 된다.
코어와 무관하지만 배울 만한 곁가지가 .github/workflows/에 있다. claude.yml은 이슈·PR 코멘트에 @claude를 달면 anthropics/claude-code-action이 응답하게 하고, claude-code-review.yml은 PR이 열리면 /code-review 플러그인으로 자동 코드 리뷰를 돌린다. 스킬 저장소가 스스로 "Claude Code를 CI에 붙이는 법"의 예제이기도 한 셈이다.
실행되는 코드가 없으니 "아키텍처"란 곧 지시문이 모델의 컨텍스트에 주입되어 출력을 바꾸는 흐름이다. 크게 두 축으로 이해하면 된다 — (A) 언제 켜지고 꺼지는가(활성화 생명주기), (B) 규칙 10개가 어떤 구조로 짜였는가.
"항상 켜기"는 프론트매터를 우회하는 트릭이다. ~/.claude/CLAUDE.md(프로젝트/사용자 전역 지시문 파일)에 "언제나 i-have-adhd 규칙을 따르라"는 한 줄을 넣으면, 슬래시 호출 없이도 매 세션 첫 응답부터 규칙이 적용된다. 플러그인 형태 vs. CLAUDE.md 한 줄의 트레이드오프도 저자가 FAQ에서 짚는다 — 플러그인은 세션별 on/off와 여러 머신 공유가 쉽고, CLAUDE.md는 더 단순하다.
SKILL.md 본문은 아무렇게나 나열된 팁이 아니라 4겹의 논리적 구조다. 이 짜임새가 이 스킬을 "그냥 간결하게 해"와 갈라놓는다.
이 구조는 잘 쓰인 "회사 문서 작성 가이드"와 똑같다. 좋은 가이드는 "이렇게 써라"만 던지지 않는다. 먼저 독자가 어떻게 읽는지(사실)를 설명하고, 그다음 구체 규칙을 좋은 예/나쁜 예와 함께 주고, "이럴 땐 규칙을 어겨도 된다"는 예외를 명시하고, 마지막에 "보내기 전 이걸 지웠는지 확인하라"는 체크리스트로 닫는다. i-have-adhd는 그 문서 작성 가이드를 사람이 아니라 AI를 위해 쓴 것이다 — 그래서 다른 어떤 스킬을 만들 때도 뼈대로 베껴 쓸 수 있다.
| # | 규칙 | 왜 존재하나 |
|---|---|---|
| 1 | 다음 행동부터 말하라 | 앎≠함. 첫 줄은 명령·경로·스니펫. 맥락/계획이 아니라 행동. |
| 2 | 여러 단계는 번호로 | 한 단계=한 행동. "and then"이 두 번 든 단계는 금지. |
| 3 | 구체적 다음 한 걸음으로 끝내라 | 2분 안에 할 수 있는 것 하나. "파일 열기"도 유효. |
| 4 | 사족(tangent) 억제 | 둘째 이슈는 첫째를 끝낸 뒤 "별개 질문"으로. 중간 투척 금지. |
| 5 | 매 턴 상태 복기 | 작업기억은 "지금 5단계 중 3단계"를 못 붙든다. 매번 다시 말하라. |
| 6 | 구체적 시간 추정 | "조금 걸림" 금지. "테스트 있으면 15분, 없으면 반나절"처럼 분 단위. |
| 7 | 완료된 일을 보이게 | "로그인 이제 됨. npm run dev 해보세요"처럼 성취를 앞에. |
| 8 | 에러는 담담하게 | "이런!"·"문제가 있는 것 같아요" 금지. 원인과 해결만. |
| 9 | 목록은 5개까지 | 5개 넘으면 "지금/나중" 또는 "필수/선택"으로 쪼갠다. |
| 10 | 서두·요약·맺음말 없음 | "Great question"·"Hope this helps!" 전부 금지. 답으로 시작해 답에서 끝. |
저장소 전체가 손바닥만 하다. 실행 코드는 없고, "설치 포장(매니페스트)"이 파일 수의 대부분이다. 정작 내용은 SKILL.md 하나에 다 들어 있다. 아래 트리에서 ★가 실제로 읽을 가치가 있는 파일이다.
① skills/i-have-adhd/SKILL.md — 다른 건 다 포장이다. 이 파일 하나가 프로젝트의 실체이자 배울 것의 90%다. 5가지 사실 → 10규칙 → 예외 → 발송 전 검사 순으로 정독하라. → ② README.md — 같은 규칙을 "어떻게 남에게 파는지"(Before/After·표·이모지)를 대조하며 읽으면 좋은 문서화 공부가 된다. → ③ INSTALL.md — 하나의 스킬을 4개 하네스에 배포하는 실전 매뉴얼. → ④ 매니페스트 4종(*.json) — 각 생태계가 요구하는 최소 메타데이터가 무엇인지 비교. → ⑤ .github/workflows/ — Claude Code를 CI에 붙이는 덤 예제.
source: "./")를 가리킨다. claude plugin marketplace add ayghri/i-have-adhd를 하면 Claude Code가 이 파일을 읽어 "아, 이 저장소에 이런 플러그인이 있구나"를 알게 된다. 하네스마다 규격이 조금씩 달라 이 저장소엔 .claude-plugin/·.agents/plugins/ 등 여러 벌이 들어 있다.좋은 시스템 프롬프트를 문서 구석에 묻어두는 대신, i-have-adhd는 그것을 설치·토글·공유·포크 가능한 플러그인으로 만들었다. "내 프롬프트 노하우를 남과 나누는 단위는 무엇인가?"라는 질문에 대한 요즘식 답이다. 여러분이 반복해 쓰는 지시문이 있다면, 그것도 SKILL.md 한 장으로 패키징해 팀에 배포할 수 있다.
10개 규칙을 그냥 나열하지 않고, "ADHD 뇌가 읽기에서 무엇이 다른가"라는 5가지 사실을 먼저 세운 뒤 각 규칙을 거기서 끌어냈다. 이렇게 하면 규칙이 기억되고, 응용되고, 반박 가능해진다. 어떤 지침서를 쓰든 "규칙 → 근거"가 아니라 "근거 → 규칙" 순서가 설득력을 만든다.
강한 규칙은 잘못 적용되면 해롭다. "무조건 짧게"는 설명이 필요한 순간 망가진다. i-have-adhd는 설명 요청·파괴적 명령·디버그 나선·진짜 모호함 네 상황에서 규칙을 완화하도록 메타 규칙을 넣었다. 규칙을 만들 땐 항상 "이 규칙이 해로운 경우"를 함께 적어라 — 이게 아마추어와 프로를 가른다.
"사족을 줄여라"는 모호하다. i-have-adhd는 규칙마다 Bad:와 Good: 실제 문장을 붙여, 모델이 패턴을 흉내낼 수 있게 한다. 프롬프트 엔지니어링의 핵심 기법인 few-shot 예시다. LLM에게 무언가를 시킬 땐 설명 한 줄보다 좋은 예시 두 개가 강하다.
맨 끝의 pre-send check는 모델이 답을 내보내기 직전 스스로 점검하게 만드는 장치다 — "예고하는 첫 문장 삭제, 되묻는 끝 문장 삭제, 그나저나 사이드바 삭제". 이는 사람에게도 통하는 글쓰기 원칙이자, LLM에게 자기 출력을 한 번 더 다듬게 하는 실전 테크닉이다.
내용(SKILL.md)은 하나로 두고, 하네스별 포장(매니페스트)만 여러 벌 얹어 Claude Code·Codex·Antigravity·Cursor를 한 저장소로 커버한다. "코어 로직과 플랫폼 어댑터를 분리한다"는 이 발상은 크로스플랫폼 소프트웨어의 보편 원리 — 프롬프트에도 똑같이 적용된다는 걸 보여준다.
실행 코드가 없으니 하드웨어 요구도 없다. 필요한 건 스킬을 읽을 수 있는 코딩 에이전트(Claude Code·Codex·Antigravity·Cursor 등) 하나뿐이고, 설치는 인터넷에서 저장소를 당겨오는 몇 초면 끝난다. GPU·메모리·디스크는 논외다.
| 항목 | 요구/권장 |
|---|---|
| 런타임 | 없음(실행 코드 0줄). 코딩 에이전트가 알아서 로드 |
| 지원 하네스 | Claude Code · Codex · Antigravity(agy) · Cursor · OpenCode · Amp · Pi 등 agent-skills 호환 도구 |
| 설치(Claude Code) | claude plugin marketplace add ayghri/i-have-adhd → claude plugin install i-have-adhd@i-have-adhd |
| 호출 | Claude Code /i-have-adhd · Codex $i-have-adhd. 끄기: "stop adhd mode" |
| 항상 켜기(선택) | ~/.claude/CLAUDE.md(또는 AGENTS.md/GEMINI.md)에 규칙 한 줄 |
| 디스크 | 저장소 약 121KB(로고 포함). 사실상 무시 가능 |
| 네트워크 | 최초 설치·업데이트 시에만. 이후 로컬 |
INSTALL.md의 트러블슈팅이 알려주는 실전 팁이다. 플러그인 인덱스는 세션 시작 시 읽히므로, 설치 후 /i-have-adhd가 자동완성에 안 보이면 에이전트를 껐다 켜면 된다. 설치했는데도 답변에 여전히 서두가 붙으면 새 세션을 열고, 그래도 새면 SKILL.md의 문구를 더 강하게 다듬으라는 안내까지 있다 — 지시문 스킬의 한계(모델이 100% 순종하진 않음)를 저자도 솔직히 인정한다.
Claude Code에 설치한 뒤, 같은 질문(예: "이 함수 리팩터해줘")을 스킬 켜기 전/후로 던져 답변을 나란히 비교하라. 첫 줄이 어떻게 바뀌는지, "Great question"이 사라지는지, 단계에 번호가 붙는지 눈으로 확인한다. 켜기 /i-have-adhd, 끄기 "normal mode".
저장소를 포크해 skills/i-have-adhd/SKILL.md에서 규칙 하나를 바꿔본다 — 예: "목록 5개 상한"을 3개로, 또는 시간 추정 단위를 "포모도로 개수"로. 내 포크를 claude plugin marketplace add <내아이디>/i-have-adhd로 설치해 변화가 반영되는지 확인하라. 프롬프트 한 줄이 출력을 어떻게 흔드는지 감이 온다.
i-have-adhd의 4겹 구조(사실 → 규칙 → 예외 → 발송전검사)를 뼈대로, 다른 목적의 문체 스킬을 만들어라. 예: "면접관 모드"(답을 되묻는 질문으로 끝내기), "코드 리뷰어 모드"(칭찬 금지·리스크 우선), "6살에게 설명 모드". SKILL.md 하나 + .claude-plugin/ 매니페스트만 있으면 동작한다.
이 스킬(또는 과제 3에서 만든 내 스킬)을 Cursor나 OpenCode에 npx skills add로 설치하거나, CLI 없이 skills/ 폴더를 에이전트 스캔 경로(~/.cursor/skills/ 등)에 복사해 띄워보라. 각 하네스의 매니페스트 규격 차이를 직접 겪으며 "멀티 하네스 배포"의 실체를 이해한다.
~/.claude/CLAUDE.md에 규칙을 넣어 상시 적용해 본 뒤, 어떤 작업에서 오히려 불편한지 기록하라(예: 긴 설계 논의, 탐색적 브레인스토밍). 그리고 SKILL.md의 "규칙을 깨야 할 때" 절이 그 부작용을 얼마나 막아주는지 평가한다. 강한 제약의 득실을 스스로 판단하는 과제다.
좋은 지시문의 기본기를 다진다: 명확·구체, 좋은 예/나쁜 예(few-shot), 단계적 추론 유도, 원하는 형식 명시. i-have-adhd의 SKILL.md를 교재 삼아 "왜 규칙마다 Bad/Good을 붙였는지", "왜 근거를 먼저 깔았는지"를 뜯어본다. Anthropic의 프롬프트 엔지니어링 가이드와 대조하면 이론과 실물이 만난다.
SKILL.md의 프론트매터(name·description·disable-model-invocation)가 각각 무슨 뜻인지, "언제 발동할지"를 description이 어떻게 결정하는지를 익힌다. 직접 간단한 스킬 하나를 만들어 /명령으로 불러본다. 지시문 스킬과 코드 실행 스킬의 차이도 정리한다.
.claude-plugin/plugin.json·marketplace.json의 최소 스키마를 이해하고, 내 스킬을 마켓플레이스로 등록해 marketplace add → install로 설치되게 만든다. 나아가 Codex·Antigravity·npx skills 규격까지 얹어 멀티 하네스 배포를 재현한다. "하나의 내용, 여러 포장"의 실무를 몸으로 익히는 주차다.
이 스킬의 뿌리인 The Adult ADHD Tool Kit의 전략을 훑고, "작업기억·시작 마찰·도파민" 같은 개념이 왜 저 규칙들을 낳았는지 이해한다. 동시에 오웰의 글쓰기 원칙이나 "불필요한 단어를 지워라"류의 고전 글쓰기 규범과 겹쳐 읽으면, 사람에게 좋은 글이 LLM 출력 규칙과 어떻게 통하는지가 보인다. 마지막으로 내 팀/개인용 output-style 스킬을 완성해 배포하며 마무리한다.
ayghri/i-have-adhd, 규칙 10개, 코드 0줄, MIT.SKILL.md 하나. 지시문만 있는 것(i-have-adhd)과 코드를 실행하는 것으로 나뉜다.--- 사이의 YAML 메타데이터. 스킬에선 name(식별자)·description(발동 판단 근거)·disable-model-invocation(자동발동 잠금) 등을 담는다.true면 모델이 스킬을 자동으로 켜지 못한다. i-have-adhd는 이걸 켜서, 사용자가 /i-have-adhd로 명시 호출하기 전엔 잠들어 있게 한다.marketplace.json)는 그 플러그인을 "설치 목록"에 등록하는 카드.skills/ 폴더를 5개 매니페스트로 감싸 Claude Code·Codex·Antigravity·npx skills 등 여러 에이전트에 한 저장소로 배포하는 전략.Bad:/Good: 실제 문장. 설명 대신 예시로 모델이 패턴을 흉내 내게 하는 프롬프트 기법.~/.claude/CLAUDE.md에 규칙 한 줄을 넣어 매 세션 첫 응답부터 적용하는 방법.skills/i-have-adhd/SKILL.md — 규칙 10개 전문(이 프로젝트의 실체)INSTALL.md — 4개 하네스별 설치·항상켜기 전체 가이드