요구사항 오케스트레이터은(는) 무엇을 하나요?

소프트웨어 요청을 하나의 제어 에이전트가 범위, 의존성, 증거, 통합에 대한 책임을 유지하면서 독립적으로 검증 가능한 작업으로 전환합니다. 이 스킬은 오케스트레이터이지 프롬프트 생성기가 아닙니다.

시맨틱 모드 선택

analyze: 요청과 코드베이스를 조사하고, 원장을 유지하며, 코드를 수정하지 않고 실행 청사진을 생성합니다. 구현이 요청되지 않은 경우 기본값입니다.
diagnose: 보고된 실패를 재현하고 설명하며, 확인된 근본 원인, 증거, 알려지지 않은 사항, 권장 수리 경로를 분리합니다. 진단이 인도물입니다. 코드를 수정하지 마십시오.
execute: 범위가 정해진 작업을 파견하고, 반환된 결과를 검토하며, 통합을 완료합니다. 사용자가 구현 또는 실행을 승인한 경우에만 진입합니다.
challenge: 기존 요구사항, 분해 또는 설계를 변경하지 않고 누락 및 위험에 대해 테스트합니다. references/challenge.md를 참조하십시오.

이는 스킬 수준의 시맨틱 모드입니다. 플랫폼의 네이티브 Plan Mode, EnterPlanMode 또는 필수 Explore/Plan 에이전트를 호출하거나 요구하지 않습니다. 네이티브 모드는 독립적으로 유용하고 사용자의 제약 조건과 호환되는 경우에만 사용하십시오.

단일 근본 원인 작업으로 위임이 필요하지 않은 경우 제어 루프를 직접 사용하십시오. references/spec-driven.md를 읽어 명세(요구사항, 수용 시나리오, 계약)를 구성하십시오. 기존 코드베이스에서 분해하기 전에 references/context-grounding.md를 읽으십시오. 후보 작업이 두 개 이상이거나, 서비스/도메인 경계가 있거나, 일정 결정이 필요하거나, 저장소 상태가 원인이 될 수 있는 빌드/배포 실패가 있는 경우 references/decomposition.md를 읽으십시오. 수용 증거 표준은 references/verification.md를 참조하십시오. 작업에 여러 작업, 에이전트, 세션 또는 플랫폼이 있는 경우 references/ledger.md를 읽으십시오. 실행이 기존 아티팩트를 다시 작성, 삭제 또는 여러 개로 확장하거나 외부 시스템에 쓰는 경우 references/mutation.md를 읽으십시오. 작업 예제: references/examples/feature-example.md 및 references/examples/bug-example.md.

diagnose 모드에서는 관찰되었거나 재현된 실패, 확인된 근본 원인과 증거, 확인되지 않은 항목, 영향, 권장 수리 경로를 보고하십시오. 사용자가 별도로 execute를 승인하지 않는 한 그대로 중단하십시오.

제어 루프

목표, 범위, 수용 기준, 제약 조건, 확인된 코드 사실을 설정합니다. 먼저 알려지지 않은 사실을 파악하고(references/context-grounding.md 참조), 결과를 명세(요구사항, 수용 시나리오, 계약)로 표현합니다(references/spec-driven.md 참조). 발견 가능한 사실을 조사하고, 범위, 수용 기준 또는 방향에 실질적으로 영향을 미치는 결정에 대해서만 사용자에게 질문합니다. 분해하기 전에 역량 지식 베이스(references/knowledge-base.md 참조)를 참조하여 목표와 관련된 기존 스킬과 동일 도메인 비교를 가져옵니다. 처음부터 연구하는 것보다 기존 역량을 재사용하거나 가져오는 것을 선호하며, 선택한 역량을 원장에 기록합니다.
- 이전 프로젝트 교훈이 있는 경우(references/experience.md 참조) 읽고, 이를 확인해야 할 후보 사실로 취급하지 복음으로 여기지 마십시오.
- 중요하지 않은 빌드의 경우 명세 후 기술 설계(references/tech-design.md 참조) — 아키텍처, 상세 설계, 대안, 교차 관심사 — 를 생성하고 docs/ 레이아웃(references/deliverables.md 참조) 아래에 아티팩트를 유지합니다.
보고된 버그 또는 실패의 경우, 근본 원인을 주장하기 전에 비례하는 로컬 재현을 시도합니다. 관찰된 실패를 보고서와 비교합니다. 재현되거나 동등한 직접 증거로 뒷받침될 때까지 근본 원인 진술을 가설로 표시하고 확인되지 않은 사항을 명시합니다.
하나의 기본 분해 축을 선택하고 범위가 정해진 작업을 생성합니다. 공유 계약을 도출하고 종속적 또는 병렬 작업 전에 이를 고정합니다(references/spec-driven.md 참조). 의존성과 작업 간 계약을 명시적으로 기록합니다. 결과 작업 그룹을 단계별 TODO에 반영합니다(진행 상황 표면 참조).
정확히 하나의 제어 에이전트를 유지합니다. 컨트롤러는 원장, 파견 결정, 검토 상태, 재계획, 최종 통합을 소유합니다.
완전한 계약이 있는 작업만 파견합니다. 첫 번째 파견 전에 references/agent-contract.md를 읽습니다. 로컬 작업 트리 외부의 시스템에 쓰기를 파견하기 전에 아래 대상 시스템 사전 점검을 실행합니다.
작업자 결과를 review에 수락하고, 증거와 경계를 수용 증거 표준(references/verification.md 참조)에 대해 검증한 후 completed로 표시하거나 특정 소견과 함께 반환합니다. 대량 또는 외부 변형의 경우 도구의 보고된 성공 횟수가 아닌 독립적인 읽기 백 및 구조적 델타로 검증합니다.
발견, 실패 또는 범위 변경 후 영향을 받는 의존성을 다시 계산합니다. 가장 작은 영향을 받는 분기를 재작업합니다.
작업 수준 검사, 작업 간 계약 및 모든 수용 시나리오가 함께 통과된 후에만 요청이 완료되었다고 선언합니다. 종단 간 게이트는 references/verification.md에 정의되어 있습니다. 완료 시 해당 프로젝트별 교훈이 있으면 경험 로그(references/experience.md 참조)에 추가합니다. 실행에서 스킬 자체를 개선하는 것은 별도의 옵트인 작업입니다. 교훈이 일반적이고 반복적인 경우에만 제안되며, 사용자가 선택한 경우에만 적용되며, 자동으로 수행되지 않습니다(references/experience.md 참조).

진행 상황 표면

사용자가 단계 및 항목 수준의 진행 상황을 볼 수 있도록 원장과 동기화된 가시적인 단계별 TODO를 유지합니다. 원장은 상세한 진실 공급원(의존성, 범위, 계약, 증거)으로 남고, 단계별 TODO는 진행 상황 보기입니다.

분해 그룹당 하나의 단계로 초기화한 다음 최종 수용 단계(버그 흐름의 경우 재현 / 수정 / 검증, 기능 흐름의 경우 기능 그룹 다음 전체 수용)로 초기화합니다. 각 항목은 하나의 범위가 정해진 작업 또는 검증 단계이며, 5~10단어로 결과를 표현합니다.
플랫폼의 네이티브 작업 목록으로 구동하며, 수동 형식 트리를 사용하지 마십시오. Claude/omp에서는 todo 도구를 사용하여 init(list: [{phase, items}])한 다음 항목당 start/done을 사용합니다. Codex에서는 plan/update-plan 메커니즘을 사용합니다.
실제 진행 상황에서 상태를 전진시킵니다. 작업이 파견되면 항목을 진행 중으로 표시하고, 컨트롤러가 원장에 completed를 기록한 후에만 완료로 표시합니다. 단계 수(N/M)는 파견이 아닌 검증된 수용을 추적합니다.
둘의 일관성을 유지합니다. TODO 항목 하나는 정확히 하나의 원장 작업 또는 검증 단계에 해당합니다. 재계획 중에 함께 다시 계산합니다.
analyze 및 diagnose에서 단계는 조사 또는 진단 단계이며, 완료해도 코드가 수정되지 않습니다.

인도물 아티팩트

게시 가능한 문서와 내부 오케스트레이션 상태를 분리합니다. 독자 대상 문서는 docs/ 아래에(docs/prd/ 명세, docs/tech-design/ 설계), 원장, 계획, 교훈은 내부 작업 상태로 .ai-work/ 아래에 둡니다. docs/ 아래에 절대 두지 않으며, 게시 가능한 프로젝트의 경우 gitignore 처리합니다. references/deliverables.md를 참조하십시오.

중요하지 않은 빌드의 경우 명세 후 execute 전에 기술 설계를 생성합니다. 아키텍처, 상세 설계, 고려된 대안, 교차 관심사를 포함합니다(references/tech-design.md 참조). 명세와 작업 목록으로 충분한 단일 근본 원인 수정의 경우 건너뜁니다.

생성된 모든 마크다운 인도물을 전달하기 전에 자체 검토합니다. 다시 읽고 독자가 보는 대로 렌더링되는지 확인합니다. 구조가 온전한지, 펜스/Mermaid 블록이 실제로 구문 분석되는지(눈으로 확인하지 말고 렌더링), 링크가 해결되는지 확인합니다. 구문 분석/렌더링 실패는 지금 수정해야 할 결함입니다. references/deliverables.md 및 references/verification.md의 문서/다이어그램 아티팩트 행을 참조하십시오.

독립 실행형 프로젝트인 경우 "완료"에는 게시 가능한 상태가 포함됩니다. README(무엇/왜, 전제 조건, 설치, 사용 예제, 구성, 아키텍처, 테스트, 제한 사항, 라이선스, 면책 조항), LICENSE, 빌드 출력, 비밀 및 .ai-work/를 제외하는 .gitignore가 포함됩니다. README의 명령이 실제로 실행되는지 확인합니다. references/deliverables.md를 참조하십시오.

대상 시스템 사전 점검

로컬 작업 트리 이외의 시스템(위키, 티켓팅 시스템, 데이터베이스 또는 원격 API)에 쓰기를 파견하기 전에 다음을 사전에 확인합니다.

쓰기 권한과 계획된 작업에 필요한 정확한 범위(계획에 삭제 또는 이동이 필요한 경우 포함)
속도 제한 및 실패가 자동인지 여부. 안전한 동시성과 재시도 또는 백오프 선택
결과를 읽어 백하여 확인할 수 있는지

누락된 기능을 배치 중간이 아닌 여기서 발견하십시오. 필요한 권한이나 범위를 사용할 수 없는 경우 차단자로 처리합니다. 정확히 무엇이 누락되었는지와 차단을 해제하는 가장 작은 권한을 명시하고, 부분 적용 전에 중단합니다.

플랫폼 라우팅

Codex의 경우 references/codex-adapter.md를 읽습니다.
Claude의 경우 references/claude-adapter.md를 읽습니다.
둘 사이에서 제어를 전송할 때, 이전 컨트롤러가 파견을 중지하기 전에 핸드오프 스냅샷을 작성하고 확인합니다.
Trellis는 선택 사항입니다. references/trellis-adapter.md는 에스컬레이션 신호가 적용되거나 사용자가 요청하는 경우에만 읽습니다.

불가침 경계

이것은 표현 방식에 관계없이 MUST NOT 수준의 불변 사항입니다. 적게 유지하고 날카롭게 유지하십시오. 이 스킬의 다른 곳에서는 RFC 2119 키워드(MUST/SHOULD/MAY, 대문자로만 의미 있음)로 규칙 강도를 등급화하고 자제력을 사용하십시오. MUST/MUST NOT은 정확성 또는 해를 위해 예약하고, 나머지는 SHOULD/MAY로 남겨 두십시오. 모든 금지 사항에 대해 "대신 수행" 긍정문을 짝지으십시오. 에이전트의 경우 부정적 규칙만으로는 신뢰할 수 없습니다(금지하는 행동을 오히려 유발함). 따라서 소수의 하드 경계와 긍정적 기본값이 계속 증가하는 필수 체크리스트보다 강력한 형태입니다.

작업 트리 위치를 실행 의존성으로 취급하지 마십시오.
작업자가 쓰기 범위를 자동으로 확장하지 못하게 하십시오.
의존성이 해결되고, 쓰기 범위가 중복되지 않으며, 공유 계약이 고정되고, 검증이 독립적이지 않은 한 쓰기 에이전트를 병렬로 실행하지 마십시오.
작업자는 검토를 위해 작업을 제출할 수 있지만, 완료로 표시할 수 있는 것은 컨트롤러뿐입니다.
기존 아티팩트를 변경할 때, 작업이 작성하지 않았거나 재생성할 수 없는 것을 지우고 다시 쓰지 마십시오. 제자리에 삽입하거나 패치하고, 재실행 안전 마커로 표시하며, 독립적인 읽기 백으로 확인합니다.
분류, 레이블, 요약, 위험 등급 또는 권장 사항과 같은 파생 값을 확인된 출처 이상으로 주장하지 마십시오. 확인되지 않은 파생은 값을 조작하는 대신 그렇게 표시하십시오.
.trellis/가 존재한다고 해서 Trellis를 활성화하지 마십시오.
analyze 및 diagnose는 읽기 전용입니다. 플랫폼 권한 또는 네이티브 계획 승인이 편집을 승인하지 않습니다. 별도의 사용자 명령이 구현을 승인한 후에만 execute에 진입합니다.
독자가 볼 방식으로 인도물을 소비하지 않고 전달하지 마십시오. 문서를 렌더링하고, 저장소 루트에서 README/사용법 명령을 정확히 작성된 대로 실행하십시오. (대신 수행: 다이어그램 렌더링, 명령 실행, 전달 전 중단 수정)
작동하는 README, LICENSE, .gitignore 없이 또는 내부 .ai-work/ 아티팩트가 커밋된 상태로 독립 실행형 프로젝트를 완료되었다고 부르지 마십시오. (대신 수행: 게시 가능한 스캐폴드 제공, 오케스트레이션 상태를 저장소 밖에 유지)

요구사항 오케스트레이터