팬아웃 -- 선택적 발산적 사고 패스
경험적 근거: 관리자의 2단계 평가. 팬아웃은 발산적 설계 작업에서 작지만 일관된 이점을 제공하고 수렴적 루트 원인 작업에서는 아무런 이점을 제공하지 않습니다. 작업이 열려 있고 중요도가 높은 경우에만 약 7배의 토큰 가치가 있습니다. 이 스킬은 일상적인 작업에서는 절대 실행되지 않으면서 필요 시 사용할 수 있도록 존재합니다.
0단계 -- 실행 전 게이트(필수)
선택자에 대해 작업을 확인합니다. 두 조건이 모두 참이어야 합니다:
- 열린 문제? 여러 정답이 있음("X에 대한 설계 / 이름 / 접근법 / 가설"). 작업이 "왜 X가 고장 났는지", "수정이 작동했는지", "근본 원인이 무엇인지" 또는 하나의 확인 가능한 답변이 있는 경우 -> 이는 수렴적 문제입니다. 단일 샷이 여기에 더 나은 도구라고 사용자에게 알리고, 실행하기 전에 계속 진행할지 물어보십시오. 수렴적 작업에서 조용히 실행하지 마십시오.
- 약 7배의 토큰에 충분히 중요? 부하 지지 규칙 / API 형태 / 이름 / 전략으로, 가벼운 것이 아닙니다. 중요도가 낮아 보이면 말하고 확인하십시오.
게이트가 모호하면 자신의 해석을 말하고 물어보십시오. 통과하면 진행합니다.
1단계 -- 문제 파악
문제 설명을 다음에서 받습니다: @-멘션된 파일, 파일 경로, 또는 사용자 메시지에 붙여넣은 텍스트. 모호한 주제만 주어진 경우, 먼저 한두 문장의 문제 프레이밍을 요청하십시오 -- 프레임에는 구체적인 내용이 필요합니다.
1.5단계 -- 대상이 프로젝트 산출물인 경우 방향 설정(필수)
/fanout <파일 경로>는 방향이 설정된 것처럼 보이지만 그렇지 않습니다: 프레임은 산출물만 추론하고, 프로젝트의 현재 상태를 제공하지 않으면 자신 있게 모순됩니다. 2단계 전에, 문제가 프로젝트 폴더 아래의 파일(사양, 결정 문서, CHECKPOINT 스레드, 코드 파일)이거나 그것을 명명하는 경우, 먼저 해당 프로젝트의 CHECKPOINT.md를 EOF까지 읽고(훅이 노출하지 않은 경우 CLAUDE.md도). SessionStart 영수증은 바이트/라인 수이며 파일이 아닙니다 -- 미리보기는 읽기가 아닙니다. 그런 다음 부하 지지 제약 조건(마감일, 자금/순서 게이트, 기존 결정, 이미 시도/거부된 것, 하드 숫자)을 추출하여 산출물 텍스트와 동일한 방식으로 모든 프레임 프롬프트와 비평가에 그대로 붙여넣습니다. 산출물을 받았지만 프로젝트 상태를 받지 못한 프레임은 문서화된 실패입니다(비용 사양에 대한 실제 팬아웃은 프로젝트의 CHECKPOINT와 직접적으로 모순되는 "손익분기점 이후에 하라, 조급하다" 프레이밍을 표면화했습니다). 이 단계는 문제가 진정으로 프로젝트가 없는 경우(과거 추상 질문, 살아있는 상태가 없는 네이밍/API 형태 연습)에만 건너뜁니다.
2단계 -- 발산(5개의 병렬 Agent 호출, 단일 메시지)
5개의 general-purpose 에이전트를 병렬로 실행합니다(단일 메시지, 5개의 도구 호출). 각각에 동일한 문제와 하나의 뚜렷한 관점을 제공합니다. 각 에이전트의 지침: "할당된 관점에서만 분석하십시오. 4-6개의 뚜렷한 접근법/아이디어를 생성하십시오; 각각에 대해, 그것이 지니는 실패 모드(함정)를 명명하고 메커니즘을 기술하십시오. 구체적으로, 메커니즘을 명명하고, 회피하지 말고, 순위를 매기지 말고, 자신의 아이디어를 평가하지 마십시오. 간결하게 유지하십시오(이것은 비평 패스에 공급됩니다)." 출력을 직접 반환합니다(사용자가 저장을 요청하지 않는 한 파일 쓰기 없음).
5가지 관점(원문 그대로):
- 아키텍처 / 시스템 -- 상태 머신, 데이터 흐름, 정보가 변환되거나 손실되는 곳을 생각하십시오; 시스템이 보이는 동작 아래 계층에서 하는 일; 동시성, 실패 또는 규모 하에서 어떻게 깨지는지.
- 적대적 / 악마의 대변인 -- 모든 옵션에 치명적인 결함이 있다고 가정하고 그것을 찾으십시오; 각각이 조용히 가정하는 것은 무엇인가; 명백한 답이 미끼라면 무엇이 사실일까.
- 첫 원칙 -- 기본 메커니즘까지 벗겨내고 실제 제약 조건에서 재구축하십시오, 관행을 불신하십시오; 실제로 필요한 것 대 단지 관례적인 것.
- 실무자 / 운영자 -- 프로덕션에서 이것을 실행하고 새벽 3시에 페이징된 적이 있습니다; 현장 실패, 에지 케이스, 운영 부담, 관찰 가능성, 설계와 온콜 현실 간의 격차에 관심을 가지십시오.
- 일반주의 외부자 -- 도메인 컨텍스트 없음; 직관적으로 이해되는 것; 순환 추론을 숨기는 전문 용어를 불신하십시오; 내부 전문가가 놓칠 수 있는 명백한-뒤늦은 함정.
3단계 -- 비평(1개의 Agent 호출)
5개가 모두 반환되면, 5개의 출력 + 문제를 포함하여 하나의 general-purpose 에이전트를 실행합니다. 지침: "1) 각 접근법을 참신성/실현 가능성/적합성에 대해 점수화하십시오(0-10). 2) 기본 전략에 따라 프레임 간에 클러스터링하십시오; 2개 이상의 프레임이 수렴된 곳을 기록하십시오(그 수렴은 신호입니다). 3) 함정 유니온: 5개 프레임 전체에서 메커니즘적으로 기술된 뚜렷한 함정의 중복 제거된 유니온, 각각의 메커니즘과 함께. 4) 상위 3개 심층 분석: 더 선명한 버전, 메커니즘, 피해야 할 함정, 그것이 의존하는 가장 위험한 가정 + 커밋하기 전에 그 가정을 테스트하는 가장 저렴한 방법, 그리고 하나의 구체적인 첫 단계. 출력 섹션: ## 점수화됨, ## 클러스터, ## 함정 유니온, ## 상위 3개 심층 분석, ## 종합(4-6문장: 가장 강력한 방향 + 그것을 가장 위협하는 함정)."
4단계 -- 제시
채팅에서 사용자에게 비평가의 ## 상위 3개 심층 분석, ## 함정 유니온, ## 종합을 보여줍니다. 수렴(여러 프레임이 독립적으로 도달한 방향)을 요약합니다. 요청하지 않는 한 5개의 원시 프레임 출력을 모두 덤프하지 마십시오.
기본적으로 아무것도 유지하지 않습니다(남은 스크래치 파일은 그 자체로 혼란입니다). 사용자가 전체 기록을 원하면, 비평가 출력 + 프레임을 사용자가 지정한 경로에 저장하겠다고 제안하십시오.
참고
- 네이티브 Agent 도구만 사용하십시오 -- 프레임을 위해 중첩된
claude -p로 셸 아웃하지 마십시오(중첩된 CLI 실행은 권한/안전 레이어에서 불안정합니다; Agent 도구가 지원되는 경로입니다). - 호출당 한 번 실행됩니다(n=1). 사용자가 변동성 확인을 원하면 /fanout을 다시 호출할 수 있습니다 -- 하지만 작은 효과 크기가 거의 정당화되지 않습니다.
- 절대 자동 트리거하지 마십시오. 설명에 명시된 표면 형식만 사용하십시오.