Fable Loop
이 스킬은 fable-method를 오케스트레이션합니다: 먼저 fable-method의 SKILL.md를 읽으십시오; 해당 규칙이 모든 단계를 관장합니다. 이 스킬은 fable-method와 함께 설치됩니다(이 플러그인의 skills/fable-method/ 디렉토리 또는 수동 설치의 경우 ~/.claude/skills/fable-method/). 메서드는 무엇을 확인할지 알려주고, 이 루프는 누가 작업을 수행할지(메인 스레드에서 실행되는 작업, 하위 에이전트로 분산되는 작업, 전달 전에 공격받는 작업) 정의합니다.
먼저 게이트부터 적용하세요.
메서드의 사소함 게이트에 따라 사소한 작업: 그냥 수행하고, 명백한 한 가지 확인으로 검증한 후, 두 문장으로 보고합니다. 단계나 하위 에이전트가 필요 없습니다. 그 외의 모든 작업은 아래 네 단계를 순서대로 실행합니다.
1단계 - 계획 (첫 번째 북엔드)
- 메서드 0-3단계 적용: 요청 분류, 명명된 검증으로 완료 조건 정의, 부담이 되는 가정 명시.
- 증거 수집 병렬화. 증거 수집기를 한 번의 메시지로 병렬 하위 에이전트로 생성합니다(절대 순차적으로 하지 않음):
- 코드베이스 질문: 각 영역별 탐색 에이전트("X는 어떻게 작동하나요?", "Y에 의존하는 것은 무엇인가요?")
- 라이브러리 또는 사실 질문: 최신 문서를 가져오거나 웹을 검색하는 연구 에이전트
- 각 하위 에이전트는 원시 파일 덤프가 아닌 인용을 포함한 정제된 결과를 반환
- 한 배치와 한 번의 후속 배치가 예산이며, 세 번째 배치는 명시된 이유가 필요함
- 계획 산출물 생성 (다음 형태):
- 분류
- 완료 조건 및 검증 방법
- 발견된 증거(인용 포함)
- 하나의 권장 접근 방식 (대안은 각각 한 줄로 기각)
- 작업 범위(작업이 다룰 정확한 파일 또는 영역)
- 위험 및 가정
- 실행 체크리스트
- 의사 결정 게이트.
- 작업 형태이며 되돌릴 수 있는 경우: 2단계로 진행(묻지 않음)
- 계획 우선 형태(모호한 범위, 되돌릴 수 없거나 외부에 영향을 주는 작업, 또는 사용자가 계획을 요청한 경우): 계획 산출물을 제시하고 승인을 위해 중단
2단계 - 실행
- 메인 스레드에서 체크리스트를 작업합니다(도구 모음에
todo도구가 있으면 사용하고, 완료된 항목은 체크 표시). 의사 결정과 편집은 메인 스레드에 유지하고, 검색과 검증만 분산합니다. - 모든 편집은 메서드 4단계를 따릅니다: 동작 변경 전 의도 게이트, 처음 열어보지 않은 항목을 사용하기 전 리콜 게이트, 가장 작고 정확한 변경, 정밀한 편집, 보지 않고 절대 파괴하지 않음.
- 독립적인 기계적 항목(여러 파일에 걸친 동일한 변경, 격리된 파일 생성)은 한 번의 메시지로 병렬 하위 에이전트에 분산할 수 있으며, 동일한 파일을 건드릴 가능성이 있으면 작업 트리 격리를 적용합니다.
- 실행 중 예상치 못한 상황 발생 시 메서드 2단계 규칙 7에 따라 처리: 상황을 알린 후 계획을 업데이트하거나 1단계로 돌아갑니다. 예상치 못한 상황을 강행하지 마십시오.
- 항목 중간에 무지가 발견되면 추측하지 않고 일시 중지합니다: 편집이 메모리에서 사실(시그니처, 키, 수치)을 가져와야 하는 순간, 해당 항목을 중단하고 메서드의 리콜 게이트에 따라 하나의 연구 하위 에이전트로 분산한 후 결과가 반환되면 재개합니다.
- 외부에 영향을 주는 체크리스트 항목은 메서드의 승인 게이트를 따릅니다: 사용자의 명시적 승인 없이는 실행하지 않으며, 해당 항목은 보고서의 다음 단계 제안으로 변환됩니다.
- 턴 예산 체크포인트. 긴 반복은 ≤50 에이전트 턴으로 제한합니다. 각 제한에서 체크포인트 산출물(완료된 작업, 증거 경로, 정확한 다음 작업)을 작성하고 이어서 재개합니다. 최종 검증이 턴 제한에 의해 중단되는 단계가 되어서는 안 됩니다. 예산 내에서 검증하거나 명시적으로 보류 중이라고 체크포인트에 표시합니다.
3단계 - 검증 (적대적으로)
-
직접 명명된 검증을 수행합니다: 완료 조건이 충족되었는지 관찰(실행, 렌더링, 카운트)하고, 주변 시스템이 여전히 정상인지 확인(빌드, 테스트, 해당 영역의 린트).
-
중대한 변경의 경우 공격자를 생성합니다. 1-3개의 병렬 하위 에이전트를 생성하고, 각각 다른 관점에서 작업을 반박하도록 프롬프트합니다. 예시:
- "이 diff를 읽고 변경이 틀렸거나 불완전함을 증명하세요."
- "런타임에 변경된 동작을 실행하고 이를 깨뜨리는 입력을 찾으세요."
- "이 주장을 사양/문서와 비교하여 모순을 찾으세요."
- "전체 변경 집합을 계획의 선언된 범위와 비교하여 범위 밖의 것이 변경되었음을 증명하세요."
동일한 검토자가 아닌 다른 관점이 중요합니다.
-
자신의 검증에서도 살아남은 발견 사항은 새로운 작업으로 2단계로 돌아갑니다. 메서드에 따른 하드 바운드: 동일한 문제에 대해 3번의 실패한 수정-검증 주기, 또는 통제 불가능한 차단기는 중단하고 출력과 가설과 함께 반환함을 의미합니다.
4단계 - 감사 및 보고 (두 번째 북엔드)
- fable-method 감사 모드에 따라 자체 감사: 각 메서드 단계에 대해, 따름, 건너뜀, 또는 가장함으로 표시합니다. 한 번의 패스로 수정 가능한 것은 수정합니다(일반적으로 검증되지 않은 주장: 지금 검증하거나 주의 사항으로 레이블 변경).
- 메서드 6단계에 따라 전달: 첫 문장에 결과, 검증 증거 제시, 정직한 주의 사항, 작업에서 발생한 경우에만 후속 작업. 보고서에 단계 이름이나 단계 번호는 포함하지 않습니다. INTENT와 AUTH 라인만이 보고서에 포함될 수 있는 유일한 메서드 산출물입니다.
이 루프를 사용하지 말아야 할 경우
- 사소한 작업(게이트가 처리함)
- 다단계 작업이 없는 순수 질문: 일반 fable-method로 충분
- 이미 오케스트레이션된 GSD 단계 내부: GSD가 해당 단계를 소유하므로, 루프를 중첩하는 대신 내부에서 fable-method 규칙을 적용
모델 경제성
이 루프는 모델에 구애받지 않습니다. 증거 및 공격자 하위 에이전트는 저비용 모델에 친화적입니다. 메인 스레드(의사 결정, 편집)는 사용 가능한 가장 강력한 모델에 유지하고, 선택권이 있을 때 공격자에게 수집기보다 더 높은 노력을 할당하십시오.
사용법
/fable-loop <작업> 전체 오케스트레이션 루프 실행