AI 코딩 에이전트용 스킬 25개와 명령 9개 공개

TL;DR 속보

- 사건: addyosmani/agent-skills는 AI 코딩 agent를 위한 프로덕션급 엔지니어링 skill 25개를 제공하며, 선임 엔지니어의 워크플로, 품질 게이트, 베스트 프랙티스를 agent가 일관되게 실행할 수 있는 모듈로 패키징한다

- 구조: 6개 라이프사이클 단계(정의/계획/구축/검증/리뷰/배포)가 9개 slash 명령에 대응하며, 각 명령은 해당 skill을 자동 활성화한다

- 핵심 트레이드오프: /build auto가 없애는 것은 '작업 사이에 사람이 개입하는' 단계이지 검증이 아니다 — 각 작업은 여전히 테스트 주도이고 개별 커밋되며, 실패하거나 위험한 단계에서는 일시 정지한다

- 진짜 영향력은 인터페이스에 있다: 설치 CLI를 통해 70개 이상의 agent(Claude Code, Cursor, Codex, Copilot, Cline 등)에 설치할 수 있다 — 동일한 skill 정의를 모델 간 재사용

- 수치 기준 교정: 저장소 ★95,899 / fork 10,148 / MIT, 2026-02-15 생성, 7개월간 축적, 오늘은 그저 다시 일간 순위에 올라섰을 뿐(하루 신규 약 680)

addyosmani/agent-skills는 엔지니어링 규율을 skill로 인코딩한 저장소로, 공식 설명은 "AI 코딩 agent를 위한 프로덕션급 엔지니어링 스킬"이다. 핵심 주장은 아주 직접적이다: skill은 모델이 매번 스스로 올바르게 하기를 기대하는 것이 아니라, 선임 엔지니어가 소프트웨어를 만들 때 사용하는 워크플로, 품질 게이트, 베스트 프랙티스를 담아야 한다. 실시간 데이터는 ★95,899, fork 10,148, MIT 라이선스다.

먼저 교정해야 할 사실이 하나 있다: 이 저장소는 2026년 2월 15일에 생성되어 이미 7개월을 축적했다. 오늘 GitHub 일간 랭킹에 다시 나타났으며 하루 신규 약 680 스타다 — "막 출시해서 폭발한" 것이 아니라 성숙한 저장소가 재발견된 것이다. 이 구분은 중요하다: 아래 내용은 7개월간 반복 개선해서 나온 것이지, 막 다 쓴 설계 초안이 아니다.

一、개발 프로세스를 여섯 단계로 자르고, 다시 아홉 개 명령을 붙인다

저장소의 골격은 흐름도 하나로, 여섯 단계가 차례로 진행된다:

DEFINE PLAN BUILD VERIFY REVIEW SHIP ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ Idea │ ───▶ │ Spec │ ───▶ │ Code │ ───▶ │ Test │ ───▶ │ QA │ ───▶ │ Go │ │Refine│ │ PRD │ │ Impl │ │Debug │ │ Gate │ │ Live │ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ └──────┘ /spec /plan /build /test /review /ship

아홉 개 명령은 각각 한 문장의 원칙을 동반하는데, 나는 실제 구속력에 따라 세 부류로 나눠 본다:

"먼저 올바른 일을 하게 하는" 세 개: /spec(코드보다 스펙을 먼저 쓴다), /plan(작고 원자적인 작업으로 쪼갠다), /constraints(한 번 정하고, 모든 곳에서 집행한다).

"올바르게 하게 하는" 네 개: /build(한 번에 한 조각), /test(테스트가 곧 증거), /review(코드 건강도 개선), /code-simplify(명료함이 기교보다 우선).

"안정적으로 배포하게 하는" 두 개: /webperf(측정 먼저, 최적화 나중), /ship(더 빠른 것이 더 안전한 것).

이 분할에서 주목할 점은: 품질 요구를 명령 계층으로 전진 배치했다는 것이다. /constraints의 "한 번 정하고, 모든 곳에서 집행한다"라는 문장은 아주 구체적인 엔지니어링 문제에 대응한다 — 제약을 매번 모델에게 상기시키는 방식에 기대면 반드시 표류한다; 한 번 정의하고 반복 집행하는 메커니즘으로 만들어야 안정적이다.

skill은 문맥에 따라 자동 활성화되기도 한다: API를 설계하면 api-and-interface-design이 트리거되고, 인터페이스를 구축하면 frontend-ui-engineering이 트리거된다. 즉, 명시적으로 명령을 입력하는 것 외에도 암묵적 경로가 하나 있다 — 당신이 지금 무엇을 하고 있는지가 어떤 스킬을 로드할지를 결정한다.

二、/build auto: 없애는 것은 "사람"이지 "검증"이 아니다

이것은 저장소 전체에서 설계가 가장 정교한 부분이다.

/build auto는 규격이 확정된 후 agent가 계획을 생성하고 모든 작업을 자율적으로 구현하게 한다: 계획을 한 번 승인하면 그다음은 스스로 끝까지 달린다. 공식 설명에는 핵심적인 단서가 한 문장 있다:

그것이 없애는 것은 작업 사이의 사람 단계이지 검증이 아니다 — 각 작업은 여전히 테스트 주도이고, 여전히 개별 커밋되며, 실패하거나 위험한 단계에서는 일시 정지한다.

나눠 보면, 이 단서는 세 가지 일을 한다:

첫째, "한 번 승인"이 계획 단계를 취소하지 않는다. 계획은 여전히 생성되어야 하고, 사람이 한 번 봐야 한다.

둘째, 작업 입자 크기는 변하지 않는다. 각 작업은 테스트 주도이고 개별 커밋된다 — 이는 문제가 생겼을 때 구체적인 커밋까지 특정할 수 있다는 뜻이며, 거대하게 뒤섞인 변경을 마주하지 않아도 된다는 뜻이다.

셋째, 일시 정지 조건이 명확히 보존된다. 실패하거나 위험한 단계에서는 멈춘다. "자율"의 경계는 성공 경로가 아니라 실패 경로에 적혀 있다 — 이것이 바로 맞다: 성공 경로에는 사람이 필요 없고, 실패 경로에야 사람이 필요하다.

이 설계는 agent 자동화를 하는 사람에게 직접적인 참고 가치가 있다: 자동화의 범위는 "성공할 때 얼마나 빨리 달릴 수 있는가"가 아니라 "실패할 때 누가 이어받을 수 있는가"로 정의되어야 한다.

三、진짜 영향력은 "이식성"에 있다

25개 skill의 내용보다 더 중요한 것은 그것들의 배포 방식이다.

저장소는 오픈소스 skills CLI를 통한 설치를 지원하며, 공식에 따르면 이 CLI는 70개 이상의 agent에 설치할 수 있다 — Claude Code, Cursor, Codex, Copilot, Cline 등등. 전체 설치:

npx skills add addyosmani/agent-skills # 25개 skill 전체 설치 npx skills add addyosmani/agent-skills --list # 먼저 둘러본 뒤 설치

단일 항목만 설치할 수도 있다:

npx skills add addyosmani/agent-skills --skill code-review-and-quality # 병합 전 5축 리뷰 npx skills add addyosmani/agent-skills --skill interview-me # 요구사항 캐묻기, 한 번에 한 질문 npx skills add addyosmani/agent-skills --skill test-driven-development # 레드-그린-리팩터, 강제 실행

"동일한 skill 정의를 서로 다른 모델에서 실행할 수 있다"는 점의 영향은 개별 skill의 품질보다 크다.

그것은 표준화의 대상을 모델에서 행위로 바꾼다. 예전에 팀이 "우리는 코드를 어떻게 리뷰하는가"를 통일하려는 방식은 문서를 쓰고 사람이 외우는 것이었다; 이제는 skill로 써서 서로 다른 사람, 서로 다른 agent, 서로 다른 모델이 같은 프로세스를 실행하게 할 수 있다. vendor 의존성이 우회된다 — skill은 모델 무관 자산이다.

이것이 이 저장소의 스타 규모가 이 위치까지 올 수 있었던 이유이기도 하다: 그 가치는 그것 자체가 얼마나 쓰기 좋은가가 아니라, 남들이 반드시 호환해야 하는 사실상의 인터페이스가 될 수 있다는 데 있다. 생태계 위치에서 보면, 이는 어느 단일 기능보다 대체하기 어렵다.

내가 스스로 프로세스를 축적하는 습관도 같은 순서다: 먼저 적고, 그다음 반복 실행할 수 있는 형태로 고치고, 마지막에야 남이 재사용할 수 있는지를 고려한다. 순서가 뒤집히면 내용은 아무도 보지 않는 방법론이 된다. 墨衍에서는 소재와 작업 규약을 한곳에 모아 두어 도구 사이를 오가며 옮기는 수고를 덜었다.

四、명확히 기록해 둔 이식성 공백

저장소에는 설치 방식에 관한 경고가 한 단락 있는데, 아주 실질적이라 원문대로 옮겨 둘 만하다:

단일 skill만 설치할 때, per-skill npx 설치는 skills/<name>/만 복사하고 저장소 수준의 references/ 디렉터리는 복사하지 않는다. skill 자체는 여전히 사용 가능하지만, 공유 목록을 가리키는 경로가 무효가 된다. 해결책은 저장소 전체 통합을 쓰거나, 저장소를 클론하거나, 필요한 목록을 설치된 skill 내부의 references/ 디렉터리로 수동 복사하는 것이다.

이 공백은 저장소의 issue #361에 기록되어 있으며, 숨기지 않았다.

그것이 드러내는 문제는 그 자체보다 더 중요하다: skill의 의존 관계는 계층적이다. 단일 skill은 독립적으로 설치할 수 있지만 저장소 수준의 공유 자원에 의존할 수 있다 — 이런 "부분 설치 곧 성능 저하" 상황은 모듈형 배포를 하는 사람이라면 누구나 겪는 일이다. 공식이 이것을 issue에 숨기지 않고 README 맨 위에 적기로 한 선택은, 그 처리 방식 자체가 배울 만하다.

五、바로 베껴 갈 수 있는 세 가지

첫째, 팀에서 반복적으로 나오는 리뷰 의견을 채팅 기록에 남기지 말고 checklist로 만들어라. 공식 사이트의 세 가지 예시 skill의 주제 선정은 시사하는 바가 크다: code-review-and-quality(병합 전 5축 리뷰), interview-me(요구사항 캐묻기, 한 번에 한 질문), test-driven-development(레드-그린-리팩터). 이 세 가지의 공통점은: 여러 번 말했지만 매번 실행이 다르다는 것이다. 이런 "고빈도 + 고표류" 고리는 skill화하기에 가장 적합하다.

둘째, 명령은 동작만이 아니라 원칙에 묶여야 한다. /webperf에 대응하는 원칙은 "측정 먼저, 최적화 나중"이고, /code-simplify는 "명료함이 기교보다 우선"이다 — 동작은 잘못 기억될 수 있지만 원칙은 그렇지 않다. 자기 팀의 명령을 쓸 때는 원칙을 동작과 함께 적어라.

셋째, 자동화의 경계는 실패 경로에 적어라. /build auto의 처리를 참조하라: 자율 실행을 허용하되, 사람을 기다리며 멈추는 조건을 명확히 나열한다.

마지막 판단: 25개 skill 중 당신이 다 쓸 수 있는 것은 아닐지 모르지만, **"skill은 이식 가능한 자산"이라는 인식은 먼저 받아들일 가치가 있다** — 그것이 앞으로 당신이 팀의 엔지니어링 지식을 어떻게 조직할지를 결정한다. 당신의 팀이 여러 개의 서로 다른 AI 코딩 도구를 쓰고 있다면, 프로세스를 skill로 쓰는 수익은 도구 수가 늘어날수록 커질 것이다.