▸  ←/→ navigate · P present · N notes · ESC overview · Cmd+P export PDF
FAST CAMPUS · CASE STUDY CHAPTER 04
OMC RALPLAN ANALYSIS

oh-my-claudecode는
sub agent를 어떻게 쓰고, 어떻게 검수하는가

GitHub 원본 기준으로 `ralplan`을 4C Stack 관점에서 다시 읽는다. 핵심은 agent 숫자가 아니라, 계획·실행·검수 책임을 분리하고 evidence로 다음 route를 정하는 구조다.

Source: github.com/Yeachan-Heo/oh-my-claudecode · decks/chapter-04.html · checked 2026-06-03
4-3 · Ralplan Case 4C · planner · architect · critic · verifier
PLAN
VERIFY
OMC CASE STUDY01 / 10
OMC RALPLAN ANALYSIS 4C STACK LENS

4C Stack으로 보면 OMC의 핵심은 세션 경계 설계다

`decks/chapter-04.html`의 4C는 Contract, Context, Control, Confidence다. 4장은 이 네 경계를 세션 단위로 확장한다. OMC의 `ralplan`은 이 중 C1을 계획 계약으로 만들고, 실행 mode는 C2-C4를 handoff, verify, route로 운영한다.
4C Stack to OMC Mapping C1 · CONTRACT 무엇을 할까 ralplan plan contract 원칙 · 결정 기준 · 선택지 planning artifact pending approval C2 · CONTEXT 무엇을 보존할까 plan path · handoff · state 대화 전문이 아니라 결정과 근거 .omc/plans · .omc/handoffs state C3 · CONTROL 어떻게 흐를까 team / ralph execution loop stage · story · fix loop team-exec → verify → fix PRD passes C4 CONFIDENCE fresh evidence review verdict pass / rework ask-back / exit 4C의 목적: main session은 상태판으로 두고, sub agent는 계약과 근거만 남긴 뒤 역할을 끝낸다.

Chapter 04: C1 leaf/plan contract · C2 handoff · C3 route control · C4 confidence gate

4C STACK ANALYSIS02 / 10
OMC RALPLAN ANALYSIS WHOLE STRUCTURE

전체 구조도 — 모호한 요청을 실행 가능한 검수 루프로 바꾼다

OMC Overall Flow from Ralplan to Verification USER PROMPT vague execution RALPLAN GATE consensus plan Planner → Architect → Critic PLAN ARTIFACT pending approval ADR · AC · verification steps EXPLICIT APPROVAL team or ralph planning agent does not code TEAM PATH PARALLEL STAGED EXECUTION team-plan team-prd team-exec team-verify fail → team-fix → verify loop RALPH PATH STORY-BY-STORY PERSISTENCE prd story implement reviewer verify reject → fix same story → re-verify Completion claim only after verification evidence and no remaining fix tasks

Overall SVG: ralplan creates the contract; team/ralph execute; verifier/reviewer controls the exit.

OVERALL STRUCTURE03 / 10
OMC RALPLAN ANALYSIS RALPLAN SVG

Ralplan 구조도 — 세 agent는 맡는 일이 다르다

Ralplan Planner Architect Critic Loop INPUT task request vague or high-risk SUB AGENT 1 Planner principles 3-5 drivers top 3 options + AC + tests SUB AGENT 2 Architect steelman antithesis tradeoff tension synthesis path SUB AGENT 3 Critic quality verdict risk + mitigation verification concrete? ITERATE / REJECT: collect feedback → Planner revises Architect → Critic OUTPUT pending approval plan USER GATE approve route HANDOFF Skill(team) Skill(ralph) Important: Architect and Critic are sequential. Planning mode must not mutate source before explicit execution approval.

Ralplan SVG: authoring, architecture review, and critique are separate lanes.

RALPLAN STRUCTURE04 / 10
OMC RALPLAN ANALYSIS VERIFICATION SVG

검수 구조도 — 스스로 “됐다”고 해도 믿지 않고 evidence를 요구한다

Verification Gate Evidence Loop CLAIM "done" not accepted yet GATE 1 AC coverage each criterion VERIFIED / PARTIAL / MISSING GATE 2 fresh checks tests · build · typecheck read actual output GATE 3 review lane verifier / architect critic / reviewer TEAM VERIFY verifier required RALPH VERIFY tiered reviewer ESCALATION security / review FAIL / INCOMPLETE: create fix task or continue same story then re-run evidence PASS only after evidence otherwise rework / ask-back / exit

Verification SVG: completion is a routed verdict, not an agent's self-report.

VERIFICATION STRUCTURE05 / 10
OMC RALPLAN ANALYSIS SOURCE MAPPING

코드 안에서는 책임 분리가 이렇게 드러난다

근거 파일확인한 구조강의 해석
skills/ralplanplan --consensus 별칭. Planner, Architect, Critic 합의 루프. 명시 승인 전 source mutation 금지.C1 Contract를 실행 전에 확정한다.
skills/planArchitect와 Critic은 순차 실행. Critic 미승인 시 최대 5회 re-review loop.sub agent 병렬 수량보다 review order가 중요하다.
skills/teamteam-plan → team-prd → team-exec → team-verify → team-fix. stage별 specialist routing.C2-C3가 stage와 handoff로 남는다.
skills/ralphPRD story별 acceptance criteria, reviewer verification, deslop, regression re-verification.C4 Confidence는 fresh evidence까지 요구한다.
REPO EVIDENCE06 / 10
OMC RALPLAN ANALYSIS ROLE SEPARATION

sub agent를 많이 띄우는 게 아니라, 책임을 나눈다

BAD LENS

agent fan-out만 본다

  • 여러 agent를 동시에 많이 띄운다.
  • 생성과 검토가 같은 대화 흐름에 뒤섞인다.
  • 완료됐다는 claim을 그대로 통과시킨다.
  • 실패 뒤 route가 없어 다시 사람이 수습한다.
4C LENS

계약과 검수 lane을 본다

  • Planner는 계약을 만든다.
  • Architect는 구조적 반론을 낸다.
  • Critic / Verifier는 evidence 기준으로 판정한다.
  • 결과는 pass / rework / ask-back / exit 중 하나로 정해진다.
FROM FAN-OUT TO LANES07 / 10
OMC RALPLAN ANALYSIS REVIEW DEPTH

검수 강도는 변경 위험에 따라 올라간다

STANDARD FLOOR

작은 변경도 evidence

Ralph는 작은 변경도 최소 STANDARD 검수를 요구한다. “작아서 괜찮다”가 아니라 “작아도 증거가 있다”가 기준이다.

TEAM VERIFY

verifier는 필수

Team의 verify stage는 verifier가 기본이다. 보안 변경에는 security-reviewer, 큰 변경에는 code-reviewer를 붙인다.

POST APPROVAL

승인 뒤 재검증

Ralph는 reviewer approval 이후에도 deslop pass와 regression re-verification을 거쳐야 비로소 완료로 인정된다.

RISK CONTROLS REVIEW DEPTH08 / 10
OMC RALPLAN ANALYSIS CLASS APPLICATION

4C Stack으로 가져갈 실습 포인트

C1은 plan contract로 확정하고, C2는 handoff와 state만 남기고, C3는 verify/fix loop로 흐름을 제어하고, C4는 fresh evidence로 completion claim을 검수한다.OMC에서 가져올 것은 구현 복사가 아니라 이 네 경계의 분리 방식이다.
4C APPLICATION09 / 10
OMC RALPLAN ANALYSIS TAKEAWAY
CLASS LINE

sub agent orchestration의 핵심은 검수 가능한 경계 설계다

Ralplan은 실행 전 계약을 만든다. Team과 Ralph는 실행 루프를 맡는다. Verifier, Critic, Architect는 claim에 evidence를 요구한다. 4C Stack은 이 분리를 가장 간결하게 설명하는 틀이다.

Key refs: skills/ralplan · skills/plan · skills/team · skills/ralph · decks/chapter-04.html
Next · deterministic review gate 계획·실행·검수를 한 context에 섞지 않는다
SPLIT
LANES
END10 / 10