AI용 연구 스킬 라이브러리를 정리하고 검토된 것만 게시하기

## 각 스킬을 연구 과정의 한 단계에만 배치하기 폴더를 선택하기 전에 라이브러리의 사명을 정의하십시오. 연구 중심 컬렉션은 질문과 문헌 검토부터 아이디어 구상, 데이터 준비, 실험, 학습, 평가, 배포, 소통까지의 경로를 지원해야 합니다. 해당 수명 주기를 반영하는 번호 기반 또는 그 밖의 안정적인 범주를 사용하십시오. 상세 지침을 중복하지 않으면서 작업을 전문 스킬로 라우팅하는 하나의 중앙 오케스트레이션 스킬을 유지하십시오. 제안된 각 스킬에 대해 다음을 수행하십시오. - 수명 주기 단계와 하나의 소유 범주를 식별합니다. - 스킬이 해결하는 사용자 문제와 사용 조건을 명시합니다. - 인접한 대안을 열거하고 어느 경우에 더 적합한지 설명합니다. - 같은 작업에 두 명의 명백한 소유자가 생기는 중복 범위를 피합니다. 분류 체계를 탐색 계약으로 취급하십시오. 소유권이나 보유 목록이 변경될 때마다 카탈로그, 개수, 설명, 로드맵을 업데이트하십시오. ## 한 스킬에 필요한 파일을 한 폴더에 모으기 각 스킬에 필수 메인 가이드가 있는 자체 디렉터리를 제공하십시오. 스킬에 필요한 지원 폴더만 추가하십시오. - `references/`: 상세 공식 문서, API 참고 사항, 튜토리얼, 이슈 패턴, 릴리스 기록을 저장합니다. - `scripts/`: 반복 가능한 보조 작업을 저장합니다. - `templates/`: 재사용 가능한 시작점을 저장합니다. - `examples/`: 완성된 대표 구현을 저장합니다. - `assets/`: 가이드에서 사용하는 코드 이외의 자료를 저장합니다. 메인 가이드는 백과사전이 아니라 진입점입니다. 운영 경로를 설명하고 바로 한 단계 아래의 상세 참조 자료로 직접 연결해야 합니다. 필수 지침을 찾기 위해 하나의 참조 자료에서 다른 참조 자료로 독자를 보내는 연결 구조를 만들지 마십시오. 검증, 아카이브 생성, 레지스트리 동기화가 하나의 명확한 경계에서 작동하도록 스킬 실행에 필요한 모든 파일을 패키지 안에 유지하십시오. ## 메인 가이드 첫머리에 이름, 버전 같은 정해진 항목 쓰기 모든 메인 가이드는 고정된 필드 계약을 사용하는 유효한 YAML 프런트매터로 시작합니다. - `name`: 고유한 케밥 표기법 식별자로, 활동을 설명하는 동명사를 우선합니다. - `description`: 스킬이 무엇을 하고 언제 사용해야 하는지를 모두 설명하는 3인칭 문장입니다. - `version`: 동작이나 지침이 변경될 때마다 업데이트하는 유의적 버전입니다. - `author`: 레지스트리 소스 분류에 사용하는 소유권 값입니다. - `license`: 배포 라이선스입니다. - `tags`: 각 단어의 첫 글자를 대문자로 쓰되, 확립된 두문자어는 대문자를 유지한 용어입니다. - `dependencies`: 명시적인 버전 제약 조건이 있는 선택적 패키지입니다. YAML 구문에서 요구하지 않는 한 스칼라 값을 따옴표로 묶지 마십시오. 설명을 설정된 문자 수 제한보다 짧게 유지하고 `helper`, `tools`, `utilities`처럼 모호한 식별자를 피하십시오. 설명자를 육안으로 확인하지 말고 파싱하여 검증하십시오. 필수 필드 누락, 유효하지 않은 버전, 중복 이름, 잘못된 종속성을 차단 오류로 취급하십시오. ## 메인 가이드는 짧게 두고 자세한 내용은 참고 파일로 옮기기 메인 가이드의 목표 분량을 200~500줄로 정하십시오. 필수 지침이 500줄을 넘으면 필요한 판단을 지나치게 압축하거나 진입점이 제한 없이 커지게 두지 말고 고급 세부 사항을 직접 참조 파일로 옮기십시오. 가이드에는 다음 내용을 포함해야 합니다. - 간결한 목적과 명확한 실행 조건 - 관련 대안과의 비교 - 복잡한 사용 사례를 위한 완전한 워크플로 2~3개 - 순서가 중요한 경우 바로 복사해 쓸 수 있는 체크리스트 - 구체적인 입력 및 출력 예시 - 품질에 중요한 작업을 검증하고 수정한 뒤 반복하는 피드백 루프 - 구체적인 해결책이 포함된 일반적인 문제 섹션 독자가 충분한 역량을 갖췄다고 가정하십시오. 작업에서 이미 암시된 기초 개념이 아니라 분야별 선택 사항과 실패 모드를 설명하십시오. 코드 펜스로 묶인 모든 예시에 언어 식별자를 지정하십시오. 분야에서 필요하다면 약 300 KB 같은 명시적 범위 목표를 두고 정본 출처를 바탕으로 충분한 참조 자료를 구축하십시오. 분량 지표를 달성하려고 문서를 억지로 늘리지 마십시오. 완전성, 추적 가능성, 실용적인 유용성이 계속 목표여야 합니다. ## 스킬을 추가하거나 고칠 때 매번 같은 순서 따르기 새 스킬의 경우: 1. 승인된 로드맵 항목과 소유 범주를 선택합니다. 2. 표준 패키지 구조를 만듭니다. 3. 본문을 확장하기 전에 설명자를 작성하고 검증합니다. 4. 주요 워크플로와 판단 지침을 구축합니다. 5. 필요에 따라 직접 참조 자료, 보조 도구, 템플릿, 예시를 추가합니다. 6. 대표적인 실제 작업으로 스킬을 테스트합니다. 7. 같은 변경에서 카탈로그, 통계, 로드맵을 업데이트합니다. 기존 스킬은 설명자 계약을 보존하고, 버전을 올리고, 메인 가이드를 분량 제한 안에 유지하고, 누락된 워크플로나 문제 해결 지침을 추가한 뒤 대표 사용 사례를 다시 실행하십시오. 기능 브랜치와 범위를 집중한 검토 요청을 사용하십시오. 저장소가 불완전한 스킬을 광고하는 일이 없도록 전체 패키지와 카탈로그 변경을 함께 커밋하십시오. ## 자동 검사와 실제 작업으로 스킬 확인하기 검토 전에 다음 기계적 검사를 실행하십시오. - 메인 파일이 존재하고 프런트매터가 파싱되는지 확인합니다. - 메인 가이드의 줄 수가 200~500줄 목표에 맞는지 계산합니다. - 모든 코드 펜스에 언어가 지정되어 있는지 검증합니다. - 선택한 목표에 따라 참조 자료의 범위를 측정합니다. - 참조된 파일이 메인 가이드에서 정확히 한 단계 아래에 있는지 검사합니다. - 이름, 태그, 버전, 종속성이 해당 스키마를 따르는지 확인합니다. 그런 다음 동작 검증을 수행하십시오. - 현실적인 입력으로 각 주요 워크플로를 실행합니다. - 명시된 출력과 복구 단계를 검증합니다. - 일반적인 실패를 최소 1개 실행해 봅니다. - 해당 스킬이 올바른 도구가 아닐 때 대안이 권장되는지 확인합니다. - 중요한 편집 후마다 반복합니다. 대규모 참조 폴더가 모호한 워크플로를 보완해 주지는 않으며, 잘 다듬어진 개요가 사용할 수 없는 예시를 보완해 주지도 않습니다. ## 승인 후 바뀐 스킬을 스킬 카탈로그에 자동으로 올리기 기본 브랜치에서 변경이 승인되면 어떤 최상위 스킬 패키지가 변경되었는지 탐지하십시오. 변경된 각 패키지에 대해 다음을 수행하십시오. 1. 메인 가이드를 필수로 요구하고 설명자를 파싱합니다. 2. 선언된 소유권 정책에 따라 소스를 분류합니다. 3. 숨겨진 운영 체제 및 버전 관리 파일을 제외하고 전체 패키지를 아카이브합니다. 4. 일치하는 레지스트리 네임스페이스에 아카이브를 업로드합니다. 5. 레지스트리 레코드를 생성하거나 업데이트합니다. 6. 건너뛰거나 실패한 패키지를 동기화된 것으로 조용히 처리하지 말고 보고합니다. 엔드포인트와 인증 값은 자동화 플랫폼의 비밀 저장소에만 보관하십시오. 복구와 테스트를 위한 수동 실행을 지원하되, 자동 및 수동 모드 모두에서 동일한 검증과 패키징 로직이 실행되도록 하십시오. 무해한 버전 변경으로 워크플로를 검증하고, 자동화 실행을 조사하며, 레지스트리 레코드와 아카이브를 확인하십시오. 단순히 파이프라인을 시작하려고 검토되지 않은 편집을 사용하지 마십시오. ## 버전 번호가 바뀔 때만 새 패키지 게시하기 기본 브랜치의 패키지 설명자 버전 변경을 기준으로 패키지를 게시하십시오. 잠금 파일만 변경되었을 때는 새 릴리스를 게시해서는 안 됩니다. 패키지 관리자의 버전 명령을 사용하여 설명자와 잠금 파일이 함께 올라가게 하십시오. 호환성에 따라 패치, 마이너 또는 메이저를 선택하고, 저장소의 릴리스 절차에서 별도 커밋을 요구할 때만 자동 버전 관리 태그 생성을 억제하십시오. 수명이 긴 레지스트리 토큰이 아니라 구성된 신뢰할 수 있는 게시자를 통해 인증하십시오. 게시되는 모든 산출물에 빌드 출처 정보 또는 동등한 공급망 증명을 첨부하십시오. 게시 전에 다음을 검증하십시오. - 신뢰할 수 있는 게시자 ID가 저장소와 워크플로 이름에 정확히 일치합니다. - 환경 변수가 오래된 토큰으로 신뢰할 수 있는 인증을 재정의하지 않습니다. - 커밋된 잠금 파일을 사용한 클린 설치가 성공합니다. - 새 버전이 이전 리비전과 다릅니다. - 패키지 내용이 검토된 소스와 일치합니다. 게시를 건너뛰었거나 인증에 실패했다면 버전 게이트 또는 신뢰할 수 있는 ID를 수정하십시오. 출처 증명을 우회하지 마십시오. ## 개수를 늘리기보다 기존 스킬을 개선하기 라이브러리를 디렉터리 수가 아닌 실행 가능한 전문성으로 평가하십시오. 유용한 스킬은 신뢰할 수 있는 실무를 에이전트가 따르고 검증하고 복구할 수 있는 형태로 정제합니다. 병합 전에 다음을 확인하십시오. - 범위가 하나의 범주에 맞고 기존 소유자와 중복되지 않습니다. - 설명자, 이름 지정, 버전 규칙을 통과합니다. - 메인 가이드가 집중된 상태를 유지하며 필요한 모든 세부 정보에 접근할 수 있습니다. - 필요한 곳에 워크플로, 체크리스트, 예시, 대안, 문제 해결 방법이 있습니다. - 실제 작업으로 지침을 검증합니다. - 카탈로그, 로드맵, 아카이브 자동화, 패키지 릴리스 데이터가 일관성을 유지합니다. 거의 중복되는 스킬을 추가하기보다 기존 스킬을 개선하십시오. 얕은 예시 여러 개보다 작동하는 피드백 루프가 있는 완전한 워크플로 하나를 우선하십시오. 지표가 명확성이나 정확성과 충돌하면 유용한 판단 지침을 보존하고 그 지표가 적절한 대리 변수가 아니었던 이유를 문서화하십시오.