


어떤 AI에서도 쓸 수 있는 스킬 모음을 만들고 관리하기
AI 스킬을 한 저장소에서 관리할 때 쓴다. 필요할 때만 세부 내용을 읽고 목록과 출처를 맞추며, AI 판단 전에 자동 검사를 하고 연구를 단계별로 진행하며, 변경 내용을 공유 저장소에 보내기(push)나 합치기(merge) 전에는 사람의 허락을 받는다.
이 AI 규칙을 사용하려면
## 스킬의 자세한 내용이 쓸 때만 읽히도록 폴더 나누기
각 스킬에 주 지침 파일, 필수 메타데이터, 선택적 참고 자료 및 스크립트 디렉터리를 갖춘 전용 디렉터리를 부여한다. 완전한 예시, 연구 자료, 표준 템플릿, 컬렉션 수준 문서는 명확히 구분된 위치에 보관한다. 사용자나 에이전트가 모든 스킬 본문을 불러오지 않고도 컬렉션을 탐색할 수 있도록 루트 스킬 지도를 유지한다.
이름과 설명을 시작 색인으로 취급한다. 세부 지침, 참고 자료, 스크립트는 스킬이 활성화될 때만 불러온다. 이 구조는 현재 작업에 집중할 여력을 보존하면서 필요할 때 더 깊은 자료를 사용할 수 있게 한다.
## 스킬 본문 파일을 짧게, 어떤 도구에서도 쓸 수 있게 쓰기
스킬의 주 지침 파일은 500줄 미만으로 유지하고 세부 자료는 참고 자료로 옮긴다. 이름과 3인칭 설명을 포함한 YAML 메타데이터를 요구하고, 소문자와 하이픈으로 구성된 디렉터리 이름을 사용하며, 모든 문단이 충분한 정보 가치를 지니는지 검토한다. 스킬이 기초를 명시적으로 가르치는 경우가 아니라면 고급 사용자를 전제로 한다.
플랫폼에 종속되지 않는 지침을 작성한다. 플랫폼 제약이 필수적인 경우가 아니라면 공급업체별 도구를 추상화하고, 개념적 의사 코드를 프로덕션에 바로 사용할 수 있는 코드처럼 제시하지 말고 예시를 이식 가능하게 만든다.
## 스킬을 쓸 때와 쓰지 않을 때의 경계 적기
활성화 조건, 핵심 개념, 실무 지침, 예시, 가이드라인, 주의점, 통합, 참고 자료에 관한 섹션을 포함한다. 모든 활성화 섹션에는 긍정적 트리거와 활성화하지 않아야 하는 경계를 명시하여 인접한 작업을 올바른 스킬로 연결해야 한다.
경험에서 얻은 주의점은 일반적인 지침이 자주 놓치는 실패 양상을 담고 있으므로 특히 중요하게 다룬다. 설치 구조에 따라 링크가 깨질 수 있는 경우 통합 지침에서는 안정적인 일반 텍스트 이름으로 다른 스킬을 참조한다.
## 스킬을 바꾸면 목록과 숫자의 출처를 함께 고치기
스킬을 추가하거나 변경할 때 컬렉션 개요, 배포 매니페스트, 코퍼스 색인을 함께 갱신한다. 탐색, 패키징, 평가가 동일한 산출물을 설명하도록 스킬을 활성화 시나리오, 재사용 가능한 동작 메커니즘, 근거가 되는 주장에 연결한다.
수치, 벤치마크, 변동 가능 정보 또는 공급업체 성능에 관한 주장에는 출처를 기록한다. 스킬이 재사용 가능한 동작 변화나 증거가 중요한 주장을 도입할 때마다 메커니즘 및 주장 레지스트리를 갱신하며, 이러한 관계를 본문에 암묵적으로만 남겨 두지 않는다.
## AI에게 판단을 맡기기 전에 정해진 자동 검사 돌리기
변경을 수락하기 전에 저장소가 선언한 검사를 실행하여 메타데이터 파싱, 엄격한 스키마와 코퍼스 구조, 플랫폼 호환 설치 구조, 스킬 본문의 건전성, 활성화 경계, 적대적 벤치마크를 확인한다. 이를 선택적 진단이 아니라 검토 관문으로 취급한다.
구조, 매니페스트 동기화, 평가 기준 산술, 검색 상태, 레지스트리 형태를 먼저 결정론적으로 검증한다. 해당 검사를 모두 통과한 뒤에만 모델 기반 판단을 사용하고, 재현 가능한 구조적 실패를 정당화하는 데 모델을 사용하지 않는다.
## 예제 프로젝트마다 그 프로젝트의 설치·테스트 명령 쓰기
저장소에 최상위 빌드 시스템이 없다면 새로 만들어 내지 않는다. 각 예시나 하위 프로젝트가 선언한 런타임과 패키지 관리자를 식별한 다음, 해당 프로젝트의 설정, 빌드, 테스트, 린트, 포맷, 유형 검사 명령을 사용한다. 환경과 의존성의 범위를 해당 하위 프로젝트로 제한한다.
반복 작업 중에는 관련된 가장 작은 명령을 실행하고, 검토 전에 하위 프로젝트 문서에 명시된 관문 전체를 완료한다. 하나의 명령이 성공했다는 사실을 모든 관문이 통과했다는 증거로 취급하지 말고 컴파일, 단위 테스트, 비동기 테스트, 린트, 포맷, 정적 유형 검사를 구분한다.
## 연구 한 번 한 번을 제공된 도구로 정해진 단계씩 진행하기
제공된 수명 주기 도구로 모든 연구 실행을 초기화하여 상태 파일, 대기열 항목, 스레드 로그, 출처 평가 골격, 메커니즘 제안 템플릿을 일관되게 생성한다. 지원되는 전이만 사용하여 검색, 평가, 제안, 신규성 검토, 실행 검증, 검토 준비, 종료 단계를 진행하며 실행 상태를 절대 직접 편집하지 않는다.
활성 실행은 저장소 전체 관문과 별도로 검증한다. 실행 준비가 완료되고 필수 검토자가 기록되었으며 준비 검사가 통과된 뒤에만 제안된 메커니즘을 승격한다. 수치, 벤치마크 또는 변동 가능한 주장이 스킬에 들어가기 전에 해당 주장의 출처를 추가한다.
## 자동으로 반복하는 연구에서는 예산이 정해질 때까지 유료 AI를 부르지 않기
반복 과정이 수동으로 시작되든 플랫폼별 스케줄러로 시작되든 탐색, 한 단계 진행, 일일 처리, 상태 보고를 위한 결정론적 명령을 제공한다. 유료 모델 호출 없이도 검색을 사용할 수 있게 유지하고, 명시적 예산 관문이 마련되기 전에는 무인 반복 과정에서 유료 모델을 호출하지 않는다.
대기열, 런타임 로그, 스냅샷, 상태 보고서, 보류된 검토, 이벤트 스트림, 실패 기록, 일반 실행 디렉터리를 소스가 아닌 운영 상태로 취급한다. 의도적으로 지정한 시드 실행을 제외하면 이러한 항목을 절대 커밋하지 않는다.
## 관련 스킬을 복사본 없이 하나의 패키지로 배포하기
호스트가 각 플러그인 소스를 별도로 캐시한다면 여러 패키지가 같은 소스 트리를 가리키게 하지 말고 하나의 패키지로 관련 스킬 컬렉션을 배포한다. 이렇게 하면 중복 캐시를 방지하면서 하나의 일관된 버전 및 매니페스트 경계를 유지할 수 있다.
시작 시에는 탐색에 필요한 메타데이터만 노출한다. 패키지 범위가 영구적인 컨텍스트 부담이 되지 않도록 전체 스킬 본문과 지원 리소스는 활성화될 때까지 불러오지 않는다.
## AI에게 주는 자료를 줄이고 변경 내용을 공유 저장소에 보내기(push) 전에 사람에게 허락받기
컨텍스트 양보다 품질을 우선한다. 집중력에는 한계가 있고 중간 위치의 정보는 손실되기 쉬우므로 자료가 많아지면 성능이 오히려 떨어질 수 있다. 하위 에이전트는 조직 역할을 흉내 내기 위해서가 아니라 범위가 명확한 작업에 집중력을 분리하기 위해 사용한다. 언어 중립적이거나 널리 읽기 쉬운 의사 코드처럼 개념적 예시를 이식 가능하게 유지한다.
결정론적 증거가 모델 판단보다 앞서게 하고 원격 게시를 사람의 통제 아래 둔다. 에이전트는 변경을 준비하고 모든 로컬 관문을 통과할 수 있지만, 푸시하거나 병합하기 전에는 명시적인 사람의 승인을 받아야 한다.
