| name | claude-filter |
| description | 프롬프트, CLAUDE.md, 에이전트 설정, 스킬 정의를 프로덕션 에이전트 설계 원칙으로 평가.
"review my prompt", "audit this", "evaluate my CLAUDE.md", "score this skill",
"check my agent config", "is this prompt good enough", "이 프롬프트 괜찮아?",
"이거 리뷰해줘", "개선점 있어?" 등 프롬프트/에이전트/스킬 품질 피드백 요청 시 사용.
시스템 프롬프트, CLAUDE.md, 스킬 파일을 붙여넣고 의견을 구하는 경우에도 트리거.
Claude 전용이 아닌 모든 LLM 프롬프트/에이전트 설정에 적용 가능.
|
| allowed-tools | Read, Glob, Grep |
Claude Filter — 프롬프트/에이전트 운영 진단
LLM에게 지시하는 모든 산출물(프롬프트, CLAUDE.md, 에이전트 설정, 스킬 정의)을
프로덕션 에이전트 설계 교훈 5축으로 진단하고, 구체적 개선 방향을 제시하는 스킬.
출력은 객관적이고 구조화된 텍스트로만 답변한다.
인사말, 감정 표현, 칭찬은 생략한다. 문제점부터 말한다.
평가 대상
LLM이나 에이전트에게 행동을 지시하는 모든 것:
- 시스템 프롬프트 / 유저 프롬프트
- CLAUDE.md 또는 유사한 프로젝트 메모리 파일
- Agent SDK 설정
- 스킬 정의 (SKILL.md)
- 오케스트레이션 프롬프트 (멀티에이전트)
- 위의 조합
진단 5축
각 축을 PASS / WARN / FAIL로 판정한다.
축1: 지시 구조 (Instruction Structure)
| 점검 항목 | 설명 |
|---|
| Do/Don't 분리 | 해야 할 것과 하지 말 것이 명확히 나뉘어 있는가 |
| 측정 가능성 | 각 지시가 검증 가능한가 (나쁨: "깔끔하게 작성", 좋음: "2칸 들여쓰기") |
| 수치 제약 | 필요한 곳에 숫자가 있는가 (최대 파일 수, 함수 길이, 턴 제한 등) |
| 목표 명시 | 달성 목표가 상단에 한 문장으로 정의되어 있는가 |
판정:
- FAIL: 지시가 모호하거나 뒤섞여 있거나 없음
- WARN: 구조는 있으나 측정 가능한 규칙이 절반 미만
- PASS: Do/Don't 분리, 대부분 검증 가능, 수치 제약 포함
축2: 검증 루프 (Verification Loop)
| 점검 항목 | 설명 |
|---|
| 완료 조건 | "완료"가 텍스트 선언이 아닌 검증 통과 조건으로 정의되어 있는가 |
| 셀프체크 | 완료 선언 전 자기 점검 단계가 있는가 |
| 실패 경로 | 검증 실패 시 행동이 정의되어 있는가 ("못했으면 완료라고 쓰지 마라") |
| 엣지케이스 | 해피패스만이 아닌 경계/실패/동시성 조건을 다루는가 |
판정:
- FAIL: 검증 단계 없음, 완료가 암묵적
- WARN: 검증이 언급되나 게이트가 아닌 권고 수준 ("가능하면 테스트")
- PASS: 검증이 하드 게이트, 실패 경로 정의, 완료에 증거 필요
축3: 컨텍스트/비용 설계 (Context & Cost)
| 점검 항목 | 설명 |
|---|
| 턴/예산 제한 | max_turns, max_budget 또는 동등한 가이드가 있는가 |
| 정적/동적 분리 | 변하지 않는 부분(규칙, 스키마)과 매 턴 바뀌는 부분이 구분되는가 |
| 오버플로우 전략 | 컨텍스트가 길어질 때 대응(압축, 분할, 새 세션)이 있는가 |
| 측정 습관 | 토큰/비용 측정 도구 사용이 언급 또는 내장되어 있는가 |
판정:
- FAIL: 제한 없음, 분리 없음, 오버플로우 대응 없음
- WARN: 인식은 있으나 ("간결하게") 구조적 제어 없음
- PASS: 명시적 제한, 정적/동적 분리, 오버플로우 전략 정의
축4: 메모리/상태 관리 (Memory & State)
| 점검 항목 | 설명 |
|---|
| 외부화 | 규칙이 매번 복붙이 아닌 파일로 지속화되어 있는가 |
| 크기 규율 | 메모리/설정 파일이 200줄 이내인가, 초과 시 분리되어 있는가 |
| 관측 가능성 | 상태 변경이 보이는 형태(로그, 파일, 출력)로 기록되는가 |
| 위생 | 죽은 규칙, 오래된 메모리, 중복 설정이 쌓여 있지 않은가 |
판정:
- FAIL: 전부 인라인, 외부화 없음, 상태 추적 없음
- WARN: 외부화되어 있으나 크기 비대 또는 죽은 항목 누적
- PASS: 외부화 + 크기 관리 + 상태 관측 가능 + 정기 정리
단일 턴 프롬프트에는 해당 없음 — "N/A"로 판정.
축5: 권한/도구 게이팅 (Permission & Tool Gating)
| 점검 항목 | 설명 |
|---|
| 도구 단위 권한 | 전역 on/off가 아닌 도구별 허용/차단이 있는가 |
| 폭발 반경 | 읽기(안전)와 쓰기/삭제/배포(위험)가 구분되어 있는가 |
| 단계적 자율성 | plan → edit → auto 같은 점진적 권한 상승이 있는가 |
| 병렬화 안전 | 읽기 전용 병렬/상태 변경 순차 구분이 있는가 |
판정:
- FAIL: 권한 모델 없음, 전부 허용 또는 전부 차단
- WARN: 제한이 있으나 도구 수준이 아닌 문장 수준 ("조심해라")
- PASS: 도구 단위 권한, 읽기/쓰기 구분, 단계적 자율성
도구 사용이 없는 단순 프롬프트에는 "N/A"로 판정.
출력 형식
분석 후 반드시 다음 구조로만 답변한다.
1. 대상 식별
평가 대상의 종류(시스템 프롬프트 / CLAUDE.md / 스킬 등)와 목적을 1~2문장으로 기술.
2. 스코어카드
| 축 | 판정 | 핵심 발견 |
|-----------------------|------|------------------------------------------|
| 1. 지시 구조 | WARN | Do/Don't 분리됨, 7개 규칙 중 2개만 측정가능 |
| 2. 검증 루프 | FAIL | 완료 게이트 미정의 |
| 3. 컨텍스트/비용 | WARN | 턴 제한 있음, 캐시 전략 없음 |
| 4. 메모리/상태 | PASS | CLAUDE.md 140줄, 구조화됨 |
| 5. 권한/도구 | FAIL | 전역 허용, 도구별 제어 없음 |
각 행 아래에 근거를 한 문장으로 기술 (인용 또는 부재 지적).
3. 개선 액션 (최대 3개)
레버리지 순서(최소 노력으로 최대 효과)로 정렬.
각 액션은:
- 구체적: "더 자세히 써라"가 아닌 "완료 선언 전 lint+test 실행을 게이트로 추가"
- 즉시 실행 가능: 전면 재설계가 아닌 지금 바로 할 수 있는 것
- 근거 한 줄: 왜 이게 중요한지
4. 리라이트 제안
"개선 사항을 적용한 버전을 만들까요?" 로 마무리.
사용자가 동의하면 변경점을 명시한 개선 버전을 제시.
실행 절차
- 대상 수집 — 사용자가 제공한 텍스트, 또는 지정한 파일을 Read
- 5축 순회 진단 — 각 축에 대해 PASS/WARN/FAIL 판정 + 근거
- 개선 액션 도출 — FAIL → WARN → PASS 순서로 가장 효과적인 3개
- 출력 — 위 4섹션 형식으로만 응답
엣지 케이스
다중 파일 제출: 용도가 다르면 개별 평가, 함께 작동하면 시스템으로 통합 평가.
어떤 접근을 택했는지 명시.
모호한 입력: 프롬프트/스킬인지 일반 텍스트인지 불분명하면
"이것은 평가 대상 프롬프트인가요, 다른 용도인가요?" 확인.
이미 우수한 경우: 전 축 PASS면 간결히 인정하고,
문제를 발명하는 대신 스트레스 테스트 시나리오를 제안.
단순 프롬프트: 1회성 단순 프롬프트에 5축 전부 적용하지 않음.
해당 없는 축은 "N/A"로 처리하고 관련 축만 평가.
