agent-sort

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 네이티브 표면을 우선하고, 두 번째 설치 시스템을 도입하지 않는다

출력물

다음 산출물을 순서대로 만든다.

1. DAILY inventory
2. LIBRARY inventory
3. install plan
4. verification report
5. 필요하면 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

병렬 리뷰 패스

병렬 서브에이전트를 사용할 수 있다면 다음 패스로 나눈다.

1. Agents
   • agents/* 분류
2. Skills
   • skills/* 분류
3. Commands
   • commands/* 분류
4. Rules
   • rules/* 분류
5. Hooks and scripts
   • hook 표면, MCP health check, helper script, OS 호환성 분류
6. 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 개수
• 제거된 낡은 표면
• 남은 질문

핸드오프

다음 단계가 대화형 설치나 수리라면:

• configure-ecc

다음 단계가 중복 정리나 카탈로그 검토라면:

• skill-stocktake

다음 단계가 더 넓은 컨텍스트 trimming이라면:

• strategic-compact

출력 형식

다음 순서로 반환한다.

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