Claudex Loop
현재 대화가 요구사항, 계획 및 조정을 소유합니다. 상대 제공자가 계획을 검토합니다. 두 제공자 모두 빌드할 수 있으며, 빌드하지 않은 제공자가 신규 세션에서 최종 코드를 검사합니다.
역할 한 번에 결정하기
PATH, 설치된 스킬, 모델명 추측 또는 저장소가 아닌, 런타임에서 실제 호스트를 식별하세요. 두 CLI 모두 설치되어 있을 수 있습니다. Claude Code에서는 host=claude를, Codex에서는 host=codex를 사용하세요. 런타임 정체성을 확인할 수 없는 경우, 사용자에게 한 번 어떤 호스트를 사용 중인지 물어보세요.
| 호스트 | 요구사항 및 계획 | 계획 검토자 | 기본 빌더 | 최종 검사자 |
|---|---|---|---|---|
| Claude Code | 현재 Claude 세션 | Codex | Claude | 신규 Codex 세션 |
| Codex | 현재 Codex 세션 | Claude | Codex | 신규 Claude 세션 |
builder=claude|codex를 준수하세요. 검사자는 항상 다른 제공자입니다. 호스트는 상대 제공자가 빌드하더라도 조정자 역할을 유지합니다. 계획 수립자를 변경하려면 다른 호스트에서 대화를 시작하세요. CLI 검토자를 사용자의 계획 수립 대화로 가장하지 마세요.
모델 선택은 제공자 역할과 독립적입니다. 호스트의 선택된 모델을 유지하세요. 검토/빌드 CLI 호출은 reviewer_model, builder_model 또는 inspector_model이 제공되지 않는 한 자체 구성을 상속받습니다. 이를 실행기의 --model에 매핑하세요. 명시적인 *_effort도 유사하게 적용하세요. Fable 5.1 및 GPT-6 Astra는 적절한 명시적 선택지이며, 필수 고정 값은 아닙니다. 호스트 UI의 모델은 별도 CLI가 사용할 모델을 증명하지 않습니다. 요청된 모델과 관찰된 모델 정보를 별도로 보고하고, 해결되지 않은 CLI 기본값을 정직하게 보고하세요. 실패 시 자동으로 다른 모델/제공자로 전환하지 마세요.
CLI를 실행하기 전에 런타임 참조를 읽으세요. 실행기는 이 설치된 SKILL.md를 기준으로 해결하고, 검토 중인 프로젝트를 기준으로 하지 마세요. 실행 시 절대 경로를 사용하세요.
사용자가 codex_cli 또는 claude_cli를 제공하는 경우, 선택한 제공자의 실행 파일 경로를 --cli에 매핑하세요. 호스트 앱은 PATH에 있는 CLI보다 최신의 작동하는 바이너리를 가질 수 있습니다. 전역 설치나 구성을 변경하지 않고 경로와 버전을 확인하세요.
조정 가능한 값
| 인수 | 기본값 | 의미 |
|---|---|---|
PLAN_FILE / plan | PLAN.md | 빌드 인계를 포함하여 전체적으로 사용되는 계획 파일 경로 |
LOG_FILE / log | PLAN-REVIEW-LOG.md | 추가 전용 기록 |
rounds / MAX_ROUNDS | 5 | 완료된 계획-검토 라운드의 최대 횟수 |
builder | host | 계획을 구현하는 제공자 |
research | 작업에 비례 | none, web 또는 명시적 동의가 필요한 deep |
mode | full | full은 정찰/인터뷰 포함; review는 기존 계획에서 시작 |
inspect | on | 사용자가 명시적으로 거부하는 경우에만 off; 기록 필수 |
MAX_FIX_ROUNDS | 2 | 보고 또는 인수 전까지 빌드-수정 시도 횟수 제한 |
MAX_INSPECTION_ROUNDS | 2 | 초기 검사 + 수정 후 한 번 |
시작하기 전에 역할, 경로, 라운드 제한, 요청된 모델 및 검사 거부 여부를 알리세요. 기존 권한을 유지하세요. 계획 요청은 빌드를 승인하지 않습니다. 계획 및 구현 요청은 승인합니다. 남은 승인을 구하기 전에 승인된 준비를 먼저 수행하세요.
0단계 — 정찰
기존 프로젝트의 경우, 관련 코드, 종속성, 호출자 및 공유 상태의 작성자를 검사하세요. 기존 CONTEXT.md / CONTEXT-MAP.md 및 관련 ADR을 읽으세요. 새로운 프로젝트의 경우, 선행 기술, 합리적인 스택 및 유용할 때 구체적인 실패 모드를 조사하세요. 명시적인 연구 깊이를 존중하세요. 심층 다중 에이전트 연구는 명시적인 동의와 사용 가능한 도구가 필요합니다. 그렇지 않으면 지원되는 목표 지향적 연구를 사용하고 제한 사항을 보고하세요. 독점 Workflow 도구가 필요하거나 연구 에이전트 모델을 하드코딩하지 마세요.
호스트의 사용 가능한 카탈로그와 접근 가능할 때 상대 제공자의 문서화된 스킬 위치를 통해 관련 스킬을 발견하세요. 관련 제안된 종속성만 기록하세요. 호스트 MCP, 브라우저, 자격 증명 또는 스킬이 다른 CLI로 전송된다고 가정하지 마세요. 의존하기 전에 필요한 빌드 기능을 확인하세요.
소스 경로 또는 연구 링크가 포함된 하나의 가정 원장을 제시하세요. 중요한 불확실성에 대한 수정을 한 번에 요청하세요. 사용자가 작업을 승인한 경우 일상적인 되돌릴 수 있는 선택은 직접 해결하세요. 침묵은 승인이 필요한 작업에 대한 동의가 아닙니다.
1단계 — 요구사항 확정
짧고 시각적인 결정 맵을 유지하세요. 결과를 변경하는 해결되지 않은 결정에 대해서만 질문하세요. 각 중요한 질문에 대해 권장 사항, 그 이유, 그리고 잘못 추측할 경우의 비용을 제시하세요. 독립적인 질문은 일괄적으로 처리하고, 종속적인 질문은 순차적으로 하세요. 코드가 답을 줄 수 있다면 대신 검사하세요. 긴 결정 목록이 사용자를 지연시킬 경우 "모든 남은 권장 사항 수락"을 제안하세요.
기존 용어집 정의를 존중하고, 모호한 도메인 언어를 해결하세요. CONTEXT-FORMAT.md를 사용하여 용어집 전용 컨텍스트를 지연 방식으로 유지하세요. 되돌리기 어렵고 명확하지 않은 트레이드오프에 대해서만 ADR-FORMAT.md를 사용하여 ADR을 기록하세요.
해결된 PLAN_FILE을 다음 내용으로 작성하세요:
- 목표 및 관찰 가능한 승인 기준.
- 구체적인 접근 방식, 주요 결정, 트레이드오프 및 비목표.
- 출처와 남은 위험이 포함된 확인된 가정.
- 제공자별 관련 도구 체인 요구 사항(있는 경우).
- 검증: 정확한 증명 명령어, 예상 결과, 필요한 경우 수동/시각적 확인.
가능한 경우 저장소에서 증명 명령어를 도출하세요. 성공 기준이 여전히 불분명할 때만 질문하세요. 역할, 모델 요청, 범위, 권한 및 라운드 제한과 함께 추가 전용 LOG_FILE을 시작하세요. 체크아웃 외부에 실행 진단을 유지하세요.
mode=review인 경우, 제공된 계획을 로드하고, 필요한 경우에만 사용자와 함께 중요한 공백을 채운 후 직접 검토로 진행하세요. 요구사항 인터뷰를 다시 시작하지 마세요.
2단계 — 독립적 계획 검토
실제 --host, 해결된 --plan 및 선택적 모델/effort와 함께 review 모드의 공유 실행기를 사용하세요. 첫 번째 라운드는 세션을 생성합니다. 이후 라운드는 동일한 제공자/모델/effort와 호스트가 작성한 처분 내용이 포함된 --feedback 파일과 함께 --resume <이전-성공-결과.json>을 사용하세요. 추측된 세션 ID, --last 또는 빌드 세션을 검토자로 사용하지 마세요.
각 성공적인 응답에는 평결, 증거 기반 발견 사항, 실제 적용 범위 및 제한 사항이 포함됩니다. 전체 응답과 실행기 결과 경로를 LOG_FILE에 보존하세요.
- 승인됨(APPROVED): 해결되지 않은 중요한 결함이 없음. 승인은 정확한 계획 경로 및 SHA256에 바인딩됩니다. 남은 낮은 우선순위 조언 및 제한 사항을 제시하세요. 발견 사항이 0개인 것도 유효하며 완전한 정확성의 증거는 아닙니다.
- 수정 요청(REVISE): 호스트가 각 발견 사항을 중재합니다. 정당한 계획 변경을 구현하고, 지원되지 않는 제안은 이유를 제시하며 거부하세요. 처분 내용을 기록하고 수정된 계획을 동일한 검토자에게 보내세요. 새로운 증거 없이 해결된 사항을 다시 논의하지 마세요.
- 차단됨(BLOCKED) / 프로세스 실패 / 잘못된 결과: 이것을 승인으로 간주하지 마세요. 실제 누락된 증거 또는 운영 실패를 설명하세요. 남은 라운드를 맹목적 재시도에 소모하거나 제공자를 조용히 변경하지 마세요.
MAX_ROUNDS에서 중지하세요. 인위적인 수렴을 조작하는 대신 해결되지 않은 발견 사항과 호스트의 입장을 제시하세요. 변경된 계획은 다른 검토가 필요합니다. 빌드하기 전에 최종 계획에 대한 승인 확인을 실행하세요. 사용자가 명시적으로 독립적 승인 없이 진행하기로 선택한 경우, 해당 재정의를 기록하고 독립형 미검토-사양 경로를 사용하세요. 승인됨으로 표시하지 마세요.
3단계 — 빌드 및 검사
검토된 계획, 개선 사항 및 남은 제한 사항을 제시하세요. 구현이 아직 승인되지 않은 경우, 해당 최종 결정을 요청하세요. 선택된 빌더(기본값은 호스트)를 사용하세요. 빌드 참조를 읽으세요.
호스트는 일반 도구를 사용하여 직접 구현할 수 있습니다. 다른 빌더의 경우, 공유 실행기의 build 모드를 사용하세요. 어느 경로든 빌드 전 커밋을 캡처하고, 관련 없는 사용자 작업을 보존하며, 동일한 해결된 계획 및 검증 계약을 이행해야 합니다.
합의된 증명 확인을 실행하고, 모든 변경된 파일을 검사하고 신규 inspect 세션에서 다른 제공자를 통해 결과를 검토하세요. 빌드 전 커밋과 빌더 정체성을 제공하세요. 허용된 수정 후 재검사도 신규 세션을 사용합니다. 발견 사항 및 처분 내용을 기록하고 수정 후 영향을 받는 증명 확인을 다시 실행하세요.
조정자가 코딩을 인수하면 빌더가 됩니다. 변경 사항에 대한 신규 다른-제공자 검사가 필요합니다. 이전 검사가 이후 편집을 포함한다고 설명하지 마세요. 두 제공자가 모두 코드를 기여한 경우, 저자를 기록하고 각자가 상대방의 변경 사항을 검사하게 하세요. 어떤 모델이 자신이 작성한 코드를 독립적으로 검토했다고 주장하지 마세요. 검사 예산이 소진된 경우, 최종 사용자의 결정을 위해 남은 발견 사항 및 검토되지 않은 편집을 명시적으로 보고하세요.
최종 diff, 증명 결과, 검사 범위, 해결되지 않은 발견 사항, 편차 및 사용된 라운드를 제시하세요. 기존 커밋/푸시 권한을 존중하고, 그렇지 않은 경우 구체적인 diff를 서명을 위해 준비하세요. 루프를 실행했다는 이유만으로 외부 게시가 암시되지 않습니다.