| name | agent-sort |
| description | 기술, 명령어, 규칙, 훅 및 기타 요소를 DAILY 대 LIBRARY 버킷으로 분류하여 특정 저장소에 대한 증거 기반의 ECC 설치 계획을 수립합니다. 전체 번들을 로드하는 대신 프로젝트에 실제로 필요한 것만 ECC를 트리밍해야 할 때 사용하세요. |
| origin | ECC |
에이전트 분류 (Agent Sort)
기본 전체 설치 대신 프로젝트별 ECC 표면이 필요한 경우 이 스킬을 사용하세요.
목표는 "유용해 보이는 것"을 추측하는 것이 아닙니다. 실제 코드베이스의 증거를 바탕으로 ECC 구성 요소를 분류하는 것입니다.
사용 시점
- 프로젝트에 ECC의 일부만 필요하고 전체 설치가 너무 번거로울 때
- 저장소 스택은 명확하지만 기술을 하나씩 수동으로 선별하고 싶지 않을 때
- 의견이 아닌 grep 증거에 기반한 반복 가능한 설치 결정을 원할 때
- 항상 로드되는 데일리 워크플로우 표면과 검색 가능한 라이브러리/참조 표면을 분리해야 할 때
- 저장소가 잘못된 언어, 규칙 또는 훅 세트로 흘러가서 정리가 필요할 때
타협할 수 없는 규칙
- 일반적인 선호도가 아닌 현재 저장소를 진실된 근거로 사용하세요.
- 모든 DAILY 결정은 실제 저장소의 구체적인 증거를 인용해야 합니다.
- LIBRARY는 "삭제"를 의미하지 않습니다. "기본적으로 로드하지 않고 액세스 가능하게 유지"함을 의미합니다.
- 현재 저장소에서 사용할 수 없는 훅, 규칙 또는 스크립트를 설치하지 마세요.
- ECC 네이티브 표면을 선호하며, 제2의 설치 시스템을 도입하지 마세요.
출력물
다음 아티팩트를 순서대로 생성합니다:
- DAILY 인벤토리
- LIBRARY 인벤토리
- 설치 계획
- 검증 보고서
- 프로젝트가 원하는 경우 선택적인
skill-library 라우터
분류 모델
두 가지 버킷만 사용합니다:
DAILY
- 이 저장소의 모든 세션에서 로드되어야 함
- 저장소의 언어, 프레임워크, 워크플로우 또는 운영 표면과 강력하게 일치함
LIBRARY
- 보유하는 것이 유용하지만 기본적으로 로드할 가치는 없음
- 검색, 라우터 기술 또는 선택적인 수동 사용을 통해 도달 가능해야 함
증거 소스
분류를 수행하기 전에 저장소 로컬 증거를 사용하세요:
- 파일 확장자
- 패키지 관리자 및 잠금 파일
- 프래임워크 구성
- CI 및 훅 구성
- 빌드/테스트 스크립트
- 임포트 및 종속성 매니페스트
- 스택을 명시적으로 설명하는 저장소 문서
유용한 명령어:
rg --files
rg -n "typescript|react|next|supabase|django|spring|flutter|swift"
cat package.json
cat pyproject.toml
cat Cargo.toml
cat pubspec.yaml
cat go.mod
병렬 리뷰 패스 (Parallel Review Passes)
병렬 하위 에이전트를 사용할 수 있는 경우 리뷰를 다음 패스로 나눕니다:
- 에이전트 (Agents)
- 기술 (Skills)
- 명령어 (Commands)
- 규칙 (Rules)
- 훅 및 스크립트 (Hooks and scripts)
- 훅 표면, MCP 상태 체크, 헬퍼 스크립트 및 OS 호환성 분류
- 기타 (Extras)
- 컨텍스트, 예시, MCP 구성, 템플릿 및 가이드 문서 분류
하위 에이전트를 사용할 수 없는 경우 동일한 패스를 순차적으로 실행합니다.
핵심 워크플로우
1. 저장소 읽기
분류하기 전에 실제 스택을 파악하세요:
- 사용 중인 언어
- 사용 중인 프레임워크
- 주요 패키지 관리자
- 테스트 스택
- 린트/포맷 스택
- 배포/런타임 표면
- 이미 존재하는 운영 통합
2. 증거 테이블 구축
모든 후보 표면에 대해 다음을 기록하세요:
- 구성 요소 경로
- 구성 요소 유형
- 제안된 버킷
- 저장소 증거
- 짧은 정당화
형식 예시:
skills/frontend-patterns | skill | DAILY | 84 .tsx files, next.config.ts present | core frontend stack
skills/django-patterns | skill | LIBRARY | no .py files, no pyproject.toml | not active in this repo
rules/typescript/* | rules | DAILY | package.json + tsconfig.json | active TS repo
rules/python/* | rules | LIBRARY | zero Python source files | keep accessible only
3. DAILY 대 LIBRARY 결정
다음의 경우 DAILY로 승격합니다:
- 저장소가 해당 스택을 명확하게 사용함
- 구성 요소가 모든 세션에 도움이 될 만큼 일반적임
- 저장소가 이미 해당 런타임 또는 워크플로우에 의존함
다음의 경우 LIBRARY로 강등합니다:
- 구성 요소가 스택과 무관함
- 나중에 필요할 수 있지만 매일 필요하지는 않음
- 즉각적인 관련성 없이 컨텍스트 오버헤드만 추가함
4. 설치 계획 수립
분류를 작업으로 변환합니다:
- DAILY 기술 ->
.claude/skills/에 설치하거나 유지
- DAILY 명령어 -> 여전히 유용한 경우에만 명시적 심(shim)으로 유지
- DAILY 규칙 -> 일치하는 언어 세트만 설치
- DAILY 훅/스크립트 -> 호환되는 것만 유지
- LIBRARY 표면 -> 검색 또는
skill-library를 통해 액세스 가능하게 유지
저장소가 이미 선택적 설치를 사용 중이라면 다른 시스템을 만드는 대신 해당 계획을 업데이트하세요.
5. 선택적 라이브러리 라우터 생성
프로젝트가 검색 가능한 라이브러리 표면을 원하는 경우 다음을 생성합니다:
.claude/skills/skill-library/SKILL.md
이 라우터에는 다음이 포함되어야 합니다:
- DAILY 대 LIBRARY에 대한 짧은 설명
- 그룹화된 트리거 키워드
- 라이브러리 참조가 위치한 곳
라우터 내부에 모든 기술 본문을 복제하지 마세요.
6. 결과 검증
계획이 적용된 후 다음을 검증하세요:
- 모든 DAILY 파일이 예상 위치에 존재함
- 오래된 언어 규칙이 활성 상태로 남지 않음
- 호환되지 않는 훅이 설치되지 않음
- 결과적인 설치가 실제 저장소 스택과 일치함
다음 내용이 포함된 요약 보고서를 반환하세요:
- DAILY 개수
- LIBRARY 개수
- 제거된 오래된 표면
- 남은 질문
핸드오프 (Handoffs)
다음 단계가 대화형 설치 또는 복구인 경우 다음으로 전달하세요:
다음 단계가 중복 정리 또는 카탈로그 리뷰인 경우 다음으로 전달하세요:
다음 단계가 광범위한 컨텍스트 트리밍인 경우 다음으로 전달하세요:
출력 형식
결과를 다음 순서로 반환하세요:
STACK
- 언어/프레임워크/런타임 요약
DAILY
- 증거와 함께 항상 로드되는 항목
LIBRARY
- 증거와 함께 검색/참조 가능한 항목
INSTALL PLAN
- 설치, 제거 또는 라우팅되어야 할 항목
VERIFICATION
- 실행된 체크 및 남은 격차
