SKILL.md 한 장의 편집 규칙과, 그 규칙을 Claude Code·Codex·ChatGPT 같은 AI 코딩 에이전트에 "플러그인"으로 배포하기 위한 매니페스트·CI 파이프라인으로만 이루어져 있다.
petergyang/no-ai-slop · 라이선스 MIT · 최신 커밋 f284f8c(2026-08-03) · 최신 태그 v1.0.6 · .git 제외 파일 13개 · GitHub 스타 4,037개(2026-08-06 기준) · 정리 기준일 2026-07-29)
No AI Slop은 초안을 붙여넣으면 저자 본인의 어투·문체는 그대로 두고 "AI가 쓴 것 같은" 상투적 표현·구조만 골라 고쳐주는 스킬(Skill)이다. Claude Code, Codex, ChatGPT 같은 AI 코딩 에이전트/챗봇에 /no-ai-slop 명령으로 설치해 쓴다.
기능은 두 가지다. ① 편집(Edit) — 초안을 최소한으로 고쳐 돌려주고 "무엇을 바꿨는지"를 요약한다. ② 감지(Detect) — 글을 고치지 않고 "AI가 썼는지"를 추측하는 대신, 어떤 슬롭 패턴이 어느 문장에 있는지 근거를 대며 짚어준다.
저장소를 열어보면 놀라운 점이 있다. 실행 코드가 사실상 없다. 핵심 산출물인 SKILL.md는 마크다운 문서이고, 유일한 파이썬 스크립트(scripts/build_plugin.py)는 이 마크다운 문서를 배포용 ZIP으로 포장하고 검증하는 역할만 한다. 이 레포에서 배울 것은 "코드 아키텍처"가 아니라 규칙을 얼마나 구체적으로, 얼마나 검증 가능하게 문서화하는가이다.
SKILL.md는 신입 편집자에게 주는 아주 구체적인 스타일 가이드다 — "이런 표현은 쓰지 마라", "이런 문장 구조는 이렇게 고쳐라"를 실제 예문과 함께 못 박아둔다. 그리고 .codex-plugin/plugin.json, scripts/build_plugin.py, .github/workflows/plugin.yml는 이 스타일 가이드를 "ChatGPT 앱스토어에 올릴 수 있는 정식 상품 패키지"로 찍어내는 컨베이어 벨트에 해당한다.
2026년 현재 챗봇으로 글을 쓰는 사람이 급증하면서, 독자들은 "이거 AI가 썼네"라고 느끼게 만드는 특정 패턴들에 피로감을 느끼기 시작했다. 흔히 AI 슬롭(AI slop)이라 부르는 이 현상은 특정 단어(delve, leverage 등)와 특정 문장 구조("It's not X. It's Y.")가 과도하게 반복되며 생긴다. No AI Slop이 주목받는 이유는 세 가지다.
많은 "AI 티 안 나게 써줘" 도구는 막연하다. 이 스킬은 다르다. SKILL.md는 "패턴을 지워라"고 뭉뚱그리지 않고, 바이너리 대조·콜론 리빌·가짜 통찰 설정·가짜 심오한 마무리 등 17개의 이름 붙은 패턴과, delve·leverage·paradigm shift 같은 24개의 금지 단어를 실제 전/후 예문과 함께 못 박는다. "무엇을 고쳐야 하는지"가 애매하지 않다(4장에서 표로 전부 정리).
AI 교정 도구의 흔한 실패는 모든 글을 똑같이 밋밋하게 만드는 것이다. SKILL.md는 정반대를 최우선 원칙으로 못 박는다 — "저자의 어휘·리듬·무뚝뚝함·유머·머뭇거림·산만함을 먼저 파악하고, 그 개성은 유지한 채 최소한의 효과적인 편집(minimum effective edit)만 하라." 강한 사람의 문장은 그대로 두고, 슬롭 패턴만 골라낸다는 것이 핵심 포지션이다.
eval.md는 편집이 끝난 뒤 스킬 스스로가 자기 결과물을 채점하는 체크리스트다. "원칙을 지켰는가, 목소리를 보존했는가, 패턴이 실제로 고쳐졌는가"를 항목별로 확인하고, 실패하면 다시 고친다. 별도의 "평가자 에이전트"를 두지 않고 같은 에이전트가 자기 결과를 자기 체크리스트로 재검토하는 구조라는 점이 README·eval.md에 명시돼 있다.
GitHub 스타 2,700개 이상(2026-08-06 현재 4,037개) · X(트위터) 게시물 노출 611,392회 · 좋아요 5,234개 · 저장 10,519회 · 링크 클릭 13,704회. 저장소 저자 Peter Yang이 자신의 글쓰기 과정("초안 25% 직접 작성 → AI로 중간 50% 편집 → 마지막 25% 직접 재검토")의 가운데 단계에 이 스킬을 쓴다고 README에서 밝히고 있다.
이 저장소에는 "백엔드/프론트엔드"가 없다. 대신 세 계층으로 나눠 보면 정확히 이해된다 — ① 사람이 읽고 AI가 따르는 스킬 본문, ② 그 스킬을 다른 플랫폼에 등록하기 위한 플러그인 매니페스트, ③ 매니페스트와 스킬 본문을 하나의 배포 가능한 파일로 묶는 패키징·CI.
| 계층 | 파일 | 역할 |
|---|---|---|
| 스킬 본문 | SKILL.md | YAML 프런트매터(name, description) + 마크다운 지시문. Claude Code·Codex가 실제로 "읽고 따르는" 유일한 실질 콘텐츠 |
| 자기검증 | eval.md | 편집 후 스스로 채점하는 체크리스트. 스킬 본문과 함께 배포되어 실행 시점에도 참조된다 |
| ChatGPT/Codex 전용 설정 | agents/openai.yaml | OpenAI 계열 에이전트 표면에 보일 표시 이름·설명·기본 프롬프트를 담은 소형 YAML |
| 플러그인 매니페스트 | .codex-plugin/plugin.json | ChatGPT/Codex 플러그인 디렉토리에 등록하기 위한 정식 스키마(이름·버전·설명·아이콘·카테고리·시작 프롬프트 등) |
| 패키징 스크립트 | scripts/build_plugin.py | 매니페스트 검증 → 배포용 디렉토리 조립 → ZIP 압축 → 빌드 결과 재검증까지 하는 순수 파이썬(표준 라이브러리만 사용) 스크립트 |
| CI/배포 | .github/workflows/plugin.yml | PR·main 푸시·태그 푸시 때 빌드 스크립트를 돌리고, 태그(v*) 푸시 시 GitHub Release에 ZIP을 자동 첨부 |
| 법적 고지 | TERMS.md, PRIVACY.md, LICENSE | 플러그인 디렉토리 등록 심사에 필요한 이용약관·개인정보처리방침·MIT 라이선스. 셋 다 플러그인 ZIP 안에도 그대로 포함된다 |
즉 "언어"로 보면 이 저장소의 스택은 마크다운(규칙 본문) + YAML(프런트매터·설정) + JSON(매니페스트) + 파이썬 표준 라이브러리(패키징) + GitHub Actions YAML(CI)이 전부다. 외부 패키지 의존성이 단 하나도 없다 — build_plugin.py는 argparse, json, shutil, zipfile, pathlib만 임포트하는데, 이는 전부 파이썬 표준 라이브러리다.
보통 "레포 분석"이라고 하면 서버가 요청을 처리하는 흐름, DB 스키마, 프론트 컴포넌트 트리를 그린다. 이 레포는 레시피 카드(SKILL.md) + 그 레시피를 검수하는 체크리스트(eval.md) + 레시피를 상품 포장지에 인쇄해 유통사에 납품하는 공정(build_plugin.py + CI)이 전부다. "실행되는 프로그램"이 아니라 "AI가 실행하는 문서"가 핵심 산출물이라는 점이 이 스택의 가장 중요한 특징이다.
---로 감싼 구간에 넣는 메타데이터. SKILL.md의 프런트매터에는 name: no-ai-slop과 description: ... 두 필드만 있다. 이 description 문구가 바로 AI 에이전트가 "지금 이 스킬을 불러와야 하는가"를 판단하는 트리거 문장이다 — 이 문서를 생성한 환경도 정확히 이 방식으로 스킬을 골라 쓴다.이 흐름에서 가장 특이한 설계는 ⑤ → ④의 되돌아가는 화살표다. 대부분의 "AI야, 결과를 스스로 검토해"류 프롬프트는 한 번 훑고 끝내지만, SKILL.md의 Workflow 5단계는 명시적으로 "어느 체크라도 실패하면 초안을 고치고 체크를 다시 돌려라(Step 5)"고 못 박는다. 같은 에이전트, 같은 대화 안에서 편집자 역할과 검수자 역할을 순차적으로 오가게 만든 것이다 — 별도의 "평가자 AI"를 호출하지 않고도 품질 게이트를 만든 셈이다.
SKILL.md의 "Editing principles" 절은 14개 원칙을 나열하는데, 순서 자체가 설계다. 맨 처음이 "저자의 진짜 목소리를 보존하라"이고, 그다음이 "최소한의 효과적인 편집만 하라"다. "AI 패턴을 지워라"는 규칙이 나오기도 전에 "지우지 말아야 할 것"부터 못 박아, 편집이 과도해지는 것을 구조적으로 억제한다.
| 원칙(요약) | 핵심 문장(원문 근거) |
|---|---|
| 목소리 보존 | "First notice the draft's vocabulary, cadence, bluntness, humor, uncertainty... Keep the traits that feel personal" |
| 최소 효과적 편집 | "Fix AI patterns, errors, repetition, and unclear passages. Leave strong human sentences alone." |
| 불필요한 도입부만 컷 | "Cut generic throat-clearing. Keep a personal aside... when it creates context, tension, or character." |
| 능동태 사용 | "'The team shipped it Tuesday' beats 'the decision emerged.' Never let inanimate things do human verbs." |
| 구체성 우선 | "'The integration improved efficiency' becomes 'The integration cut deploy time from 40 minutes to 4.'" |
| 사실 보호 | "'The tool significantly improves engineering productivity' becomes 'The tool cut review time from 30 minutes to 8.'" |
| 강한 동사 | "'Made a decision' becomes 'decided.' 'Has the ability to' becomes 'can.'" |
| 개성·거친 표현 보호 | "Keep strong opinions, blunt language, humor, profanity, self-interruptions... Don't replace them with safer... wording." |
단어 목록도 한 덩어리가 아니라 강도별로 3단계로 나뉜다. 이 구분이 없으면 "just", "actually" 같은 일상 단어까지 기계적으로 다 지워버려 저자의 말투(구어체 리듬)가 사라진다.
| 분류 | 처리 규칙 | 예시(원문) |
|---|---|---|
| 무조건 삭제 (Banned outright) | 맥락 관계없이 항상 삭제 | delve, foster, leverage, utilize, facilitate, empower, streamline, robust, cutting-edge, paradigm shift, game changer, this is huge, this changes everything, tapestry, realm, beacon, multifaceted, meticulous, intricate, paramount, transformative, elevate, embark, supercharge, harness, ever-evolving (24개) |
| 자주 비어있는 부사 (Often-empty adverbs) | 의미 없이 쓰였으면 삭제, 강조·불확실성·억양이면 유지 | just, literally, honestly, simply, actually, truly, fundamentally, importantly, crucially, inherently, inevitably (11개) |
| 자주 비어있는 문구 (Often-empty phrases) | 본론을 늦추면 삭제, 저자 특유의 말버릇이면 가끔은 유지 | it's worth noting, at the end of the day, when it comes to, in today's world, the reality is, in order to, let's dive in 등 (약 20개) |
이 스킬의 핵심 자산이다. 각 패턴은 ① 무엇처럼 들리는지(냄새) ② 실제 전/후 문장 예시로 정의된다. 아래는 SKILL.md 본문에서 그대로 가져온 표다.
| 패턴 | 냄새(무엇처럼 들리는가) | 수정 예 (원문 근거) |
|---|---|---|
| 바이너리 대조 | "It's not X. It's Y." | "The question isn't the model. It's the eval." → "The eval matters more than the model." |
| 헛기침식 도입 | "Here's the thing," "I'll be honest" | 도입 문구를 지우고 곧장 본론으로 |
| 가짜 통찰 설정 | "What nobody tells you..." | "The part everyone misses: distribution is the real moat" → "Distribution is the moat." |
| 콜론 리빌 | "The best part: it learns." | "The detail that makes it work: a separate agent grades it." → "A separate agent does the grading, which is what makes it work." |
| 피상적 분석 | "...highlighting the team's commitment" | "adds file search, highlighting the team's commitment" → "adds file search, so users can find old drafts without leaving the editor." |
| 과잉 의미부여 | "marks a pivotal moment" | "marks a pivotal moment for the company" → "is the company's first paid product." |
| 위즐 인용 | "experts agree," "studies show" | 출처를 명시하거나, 없으면 지운다(지어내지 않고 사용자에게 물어본다) |
| 가짜 강한 동사 | "serves as a centralized hub" | "The app serves as a centralized hub for sponsor management" → "The app tracks sponsors, drafts, due dates, and approvals in one place." |
| 동의어 순환 | the agent → the assistant → the tool | "The agent reviews... The assistant scores... The tool suggests..." → "The agent reviews the draft, scores it, and suggests fixes." |
| 부정 나열 | "Not a X. Not a Y. A Z." | 그냥 Z라고 말한다 |
| 극적 파편화 | "X. And Y. And Z." / "That's it." | 완전한 문장으로 다시 쓴다 |
| 기계적 리듬 | 같은 문장 구조·똑같은 문단 구조 반복 | 도움이 될 때만 구조를 바꾼다 |
| 수사적 설정 | "What if I told you...", "Plot twist:" | 설정을 버리고 바로 요점만 말한다 |
| 가짜 심오한 마무리 | 은유·경구로 끝맺는 "미소드롭" 문장 | 더 나은 은유로 다시 쓰지 말고 삭제한 뒤, 이미 있던 가장 명확한 문장으로 끝낸다 |
| 요약 반복 결말 | "In conclusion," "Ultimately," | 마지막 구체적 요점·다음 행동으로 끝낸다 |
| 포맷 슬롭 | 제목에 이모지, 문장 중간 볼드 남발, 두 문장짜리 섹션에 헤더 | 포맷은 내용을 따라가야지 장식이 아니다 |
| 엠대시(—) 남용 | 기본 리듬 장치로 쓰는 습관 | 짧은 글엔 0개, 긴 글도 콤마·마침표보다 명백히 나을 때만 1~2개 |
SKILL.md는 반복해서 경고한다 — 부사 "just"도, "I think"도, 엠대시도 맥락에 따라 살릴 수 있다. 예를 들어 "often-empty adverbs" 절은 "Cut them when they add nothing. Keep them when they carry emphasis, uncertainty, contrast, or the writer's natural spoken rhythm"이라고 명시한다. 이 스킬을 "무조건 금지어 목록으로 find & replace"하듯 구현하면 원저자의 의도와 반대로 모든 글을 획일화시키는, 이 스킬이 막으려는 바로 그 문제를 재생산하게 된다.
SKILL.md는 감지 요청에 대해 아주 명확한 제약을 둔다: 다시 쓰지 않는다, 점수를 매기지 않는다, AI가 썼는지 추측하지 않는다. 대신 "이 패턴이 있다, 이 문장이 근거다, 이렇게 고치면 된다"만 제시한다. README는 이 결정의 이유를 명시한다 — "AI detectors guess. Named patterns are evidence the user can check." 즉 "AI 여부 판별"이라는, 근본적으로 신뢰하기 어려운 작업 대신 "검증 가능한 증거 나열"이라는 더 좁지만 더 정직한 작업으로 범위를 의도적으로 제한한 것이다.
이 목록에서 눈에 띄는 것은 무엇이 없는가다. package.json도, requirements.txt도, 테스트 프레임워크도, 앱 서버 코드도 없다. "산출물"은 오직 SKILL.md 한 장(9,901바이트)이고, 나머지 12개 파일은 전부 그 한 장을 보증(eval.md)·설명(README)·법적으로 정리(TERMS/PRIVACY/LICENSE)·다른 플랫폼에 맞게 포장(agents/openai.yaml, .codex-plugin, scripts, .github)하는 부속물이다.
| 파일 | 바이트(대략) | 한 줄 역할 |
|---|---|---|
| SKILL.md | 9,901 | 편집·감지 규칙 본문(가장 큼 — 이 저장소의 진짜 무게중심) |
| eval.md | 3,077 | 자기채점 체크리스트 |
| plugin-submission.md | 2,105 | 플러그인 심사 제출 문서 |
| README.md | 2,956 | 사용자 대상 소개·설치·사용법 |
| LICENSE | 1,067 | MIT 전문 |
| TERMS.md | 510 | 이용약관 |
| PRIVACY.md | 470 | 개인정보처리방침 |
| .gitignore | 6 | dist/ 한 줄 |
SKILL.md·eval.md가 캐노니컬 소스이고, scripts/build_plugin.py가 빌드 시 이 둘을 그대로 복사해 배포판(dist/no-ai-slop/skills/no-ai-slop/)에 넣는다. 5-절에서 다루듯 빌드 스크립트는 복사본이 원본과 바이트 단위로 동일한지까지 검증한다.description은 "Use when the user wants a draft clearer, more direct, more opinionated, or less AI-sounding, or asks whether writing reads as AI"처럼 언제 이 스킬을 불러야 하는지를 명확한 트리거 문구로 못 박는다. 이 문서 서두의 시스템 안내에 나열된 다른 스킬들의 description도 전부 이 패턴을 따른다 — 막연한 요약이 아니라 "이런 요청이 오면 반드시 사용"이라는 조건문에 가깝다.이 스킬처럼 "이름 + 냄새 + 전/후 예문" 형식으로 자신이 자주 겪는 글쓰기 습관(예: 문장이 항상 "그래서"로 시작한다, 결론을 항상 질문으로 끝낸다) 하나를 SKILL.md 스타일로 규칙화해보자. 그리고 실제 자기 글에 적용해 규칙이 잘 작동하는지 확인한다.
validate_source() 함수는 plugin.json의 필수 필드(name, version, description, author, skills, interface)와, interface 안의 하위 필수 필드(displayName, shortDescription, longDescription, developerName, category, capabilities, defaultPrompt)가 다 채워져 있는지 확인하고, 하나라도 비면 SystemExit으로 즉시 빌드를 중단시킨다.defaultPrompt는 "최대 3개, 각 128자 이하"라는 ChatGPT 플러그인 디렉토리 쪽 제약을 if len(prompts) > 3 or any(len(prompt) > 128 for prompt in prompts)로 그대로 코드에 옮겨뒀다. 사람이 매번 손으로 세지 않아도 된다.validate_build()는 압축한 ZIP 안의 파일 목록이 기대한 7개 경로와 정확히 일치하는지, 그리고 압축된 SKILL.md·eval.md가 원본과 바이트 단위로 동일한지까지 확인한다. 즉 "패키징 과정에서 실수로 내용이 달라지는 드리프트"를 구조적으로 차단한다.--check 플래그를 주면 검증만 하고 dist/를 정리하고, 안 주면(plugin.yml이 그렇게 호출한다) 결과물을 남겨 다음 스텝(아티팩트 업로드·릴리스 첨부)이 쓸 수 있게 한다. 로컬 개발자용 모드와 CI용 모드를 옵션 하나로 나눈 것이다.plugin.yml은 v* 태그가 푸시될 때만 gh release create "${GITHUB_REF_NAME}" dist/no-ai-slop-plugin-*.zip --generate-notes --verify-tag를 실행해 릴리스를 만든다. PR·일반 push에서는 빌드·검증만 하고 릴리스는 만들지 않는다 — "검증은 항상, 배포는 태그가 있을 때만"이라는 구분이 워크플로 조건(if: startsWith(github.ref, 'refs/tags/v'))에 그대로 드러난다.로컬 클론에서 plugin.json의 defaultPrompt에 항목을 4개로 늘리거나 129자짜리 프롬프트를 넣고 python3 scripts/build_plugin.py --check를 실행해본다. SystemExit 메시지가 정확히 어떤 조건에서 뜨는지 직접 확인하면 "검증 코드를 방어적으로 짜는 법"이 손에 잡힌다.
| 목적 | 요구사항 | 근거 |
|---|---|---|
| 스킬을 AI 에이전트에 설치해 쓰기 | Claude Code·Codex·ChatGPT 등 스킬을 지원하는 AI 하네스 하나. 별도 설치 프로그램·계정·서버 불필요 | README: "Paste this into Claude Code, Codex, or your favorite AI harness: 'Install this skill globally: https://github.com/petergyang/no-ai-slop'" |
| 스킬을 로컬에서 편집·확인 | 텍스트 에디터 하나(마크다운 파일이므로) | SKILL.md·eval.md는 순수 마크다운 |
| 플러그인 ZIP 빌드/검증 | Python 3.12(CI 기준), 추가 pip 설치 불필요(표준 라이브러리만 사용) | .github/workflows/plugin.yml의 actions/setup-python@v7 설정 + build_plugin.py의 import 목록 |
| 태그 릴리스에 ZIP 자동 첨부 | GitHub Actions 실행 환경(ubuntu-latest) + contents: write 권한 + gh CLI(러너에 기본 포함) | .github/workflows/plugin.yml |
| ChatGPT/Codex 플러그인 디렉토리 제출 | 공개 GitHub 저장소 + 태그된 릴리스(ZIP 첨부) + 아이콘 이미지(assets/no-ai-slop.png) + 이용약관·개인정보처리방침 URL | .codex-plugin/plugin.json의 privacyPolicyURL/termsOfServiceURL 필드가 TERMS.md/PRIVACY.md의 GitHub 링크를 직접 가리킴 |
① Claude Code/Codex 등에서 "Install this skill globally: https://github.com/petergyang/no-ai-slop"를 그대로 붙여넣는다.
② 이후 아무 대화에서나 /no-ai-slop 뒤에 초안을 붙여 편집을 요청하거나, "is this AI slop?"과 함께 검사할 글을 붙인다.
① git clone --depth 1 https://github.com/petergyang/no-ai-slop.git
② SKILL.md, eval.md를 읽어 규칙 원문을 확인한다.
③ (선택) python3 scripts/build_plugin.py --check로 플러그인 패키징이 로컬에서도 재현되는지 확인한다. 추가 의존성 설치가 필요 없다.
일반적인 소프트웨어 레포처럼 npm install·서버 기동 같은 절차를 기대하면 안 된다. 유일하게 "실행"할 만한 것은 scripts/build_plugin.py 하나뿐이고, 그 목적도 "앱을 띄우는 것"이 아니라 "정적 문서 두 개(SKILL.md, eval.md)를 규격에 맞는 ZIP으로 포장하는 것"이다.
자신이 최근에 쓴 이메일·블로그 초안 하나를 스킬에 붙여넣고 편집을 요청한다. 돌아온 "What changed" 요약과 표(4-3절)를 나란히 놓고, 실제로 어떤 패턴이 몇 번 걸렸는지 세어본다. 그 다음 원래 글에서 정말 저자 목소리가 살아있는 문장이 편집 후에도 그대로 남았는지 확인한다.
일부러 슬롭 패턴을 3~4개 심은 문단과, 슬롭이 없는 자연스러운 문단을 각각 만들어 "is this AI slop?"으로 검사해본다. 패턴표(4-3절)에 없는 표현인데 잘못 걸리거나(오탐), 반대로 패턴에 해당하는데 안 걸리는 경우(미탐)를 찾아 SKILL.md의 규칙 문구와 대조해본다.
python3 scripts/build_plugin.py --check를 실행해 Built dist/no-ai-slop-plugin-1.0.4.zip 로그를 확인한다. 그 다음 .codex-plugin/plugin.json을 임시로 복사해 author 필드를 지우고 다시 실행해 SystemExit 메시지가 정확히 뜨는지 본다(실습만 하고 원본은 되돌린다).
다른 도메인(예: 코드 리뷰 코멘트 톤, 커밋 메시지 스타일)에 대해 같은 형식 — 원칙, 금지어/패턴 표, 워크플로, 자기검증 체크리스트 — 으로 SKILL.md를 작성하고, build_plugin.py를 참고해 자신만의 패키징 스크립트와 GitHub Actions 워크플로를 만들어본다.
이 스킬의 감지 모드 설계 원칙("점수 매기지 않기, 추측하지 않기, 근거 인용하기")을 그대로 다른 심사 작업(예: 계약서의 모호한 조항 찾기, PR 설명의 누락된 정보 찾기)에 적용한 SKILL.md를 설계해본다. 핵심은 "결론을 단정하지 않고 검증 가능한 증거만 나열한다"는 제약을 그대로 지키는 것이다.
| 주차 | 주제 | 구체적으로 할 일 |
|---|---|---|
| 1주 | 스킬(프롬프트) 설계 기초 | SKILL.md의 YAML 프런트매터(name, description)가 어떻게 트리거로 쓰이는지 이해하고, 자신이 자주 쓰는 AI 하네스의 스킬/커스텀 명령 문서를 찾아 SKILL.md와 형식을 비교한다. |
| 2주 | 글쓰기 편집 이론 — AI 슬롭이 왜 생기는가 | 4장의 17개 패턴을 실제 뉴스레터·블로그 글에서 하나씩 찾아 표시해보고, "왜 언어모델이 이런 표현을 반복적으로 고르는 경향이 있는지"를 자기 나름대로 정리한다. |
| 3주 | 자기검증(self-critique) 프롬프트 패턴 | eval.md 같은 "생성 후 체크리스트 재검토" 구조를 직접 설계해보고, autoresearch 스타일의 keep/revert 반복 실험 루프와 비교해 "검증 기준이 명확할 때"와 "측정 가능한 지표가 있을 때"의 차이를 정리한다. |
| 4주 | 플러그인/매니페스트 패키징 | plugin.json의 스키마를 손으로 채워 다른 미니 플러그인 매니페스트를 만들어보고, build_plugin.py의 검증 함수(validate_source, validate_build) 구조를 그대로 따라 자신의 패키징 스크립트를 짠다. |
| 5주 | 멀티 플랫폼 배포 전략 | 같은 SKILL.md를 Claude Code(그대로), Codex/ChatGPT(.codex-plugin 경유), 그리고 자체 웹사이트(README 경유)까지 세 경로로 동시에 배포하는 구조를 .github/workflows/plugin.yml을 참고해 자신의 레포에 적용해본다. |
| 용어 | 뜻 |
|---|---|
| AI 슬롭 (AI slop) | AI가 쓴 글에서 반복적으로 나타나 "AI 티"로 느껴지는 상투적 표현·구조 |
| SKILL.md | 이름·설명(description) 프런트매터 + 지시문 본문으로 이뤄진, AI 에이전트가 특정 상황에 불러와 따르는 마크다운 규칙 파일 |
| eval.md | 편집이 끝난 뒤 스킬 스스로 자기 결과물을 채점하는 pass/fail 체크리스트 |
| YAML 프런트매터 | 마크다운 파일 맨 위 --- 사이에 넣는 메타데이터 블록. SKILL.md에서는 name, description 두 필드만 사용 |
| 셀프 크리틱 루프 | 같은 에이전트가 결과를 만들고, 체크리스트로 스스로 재검토·수정하는 패턴. 별도의 평가자 모델 없이 품질을 관리한다 |
| 바이너리 대조 (binary contrast) | "It's not X. It's Y." 형식의 대조 문장. Y만 직접 서술하도록 고친다 |
| 콜론 리빌 (colon reveal) | 명사구 + 콜론 + 극적인 소문자 반전으로 끝맺는 문장 패턴 |
| 위즐 인용 (weasel attribution) | "experts agree," "studies show"처럼 출처 없이 권위를 빌리는 표현 |
| 가짜 심오한 마무리 (fake-profound kicker) | 은유·경구로 글을 마무리하는 "미소드롭" 문장. 다른 은유로 바꾸지 않고 통째로 삭제하는 것이 규칙 |
| 최소 효과적 편집 (minimum effective edit) | 슬롭·오류·반복만 고치고 강한 인간적 문장은 그대로 두는 편집 원칙 |
| 플러그인 매니페스트 (plugin manifest) | ChatGPT/Codex 같은 플랫폼에 등록하기 위해 이름·설명·아이콘·시작 프롬프트 등을 정의한 JSON 규격 파일 |
| defaultPrompt 제약 | ChatGPT 플러그인 디렉토리가 요구하는, 시작 프롬프트는 최대 3개·각 128자 이하라는 규칙 |
| 캐노니컬 소스 (canonical source) | 여러 곳에 복사되는 콘텐츠 중 "진짜 원본"으로 취급되는 파일. 이 레포에서는 루트의 SKILL.md·eval.md |
| 바이트 단위 검증 | 패키징된 사본이 원본과 완전히 동일한 바이트열인지 확인해 "패키징 드리프트"를 막는 방식 |
| 태그 기반 릴리스 | v* 형식의 git 태그가 푸시될 때만 GitHub Release와 배포 아티팩트를 자동 생성하는 CI 패턴 |
| gh release --verify-tag | GitHub CLI로 릴리스를 만들 때 태그의 서명·존재를 검증하도록 요구하는 옵션 |
| ChatGPT 앱 디렉토리 (plugin directory) | ChatGPT/Codex 사용자가 서드파티 플러그인을 검색·설치할 수 있는 공개 목록 |
| 25/50/25 프로세스 | 저장소 저자 Peter Yang이 README에서 밝힌 자신의 글쓰기 습관 — 초안 25% 직접 작성, 중간 50% AI로 편집(이 스킬 사용 구간), 마지막 25% 직접 재검토 |
| 포맷 슬롭 (formatting slop) | 제목 이모지, 문장 중간 볼드 남발, 두 문장짜리 섹션에 헤더를 넣는 등 "내용과 무관한 장식적 포맷팅" |
| 워크플로(Workflow) 6단계 | SKILL.md 맨 끝에 정의된 실행 순서 — 전체 읽기 → 목소리 신호 메모 → (감지면 리포트 후 종료) → 최소 편집 → eval.md로 자기채점 → 실패 시 반복 수정 |