omc-plan

<목적> Plan은 지능적인 상호작용을 통해 포괄적이고 실행 가능한 작업 계획을 생성합니다. 광범위한 요청 시 사용자와 인터뷰를 진행하거나, 세부 요청 시 직접 계획을 수립하는 것을 자동으로 감지합니다. 또한 합의 모드(Planner/Architect/Critic 반복 루프와 RALPLAN-DR 구조화된 심의)와 검토 모드(Critic이 기존 계획 평가)를 지원합니다. </목적>

<사용_시기>

• 사용자가 구현 전에 계획을 원할 때 -- "plan this", "plan the", "let's plan"
• 사용자가 막연한 아이디어에 대한 구조화된 요구사항 수집을 원할 때
• 사용자가 기존 계획의 검토를 원할 때 -- "review this plan", --review
• 사용자가 계획에 대한 다각적 합의를 원할 때 -- --consensus, "ralplan"
• 작업이 광범위하거나 모호하여 코드를 작성하기 전에 범위 설정이 필요할 때 </사용_시기>

<사용하지_말아야_할_시기>

• 사용자가 완전 자동화된 종단간 실행을 원할 때 -- 대신 autopilot 사용
• 사용자가 명확한 작업으로 즉시 코딩을 시작하려 할 때 -- 대신 ralph를 사용하거나 실행기에 위임
• 사용자가 직접 답변할 수 있는 간단한 질문을 할 때 -- 그냥 답변
• 작업이 명백한 범위를 가진 단일 집중 수정일 때 -- 이 계획 모듈에서 실행하지 말고 대신 실행 기술 사용 </사용하지_말아야_할_시기>

<이_기능이_존재하는_이유> 요구사항을 이해하지 못한 채 코드에 뛰어들면 재작업, 범위 확장, 예외 케이스 누락이 발생합니다. Plan은 구조화된 요구사항 수집, 전문가 분석, 품질 검증을 거친 계획을 제공하여 실행이 견고한 기반 위에서 시작되도록 합니다. 합의 모드는 고위험 프로젝트에 대해 다각적 검증을 추가합니다. </이_기능이_존재하는_이유>

<실행_정책>

• 요청의 구체성에 따라 인터뷰 모드와 직접 모드를 자동 감지
• 인터뷰 중에는 한 번에 하나의 질문만 하세요. 여러 질문을 일괄 제출하지 마세요.
• 사용자에게 묻기 전에 explore 에이전트를 통해 코드베이스 사실 수집
• 계획은 품질 기준을 충족해야 함: 80% 이상의 주장이 파일/라인을 인용, 90% 이상의 기준이 테스트 가능
• 합의 모드는 기본적으로 완전 자동화로 실행됨. 초안 검토 및 최종 승인 단계에서 사용자 프롬프트를 활성화하려면 --interactive 추가
• 합의 모드는 기본적으로 RALPLAN-DR 단축 모드를 사용함. --deliberate를 사용하거나 요청이 명시적으로 높은 위험(인증/보안, 데이터 마이그레이션, 파괴적/되돌릴 수 없는 변경, 프로덕션 장애, 규정 준수/PII, 공개 API 손상)을 나타낼 경우 심의 모드로 전환
• 계획/실행 경계: 계획 모드는 컨텍스트를 검사하고 계획/명세/제안서만 생성합니다. 사용자가 현재 턴에서 또는 구조화된 승인 UI를 통해 명시적으로 실행에 동의하지 않는 한, 아티팩트를 승인 보류로 표시해야 합니다. 명시적인 실행 승인 전에, 계획 모드는 변경을 가하는 쉘 명령어를 실행하거나, 소스 파일을 편집하거나, 커밋, 푸시, PR 열기, 실행 기술 호출 또는 구현 작업 위임을 해서는 안 됩니다.
• 목표 워크플로우 경계: 계획이 Claude Code /goal, Ralph, Team, 또는 아티팩트 전용 Ultragoal을 비교할 때, 정확히 하나의 기본 루프 권한을 식별하고 비결정적 경고 처리 대신 refuse, adopt_existing, artifact_only와 같은 결정적 충돌 정책을 사용하세요. /goal 사실은 Claude Code/Anthropic 소스만 인용해야 하며(Claude Code /goal 문서: https://code.claude.com/docs/en/goal; Anthropic Claude Code 변경 로그: https://raw.githubusercontent.com/anthropics/claude-code/main/CHANGELOG.md), 계획은 /goal 평가자가 독립적으로 명령어를 실행하거나 파일을 읽는다고 주장해서는 안 됩니다. 완료 주장 전에 입증된 증거가 필요합니다.
• 목표 워크플로우 문서 대상: 사용자 대면 비교의 경우, 예제를 docs/shared/mode-selection-guide.md#goal-oriented-workflow-selection 및 docs/REFERENCE.md#goal-workflow-ux-goal-ralph-team-ultragoal에 맞추세요. </실행_정책>

<단계>

모드 선택

모드	트리거	동작
인터뷰	광범위 요청 시 기본값	대화형 요구사항 수집
직접	--direct, 또는 세부 요청	인터뷰 생략, 계획 직접 생성
합의	--consensus, "ralplan"	Planner -> Architect -> Critic 루프를 RALPLAN-DR 구조화된 심의와 함께 합의에 도달할 때까지 반복(기본값 단축, 고위험 시 --deliberate); 초안 및 승인 단계에서 사용자 프롬프트를 위해 --interactive 추가
검토	--review, "review this plan"	기존 계획에 대한 Critic 평가

인터뷰 모드 (광범위/모호한 요청)

1. 요청 분류: 광범위(모호한 동사, 특정 파일 없음, 3개 이상 영역에 영향)는 인터뷰 모드 트리거
2. 집중 질문 하나 하기: 선호도, 범위, 제약 조건에 대해 AskUserQuestion 사용
3. 먼저 코드베이스 사실 수집: "코드에서 어떤 패턴을 사용하나요?"라고 묻기 전에, explore 에이전트를 실행하여 알아낸 후 정보에 기반한 후속 질문을 하세요.
4. 답변 기반 구축: 각 질문은 이전 답변을 기반으로 함
5. Analyst(Opus) 상담: 숨겨진 요구사항, 예외 케이스, 위험 파악
6. 사용자가 준비 신호를 보내면 계획 생성: "계획을 만들어 줘", "준비됐어", "작업 계획으로 만들어 줘"

직접 모드 (세부 요청)

1. 빠른 분석: 선택적 간략한 Analyst 상담
2. 계획 생성: 즉시 포괄적인 작업 계획 생성
3. 검토 (선택 사항): 요청 시 Critic 검토

합의 모드 (--consensus / "ralplan")

RALPLAN-DR 모드: 단축(기본값, 범위가 정해진 구조) 및 심의(--deliberate 또는 명시적 고위험 요청용). 두 모드 모두 동일한 Planner -> Architect -> Critic 시퀀스와 동일한 AskUserQuestion 게이트를 유지합니다.

제공자 재정의(제공자 CLI가 설치된 경우 지원됨):

• --architect codex — 구현 위주의 아키텍처 검토를 위해 Claude Architect 패스를 omc ask codex --agent-prompt architect "..."로 대체
• --critic codex — 실행 전 외부 검토를 위해 Claude Critic 패스를 omc ask codex --agent-prompt critic "..."로 대체
• 요청된 제공자를 사용할 수 없는 경우, 간략히 알리고 해당 단계의 기본 Claude Architect/Critic 단계로 계속 진행

상태 수명 주기: 지속 모드 중지 후크는 ralplan-state.json을 사용하여 합의 루프 동안 계속을 강제합니다. 스킬 MUST 이 상태를 관리해야 합니다:

• 진입 시: 1단계 전에 state_write(mode="ralplan", active=true, session_id=<current_session_id>) 호출
• 실행으로 전환 시(승인 → ralph/team): state_write(mode="ralplan", active=false, session_id=<current_session_id>) 호출. 여기서 state_clear를 사용하지 마세요 — state_clear는 30초 취소 신호를 작성하여 새로 시작된 실행 모드를 보호하지 않은 채 모든 모드에 대한 중지 후크 적용을 비활성화합니다.
• 진정한 터미널 종료 시(거부, 비대화형 계획 출력, 오류/중단): state_clear(mode="ralplan", session_id=<current_session_id>) 호출 — 실행 모드가 뒤따르지 않으므로 취소 신호 창은 무해합니다.
• Critic 승인 또는 최대 반복 표시와 같은 중간 단계에서 지우지 마세요. 사용자가 여전히 "변경 요청"을 선택할 수 있습니다.

정리하지 않으면 중지 후크는 합의 워크플로우가 완료된 후에도 [RALPLAN - CONSENSUS PLANNING] 강화 메시지로 모든 후속 중지를 차단합니다. 항상 session_id를 전달하여 다른 동시 세션의 상태를 지우지 않도록 하세요.

1. Planner가 Architect 검토 전에 초기 계획과 간결한 RALPLAN-DR 요약을 생성합니다. 요약 MUST에 다음이 포함되어야 함:

   • 원칙 (3-5개)
   • 결정 동인 (상위 3개)
   • 실행 가능한 옵션 (>=2개) 각 옵션에 대한 범위가 정해진 장단점
   • 실행 가능한 옵션이 하나만 남은 경우, 거부된 대안에 대한 명시적 무효화 근거
   • 심의 모드에서: 사전 사고 (3가지 실패 시나리오) 및 단위 / 통합 / e2e / 관찰 가능성을 포함한 확장된 테스트 계획

2. 사용자 피드백 (--interactive 전용): --interactive로 실행하는 경우, MUST AskUserQuestion을 사용하여 초안 계획 및 RALPLAN-DR 원칙/결정 동인/옵션 요약을 조기 방향 정렬을 위해 다음 옵션과 함께 제시합니다:

   • 검토 진행 — 평가를 위해 Architect와 Critic으로 전송
   • 변경 요청 — 사용자 피드백을 통합하여 1단계로 복귀
   • 검토 건너뛰기 — 최종 승인(7단계)으로 직접 이동 --interactive 없이 실행하는 경우, 자동으로 검토(3단계)로 진행합니다.

3. Architect가 Task(subagent_type="oh-my-claudecode:architect", ...)를 사용하여 아키텍처 건전성을 검토합니다. Architect 검토 MUST에 다음이 포함되어야 함: 선호 옵션에 대한 가장 강력한 철인 반론(반제), 최소 하나의 의미 있는 트레이드오프 긴장, 그리고 (가능한 경우) 종합 경로. 심의 모드에서 Architect는 원칙 위반을 명시적으로 표시해야 합니다. 이 단계가 완료될 때까지 기다린 후 4단계로 진행하세요. 3단계와 4단계를 병렬로 실행하지 마세요. Architect는 Planner가 1단계에서 생성한 동일한 고정 계획 스냅샷을 변경하지 않고 평가해야 합니다. Architect 출력은 Critic에 전달되어서는 안 됩니다.

4. Critic이 Task(subagent_type="oh-my-claudecode:critic", ...)를 사용하여 품질 기준에 대해 평가합니다. Critic MUST 원칙-옵션 일관성, 공정한 대안 탐색, 위험 완화 명확성, 테스트 가능한 승인 기준, 구체적인 검증 단계를 확인해야 합니다. Critic MUST 피상적 대안, 동인 모순, 모호한 위험, 또는 약한 검증을 명시적으로 거부해야 합니다. 심의 모드에서 Critic MUST 누락되거나 약한 사전 사고 또는 누락되거나 약한 확장된 테스트 계획을 거부해야 합니다. 3단계가 완료된 후에만 실행하세요. Critic은 동일한 고정 계획 스냅샷을 독립적으로 개별적으로 대기된 별도의 Task 호출로 평가해야 합니다. Critic은 Architect 검토를 소비하거나 수신해서는 안 됩니다.

   하나의 고정 계획 스냅샷에 대한 독립적인 순차 검토. Architect와 Critic은 각각 Planner가 1단계에서 생성한 동일한 고정 계획 스냅샷을 검토하며, 어떤 검토도 이를 변경하지 않습니다. Architect 출력은 Critic에 전달되어서는 안 됩니다. Architect와 Critic은 별도의 개별적으로 대기된 Task 호출로 순차적으로 실행되어야 하며 — 병렬로 실행되어서는 안 되며 — Critic Task는 Architect Task가 완료되고 그 결과가 대기될 때까지 발행되어서는 안 됩니다. Critic은 Architect 검토를 소비하거나 수신해서는 안 됩니다. Architect와 Critic 결과는 개정 또는 개선 종합 중에만 Planner에 의해 결합되어야 하며, 두 검토가 모두 완료된 후에만 가능합니다.

5. 재검토 루프 (최대 5회 반복): Critic이 거부하면 이 폐쇄 루프를 실행합니다: a. Architect + Critic의 모든 거부 피드백 수집(Planner 전용 종합: Architect와 Critic 결과는 Planner에 의해서만, 그리고 두 검토가 모두 완료된 후에만 결합되어야 합니다). b. 수정된 계획을 생성하기 위해 피드백을 Planner에 전달 c. 3단계로 복귀 — Architect가 수정된 계획 검토 d. 4단계로 복귀 — Critic이 수정된 계획 평가 e. Critic이 승인하거나 최대 5회 반복에 도달할 때까지 반복 f. 최대 반복 횟수에 도달했지만 승인되지 않은 경우, 전문가 합의에 도달하지 못했다는 메모와 함께 AskUserQuestion을 통해 사용자에게 최상의 버전 제시

6. 개선 사항 적용: 검토자가 개선 제안과 함께 승인할 때, 계획 파일에 모든 승인된 개선 사항을 진행 전에 병합합니다. 최종 합의 출력 MUST에 ADR 섹션이 포함되어야 함: 결정, 동인, 고려된 대안, 선택된 이유, 결과, 후속 조치. 구체적으로: a. Architect와 Critic 응답에서 모든 개선 제안 수집 b. 제안 중복 제거 및 분류 c. .omc/plans/의 계획 파일을 승인된 개선 사항으로 업데이트(누락된 세부 사항 추가, 단계 개선, 승인 기준 강화, ADR 업데이트 등) d. 계획 끝에 간단한 변경 로그 섹션에 적용된 개선 사항 기록

7. Critic 승인 시(개선 사항 적용됨): 명시적 실행 승인이 이미 캡처되지 않은 한 계획 상태를 승인 보류로 표시합니다. (--interactive 전용) --interactive로 실행하는 경우, AskUserQuestion을 사용하여 다음 옵션과 함께 계획을 제시합니다:

   • 팀을 통한 실행 승인 (권장) — 조정된 병렬 팀 에이전트(/team)를 통해 진행하는 명시적 동의. Team은 v4.1.7 이후 표준 오케스트레이션 표면입니다.
   • ralph를 통한 실행 승인 — 검증과 함께 Ralph 지속성을 통해 진행하는 명시적 동의
   • 압축 후 실행 승인을 위해 반환 — 먼저 컨텍스트 창을 압축(계획 후 컨텍스트가 큰 경우 권장)한 다음 저장된 승인 보류 계획에서 중지하고 실행을 시작하기 전에 다시 요청하는 명시적 동의
   • 변경 요청 — 사용자 피드백을 통합하여 1단계로 복귀
   • 거부 — 계획을 완전히 폐기 --interactive 없이 실행하는 경우, 최종 계획을 승인 보류로 표시하여 출력하고 state_clear(mode="ralplan", session_id=<current_session_id>)를 호출한 다음 중지합니다. 자동 실행하지 마세요.

8. (--interactive 전용) 사용자가 구조화된 AskUserQuestion UI를 통해 선택합니다(절대 일반 텍스트로 승인을 요청하지 마세요). 사용자가 거부를 선택하면 state_clear(mode="ralplan", session_id=<current_session_id>)를 호출하고 중지합니다.

9. 사용자가 …

[중복되어 번역 대상에서 제외됨]