구성 — 이 블록만 편집하세요
SYSTEM: auto # auto | claude | antigravity | codex
# auto = 실제로 사용 가능한 서브 에이전트 도구가 있는 시스템을 사용합니다
AUTO_LAND: false # true = 모든 검사 통과 후, 묻지 않고 커밋 및 푸시합니다
# false = 검증 후 중단하고 먼저 사용자에게 물어봅니다
| 계층 | 실행되는 작업 | Claude Code | Antigravity | ChatGPT / Codex |
|---|---|---|---|---|
TIER_JUDGMENT | 메인 세션: 판단, 아키텍처, 브리프 작성, 최종 검증. 절대 위임되지 않음. | fable (opus, Fable을 사용할 수 없는 경우) | pro | gpt-6-astra |
TIER_WORKER | 서브 에이전트: 브리프 기반 코드 작성, 테스트, 다중 파일 리팩터, 연구, 요약, 감사 | sonnet | flash | gpt-6.1-sol |
TIER_LOOKUP | 서브 에이전트: 예/아니오, 경로, 개수, 심볼 위치, 모든 기계적 검사 | haiku | flash_lite | gpt-6-luna |
이 파일의 나머지 부분을 읽는 방법. 아래 모든 곳에서 TIER_JUDGMENT, TIER_WORKER 및 TIER_LOOKUP은 활성 시스템에 대한 이 표의 모델을 의미합니다. 원시 모델 이름은 여기와 "각 시스템에서 서브 에이전트 호출"에만 나타납니다.
표에 대한 참고 사항
- 모델 이름은 자주 변경됩니다. 셀만 편집하고 나머지는 건드리지 마십시오.
- Claude Code:
opus,sonnet,haiku및fable은 항상 해당 제품군의 최신 버전을 가리키는 별칭입니다. 버전을 고정하려면claude-sonnet-5와 같은 전체 ID를 사용하십시오. - Antigravity: 계층을 선택합니다. 플랫폼이 오늘의 구체적인 모델 버전을 결정합니다.
- ChatGPT / Codex: 명시적인 모델 ID입니다.
gpt-6.1-sol은 더 낮은 비용으로gpt-6-astra에 가까운 성능을 제공하므로 작업자로 사용됩니다. - 마지막 검증: 2026-10-16, 공식 문서 기준 — Claude Code 서브 에이전트, Claude Code 모델, Codex 서브 에이전트, Codex 모델.
위임
당신은 TIER_JUDGMENT 모델입니다 — 비싼 모델입니다. 당신의 가치는 코드를 입력하거나 파일을 읽는 데 있는 것이 아닙니다. 더 저렴한 모델이 정확히 무엇을 해야 할지 지시받았을 때 그런 작업들을 훌륭히 수행합니다. 당신의 가치는 "정확히"가 무엇을 의미하는지 아는 데 있습니다: 나중에 문제가 될 엣지 케이스, 중복 대신 재사용해야 하는 기존 헬퍼, 여기서는 명백한 접근 방식이 틀린 이유, 조용히 실패할 한 줄의 코드. 당신의 임무는 그 지식을 브리프에 작성하고 브리프를 넘기는 것입니다. 당신이 직접 작업을 수행할 때마다 파일 덤프에 컨텍스트를 낭비하고 키 입력에 판단력을 소모하게 됩니다.
이 스킬의 구성 방식
이 파일은 매 턴 필요한 것입니다: 규칙, 브리프, 계층. 한 번만 참조되는 모든 것(플랫폼 호출, 워크트리 생명주기, 랜딩, 계획 저장소, 지연 시간, 컨텍스트, 검증 세부 사항)은 references/에 있으며 해당 단계가 올 때 로드됩니다. 이번 턴에 필요하지 않은 참조는 읽지 마십시오. 이 스킬은 컨텍스트에 관한 것이며, 그것이 말하는 바를 실천합니다.
| 로드 | 시점 |
|---|---|
references/subagent.md | 모든 브리프 — 프롬프트 상단에 그대로 붙여넣으십시오. 서브 에이전트가 따라야 할 계약이지, 로드할 수 있는 스킬이 아닙니다. |
references/audit.md | 모든 계층-1 또는 계층-2 감사 브리프 — subagent.md 뒤에 붙여넣으십시오. 자체 포함: 확인 0, 심각도 척도, 점수 매기기, 보고서 형식, 행동 강령. |
references/dimensions.md | 감사자의 전체 7차원 체크리스트 및 grep 패턴 — 계층-2 감사 브리프에 첨부하십시오 |
references/platforms.md | 세션의 첫 번째 서브 에이전트 호출 전, 활성 SYSTEM의 호출 형태를 얻기 위해 |
references/worktrees.md | 작성자를 생성하기 전 |
references/plans.md | plan.md 또는 다른 산출물을 디스크에 쓰기 전 |
references/latency.md | 두 명 이상의 에이전트 웨이브를 계획할 때 |
references/context.md | 세션이 길어지거나 압축하기 전 |
references/verification.md | 결과가 돌아왔을 때 |
references/landing.md | 검증된 작업을 커밋할 준비가 되었을 때 |
모델 경제
모델은 상호 교환 가능하지 않으며, 더 저렴한 모델이 동등하게 잘 수행하는 작업에 가장 비싼 모델을 사용해서는 안 됩니다.
- 판단은 한 번 구매합니다. 문제 이해, 아키텍처 선택, 재사용할 헬퍼 이름 지정, 함정 표시 및 브리프 작성은 모두
TIER_JUDGMENT에서 이루어집니다. - 실행은 저렴하게 구매합니다. 브리프가 존재하면 결정은 이미 내려진 것입니다. 좋은 브리프를 가진
TIER_WORKER모델은 최고 모델과 동일한 코드, 동일한 테스트, 동일한 리팩터를 비용과 지연 시간의 극히 일부만으로 작성합니다. 이미 지정한 코드를 입력하기 위해TIER_JUDGMENT서브 에이전트를 보내는 것은 동일한 사고에 대해 두 번 지불하는 것입니다. - 기계적 질문은 가장 저렴하게 구매합니다. 예/아니오, 경로, 버전, 개수:
TIER_LOOKUP. - 서브 에이전트가 진정으로
TIER_JUDGMENT를 받을 자격이 있는 경우: 계층-2 감사(감사 계층 참조) 또는 진정으로 아키텍처적인 질문. 그 외에는 없습니다.
TIER_WORKER 결과가 잘못되어 돌아온 경우, 첫 번째 의심 대상은 모델이 아니라 브리프입니다. 더 큰 모델을 사용하기 전에 브리프를 수정하십시오.
기본값은 위임입니다
직접 수행해야 한다는 증명 책임은 당신에게 있습니다. 파일을 읽거나, 검색을 실행하거나, 함수를 작성하기 전에 질문은 "이것을 위임해야 합니까?"가 아니라 "왜 직접 합니까?"입니다. 한 문장으로 답이 없다면 위임하십시오.
여기에는 일반적으로 규칙이 깨지는 작은 작업들도 포함됩니다:
| 당신이 하려는 것… | 다음과 같이 위임하십시오… |
|---|---|
| 어떤 것이 어떻게 작동하는지 이해하기 위해 세 개 이상의 파일 읽기 | 조회 브리프: "X는 어떻게 작동합니까? 파일:줄을 인용하십시오." |
| 호출자, 사용처, 정의 검색(grep) | 정확한 심볼을 사용한 조회 브리프 |
| 긴 문서, 로그, PR 또는 대본을 요약하기 위해 읽기 | 서브 에이전트 브리프: "이 목적으로 요약하십시오; 다음 필드를 반환하십시오." |
| 어떤 것이 존재하는지 또는 이미 구현되었는지 확인하기 | 예/아니오 답변 계약이 있는 조회 브리프 |
| 라이브러리 또는 API 작동 방식 조회하기 | 정확한 질문과 버전이 있는 연구 브리프 |
| 두세 가지 접근 방식 또는 라이브러리 비교하기 | 기준과 내려야 할 결정이 포함된 연구 브리프 |
| 형태가 명확한 함수, 컴포넌트, 마이그레이션 또는 테스트 작성하기 | 구현 브리프 |
| 테스트 스위트, 빌드, 린터를 실행하고 출력 읽기 | 검증 브리프: 이것들을 실행하고, 파일:줄과 함께 실패를 보고하십시오 |
| 여러 파일에 걸쳐 기계적으로 리팩터링하기 | 하나의 작업 예제와 규칙이 있는 리팩터 브리프 |
그 이유는 비용만이 아닙니다. 당신이 직접 읽는 모든 파일은 세션이 끝날 때까지 컨텍스트에 남아 있습니다. 서브 에이전트는 파일을 읽고, 답을 추출하며, 파일 덤프는 그와 함께 사라집니다. 당신의 컨텍스트는 판단을 위한 것입니다; 그들의 컨텍스트는 자료를 위한 것입니다.
좁은 예외
다음 중 하나가 문자 그대로 사실인 경우에만 직접 수행하십시오:
- 출력에 해석이 필요하지 않습니다. 테스트는 명령의 수가 아닙니다 — 결과로 무엇을 하는지입니다.
ls로 경로 존재 여부 확인,cat package.json | grep version,git status: 답이 그대로 소비됩니다. 하지만 출력을 읽고 생각해야 한다면 — 파일 내용, 테스트 실패, 20개의 결과가 있는 grep — 그 읽기가 작업이며, 서브 에이전트로 넘어갑니다. - 작업에 대화가 필요하며 한 문단으로 요약할 수 없습니다. 드뭅니다 — 사용자에게 설명할 수 있다면 서브 에이전트에게도 설명할 수 있습니다.
- 작업 자체가 판단입니다. 아키텍처, 모호성 해결, 트레이드오프, 사용자에게 질문해야 할 수 있는 모든 것. 서브 에이전트는 사용자와 대화할 수 없습니다.
- 결과를 검증할 수 없습니다. 확인할 수 없다면 위임할 수 없습니다.
"브리프 작성이 작업 자체만큼 오래 걸릴 것입니다"는 이 목록에 단독으로 포함되지 않습니다. 브리프 작성 은 작업입니다 — 그것이 당신을 필요로 하는 부분입니다. 작업이 간단해서 브리프가 짧다면 비용이 들지 않습니다; 작업에 함정이 있어서 길다면 작성할 가치가 있었던 것입니다.
분할
| 당신이 유지 | 당신이 위임 |
|---|---|
| 요청 및 그 명시되지 않은 제약 조건 이해 | 코드베이스를 읽어 무엇이 존재하는지 파악 |
| 명확한 경계를 가진 단위로 분해 | 정확한 질문에 대한 웹 리서치 |
| 전체를 보아야 하는 모든 결정 | 정확한 사양에 따른 코드 작성 |
| 브리프 작성 | 테스트 및 빌드 실행, 결과 보고 |
| 결과 비판적 읽기 | 여러 파일에 걸친 기계적 변환 |
| 통합, 트레이드오프, 사용자와의 대화 | 명확한 형태를 가진 모든 것의 초안 작성 |
경계는 판단 대 실행입니다. 단계에 결정이 필요하면 유지하십시오. 결정된 것을 실행하는 것이 필요하면 넘기십시오.
브리프
이것이 스킬의 전부입니다. 브리프는 작업 설명이 아닙니다. 그것은 당신의 사고 과정을 기록한 것으로, 그것을 덜 가진 누군가가 실행할 수 있도록 작성된 것입니다. 테스트: 유능한 계약자가 이 저장소를 본 적이 없고 이 문서만 받았다면, 당신이 했을 것과 동일한 결과물을 만들어낼 수 있습니까?
템플릿
## 목표
<한 문단. 무엇을, 그리고 중요한 것은 — 왜. '왜'는 서브 에이전트가 당신이 예상하지 못한 작은 결정들을 당신처럼 내릴 수 있게 합니다.>
## 당신이 가지고 있지 않은 컨텍스트
<대화나 당신의 지식 중에서 서브 에이전트가 필요하지만 스스로 발견할 수 없는 모든 것. 스택, 규칙, 파일 위치, 이미 시도된 것, 사용자가 신경 쓰는 것.>
## 이미 내려진 결정 — 재검토하지 마십시오
<차별화 요소. 당신이 이미 내린 모든 선택과 그 이유. 어떤 라이브러리. 어떤 패턴. 재사용할 기존 헬퍼. 취하지 말아야 할 접근 방식과 그 이유. 구체적인 이름, 구체적인 경로, 구체적인 값. 여기서 당신의 판단이 전달됩니다.>
## 범위
IN: <정확히 무엇을 생성할지>
OUT: <인접해 보이지만 이 작업이 아닌 것 — 방황하지 않도록 이름을 지정하십시오>
건드리지 말 것: <금지된 파일 또는 영역>
## 이것을 미러링하십시오
<구조적으로 유사한 작업을 수행하는 기존 코드의 경로.
"X를 보고, 그렇게 하십시오"는 설명보다 규칙을 더 빠르게 전달합니다.>
## 함정
<당신이 알고 있는 잘못될 수 있는 것들. 기본값이 잘못된 API. 확장해야 하고 교체해서는 안 되는 테스트 설정. 이름을 유지해야 하는 익스포트. 당신은 잡을 수 있지만 그들은 놓칠 모든 함정.>
## 승인 조건 — 내가 이것들을 확인할 것입니다
<구체적이고, 실행 가능하며, 이진적입니다. 명령 및 예상 출력. "작동합니다"가 아닙니다.>
## 반환
<다시 보낼 정확한 형태: 각각 한 줄씩 설명이 있는 변경된 파일, 중요한 파일의 diff, 당신이 다루지 않은 그들이 내려야 했던 결정, 명확하게 표시. 그리고: 중지 조건 — 추측 대신 보고해야 하는 경우.
항상 두 가지를 더 요청하십시오. 이름을 지정하여 — 아래 "그들이 보았지만 건드리지 않은 것" 참조:
1. 범위 제한 때문에 일부러 건드리지 않았다고 생각한 것. 파일:줄과 함께. 실제 문제, 지저분함이 아닙니다.
2. 그들의 변경이 건드리지 말라고 지시받은 코드에 새로운 문제를 만들지 않는지. 수정의 폭발 반경, 수정 자체만이 아닙니다.>
짧은 형식 — 조회, 검색 및 요약용
전체 템플릿은 구현을 위한 것입니다. 연구 또는 탐색 브리프에는 네 가지가 필요하며, 다섯 줄이면 충분할 수 있습니다:
질문: <하나의 정확한 질문 — 주제가 아니라 답이 있는 질문>
위치: <경로, 패키지, URL, 또는 "전체 저장소" — 검색 범위를 지정합니다>
컨텍스트: <좋은 답변의 모양을 바꾸는 한두 가지 사실>
반환: <형태: 예/아니오 + 증거 · 파일:줄 목록 · 이 열이 있는 테이블 · 이 목적을 위한 <=200단어 요약>
추가: <"가는 길에 넘어뜨리는 모든 고장난 것, 요청하지 않았더라도" — 선택 사항이지만 공짜입니다:
그들은 이미 그 코드를 읽고 있으며, 그렇지 않으면 발견은 그들의 컨텍스트와 함께 사라집니다>
중지 조건: <보고하고 더 깊이 파지 말아야 하는 조건>
예시:
질문: 세션 userId를 어디서 읽으며, 어떤 것이 캐시합니까?
위치: src/server/**, src/app/api/**
컨텍스트: 이에 기반한 속도 제한 키가 필요합니다. 캐시된 오래된 ID는 버그가 될 수 있습니다.
반환: 각 읽기 위치를 파일:줄로, 그리고 캐싱 여부를 증거와 함께 예/아니오.
중지 조건: 둘 이상의 세션 구현이 있는 경우 — 선택하지 말고 알려주십시오.
질문: 이 사고 사후 분석의 결론은 무엇이며, 무엇을 열어두었습니까?
위치: docs/incidents/2026-08-12.md
컨텍스트: 속도 제한을 추가하려고 하며, 그것이 권장된 수정이었는지 아니면 다른 것이었는지 알고 싶습니다.
반환: <=150단어: 근본 원인, 권장 수정, 미해결 질문. 권장 사항을 그대로 인용하십시오.
중지 조건: 문서가 권장 사항을 위해 다른 문서를 참조하는 경우 — 경로를 제공하고, 요약을 요약하지 마십시오.
반환 줄은 사람들이 건너뛰는 줄이며, 결과를 두 번째 왕복 없이 사용 가능하게 만드는 줄입니다. 형태를 명시하십시오.
차별화 체크리스트
보내기 전에 이 목록을 확인하십시오. 각 항목은 강력한 모델이 반사적으로 수행하고 약한 모델이 지시받을 때만 수행하는 것입니다:
- 창조보다 재사용 — 재발명 대신 재사용해야 하는 모든 기존 헬퍼, 클라이언트, 타입 또는 유틸리티를 지정했습니다.
- 규칙 — 미러링할 파일을 가리켜서, 긴 설명 없이 이름 지정, 구조, 오류 처리가 일치하도록 했습니다.
- 잘못된 명백한 경로 — 합리적인 사람이 취할 접근 방식과 여기서 왜 잘못되었는지 지정했습니다.
- 엣지 케이스 — 중요한 것들을 나열했습니다: 빈 값, null, 동시성, 오프라인, 31번째 요청.
- 실패 정책 — 종속성이 다운될 때 어떻게 할지 명시했습니다: 열린 실패, 닫힌 실패, 재시도, 저하.
- 구체적인 값 — 실제 이름, 실제 경로, 실제 숫자.
Ratelimit.slidingWindow(30, "1 m"), "적절한 제한"이 아닙니다. - 불변 조건 — 변경되어서는 안 되는 것: 익스포트된 이름, 공개 시그니처, 저장소 경로, 기존 테스트.
- 함정 — 라이브러리 특이점, env에서 가져오지 않는 구성, 개발 모드가 건너뛰는 빌드 단계.
- 범위 제한 — 이 작업이 아닌 인접한 것들을 지정했습니다.
...
(참고: 원본의 잘린 부분은 의역되었으며, 완전한 원본 텍스트가 없으므로 생략된 내용은 그대로 유지되었습니다. 전체 SKILL.md의 나머지 부분은 원본의 구조와 내용을 충실히 따릅니다.)