claude-dynamic-workflows-codex

Codex Workflows

로컬 Codex 앱 서버에 대해 Claude Code 동적 워크플로우 스크립트를 실행합니다. 작성 표면은 네이티브 동적 워크플로우와 동일합니다. export const meta와 agent(), parallel(), pipeline(), phase(), log(), args, budget, workflow()를 사용하는 본문으로 구성되지만, 모든 agent() 호출은 Claude 서브에이전트 대신 하나의 Codex (GPT) 스레드+턴으로 실행됩니다.

수동 호출 전용. Claude는 이 스킬을 자동으로 트리거하지 않습니다(disable-model-invocation: true). 사용자가 /codex-workflows를 입력하거나 Codex 워크플로우를 명시적으로 요청할 때만 실행됩니다. 호출되면 아래 루프를 따르세요. 작업은 Codex/GPT 에이전트에서 실행됩니다. 사용자가 실제로 Claude 서브에이전트를 원했다면 그렇게 말하고 네이티브 Workflow 도구를 안내하세요.

RUNNER 아래는 번들된 러너 디렉토리를 의미합니다: 이 스킬의 기본 디렉토리 기준 runner/ (스킬이 로드될 때 표시됨). 클래식 skills-dir 설치의 경우 ~/.claude/skills/codex-workflows/runner입니다. 아래 예제의 실제 경로는 이를 가정합니다. 이 스킬이 플러그인으로 설치된 경우 기본 디렉토리로 대체하세요. 의존성 없는 Node ≥ 18입니다.

기본 대략적 의도 모드

한두 문장의 간략한 설명으로 충분합니다. 이 스킬에 완전히 설계된 사양을 제공할 필요가 없습니다. 원하는 것을 설명하면(예: /codex-workflows 이 목표를 실행하기 전에 강화해줘) 스킬이 자체적으로 작동 가능한 워크플로우로 컴파일합니다. 작업을 분류하고, 가장 작은 실행 가능한 규모와 아키텍처, 패턴을 선택하며, 작업 계약을 구축하고, 단계를 구성하고, 페르소나를 캐스팅하고, 품질/인식적 기준을 적용하며, 스크립트를 작성하고, 안전한 실행 설정을 선택한 후 실행합니다. 진행하면서 가정을 명시합니다.

이 모드의 운영 규칙:

• 대략적 의도가 계약입니다. 지정되지 않은 사항에 대해 합리적인 가정을 하고 명시하십시오. 후속 질문으로 사용자에게 묻지 마십시오.
• 가능한 가장 큰 것이 아닌 가장 작은 유용한 워크플로우를 선택하십시오(과잉 구축 금지 규칙 참조).
• 사용자가 다시 붙여넣을 거대한 프롬프트를 생성하지 마십시오. 컴파일하고 작성/실행으로 진행하십시오. (유일한 예외는 prompt-only 모드입니다. 모드 감지 참조.)
• 이는 외부 "메타프롬프트"를 대체합니다. 확장은 이제 스킬 내에서 발생합니다. 아래 대략적 의도를 워크플로우로 컴파일 섹션 전체가 그 컴파일러입니다.

기본 실행 체크리스트

모든 실행에서 순서대로 (아래 섹션에서 각 단계를 확장합니다):

1. 사전 점검 Codex 한 번(handshake.js); 최신 프론티어 모델을 확인합니다.
2. 컴파일 대략적 의도: 작업 분류 → 규모 → 아키텍처 → 패턴 (방지하는 실패 모드 이름 지정) → 작업 계약. 가정을 명시하십시오.
3. 작성 스크립트를 저장소(./<name>.workflow.js)에 작성합니다.
4. 설정: --frontier · 규모별 노력 (quick_harness의 경우 --effort medium, standard/deep의 경우 --auto-effort) · 반드시 작성해야 하는 경우가 아니면 --sandbox read-only · 제한된 --budget · 엄격한 스키마 (additionalProperties:false).
5. 크기 측정 — 비용이 많이 들거나 복잡한 워크플로우의 경우 먼저 --plan을 실행합니다.
6. 실행 Codex 러너에서 실행합니다(네이티브 Workflow 도구가 아님).
7. 표면화 — 인라인 ASCII 맵 + summarize-run 하이라이트; 스크립트, 저널, 뷰어, 보고서 및 실행 요약 경로를 인용합니다(출력 동작 참조).

모드 감지

사용자의 표현에서 모드를 읽고 그에 따라 행동합니다:

모드	트리거	동작
기본 (대략적 의도)	1–2개의 간략한 문장	내부 컴파일 → 작성 → 실행. 가정 명시.
--multi (함대)	--multi 플래그, 또는 "fleet" / "여러 워크플로우를 동시에"	함대 계획 컴파일 (2–4개의 동시 변형 워크플로우, 유사 및/또는 다양), 백그라운드에서 실행, 감독: fleet status 폴링, 게이트 응답, 조종, 종료, 포크, 종합. 함대 모드 참조.
prompt-only	"prompt-only", "just the invocation", "don't run it"	완전한 /codex-workflows 호출/사양을 출력하고 중지 — 작성 또는 실행하지 않음.
write-only	"write it but don't run", "author only"	워크플로우 스크립트를 작성하고 경로를 출력한 후 실행하기 전에 중지.
run-existing	스크립트 경로 또는 저장된 워크플로우 이름 제공	컴파일 생략; 러너를 통해 해당 스크립트/이름 실행.
quick	"quick", "small", "cheap"	quick_harness (2–5 에이전트)로 편향.
deep	"deep", "thorough", "exhaustive"	더 큰 워크플로우 허용 / deep_harness; 크기 정당화.
no-write	"don't write files", "just tell me"	최종 JSON/Markdown만 반환; 보고서/소스 파일 없음; --sandbox read-only.

두 가지 우선 순위 규칙: 사용자가 스크립트 경로 또는 저장된 이름을 제공하면 실행합니다(다시 컴파일하지 않음). 사용자가 상세 사양을 제공하면 그대로 따르되 아래 안전 및 기본 실행 설정을 계속 적용합니다. 그렇지 않으면 대략적 의도 → 컴파일입니다.

prompt-only 모드에서, 출력하는 호출은 스킬이 내부적으로 구축하는 것과 동일한 A–L 구조를 따릅니다: A 이름 · B 목적 · C 작업 계약 · D 입력 / 컨텍스트 재구성 · E 단계 · F 페르소나 · G 래퍼 방지 기준 · H 출력 · I 실행 설정 · J 안전 / 인식론 · K 최종 응답 형식 · L 제품화. 그런 다음 중지 — 실행하지 않음.

루프

기본 대략적 의도 모드에서, 1–2단계를 조용히 수행하고 작성 전에 가정을 명시합니다. 아래 메커니즘(핸드셰이크, 실행 명령, 인라인 맵)은 변경되지 않습니다. 2단계와 4단계에서 대략적 의도가 컴파일됩니다.

1. 사전 점검 — 세션당 한 번, 또는 실행이 연결에 실패할 때마다 Codex에 연결 가능하고 인증되었는지 확인합니다:

   node ~/.claude/skills/codex-workflows/runner/test/handshake.js
   

   state: ready와 사용 가능한 모델을 출력합니다. 실패하면 사용자에게 codex login을 실행하라고 알립니다(러너는 PATH에 로그인된 codex CLI가 필요합니다). 해당 목록에서 최신 프론티어 모델을 확인합니다(가장 최신의 주력 일반 모델, -mini/-spark 변형이 아님; model/list에서 isDefault로 플래그 지정되고 설명이 가장 강력하다고 표시됨). GPT-5.6 Codex 시리즈는 Sol(주력), Terra(균형), Luna(효율적)입니다. 오늘날 프론티어는 gpt-5.6-sol입니다. 실행의 모든 에이전트가 이를 사용합니다(모델 참조).

2. 컴파일 대략적 의도를 워크플로우로 변환합니다(대략적 의도를 워크플로우로 컴파일 참조): 작업 분류 → 규모 선택 → 아키텍처 선택 → 패턴 선택 및 방지하는 실패 모드 이름 지정 → 작업 계약 구축 → 단계 구성 → 페르소나 캐스팅 → 기준 적용. 결과 가정을 작성 전에 사용자에게 명시하십시오.

3. 작성 해당 컴파일에서 워크플로우 스크립트를 작성합니다(작성 참조). 사용자가 읽고 다시 실행할 수 있도록 사용자 프로젝트에 기록합니다: ./<name>.workflow.js, 또는 재사용 가능한 워크플로우의 경우 workflows/<name>.workflow.js / examples/harness-zoo/<name>/. 스크립트는 주입된 전역 변수만 사용하는 일반 JavaScript입니다(가져오기 없음).

4. 실행 설정 선택 (기본 실행 설정 참조): --frontier, 선택한 규모에 대한 노력 플래그(표준/심층 워크플로우의 경우 --auto-effort, 빠른 워크플로우의 경우 --effort medium), 반드시 작성해야 하는 경우가 아니면 읽기 전용 샌드박스, 제한된 --budget. 비용이 많이 들거나 복잡한 워크플로우의 경우 먼저 --plan — 토큰을 사용하지 않는 드라이 실행으로 단계/노력당 에이전트 수를 계산하고 --budget을 추정합니다.

5. 실행 — **항상 --frontier**를 전달하고, 선택한 규모에 대한 노력 플래그를 함께 전달합니다: 표준/심층 워크플로우의 경우 --auto-effort (레이어의 병렬 너비에 각 에이전트의 노력을 조정하므로 단독 합성/판단 게이트가 가장 열심히 생각함), 빠른 워크플로우의 경우 --effort medium (노력 참조). --frontier는 모든 에이전트를 최신 프론티어 모델로 고정합니다(모델 참조):

   node ~/.claude/skills/codex-workflows/runner/bin/run-workflow.js <script.js> --frontier --auto-effort [other flags]
   #   quick_harness:  … <script.js> --frontier --effort medium [other flags]
   

   진행 상황은 stderr로 스트리밍됩니다. 워크플로우의 반환 값은 stdout에 JSON으로 출력됩니다. 결과가 큰 경우 stdout을 캡처합니다(… 1>/tmp/result.json). 실시간으로 실행을 보려면 --tui(새 터미널 창의 라이브 ASCII 맵) 및/또는 --gui(브라우저의 라이브 HTML 뷰어)를 추가하십시오(실행 → 라이브 모니터링 참조).

6. 표면화 사용자에게 결과를 표시합니다(출력 동작 참조) — 요약하고, 스크립트 경로를 언급하며, 실행의 ASCII 맵을 이 대화에 인라인으로 렌더링하여 실행 그래프를 기본적으로 볼 수 있도록 합니다(열 창 없음):

   node ~/.claude/skills/codex-workflows/runner/bin/map-run.js --journal <journal> --no-color
   

   (<journal>은 실행이 ✎ journal: …으로 기록한 경로이며, 기본값은 .workflow-journal/<name>.jsonl입니다.) 해당 출력을 ```text 블록 내에서 응답에 붙여넣습니다. 오케스트레이터 → 단계 레이어 → 에이전트 그리드 → 에이전트별 모델/노력/토큰/시간 및 한 줄 결과 조각이 있는 결과 DAG입니다. **항상 --no-color**를 인라인으로 사용합니다(원시 ANSI는 채팅에서 쓰레기로 렌더링됨). 실시간, 세션 내 모니터링의 경우 run_in_background로 워크플로우를 실행하고 실행 중에 이 스냅샷을 몇 번 다시 렌더링합니다(실행 중인 에이전트는 ⠋ … running…으로 표시됨). 부드러운 라이브 창을 원하면 --tui/--gui를 추가하십시오(실행 → 라이브 모니터링 참조).

   실행이 완료되면 한 줄의 비용/신뢰성 요약도 출력합니다. 더 자세한 분석(단계별 토큰, 가장 비싸거나 느린 에이전트, 적신호(많은 null, 준비되지 않은 거대한 팬아웃, 기본 노력 비용))을 위해 저널에서 summarize-run을 실행하고 하이라이트를 응답에 포함하십시오(실행 요약 참조).

이 스킬을 사용하는 동안 네이티브 Workflow 도구를 호출하지 마십시오. 스크립트를 작성하고 위 CLI를 통해 실행하는 것이 작업을 Codex로 라우팅하는 방법입니다. 네이티브 도구를 호출하면 대신 Claude 서브에에이전트가 생성됩니다.

함대 모드 (--multi): 실행, 감독, 조종

사용자가 **--multi**를 전달하면(또는 함대 / 여러 워크플로우를 동시에 요청하면), 발사 후 망각이 아닌 N개의 동시 실행 운영자가 됩니다. 함대 계획을 컴파일하고, 모든 변형을 백그라운드에서 실행한 다음 감독 루프를 실행합니다: 상태 폴링, 게이트 응답, 표류하는 작업자 조종, 막다른 길 종료, 유망한 리드 포크, 마지막에 종합합니다. 인간은 정책을 한 번 설정합니다(목표, 총 예산, 위험 허용도). 당신이 변형 스스로는 내릴 수 없는 중간 실행 판단을 내립니다.

1 · 함대 계획 컴파일

의도를 2–4개의 변형으로 분해하고 실행 전에 계획을 명시합니다(변형, 각각이 무엇에 베팅하는지, 실행당 예산). 두 가지 축, 자유롭게 혼합:

• 유사 — 동일한 워크플로우, 다른 조각: --args를 통해 큰 입력을 실행에 분할하거나, 다른 시작 가설/시드에서 동일한 질문을 공격합니다. 하나의 스크립트 + 실행당 --args + --run-id(저널이 충돌하지 않도록), 또는 N개의 스크립트 복사본.
• 다양 — 작업에 대한 다른 이론에 베팅하는 다른 워크플로우 형태: 예를 들어 loop_until_dry 버그 사냥 vs adversarial_verification 스윕 vs sessionful_controller_loop 조사, 모두 동일한 목표를 목표로 합니다. 변형당 하나의 스크립트.

사용자의 전체 예산을 변형에 분할합니다(상태는 각 실행의 지출을 상한선과 비교하여 보여줌). 기존 GPT-5.5 측정을 사용하여 읽기 중심 팬아웃을 현실적으로 크기 조정: 저장소/코퍼스를 읽는 것이 작업인 에이전트는 노력 계층에 관계없이 ~400–600k 토큰이 듭니다 — 입력이 지배적이므로 --effort low는 스윕을 저렴하게 만들지 않으며, --plan의 노력당 추정치는 이를 과소 평가합니다(측정됨: 4개의 "low" 스윕 = 2.1M, 각각 525k, 150k/에이전트 계획 추정치와 대조). xhigh에서 — --auto-effort가 모든 세션 기반 작업자의 턴(너비 1)에 제공하는 것 — 읽기 턴은 ~1–1.5M을 실행합니다(측정됨: 워크스루 작업자의 첫 번째 턴 + 하나의 조종이 2.5M 상한선을 트리거함). 예산 ≈ readers × 500k + xhigh reading turns × 1.2M + non-readers × the plan estimate, 여유 공간 포함. 상한선이 트리거되면 복구 가능하지만(--resume은 접두사를 무료로 다시 재생함) 감독 왕복 비용이 발생합니다. 함대에도 과잉 구축 금지 규칙을 적용하십시오: 2개의 잘 차별화된 변형이 4개의 중복 변형보다 낫습니다. 모든 변형은 다른 변형이 하지 않는 것에 베팅해야 합니다.

2 · 감독을 위한 작성

모든 변형에는 감독자 체크포인트가 있습니다 — 외부 판단이 실행을 리디렉션할 수 있는 분기점에서 human() 게이트:

const directive = await human(
  `라운드 ${round} 결과: ${summary}. 다음 라운드 지시?`,
  { id: `round${round}`, choices: ["continue", "stop"], default: "continue", timeoutMs: 240_000 })
if (directive === "stop") break
if (directive !== "continue") await worker.steer(directive)   // 자유 텍스트 = 조종

이것이 조종 채널입니다: 자유 텍스트 답변 은 지시이며, 스크립트가 이를 적용합니다(session.steer(...), 다음 라운드 재조준, 범위 좁히기). 라운드 사이, 비용이 많이 드는 단계 전, 불확실성 시 게이트를 배치하십시오. 기본값은 안전해야 합니다 — 응답되지 않은 게이트는 기본값으로 시간 초과되고 실행은 수동 개입 없이 저하되며 중단되지 않습니다. (이것은 저널링된 human() 채널을 사용하므로, --resume은 다시 묻는 대신 답변을 재생합니다.)

3 · 실행 — 함대당 하나의 디렉토리, 모든 실행은 백그라운드에서

변형은 하나의 디렉토리를 공유합니다(이것이 fleet status <dir>이 감독하는 것). 각각을 run_in_background로 실행하고, **항상 --interactive**을 함께 사용합니다(헤드리스로 답변 채널 활성화):

node ~/.claude/skills/codex-workflows/runner/bin/run-workflow.js hunt-orm.workflow.js \
  --frontier --auto-effort --interactive --budget 1500000 1>hunt-orm.result.json
# 동일한 스크립트, 다른 조각 → --run-id로 격리:
node …/run-workflow.js hunt.workflow.js --args '{"slice":"auth"}' --run-id auth --interactive …

4 · 감독 — 루프

다른 작업 사이에 함대 다이제스트를 폴링하고(게이트가 보류 중일 수 있는 동안 신속하게) —

…

[번역을 위해 잘렸습니다]