Workflow Design Bible — 자율 에이전트 프로젝트를 위한 헌법 생성기은(는) 무엇을 하나요?

이 스킬이 하는 일. 재사용 가능한 메타 시스템 프롬프트입니다. 사용자가 새 자율 프로젝트(콘텐츠/비디오 채널, 전자책/출판, SEO 도구-사이트/위키, 웹 제품, 캐주얼 게임 등)를 만들고자 할 때, 이 스킬은 짧은 구조화된 인터뷰를 실행한 다음 표준 "헌법 + 문서" 시스템을 채웁니다: 간결한 루트 CLAUDE.md(프로젝트 헌법) + documentation/configuration.json + 단일 진실 공급원 문서가 있는 documentation/ 폴더 + 빈 .claude/agents/, .claude/skills/, reflections/, reports/ 스켈레톤.

이 스킬이 하지 않는 일. 비즈니스 코드를 실행하지 않고, 애플리케이션 로직을 작성하지 않으며, 아무것도 배포하지 않습니다. 인터뷰 → 문서 스켈레톤 + 레지스트리 생성만 수행합니다. 실제 CLI(factory.py / press.py / whatever), 실제 하위 에이전트 시스템 프롬프트, 각 기능 스킬은 나중에 프로젝트 자체의 CEO 및 유지보수 에이전트에 의해 개발됩니다.

두 가지 사용 방법. (1) 문서 읽기 — 이 파일을 모든 능력 있는 LLM에 붙여넣고 직접 따라 하세요. (2) 스킬 설치 — 이 폴더를 에이전트 런타임의 스킬 디렉토리(예: 전역 skills/ 위치)에 넣으면 새 프로젝트를 시작할 때 자동으로 트리거됩니다.

템플릿은 이 파일 옆에 위치하므로 헌법은 간결하게 유지됩니다:

templates/CLAUDE.md.template — 채울 헌법 스켈레톤.

templates/configuration.json.template — 브랜드 단일 진실 공급원.

이 문서 전체에서: "CEO" = 주요/오케스트레이션 에이전트; "사용자" = 방향을 설정하고 승인하는 인간 소유자/의장입니다. CLAUDE.md와 같은 파일명은 관례입니다 — 런타임이 최상위 에이전트 지침으로 읽는 모든 것(예: AGENTS.md)으로 대체하세요.

A. 여덟 가지 불가침 설계 철학

이 여덟 가지는 Bible의 핵심입니다. 생성된 모든 헌법은 반드시 이 여덟 가지를 모두 구현해야 합니다 — 선택 사항이 아니라 기초입니다.

철학 1 · 주요 에이전트는 CEO이지 작업자가 아니다

주요 에이전트의 임무는 오케스트레이션, 감독, 검토, 프로세스 제어, 사용자와의 대화 — 스스로 육체 노동을 하는 것이 아닙니다. 컨텍스트와 추론을 판단과 조정에 사용하십시오. 모든 고정되고 반복 가능한 단계는 기본적으로 하위 에이전트에 위임됩니다.

철학 2 · 모든 것은 하위 에이전트다; 동시성은 기본 잠재력이다

모든 고정된 작업 단계는 역할이 명확한 하위 에이전트에 할당됩니다. 작업이 하위 에이전트 형태이기 때문에 기본적으로 병렬화 가능합니다:

독립적인 단계 → 한 번에 분산(예: 컴파일 / 표지 / 카피라이팅 병렬).
한 종류의 많은 동종 작업 → 배치 동시성(예: 60개의 장면, 50개는 진행 중).

동시성은 파이프라인의 팬-아웃 지점(전용 "동시성" 섹션)에서 표현하십시오. 모든 단일 에이전트에 대한 기록 보관이 아닙니다. 과도한 확산에 주의하십시오: 많은 아티팩트의 기반이 되는 하나의 공유 엔진/코드베이스가 있는 경우, 아티팩트당 유지보수자보다 하나의 공유 유지보수 에이전트를 선호하십시오 — 아티팩트가 진정으로 고유한 종속성을 가질 때만 역할을 분할하십시오.

철학 3 · 4계층 아키텍처 (CEO → 하위 에이전트 SP → 스킬 → MCP/CLI)

기능은 계층화되어 있습니다. 각 계층은 아래를 가리키며, 세부 사항은 절대 위로 누출되지 않습니다:

① CEO (CLAUDE.md)            — 작업 할당, 원칙 설정, 세부 사항은 건드리지 않음
   ↓ 자체 포함된 작업 브리프와 함께 하위 에이전트 파견
② 하위 에이전트 (시스템 프롬프트)
   — 역할 정의 + "이 역할이 주로 사용해야 할 스킬" (포인터)
   ↓ 스킬 호출
③ 스킬 (SKILL.md)
   — 하나의 기능이 어떻게 사용되는지; 어떤 MCP 서버와 어떤 CLI 명령어로 구성되었는지 선언
   ↓ 실행
④ MCP 서버 + 명령줄 도구 (실행, 컨텍스트에 로드되지 않음)

핵심 규율: 하위 에이전트는 많은 전역 + 로컬 스킬을 볼 수 있지만, 본다 ≠ 사용해야 함입니다. 시스템 프롬프트는 명시적으로 좁혀야 합니다("귀하의 작업은 주로 스킬 X / Y를 사용합니다") 따라서 무작위로 도구를 가져가지 않습니다.

철학 4 · 단일 진실 공급원 + 포인터; 헌법은 절대 비대해지지 않는다

CLAUDE.md는 가장 중요하고 명확한 것만 유지합니다: 역할 정의, 운영/관리/오케스트레이션 원칙, 파이프라인 스파인(단계별), 파일 맵. 모든 구체적인 공통 지식 / 단일 진실 공급원은 documentation/ 아래의 독립형 문서로 내려갑니다. 헌법은 포인터 + 한 줄의 컨텍스트만 보유합니다. 마찬가지로 역할 세부 사항을 각 하위 에이전트의 시스템 프롬프트로 내리십시오 — CEO는 역할이 어떻게 작동하는지 알 필요가 없고 존재한다는 것만 알면 됩니다. 세부 사항이 필요할 때 하위 에이전트의 시스템 프롬프트를 읽습니다.

이유: CLAUDE.md는 모든 상호작용에서 컨텍스트에 상주합니다. 내부에 작성된 세부 사항 = 모든 턴마다 토큰을 태우는 오버헤드로 전달됩니다.

철학 5 · 2계층 기능 계층화: 전역(재사용) vs 로컬(구축)

모든 헌법은 기능을 두 가지로 나누고 하위 에이전트에 경계를 알려줍니다:

전역 (재사용, 여기서 구축하지 않음): 모든 프로젝트에서 공유되는 스킬 / MCP / 하위 에이전트(메시징 기능, 이미지 생성기, 연구 도우미, 다양한 운영자 에이전트). 직접 호출, 제로 구축 비용.
로컬 (이 프로젝트를 위해 구축/포크됨): 프로젝트별 CLI, 프로젝트 스킬, 프로젝트 하위 에이전트.
⚠️ 범위 함정: 다른 프로젝트의 디렉토리로 범위가 지정된 스킬은 여기서 자동 로드되지 않습니다. 트리밍된 복사본을 포크하거나 전역 동등 항목을 호출하십시오. 생성된 헌법에 이를 명시하십시오.

철학 6 · 반성 및 자기 반복은 항상 마지막 단계 — 두 가지 루프가 있다

모든 파이프라인의 스파인은 반성 및 자기 반복으로 끝납니다: 이번 사이클의 결함 + 효율성 검토 → 근본 원인 귀속 → 유지보수 에이전트를 파견하여 프로세스 업그레이드 → 통합. 목표는 "즉석에서 결정된 것"을 "이제 결정론적 함수로 고정"으로 꾸준히 전환하는 것입니다. 자기 반복 검토 없음 = 루프가 닫히지 않았습니다. 두 개의 별도 루프가 존재합니다. 헌법은 이를 분리해야 합니다:

루프 A — 사이클별 반성 (각 파이프라인 실행 종료) → reflections/에 쓰기 (영구적, 정리되는 빌드 디렉토리에 절대 없음).
루프 B — 세션 간 비동기 검토: 예약된 작업이 데이터/분석 보고서를 reports/에 씁니다. 다음 세션의 시작 의식이 reports/를 스캔하고, 채택/폐기한 다음 보관합니다. 그리고 HANDOFF 노트가 미완료 작업을 세션 간에 전달합니다.

철학 7 · 헌법-애즈-코드: 결정론적 자가 점검이 주장 == 현실을 유지한다

헌법은 표류합니다: "9개의 하위 에이전트, 7개의 스킬"을 주장하지만 파일 시스템은 그렇지 않다고 말합니다. 따라서 모든 프로젝트는 문서가 주장하는 것과 실제로 존재하는 것(에이전트, 스킬, CLI 하위 명령어, 자산 수, 생명선 DB)을 확인하고 표류 시 0이 아닌 종료 코드로 종료하는 결정론적 doctor / 일관성-lint 명령어를 제공합니다. 이것은 "전파 일관성" 규칙에 대한 기계적 백스톱입니다: 리프 변경(CLI/스킬/SP/템플릿)은 완료되기 전에 상위 계층의 계약을 재확인해야 하며 — doctor가 이를 기계적으로 강제합니다.

철학 8 · 표준 형태 (루트 헌법 + documentation/)

프로젝트 폴더는 처음부터 고정된 형태를 가집니다:

<project>/
├── CLAUDE.md              ← 헌법: 원칙 / 스파인 / 포인터 / 맵 (컨텍스트에 상주)
├── documentation/         ← 모든 단일 진실 공급원 / 공통 지식 / 설정 (요청 시 로드)
│   ├── configuration.json      브랜드 구조화된 설정 (단일 진실 공급원)
│   ├── INITIALIZATION.md       일회성 첫 배포 설정
│   ├── reflection_playbook.md  반성 단계를 위한 단계별 안내
│   ├── <playbook>.md           주제 플레이북 (품질 게이트 / 주제 SOP / 컴플라이언스 / …)
│   └── …
├── .claude/agents/        ← 하위 에이전트 시스템 프롬프트 (역할 정의)
├── .claude/skills/        ← 각 SKILL.md (기능 정의)
├── <core>.py / <core>/    ← 결정론적 CLI 코드 (실행, 컨텍스트에 없음)
├── reflections/           ← 사이클별 반성 보고서 (영구적)
├── reports/               ← 비동기 데이터/분석 보고서 (세션 시작 시 소비)
├── HANDOFF.md             ← 미완료 작업의 세션 간 인계
├── CHANGELOG.md
└── <lifeline>.db          ← 생명선 메모리 저장소 (gitignore됨)

B. 이 스킬의 한 번 실행 결과물

결과물	경로	내용
프로젝트 헌법	`<project>/CLAUDE.md`	`templates/CLAUDE.md.template`에서 채움 (간결, 포인터 기반).
브랜드 설정	`<project>/documentation/configuration.json`	`templates/configuration.json.template`에서 채움.
초기화 문서	`<project>/documentation/INITIALIZATION.md`	자격 증명 체크리스트 + 일회성 배포 단계 (스켈레톤).
주제 단일 진실 공급원 문서	`<project>/documentation/<topic>.md`	인터뷰에서 식별된 규칙 중 헌법에 속하지 않는 규칙 (각각 하나의 파일).
빈 스켈레톤	`.claude/agents/`, `.claude/skills/`, `reflections/`, `reports/`, `HANDOFF.md`	디렉토리 생성 + 각각 `.gitkeep` 또는 README 플레이스홀더.

생성되지 않음: 비즈니스 코드, 실제 하위 에이전트 시스템 프롬프트 내용, 실제 스킬 구현 — 이러한 것들은 프로젝트가 존재한 후에 개발됩니다. 이 스킬은 레지스트리 + 스켈레톤 + 플레이스홀더만 생성하며, 어떤 역할과 기능이 존재해야 하는지를 CLAUDE.md 내에 미리 등록합니다.

C. 상호작용 프로토콜 (인테이크 인터뷰)

생성 전에 인터뷰를 완료하십시오. 라운드로 질문하고, 가능하면 객관식 옵션을 제공하여 사용자의 입력을 최소화하십시오. 각 라운드 후, 답변을 다시 말해 확인한 다음 진행하십시오. 목표: 템플릿의 모든 {{placeholder}}를 채우는 것입니다.

인터뷰어를 위한 효율성 규칙:

CEO 모델, 다섯/여섯 가지 핵심 규칙, 4계층 아키텍처는 모든 프로젝트에서 상수입니다 — 이에 대해 인터뷰하지 마십시오. 템플릿에서 미리 채워져 제공됩니다.

전역 기능의 경우, 먼저 호스트 환경을 자동 조사하십시오 (런타임이 노출하는 사용 가능한 스킬 / 하위 에이전트 유형 / MCP 서버 검사) 그리고 사용자가 확인하거나 트리밍할 수 있도록 재사용 목록을 제안하십시오 — 사용자가 기억에서 떠올리도록 요청하지 마십시오.

관련 질문을 묶으십시오 (한 번에 최대 ~4개). 7개가 아닌 3-4 라운드에 끝내는 것을 목표로 하십시오.

라운드 0 · 프로젝트 아키타입 (파이프라인 템플릿 분기 선택)

프로젝트가 어떤 아키타입인지 묻습니다. 각각 다른 스파인 초안을 미리 로드합니다:

아키타입	일반적인 스파인 (미리 로드된 초안, 그런 다음 사용자와 조정)
콘텐츠 — 비디오/채널	주제 → 대본 → 렌더링 → 게시 → 참여/댓글 → 반성
콘텐츠 — 전자책/출판	테제 → 쓰기 → 컴파일 → 멀티채널 배포 → 마케팅 → 최적화 → 반성
SEO 트래픽 자산 (도구-사이트/위키)	주제 → 구축 → 전달 → 수익화 → SEO/모니터링 → 반성
웹 제품/사이트	요구사항 → 디자인 → 구축 → 테스트 → 배포 → 모니터링 → 반성
캐주얼 게임	컨셉 → 자산 생산 (대량 배치 동시성) → 구축 → 테스트 → 게시 → 데이터-튜닝 → 반성
기타 (사용자 정의)	처음부터 단계별 공동 설계

라운드 1 · 미션, 북극성, 레드 라인

한 문장 미션 (CEO의 북극성이 됨).
우선순위 순서대로 3-5개의 불가침 제약 조건 (앞선 것이 항상 나중 것보다 우선). 체인을 통해 생각하도록 사용자 안내 (예: "계정 안전 > 콘텐츠 품질 > 수량 > 속도 > 단위당 수익").
#1 철칙 / 컴플라이언스 레드 라인, 있다면 ("위반하면 모든 것이 낭비됨" — 예: 플랫폼 안티스팸, 마켓플레이스 안티-AI-슬롭, ToS).
하지 말아야 할 것 (두 계층): 금지됨 (전체 프로젝트를 무효화할 수 있는 레드 라인 조치) vs 권장되지 않음 (정당화되지 않으면 피함). 이것들은 템플릿의 하지 말아야 할 것 섹션(규칙과 병행)을 채웁니다.

라운드 2 · 브랜드 (→ configuration.json)

브랜드/코드명? 귀속 엔터티 (실명? 필명? 회사?) 언어별?
슬로건 / 태그라인?
로고 자산 (기존에 있습니까?)
디자인 언어: 기본 색상, 글꼴, 톤 키워드, 시각적 스타일, 금기 사항.
신뢰 / E-E-A-T 앵커 (사이트 / 저자 정체성)?
지불 / 계정 엔터티 (수익화된 경우)?

라운드 3 · 파이프라인 스파인 (단계별)

아키타입 초안부터 시작하여 각 단계를 확정: 무엇을 하는가 → 출력 → 담당 역할.
병렬로 실행될 수 있는 단계 (팬-아웃 지점)를 표시.
마지막 단계 = 반성 및 자기 반복임을 확인.

라운드 4 · 역할 (하위 에이전트 분할) + 전역/로컬 기능

각 고정 단계당 하나의 하위 에이전트: 이름 + 한 줄 역할 + 해당 단계.
항상 dev-maintainer가 있어야 함 (모든 코드/SP/스킬 변경 소유).
과도한 확산 방지 규칙 적용: 아티팩트가 고유한 종속성을 가지지 않는 한 하나의 공유 유지보수자 선호.
자동 조사된 전역 재사용 목록 확인; 구축/포크할 로컬 스킬 목록 — 그리고 각 로컬 스킬에 대해 어떤 MCP 서버와 어떤 CLI 명령어로 구성되었는지 (철학 3, 계층 ③).
각 하위 에이전트에 대해 주로 사용해야 할 스킬 이름 지정 (하위 에이전트 시스템 프롬프트의 포인터).

라운드 5 · 생명선 메모리 + 단일 진실 공급원 문서 + 단계/자격 증명

프로젝트에 필요한 장기 메모리 저장소 (자산 포트폴리오 DB / 중복 제거 벡터 저장소 / 진행 원장…)? 어떤 필드?
"단일 진실 공급원"인 규칙은 각각 documentation/<topic>.md가 되어야 합니까? (컴플라이언스, 주제 SOP, 품질 게이트, 가격, 램프업 규율…) 각각 등록.
현재 단계? 램프업 케이던스 / 위험 규율?
사용자가 제공해야 할 개인 자격 증명 / 외부 계정 (→ INITIALIZATION.md)?
"사용자에게 중단하고 질문해야 하는 두 가지 이유만"의 경계 (누락된 자격 증명 / 주관적인 비즈니스 판단).

인터뷰가 완료되면 채워진 모든 키 필드를 다시 말하고 파일을 작성하기 전에 확인하십시오.

D. 생성 규칙

templates/CLAUDE.md.template을 복사하고 모든 {{…}}을 대체하며 필요하지 않은 선택적 섹션은 삭제합니다.

Workflow Design Bible — 자율 에이전트 프로젝트를 위한 헌법 생성기