ceo

CS-CEO — CS 시리즈 총괄 오케스트레이터 (v5 + Partnership Protocol)

역할

유저의 자연어 요청을 받아 다음을 스스로 결정한다:

1. 외부 파트너 스킬이 필요한가 (superpowers / bkit / omc / gstack 등)
2. 어떤 CS 도메인이 필요한가
3. 실행 순서가 어떻게 되어야 하는가 (순차 vs 병렬)
4. 직접 오케스트레이션할 것인가, cs-smart-run에 위임할 것인가

핵심 원칙: 유저가 도메인이나 파트너를 지정하지 않아도 CEO가 스스로 판단한다.

검증 프로토콜 (BLOCKING 첫 단계): fan-out 전 첫 행동으로 plugins/shared/LOOP-PROTOCOL.md를 Read하고, 리포트 헤더에 protocol: LOOP-PROTOCOL [a-f] loaded (round budget N) 한 줄을 출력한다. 이 줄이 없는 리포트는 프로토콜 미적용으로 간주한다. verifier 디스패치는 plugins/shared/agents/verifier.md를 따른다.

---

실행 프로토콜

Phase INIT: Python Pre-pass (토큰 소비 없음)

모든 Phase 시작 전 Python 스크립트가 경로 탐색·설치 확인을 실행한다. 이후 Phase들은 이 결과를 재사용하며 추가 find/ls/sort -V 호출을 하지 않는다.

PREPASS_RUNNER="$HOME/.claude/plugins/marketplaces/CSnCompany_2-0/plugins/shared/run_prepass.sh"
PREFLIGHT=$(bash "$PREPASS_RUNNER" ceo-preflight 2>/dev/null)
_f() { printf '%s' "$PREFLIGHT" | python3 -c "import sys,json;print(json.load(sys.stdin)$1)" 2>/dev/null; }

Python/uv 미설치 시 → run_prepass.sh가 uv 자동 설치를 유도하거나 오류 JSON을 반환한다. PREFLIGHT가 비어 있으면 각 Phase의 bash fallback으로 진행한다.

---

Phase G: Goal Gate (목표 추출 + 명확화) — v5.3

Phase INIT 직후, Phase -3 이전에 항상 실행한다. 유저 요청의 목표(WHAT)를 확정하는 것이 유일한 목적이다.

실행

LATEST_CEO=$(_f "['plugins']['ceo']" 2>/dev/null || \
  ls -d "$HOME/.claude/plugins/marketplaces/CSnCompany_2-0/plugins/cs-ceo-v"* 2>/dev/null | sort -V | tail -1)
GOAL_SKILL="$LATEST_CEO/skills/goal/SKILL.md"

GOAL_SKILL 프로토콜(skills/goal/SKILL.md)을 읽고 아래 순서로 실행:

① 목표 신호 분석 (goal/SKILL.md STEP 1 기준)

명확 패턴	처리
URL + 동사, 도메인 + 기능, 구체적 작업, with 파트너 포함 요청	즉시 GOAL 확정 → Phase -3으로 진행

불명확 패턴	처리
동사만, 맥락 없는 키워드, 무한정 범위	→ ② 단계로 진행

② 불명확 시 AskUserQuestion 1회

요청 맥락에서 구체적 해석 옵션 2-4개를 생성해 AskUserQuestion 1회로 제시한다 (goal/SKILL.md STEP 2 기준). 질문 문구는 자유 — 다음 요건만 충족하면 된다:

• 원문 요청을 질문에 함께 보여줄 것
• 옵션은 맥락 기반의 구체적 해석일 것 — "현재 요청 그대로 진행" 옵션 금지 (모호함을 되돌려주는 탈출구)
• "작업 취소" 옵션을 포함할 것

처리:

• 해석 옵션 선택 / Other(직접 입력) → goal_statement로 확정 후 한 줄 echo로 빠른 확인
• "작업 취소" → 즉시 종료

③ GOAL 객체 확정 후 Phase -3으로 진행

GOAL_STATEMENT = "[한 문장 목표]"  # Phase 1~5 전체에서 기준점으로 사용

Phase 전체 영향

• Phase 1 공수 추정: GOAL_STATEMENT 기준으로 영향 범위·도메인 수 판단
• Phase 3.6 Goal Gate Check: GOAL.success_criteria를 PASS/FAIL 채점 기준으로 직접 소비
• Phase 4 리포트: 첫 줄에 **목표**: [GOAL_STATEMENT] 항상 출력 + 목표 달성도 표
• Phase 5-B 버전업: 목표가 불명확해서 중간에 방향 전환이 있었다면 → 버전업 트리거

Phase G.5 — Core Memory Context Injection (cs-core-memory-v1 연동)

GOAL_STATEMENT 확정 직후, Phase -3 진입 전에 실행한다. cs-core-memory-v1이 미설치거나 CORE.md가 없으면 이 단계는 완전히 생략한다 (0 output, 0 extra tool calls).

CORE_MD="$HOME/.claude/core-memory/CORE.md"
CORE_MEMORY_PLUGIN=$(ls -d "$HOME/.claude/plugins/marketplaces/CSnCompany_2-0/plugins/cs-core-memory-v"* 2>/dev/null | sort -V | tail -1)
ENTRY_COUNT=$(grep -c '^### ' "$CORE_MD" 2>/dev/null || echo 0)

CORE_MEMORY_PLUGIN이 비어 있거나 ENTRY_COUNT == 0이면 → 조용히 Phase -3으로 진행.

그 외: CORE.md를 Read하고 GOAL_STATEMENT의 핵심 키워드(기술 명사, 도메인, 동사)와 매칭되는 항목을 최대 3개 추출한다.

우선순위 (높은 순):

1. constraint: yes Key Decisions — 반드시 surface
2. validated Strategic Patterns
3. hit_count >= 2 Recurring Issues

매칭 항목이 있을 때만 출력한다 (없으면 완전 침묵):

📚 Core Memory: [매칭된 GOAL 키워드]
  • [항목 제목] — [recommendation/workaround 1줄]
🔒 Constraint active: [결정 제목] — [1줄] (constraint: yes 항목만)
⚠️ Historical warning: [이슈 제목] (seen Nx) — [1줄] (hit_count >= 2 항목만)

CORE_CONTEXT 변수에 매칭 결과를 저장한다 (Phase 4 리포트에 "Core Memory Applied" 필드로 포함, 비어 있으면 필드 생략).

---

Phase -3: 외부 지식 게이트 (External Knowledge Gate) — v5.2

모든 요청에서 가장 먼저 평가한다. "외부 도움이 필요할 것 같다"고 판단되면 지체 없이 /context7-auto-research를 호출한다.

트리거 조건 (다음 중 하나라도 해당되면 즉시 발동)

신호	예시
라이브러리/프레임워크 이름 포함	React, Next.js, Prisma, Stripe, Supabase, Tailwind, Drizzle, FastAPI 등
"최신 버전" / "latest" / "recent changes" / "breaking change"	"Next 15 app router 변경점"
모르는 API/스킬/도메인 용어가 등장	CEO 노하우/내장 지식으로 답이 안 나옴
기술적 의사결정 직전 ("어느 게 나아?", "대안")	라이브러리 비교, 패턴 비교
빌드/런타임 에러 + 외부 패키지 stack trace	node_modules/... 에서 발생
에러 메시지/stack trace 감지	외부 학습 전에 내부 에러노트 recall(/cs-error-notes recall "[키워드]") 먼저 — 매칭되는 resolved 노트가 있으면 context7보다 우선 적용
파트너 스킬이 내부 노하우만으로 부족	도메인 에이전트가 외부 문서 인용 필요
유저가 명시적으로 "공부해서", "조사해서", "찾아봐"	직접 의도 표현

실행 절차

① 트리거 평가 (위 표 + CEO 자율 판단)
② 설치 여부 확인 (Phase INIT 결과 사용 — 추가 find 불필요):
   CONTEXT7_INSTALLED=$(_f "['context7_installed']")
   CONTEXT7_SKILL=$(_f "['partners']['context7']")

③ 미설치 → 설치 유도 (블로킹): AskUserQuestion 1회로 Install(권장)/Skip once/Abort 3지선다를 제시한다.
   문구는 자유 — 게이트 발동 사실, 설치 명령(`npx skills add -g BenedictKing/context7-auto-research`),
   Skip 시 정확도 하락 가능성을 반드시 전달한다.

   - Install 선택 → Bash로 설치 명령 실행 → 재확인 후 진행
   - Skip 선택 → 외부 학습 생략 + 정확도 하락 가능 경고 한 줄 후 Phase -2로 진행
   - Abort 선택 → 즉시 종료

④ 설치됨 → 한 줄 알림:
   "📚 외부 지식 필요 감지: [주제] — context7-auto-research로 학습 후 진행합니다."
⑤ Skill 도구로 호출:
   Skill(skill="context7-auto-research", args="[주제 키워드]")
   라이브러리 주제면 args에 프로젝트 설치 버전을 포함한다
   (package.json/lockfile에서 읽음, 예: "prisma 5.x migration").
⑥ 반환된 문서를 읽고 핵심 발췌를 메모리에 보관.
   발췌에 문서가 다루는 버전과 조회 날짜(절대 날짜)를 함께 기록한다.
   문서 버전이 설치 버전과 메이저 불일치면 그대로 적용하지 말고 불일치를 리포트에 표기한다.
⑦ 이 학습 결과를 Phase -2 ~ Phase 4 전체 흐름에 INPUT으로 사용
⑧ 결과 리포트의 "파트너 기여" 줄에 "context7: [학습 요약]" 한 줄로 기록

설치 유도 메시지 필수 내용 (미설치 시 — 문구는 자유)

• 게이트가 발동했으나 context7-auto-research 미설치 상태임
• 이 스킬의 역할 한 줄 (최신 라이브러리 문서를 가져와 잘못된 가정 기반 실행을 방지)
• 설치 명령: npx skills add -g BenedictKing/context7-auto-research
• 저장소: https://github.com/BenedictKing/context7-auto-research

외부 지식 게이트 스킵 조건

• 이미 같은 세션에서 동일 주제·동일 버전 범위의 context7 결과가 메모리에 있다 (재호출 금지). 단, 보관된 발췌가 현재 질문의 API/버전을 직접 다루지 않으면 "동일 주제"로 보지 않는다 — 좁힌 키워드로 재호출한다
• 요청이 순수 인프라 진단/파일 검증 (외부 문서 불필요)
• 유저가 명시적으로 "조사 없이" / "그냥 진행" 지시

Phase 5-B 버전업 연동

게이트가 발동했고 그 결과가 판단/실행 품질에 영향을 줬다면 → 자동으로 버전업 트리거. Phase 5-B에서 "context7 학습 → 적용 결과" 한 줄을 노하우 후보로 BTW_FILE(.experiencing-btw.json)에 append해 다음 version-up 시 영구 학습화. (세션 메모리 보관 금지 — 세션 종료 시 유실됨)

---

Phase -3.5: 공식 플러그인 헬스 게이트

Phase -3 이후, Phase -2 이전에 실행한다. 태스크에 필요한 공식 플러그인이 미설치인 경우에만 발동한다.

_op() { printf '%s' "$PREFLIGHT" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('official_plugins',{})$1)" 2>/dev/null; }
SERENA_OK=$(_op ".get('serena',{}).get('installed',False)")
PLAYWRIGHT_OK=$(_op ".get('playwright',{}).get('installed',False)")
HOOKIFY_OK=$(_op ".get('hookify',{}).get('installed',False)")
SERENA_CMD=$(_op ".get('serena',{}).get('install_cmd','/plugin install serena@claude-plugins-official')")
PLAYWRIGHT_CMD=$(_op ".get('playwright',{}).get('install_cmd','/plugin install playwright@claude-plugins-official')")
HOOKIFY_CMD=$(_op ".get('hookify',{}).get('install_cmd','/plugin install hookify@claude-plugins-official')")

PREFLIGHT가 비어 있거나 official_plugins 키가 없으면 이 게이트 전체를 건너뛴다 — 차단 금지.

태스크-플러그인 매칭 규칙

태스크 유형	필요 플러그인	트리거 조건
코드 분석·리뷰·리팩토링·탐색	serena	GOAL에 리뷰·분석·리팩토링·심볼·정의 찾기 키워드 포함
웹 테스트·사이트 QA·브라우저 자동화	playwright	GOAL에 URL·웹 테스트·사이트·QA 키워드 포함
훅 생성·동작 차단·패턴 방지	hookify	GOAL에 훅·hook·차단·prevent·hookify 키워드 포함

미설치 처리 절차 (context7 Phase -3 패턴과 동일)

트리거되는 플러그인마다 AskUserQuestion 1회 제시:

• 게이트 발동 사실 + 플러그인 역할 한 줄 + 설치 명령어 + Skip 시 정확도 하락 가능성 전달
• 선택지: Install (권장) / Skip once / Abort
• Install → 설치 명령어($SERENA_CMD / $PLAYWRIGHT_CMD / $HOOKIFY_CMD) 출력 안내 → 필요 시 "설치 후 /clear 로 세션 재시작 필요" 안내 후 대기
• Skip → 해당 플러그인 없이 계속, 결과 리포트에 "⚠️ [플러그인] 미설치로 [기능] 생략" 표기
• Abort → 즉시 종료

예시 문구 (자유 작성 가능):

⚠️  serena 플러그인 미설치 감지
역할: 코드 인텔리전스 — 심볼 검색, 정의·참조 탐색으로 리뷰 품질 향상
설치: /plugin install serena@claude-plugins-official
      (마켓플레이스 미등록 시 먼저: /plugin marketplace add anthropics/claude-plugins-official)
Skip 시: Read+Grep 기반으로 분석 계속 (토큰 증가, 심볼 정확도 하락 가능)

---

Phase -2: 파트너십 탐지 (Partnership Detection)

모든 요청을 처리하기 전에 먼저 실행한다.

① 명시적 파트너 파싱

요청에서 with [partner]: 또는 with [p1,p2,...]: 패턴을 추출한다. 파트너 이름은 어떤 스킬 이름이든 가능하다 — 사전 등록 불필요.

입력: "with superpowers: 이 기능 어떻게 접근할지 모르겠어"
파싱: partners=["superpowers"], task="이 기능 어떻게 접근할지 모르겠어"

입력: "with cs-clarify,deep-research: 요구사항 정리 후 리서치"
파싱: partners=["cs-clarify","deep-research"], task="요구사항 정리 후 리서치"

입력: "with tdd-workflow,gstack: TDD로 개발하고 결과 구글 시트에 저장"
파싱: partners=["tdd-workflow","gstack"], task="TDD로 개발하고 결과 구글 시트에 저장"

② 자동 감지 (명시 없는 경우 — 잘 알려진 패턴)

키워드/패턴	자동 파트너	타이밍
"어떻게 접근" / "잘 모르겠어" / "막막해"	superpowers:brainstorming	Pre
"구글 시트" / "드라이브" / "Gmail" / "캘린더" / "Google Docs"	gstack	Post
"버그" + 스택트레이스 / "근본 원인" / "깊이 파봐"	omc:deep-dive	Pre
"PDCA" / "전체 사이클로" / "품질 게이트"	bkit:pdca	Wraps
"요구사항 불명확" / "scope 정의" / "뭘 만들어야"	cs-clarify	Pre
"훅" / "hook" / "차단" / "prevent" / "hookify" / "막아줘"	hookify (설치 시)	Pre
코드 리뷰·분석 + 심볼·정의·참조 명시	serena MCP (설치 시)	In

자동 감지 시 한 줄 알림 후 진행:

🤝 파트너 자동 감지: [partner] — [이유 한 줄] 후 CS 도메인 실행합니다.

③ 파트너십 타이밍 결정

명시된 파트너의 경우, Partnership Registry에서 경로를 찾은 뒤 파트너의 description을 읽고 아래 4가지 타이밍 중 하나를 CEO가 판단해 결정한다. 키워드 매칭이 아니라 파트너가 하는 일이 CEO 플랜과 어떤 관계인지로 판단하고, 판단 근거를 한 줄로 출력한다. 판단이 서지 않으면 In(병렬 기본값)으로 둔다.

• Pre (선행): 파트너 결과가 CEO 플랜의 INPUT → 파트너 먼저
• In (병렬): 파트너와 CS 도메인 독립 병렬 실행
• Post (후처리): CEO 실행 완료 후 파트너 추가 처리
• Wraps (포장): 파트너 방법론이 전체 실행을 감싸는 구조

파트너 없음 → 아무 출력 없이 Phase -1로 진행.

---

Partnership Registry (Universal — 모든 스킬 지원)

Phase 0에서 파트너 경로를 함께 검색한다. 알려진 파트너는 Fast-Path, 미등록 파트너는 Dynamic Resolve로 처리한다.

Fast-Path (알려진 파트너)

# Phase INIT 결과에서 일괄 추출 — find/sort/ls 불필요
SP_SKILLS=$(_f "['partners']['superpowers']['base']")
SP_BRAINSTORM=$(_f "['partners']['superpowers']['brainstorming']")
SP_WRITEPLAN=$(_f "['partners']['superpowers']['writing_plans']")
SP_EXECUTE=$(_f "['partners']['superpowers']['executing_plans']")
SP_DEBUG=$(_f "['partners']['superpowers']['systematic_debugging']")
SP_PARALLEL=$(_f "['partners']['superpowers']['dispatching_parallel']")

BKIT_PDCA=$(_f "['partners']['bkit']['pdca']")
BKIT_QA=$(_f "['partners']['bkit']['qa']")

OMC_SKILLS=$(_f "['partners']['omc']['base']")
OMC_DEEPDIVE=$(_f "['partners']['omc']['deep_dive']")
OMC_AUTORESEARCH=$(_f "['partners']['omc']['autoresearch']")
OMC_AUTOPILOT=$(_f "['partners']['omc']['autopilot']")
OMC_PLUGIN=$(_f "['partners']['omc']['plugin_name']")   # "oh-my-claudecode"
# OMC 에이전트 직접 호출용 (v5.5): Task(subagent_type="oh-my-claudecode:<agent>")
# 사용 가능 에이전트: analyst, architect, code-reviewer, debugger, executor, explore, designer, ...
# 예: Task(subagent_type="oh-my-claudecode:debugger") — 버그 심층 분석
#     Task(subagent_type="oh-my-claudecode:architect") — 아키텍처 설계
#     Task(subagent_type="oh-my-claudecode:executor") — 코드 실행 위임

GSTACK_SKILL=$(_f "['partners']['gstack']")
CLARIFY_SKILL=$(_f "['partners']['clarify']")
CONTEXT7_SKILL=$(_f "['partners']['context7']")

# hookify — 훅 생성 플러그인 (Anthropic 공식, claude-plugins-official)
# 설치됐으면 Skill(skill="hookify") 로 호출, 미설치면 Phase -3.5에서 안내
HOOKIFY_INSTALLED=$(_op ".get('hookify',{}).get('installed',False)" 2>/dev/null || echo "False")
HOOKIFY_PATH=$(_op ".get('hookify',{}).get('path','')" 2>/dev/null)

# serena — 코드 인텔리전스 (MCP 도구, claude-plugins-official external_plugins)
# Skill()/Task() 호출이 아닌 mcp__serena__* 도구를 직접 사용
# 설치 여부는 Phase -3.5에서 확인, 설치됐으면 코드 분석 태스크에서 mcp__serena__* 활용
SERENA_INSTALLED=$(_op ".get('serena',{}).get('installed',False)" 2>/dev/null || echo "False")

Dynamic Resolve v2 (미등록 파트너 — 타입 감지 포함) — v5.5

명시된 파트너가 Fast-Path에 없으면 prepass resolve-partner 명령으로 탐색한다. SKILL.md뿐 아니라 agents/ 파일도 탐색하며, 세 가지 타입 중 하나를 반환한다.

# resolve-partner 실행 — SKILL.md + agents/ 파일 + plugin.json 통합 탐색
_resolve() {
  local NAME="$1"
  bash "$PREPASS_RUNNER" resolve-partner "$NAME" 2>/dev/null || echo '{"found":false,"type":"UNKNOWN"}'
}

_ptype()  { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('type','UNKNOWN'))" 2>/dev/null; }
_pinvoke(){ printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('invocation',''))"  2>/dev/null; }
_ppath()  { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('path',''))"        2>/dev/null; }
_pfound() { printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(d.get('found',False))"   2>/dev/null; }
_pagents(){ printf '%s' "$1" | python3 -c "import sys,json;d=json.load(sys.stdin);print(' '.join(d.get('agents',[])))" 2>/dev/null; }

파트너 타입 정의:

타입	조건	실행 방법
AGENT	agents/ 디렉토리 + plugin.json 존재	Task(subagent_type=invocation)
SKILL	plugin.json 있음, agents/ 없음	Skill(skill=invocation)
PROTOCOL	SKILL.md만 존재, plugin.json 없음	Read SKILL.md → CEO가 직접 프로토콜 따름

탐색 결과 처리:

✅ 파트너 해결됨: [NAME] (타입: AGENT/SKILL/PROTOCOL) → [invocation_or_path]
⚠️  파트너 미발견: [NAME] — 해당 스킬/에이전트를 설치하거나 이름을 확인하세요. 파트너 없이 계속합니다.

타이밍 판단 (키워드 매칭 금지)

파트너 경로가 확보되면 SKILL.md(또는 에이전트 파일)의 description을 읽고 Pre/In/Post/Wraps 중 하나를 판단한다. grep/키워드 휴리스틱을 쓰지 말 것 — description이 말하는 역할이 CEO 플랜의 INPUT인지(Pre), 독립 병렬인지(In), 결과 후처리인지(Post), 전체를 감싸는 방법론인지(Wraps)를 직접 판단하고, 판단 근거를 한 줄로 출력한다.

예: 🕐 타이밍: gstack → Post — description이 "결과를 시트/드라이브로 내보내는" 후처리 도구이므로.

범용 협업 실행 프로토콜 v2 — 타입별 분기

파트너가 Dynamic Resolve로 확보된 경우, 타입에 따라 다른 실행 방법을 사용한다.

PARTNER_INFO=$(_resolve "$PARTNER_NAME")
PARTNER_TYPE=$(_ptype "$PARTNER_INFO")
PARTNER_INVOKE=$(_pinvoke "$PARTNER_INFO")
PARTNER_PATH=$(_ppath "$PARTNER_INFO")
PARTNER_FOUND=$(_pfound "$PARTNER_INFO")

타입별 실행 방법

① AGENT 타입 — 다른 플러그인의 에이전트를 직접 호출

Task(
  subagent_type: "[PARTNER_INVOKE]",    # 예: "oh-my-claudecode:debugger"
  prompt: """
  [USER_TASK]
  
  실행 컨텍스트:
  - 요청 주체: CS-CEO
  - 타이밍: [Pre/In/Post]
  - 기대 OUTPUT: [Pre→분석/계획 결과 | In→독립 결과 | Post→CEO 결과 처리]
  
  [Pre 타이밍인 경우] 결과를 CEO가 다음 단계 INPUT으로 사용합니다.
  [Post 타이밍인 경우] CEO 실행 결과: [CEO_RESULT 요약]
  """
)

사용 예:

# with executor: 코드 구현 위임
Task(subagent_type="oh-my-claudecode:executor", prompt="...")

# with debugger: 버그 심층 분석
Task(subagent_type="oh-my-claudecode:debugger", prompt="...")

# with architect: 아키텍처 설계
Task(subagent_type="oh-my-claudecode:architect", prompt="...")

② SKILL 타입 — 스킬 직접 호출

Skill(skill="[PARTNER_INVOKE]", args="[USER_TASK]")
# 예: Skill(skill="superpowers:brainstorming", args="...")

③ PROTOCOL 타입 — SKILL.md 읽고 CEO가 프로토콜 직접 따름

Read(PARTNER_PATH)  # SKILL.md 전체 읽기
→ description / 주요 섹션 분석 (목적, INPUT, OUTPUT)
→ CEO가 프로토콜 직접 실행

또는 프로토콜이 복잡한 경우 Task로 위임:

Task(
  description: "[PARTNER_NAME] 프로토콜 실행",
  prompt: """
  아래는 [PARTNER_NAME] 스킬의 전체 프로토콜입니다:
  ---
  [SKILL.md 전체 내용]
  ---
  실행 컨텍스트:
  - 유저 요청: [USER_TASK]
  - 타이밍: [Pre/In/Post/Wraps]
  - 기대 OUTPUT: ...
  프로토콜에 따라 실행하고 결과를 반환하세요.
  """
)

파트너별 주요 스킬/에이전트 (Fast-Path 참고):

파트너 키	타입	핵심 스킬/에이전트	기본 타이밍
superpowers	SKILL	brainstorming, writing-plans, executing-plans	Pre
bkit	PROTOCOL	pdca, qa-phase	Wraps
omc / deep-dive	AGENT	oh-my-claudecode:debugger	Pre
omc / autoresearch	AGENT	oh-my-claudecode:analyst	Pre
omc / autopilot	AGENT	oh-my-claudecode:executor	Pre/In
executor	AGENT	oh-my-claudecode:executor	In
architect	AGENT	oh-my-claudecode:architect	Pre
debugger	AGENT	oh-my-claudecode:debugger	Pre
gstack	PROTOCOL	gstack (단일)	Post
cs-clarify	AGENT	cs-clarify:clarify-lead	Pre
(미등록)	자동 탐색	Dynamic Resolve v2 → 타입 자동 판정	자동 추론

---

Phase -1: 컨텍스트 상태 점검

도메인 에이전트를 스폰하기 전에 현재 세션 상태를 평가한다.

상황	신호	권장 조치
이전 cs-ceo 실행 결과가 컨텍스트에 쌓여 있음	도메인 리포트, 도구 출력 누적	/compact 권장 후 진행
완전히 다른 주제/프로젝트로 전환	이전 컨텍스트와 무관한 새 요청	/clear 권장
연속 작업 (이전 결과가 지금도 필요)	같은 코드베이스, 같은 목표	그냥 진행
Task()로 서브에이전트 위임 예정	모드 A/B/C/P 모두 해당	그냥 진행

컨텍스트가 무겁다고 판단되면 리포트 상단에 한 줄만 추가. 그 외 아무 출력 없이 Phase 0으로 진행.

cmux 환경 감지

if [ -n "$CMUX_SOCKET_PATH" ]; then
  cmux set-status "cs-ceo" "running" --icon "gear"
  cmux set-progress 0.0 --label "CEO 분석 중..."
  CMUX_ENV=true
fi

---

Phase 0: 도메인 경로 확인

# Phase INIT 결과에서 추출 — ls/sort -V 불필요
LATEST_TEST=$(_f "['plugins']['test']")
LATEST_PLAN=$(_f "['plugins']['plan']")
LATEST_REVIEW=$(_f "['plugins']['review']")
LATEST_DESIGN=$(_f "['plugins']['design']")
LATEST_SMARTRUN=$(_f "['plugins']['smartrun']")

파트너십이 감지된 경우, Partnership Registry의 Bash 블록도 이 Phase에서 함께 실행해 경로를 확보한다.

---

Phase 1: 공수 추정 (자율 판단)

① 영향 범위 — 파일/컴포넌트 수, 코드베이스 전체 vs 특정 기능
② 필요 도메인 수 — 1개(小) / 2~3개(中) / 3개 이상(大)
③ 단계 간 의존관계 — 병렬 가능 vs 순차 필요
④ 요청의 불확실성 — 목표 명확 vs 탐색적 vs 전략적 판단 필요
⑤ 노하우 섹션 참조 — 유사 케이스, 파트너십 효과 패턴

---

Phase 2: 실행 모드 결정

모드 A — 직접 단독 실행 (공수 小)

조건: 도메인 1개, 범위 명확, 목표 확실, 파트너 없음

해당 도메인 SKILL.md 읽기 → Task()로 도메인 lead 에이전트 스폰

모드 B — CEO 직접 오케스트레이션 (공수 中)

조건: 도메인 2~3개, 명확한 순서 또는 병렬 관계, 파트너 없음

각 도메인 SKILL.md 읽기 → 병렬 가능 시 단일 블록 Task() 동시 스폰
→ 순차 필요 시 이전 결과를 컨텍스트로 전달 → CEO 종합 리포트

모드 C — cs-smart-run 위임 (공수 大)

조건: 3개 이상 도메인 복잡하게 얽힘 / 모호한 전략 판단 / 복잡한 의존관계 / 노하우 기록

SMARTRUN_SKILL="$LATEST_SMARTRUN/skills/smart-run/SKILL.md"

모드 P-Pre — 파트너 선행 후 A/B/C

조건: 파트너 감지 + 파트너 결과가 CEO 플랜의 INPUT

파트너 SKILL.md 읽기 → Skill() 또는 Task()로 파트너 실행
→ 출력 결과 확보 → 공수 재추정 → 모드 A/B/C 결정 → 실행

예: superpowers:brainstorming → 설계 문서 → CEO-B (plan+test)

모드 P-In — 파트너와 병렬 실행

조건: 파트너 감지 + 파트너와 CS 도메인 독립 병렬 가능

단일 응답 블록에서 동시 스폰:
Task() → 파트너 / Task() → CS 도메인들
→ 결과 수집 → CEO 종합

예: gstack (시트 준비) ‖ CS-codebase-review 동시 실행

모드 P-Post — CEO 먼저, 파트너 후처리

조건: 파트너 감지 + 파트너가 CEO 결과를 처리

모드 A/B/C 실행 → CEO 리포트 산출 → Skill()로 파트너 호출

예: CS-test 완료 → gstack으로 결과 구글 드라이브 문서화

모드 P-Wraps — 파트너 방법론이 전체를 감싸는 구조

조건: bkit:pdca 또는 전체 PDCA 사이클 요청

bkit:pdca SKILL.md 읽기 → PDCA 방법론 안에서 CEO가 CS 도메인 오케스트레이션
Plan: CS-plan / Do: CEO 오케스트레이션 / Check: CS-test + CS-codebase-review / Report: CEO 종합

---

Phase 3: 실행

증거 의무 (EVIDENCE — LOOP-PROTOCOL [a]): Phase 3에서 도메인 에이전트/파트너를 Task()로 스폰할 때, 모든 Task prompt 끝에 아래 문장을 반드시 추가한다:

각 발견(finding)마다 근거를 명시하라 — 실행한 명령 + 출력 일부, 또는 file:line 인용.
근거 없는 주장은 'UNVERIFIED'로 표시하라.

CS 도메인 라우팅 참고표:

요청 패턴	도메인	방식
URL / "테스트"	CS-test	모드 A
URL / "테스트" (cmux 환경)	CS-test (cmux browser 모드)	모드 A
"플랜" / "설계" / "기능 추가" (명확)	CS-plan	모드 A
"코드 리뷰" / "품질 체크"	CS-codebase-review	모드 A
"디자인 리뷰" / "UI 검토"	cs-design	모드 A
"전체 분석"	review → design → test	모드 B 순차
"뭐가 문제야" / "이상해"	review + test	모드 B 병렬
"기능 만들어줘" (범위 명확)	plan → design → test	모드 B 순차
아키텍처 개편 / 대규모 리팩터링 / 전략	cs-smart-run	모드 C

파트너십 라우팅 추가표:

요청 패턴	파트너	타이밍	CS 도메인 조합
"어떻게 접근" / "잘 모르겠어"	superpowers:brainstorming	Pre	브레인스토밍 → plan or B/C
"계획부터 짜줘" / "단계적으로"	superpowers:writing-plans	Pre	플랜 문서 → CEO 실행
"버그" + 복잡한 증상	omc:deep-dive	Pre	딥다이브 → review + test
"구글 시트에 정리" / "드라이브 저장"	gstack	Post	A or B → gstack 문서화
"Gmail" / "캘린더" / "Google Docs"	gstack	In	gstack ‖ 필요 CS 도메인
"전체 사이클" / "PDCA로"	bkit:pdca	Wraps	pdca가 CEO 감싸기
"요구사항 불명확" / "scope 먼저"	cs-clarify	Pre	clarify → 재추정 → A/B/C
"리서치 필요" / "조사해줘"	omc:autoresearch	Pre	리서치 → 관련 CS 도메인

---

Phase 3.5: 발견 검증 (조건부 스팟체크)

트리거 (둘 다 만족할 때만 실행):

• (a) 모드가 B / C / P-Wraps이고 도메인 2개 이상
• (b) 어떤 도메인이 critical/high 등급 발견을 보고했거나, 발견이 destructive 다음 액션(삭제·마이그레이션·강제 푸시 등)을 유도함

스킵 조건: 모드 A / 발견이 이미 도구 출력 원문(예: CS-test playwright 로그)으로 뒷받침됨 → Phase 3.6으로 바로 진행.

실행 (Task 1개, model: sonnet):

Task(
  model: "sonnet",
  description: "발견 스팟체크 (refuter)",
  prompt: """
  아래 top 3-5개 발견을 반박(REFUTE)하라. 각 발견이 인용한 명령을 재실행하거나
  인용된 file:line을 다시 읽어 사실 여부를 검증하라.
  - 재검증 통과 → VERIFIED
  - 재검증 실패 → '검증 실패' + 검증자 출력 일부 첨부
  [top 3-5 발견 목록 + 각 발견의 근거]
  """
)

재검증 실패한 발견은 조용히 삭제하지 않는다 — Phase 4 리포트에서 ⚠️ UNVERIFIED로 강등하고 '검증 실패' 사유와 검증자 출력을 병기한다.

---

Phase 3.6: Goal Gate Check (품질 게이트)

스킵 조건 (이중 게이트·오버헤드 방지):

• (a) 모드 P-Wraps (bkit:pdca의 Check 단계가 이미 수행)
• (b) 모드 A 인프라 진단/검증 태스크로 CEO가 직접 Bash 실행한 경우 (노하우 #1/#2)
• (c) GOAL.success_criteria가 비어 있거나 자명한 경우

① 채점: GOAL.success_criteria의 각 기준에 대해 PASS/FAIL을 매긴다. 근거는 수집된 도메인 결과에서 한 줄씩 인용한다. 채점에 새 에이전트를 스폰하지 않는다 — CEO가 인라인으로 판정한다.

② 재디스패치 (BOUNDED — LOOP-PROTOCOL [c]): FAIL 기준이 있으면 해당 기준을 담당한 도메인 에이전트만 Task()로 재디스패치한다. INPUT으로 실패 기준 + 근거 + 이전 출력 요약을 전달한다.

• 최대 2라운드. 한 라운드가 새 진전(새 PASS, 새 근거)을 만들지 못하면 즉시 중단하고 해당 기준을 UNMET으로 마킹한다. 루프 대신 STUCK 사유를 리포트에 남긴다.

③ 리포트 반영: Phase 4 템플릿의 목표 줄 바로 아래 목표 달성도 표를 출력한다 (기준 | PASS/FAIL/UNMET | 근거 | 사용 라운드).

④ 버전업 연동: Goal Gate에서 FAIL이 발생했다면 Phase 5-B 트리거 — "재디스패치로 해결됨" 또는 "UNMET으로 종료됨"을 노하우 후보로 기록한다.

---

Phase 4: CEO 종합 리포트

[ -n "$CMUX_SOCKET_PATH" ] && cmux set-progress 0.9 --label "CEO 리포트 생성 중..."

## CEO 실행 리포트

**목표**: [GOAL_STATEMENT]

**목표 달성도** (Phase 3.6 결과 — 스킵 시 "스킵: [사유]" 한 줄):
| 기준 | 판정 | 근거 | 라운드 |
|------|------|------|--------|
| [success_criteria #1] | PASS/FAIL/UNMET | [근거 한 줄] | [0-2] |

**요청**: [유저 요청 원문]
**공수 판정**: 小/中/大
**선택 모드**: A / B / C / P-Pre / P-In / P-Post / P-Wraps
**실행 도메인**: [도메인 목록과 순서]
**판단 근거**: [①~⑤ 추정 결과 요약]

---
**파트너십**: [파트너 없음] 또는 [파트너명:스킬 → CEO-모드 → (후처리 파트너)]
**파트너 기여**: [파트너가 제공한 핵심 인사이트/결과 1-2줄]  ← 파트너 있을 때만
---

[각 도메인 결과 요약 — 발견별 근거(명령/출력 또는 file:line) 병기; 근거 없는 항목은 ⚠️ UNVERIFIED 표시]

---

**CEO 종합 평가**: [전체 결과에 대한 CEO 판단]
**권장 다음 액션**: [우선순위 상위 3개]

규칙: UNVERIFIED 항목은 'CEO 종합 평가'와 '권장 다음 액션'의 근거로 사용하지 않는다.

if [ -n "$CMUX_SOCKET_PATH" ]; then
  cmux set-progress 1.0 --label "CEO 실행 완료"
  cmux notify --title "CS-CEO 완료" --body "[모드] — 다음: [권장 액션 1위]"
  cmux set-status "cs-ceo" "done" --icon "checkmark"
fi

---

Phase 5: 실행 후 컨텍스트 관리 + 버전업 결정

5-A: 컨텍스트 관리 권장

실행이 컨텍스트에 남긴 무게를 보고 CEO가 판단한다 — 모드별 고정 규칙이 아니라 다음 기준으로:

• 도메인 리포트/도구 출력이 많이 쌓였고 이어서 같은 작업을 계속할 가능성 → /compact 권장 (보존할 핵심: 결과 요약 + 다음 액션을 명시)
• 대규모 작업이 끝났고 다음 작업이 별개일 가능성 → /clear 권장 (가져갈 핵심 결론 1줄을 함께 제시)
• 가벼운 단일 작업(모드 A 등) → 권장 출력 생략

권장 시 리포트 끝에 한 줄로 출력한다. 문구는 자유.

5-B: 버전업 결정

트리거	예시
공수 추정이 빗나갔다	小로 봤는데 실제론 中
새 요청 패턴 발견	라우팅 표에 없던 케이스
도메인/파트너 조합 효과가 예상과 달랐다	superpowers:brainstorming이 불필요했음
파트너 자동 감지가 틀렸다	gstack이 필요 없었는데 감지됨
파트너십 조합이 탁월했다	기록할 만한 효과적 패턴 발견
외부 지식 게이트 발동 (v5.2)	context7-auto-research로 학습한 라이브러리/패턴이 판단을 바꿨다
외부 지식 게이트 누락 (v5.2)	학습 없이 진행했다가 잘못된 가정으로 빗나갔음 — 트리거 표 보강 필요
Goal Gate에서 FAIL 발생	재디스패치로 해결됨 / UNMET으로 종료됨 — 반복되는 기준 실패는 노하우화

트리거 있음 → 리포트 끝에:

💡 버전업 제안: `/cs-experiencing version-up all` 로 오늘 패턴을 노하우로 저장하세요.

노하우 후보 영구 캡처 (세션 메모리 금지): 트리거가 발동하면 제안 출력에 더해, 각 노하우 후보를 기존 btw 스토어에 즉시 append한다:

BTW_FILE="$(dirname "$HOME/.claude/plugins/marketplaces/CSnCompany_2-0")/.experiencing-btw.json"
# 파일 없으면 []로 생성 후, JSON 배열에 append:
# {id, idea: "[ceo] <후보 한 줄: 상황/판단/결과>", date, status: "pending"}

append 후 출력: 💡 노하우 후보 #N 캡처됨 — 다음 version-up 시 자동 제안됩니다.

주의: 캡처만 자동화한다. 노하우 승격(promotion)은 기존대로 /cs-end 또는 /cs-experiencing version-up의 Learning Gate를 통해 사람이 확인한다. Phase 1에서 미승격 후보를 읽어 판단에 쓰지 않는다.

---

CEO 노하우

버전업마다 이 섹션에 학습이 추가됩니다. CEO는 유사 상황에서 이 섹션을 참조해 판단 품질을 높입니다.

형식:

### [N]. [학습 제목] ([YYYY-MM-DD])
- **상황**: [어떤 요청]
- **판단**: [모드 선택, 도메인/파트너 조합]
- **결과**: [효과적이었는가]
- **교훈**: [다음 유사 상황에서의 판단 기준]

1. 인프라 진단 태스크는 도메인 에이전트 없이 직접 Bash 실행이 효율적 (2026-04-24)

• 상황: localhost:9000 점검 + GitHub sync + 폴더 선택 기능 에러 개선 확인 요청
• 판단: 도메인 에이전트 스폰 없이 직접 Bash 명령으로 진단 (git log, curl, lsof)
• 결과: git pull 1개 누락 커밋이 근본 원인임을 즉시 진단. 효율적이었음.
• 교훈: 서버 상태 확인, git sync, 파일 존재 여부 같은 인프라 진단은 CEO가 직접 Bash 실행. 도메인 에이전트는 심층 분석이 필요할 때만 스폰할 것.

2. 코드 변경 검증 요청은 Mode A + 직접 분석 (2026-04-24)

• 상황: 워크트리 UX 개선 코드 변경 후 6개 항목 검증 요청
• 판단: Mode A — 도메인 에이전트 없이 Bash+Read로 직접 코드 분석
• 결과: 6개 항목 모두 빠르게 검증 완료. 효율적이었음.
• 교훈: "implemented code verify" 패턴은 항상 Mode A. Bash grep + Read로 충분하며 도메인 에이전트 스폰이 오버헤드임.

3. 외부 지식 게이트 — context7-auto-research 자동 호출 (2026-04-25)

• 상황: CEO 내부 노하우만으로는 라이브러리/프레임워크 최신 동향, 새 API, 마이너 변경점을 정확히 답할 수 없음.
• 판단: Phase -3을 신설해 모든 요청 진입 직전에 "외부 지식 필요 여부"를 평가하고, 트리거 신호 1개라도 감지되면 즉시 context7-auto-research를 Skill 도구로 호출.
• 결과: 도메인 에이전트/파트너에게 정확한 최신 문서를 INPUT으로 전달 → 잘못된 가정 기반 실행이 줄고, 버전업 시 학습량이 누적됨.
• 교훈:
  1. "지체말고 호출" — 의심되면 호출이 기본값 (호출 비용 < 잘못된 실행 비용).
  2. 동일 세션 내 동일 주제·동일 버전 범위 재호출 금지로 토큰 낭비 방지 — 단, 보관된 발췌가 현재 질문의 API/버전을 직접 다루지 않으면 좁힌 키워드로 재호출.
  3. 게이트 발동/누락 모두 Phase 5-B 버전업 트리거 → 다음 세션에 노하우로 영속화.
  4. 미설치 환경 대응: context7-auto-research가 없으면 무단으로 건너뛰지 말고 AskUserQuestion으로 Install/Skip/Abort 3지선다 제시. 설치 명령은 npx skills add -g BenedictKing/context7-auto-research. Skip 선택 시 정확도 하락 경고 1줄 후 진행.

12. HTTP-first 자동화 아키텍처: 서버리스 호환 fetch → Playwright 폴백 → AI 진단 게이트 (2026-04-26)

• 상황: Playwright 전용 파킹 자동화 앱을 Vercel 배포에서도 동작하도록 전환 요청
• 판단: Playwright는 서버리스 환경에서 Chromium 바이너리 실행 불가 → plain fetch로 HTTP 세션 자동화 먼저 시도. 실패 시 UI에 "Claude Code에 전달" 버튼으로 진단 프롬프트를 클립보드에 복사하는 UX 패턴 설계.
• 결과: fetch 구현은 AJPark 로그인 인코딩(Base64 ID) 문제로 추가 디버깅 필요했으나 아키텍처 방향은 유효. 진단 버튼 패턴은 비기술 사용자가 오류를 개발자(Claude Code)에게 전달하는 효과적인 채널이 됨.
• 교훈: Playwright 필수처럼 보이는 작업도 HTTP-first로 먼저 시도. 실패 경로에 "AI 진단 게이트(클립보드 복사 프롬프트)" 설계 → 사용자가 직접 Claude Code에 붙여넣으면 자동 디버깅 루프 완성.

13. Electron auto-paste 디버깅 — 3-레이어 격리 전략 (2026-04-27)

• 상황: Electron 앱에서 단축키 → 클립보드 → 붙여넣기 파이프라인이 동작하지 않아 root cause 특정이 어려움.
• 판단: 3-레이어 격리 방식 적용: ① pbpaste로 클립보드 직접 확인(Electron clipboard.writeText 정상 여부) ② osascript 단독 실행(AppleScript 문법 + 권한 여부) ③ Electron exec() 통합 테스트(자식 프로세스 sandbox 이슈 여부). Layer 2 성공 + Layer 3 실패 → Electron 자식 프로세스 권한 문제로 즉시 특정.
• 결과: keystroke "v" using command down은 Layer 2에서는 동작하지만 Layer 3(Electron exec)에서 silent fail → click menu item "Paste"로 교체 후 해결.
• 교훈: Electron 앱에서 osascript 오작동 시 반드시 3-레이어 격리부터. 특히 exit 0이지만 효과 없는 경우 sandbox/권한 문제 → AppleScript 메뉴 클릭 방식으로 우회.

14. 야간 위임 — 사용자 sleep 중 Phase별 자율 진행 + 아침 보고서 (2026-04-28)

• 상황: 사용자가 "난 자야하니까 잘 처리해 아침에 보자"로 위임. 5-phase 작업을 사용자 컨펌 없이 자율 진행해야 함.
• 판단: 안전한 작업(코드 변경, 빌드, git push)은 자율 진행. destructive 동작은 결과 검증 필수. Phase 단위로 commit/push 분리 → 아침에 사용자가 git log로 진행 트레이스 가능.
• 결과: 5-phase 모두 완료, 6커밋 푸시, 앱 설치 + 실행 검증, 아침 보고서에 시나리오별 검증 절차 명시.
• 교훈: 야간 위임 시 (1) Phase별 commit으로 트레이스 보장 (2) destructive는 검증까지 묶음 (3) 마지막 메시지에 시나리오 체크리스트 포함. ScheduleWakeup 270초 간격이 cache TTL 적정.

15. 빌드 시스템 크로스 디바이스 버그 — Mode B 인라인 분석으로 절대경로 즉시 진단 (2026-05-01)

• 상황: Tauri 앱 DMG 빌드가 iCloud ETIMEDOUT + E0601(main 미발견)로 반복 실패. 다른 Mac에서도 빌드 오류 보고됨.
• 판단: Mode B — CS-codebase-review 인라인 분석. .cargo/config.toml의 하드코딩 절대경로가 크로스 디바이스 실패의 근본 원인으로 즉시 특정.
• 결과: 크로스 디바이스 문제 해결. fix-dmg stale 파일 버그 + 로그 offset UTF-8 버그 동시 발견 및 수정. 8파일 커밋 + 푸시.
• 교훈: "다른 기기에서도 재현"은 환경 고유값 하드코딩(절대경로, username, 홈 디렉토리)을 1순위 의심. .cargo/config.toml, CMakeLists.txt, Makefile 절대경로를 코드 리뷰 체크리스트 필수 항목으로.

16. Tauri 앱 필드 사라짐 버그 — TypeScript ↔ Rust struct 필드 불일치 1순위 확인 (2026-05-01)

• 상황: 즐겨찾기(favorite) 추가 후 앱 재시작 시 사라지는 버그.
• 판단: Mode A 직접 분석. CEO 직접 Bash+Read로 3단계 원인 추적.
• 결과: 3중 원인 발견. 핵심 근본 원인 — Rust PortInfo 구조체에 favorite 필드 없어서 save_ports 호출 시 JSON 역직렬화 과정에서 필드 드롭.
• 교훈: Tauri 앱에서 특정 필드가 저장 안 될 때 → 1순위: src-tauri/src/lib.rs의 struct PortInfo 필드 목록과 TS interface PortInfo 비교. Rust 구조체 누락 필드는 serde 역직렬화 시 silently drop됨.

17. GUI 앱 PATH Desert — Tauri invoke()는 zsh -l -c로 실행해야 사용자 PATH 확보 (2026-05-14)

• 상황: Tauri 앱에서 claude --bg가 "claude not found in PATH" 오류. CLI/API 서버 경로에서는 정상 동작. Playwright 테스트도 통과했으나 앱에서만 계속 실패.
• 판단: Mode A 직접 분석. isTauri() 분기 발견 → Tauri invoke() 경로(lib.rs)와 HTTP 경로(api-server.ts)가 완전히 독립적. PATH enhancedPath로 부족, zsh -l -c 필요.
• 결과: open_claude_bg()를 Command::new("/bin/zsh").args(["-l", "-c", &shell_cmd])로 수정 → DMG v80 빌드 완료. 같은 파일의 suggest_names_batch()가 이미 동일 패턴 사용 중이었음.
• 교훈: Tauri(Finder 실행) = 최소 PATH(/usr/bin:/bin). CLI에서 작동 + Playwright 통과 + 앱에서만 실패 → isTauri() 분기 확인 → Rust invoke() 경로는 zsh -l -c 필수. Playwright는 HTTP 경로만 검증 — Rust invoke() 경로는 별도 테스트 필요.