| name | agent-sort |
| description | 실제 저장소 근거를 바탕으로 skills, commands, rules, hooks, extras를 DAILY와 LIBRARY로 분류해 특정 저장소용 ECC 설치 계획을 만든다. 전체 번들을 그대로 로드하는 대신 프로젝트에 맞게 ECC를 줄여야 할 때 사용한다. |
| origin | ECC |
Agent Sort
기본 전체 설치 대신 프로젝트 전용 ECC 표면이 필요한 저장소에서 이 스킬을 사용한다.
목표는 “뭔가 유용해 보이는 것”을 추측하는 것이 아니다. 목표는 실제 코드베이스 근거를 바탕으로 ECC 구성 요소를 분류하는 것이다.
언제 사용할지
- 프로젝트가 ECC 일부만 필요하고 전체 설치는 너무 시끄러울 때
- 저장소 스택은 명확하지만 사람이 스킬을 하나씩 수동 선별하고 싶지 않을 때
- 팀이 의견이 아니라 grep 근거에 기반한 반복 가능한 설치 결정을 원할 때
- 항상 로드되는 daily 워크플로 표면과 검색형 library/reference 표면을 분리해야 할 때
- 저장소가 잘못된 언어, 규칙, 훅 세트로 드리프트했고 정리가 필요할 때
양보 불가 규칙
- 일반적 취향이 아니라 현재 저장소를 기준으로 판단한다
- 모든 DAILY 결정은 구체적인 저장소 근거를 인용해야 한다
- LIBRARY는 “삭제”가 아니라 “기본 로드 없이 접근 가능하게 유지”를 뜻한다
- 현재 저장소가 사용할 수 없는 훅, 규칙, 스크립트는 설치하지 않는다
- ECC 네이티브 표면을 우선하고, 두 번째 설치 시스템을 도입하지 않는다
출력물
다음 산출물을 순서대로 만든다.
- DAILY inventory
- LIBRARY inventory
- install plan
- verification report
- 필요하면
skill-library router
분류 모델
버킷은 두 개만 사용한다.
DAILY
- 이 저장소의 모든 세션에서 로드되어야 함
- 저장소의 언어, 프레임워크, 워크플로, 운영 표면과 강하게 일치
LIBRARY
- 유지할 가치는 있지만 기본 로드할 정도는 아님
- 검색, router skill, 선택적 수동 사용으로 접근 가능해야 함
근거 출처
분류 전에 저장소 로컬 근거를 먼저 확인한다.
- 파일 확장자
- 패키지 매니저와 lockfile
- 프레임워크 설정
- CI 및 훅 설정
- 빌드/테스트 스크립트
- import 및 의존성 매니페스트
- 스택을 명시적으로 설명하는 저장소 문서
유용한 명령 예시:
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
병렬 리뷰 패스
병렬 서브에이전트를 사용할 수 있다면 다음 패스로 나눈다.
- Agents
- Skills
- Commands
- Rules
- Hooks and scripts
- hook 표면, MCP health check, helper script, OS 호환성 분류
- Extras
- contexts, examples, MCP config, templates, 가이드 문서 분류
서브에이전트를 쓸 수 없으면 같은 패스를 순차적으로 실행한다.
핵심 워크플로
1. 저장소 읽기
무엇이든 분류하기 전에 실제 스택을 확정한다.
- 사용 언어
- 사용 프레임워크
- 주 패키지 매니저
- 테스트 스택
- lint/format 스택
- 배포/런타임 표면
- 이미 존재하는 운영자 연동
2. 근거 테이블 만들기
각 후보 표면에 대해 다음을 기록한다.
- component path
- component type
- proposed bucket
- repo evidence
- short justification
형식:
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 vs LIBRARY 결정
다음이면 DAILY로 올린다.
- 저장소가 해당 스택을 명확히 사용한다
- 구성 요소가 모든 세션에 도움이 될 만큼 일반적이다
- 저장소가 이미 해당 런타임이나 워크플로에 의존한다
다음이면 LIBRARY로 내린다.
- 현재 스택과 맞지 않는다
- 나중엔 필요할 수 있지만 매일은 아니다
- 즉시 관련성 없이 컨텍스트 오버헤드만 더한다
4. 설치 계획 만들기
분류 결과를 실제 행동으로 번역한다.
- DAILY skills -> 설치하거나
.claude/skills/에 유지
- DAILY commands -> 여전히 유용할 때만 explicit shim 유지
- DAILY rules -> 해당 언어 세트만 설치
- DAILY hooks/scripts -> 호환되는 것만 유지
- LIBRARY 표면 -> search 또는
skill-library로 접근 가능하게 유지
저장소가 이미 selective install을 쓰고 있다면 새로운 시스템을 만들지 말고 기존 계획을 갱신한다.
5. 선택적 library router 만들기
프로젝트가 검색형 library 표면을 원하면 다음을 만든다.
.claude/skills/skill-library/SKILL.md
이 router에는 다음이 들어가야 한다.
- DAILY vs LIBRARY에 대한 짧은 설명
- 그룹화된 트리거 키워드
- library reference가 어디에 있는지
모든 skill 본문을 router 안에 중복 복사하지 않는다.
6. 결과 검증
계획 적용 후 다음을 검증한다.
- 모든 DAILY 파일이 기대 위치에 존재하는가
- 낡은 언어 규칙이 활성 상태로 남아 있지 않은가
- 호환되지 않는 훅이 설치되지 않았는가
- 최종 설치 구성이 실제 저장소 스택과 일치하는가
다음 항목을 포함한 간결한 보고를 반환한다.
- DAILY 개수
- LIBRARY 개수
- 제거된 낡은 표면
- 남은 질문
핸드오프
다음 단계가 대화형 설치나 수리라면:
다음 단계가 중복 정리나 카탈로그 검토라면:
다음 단계가 더 넓은 컨텍스트 trimming이라면:
출력 형식
다음 순서로 반환한다.
STACK
- language/framework/runtime summary
DAILY
- always-loaded items with evidence
LIBRARY
- searchable/reference items with evidence
INSTALL PLAN
- what should be installed, removed, or routed
VERIFICATION
- checks run and remaining gaps
