picoduck/orchestrate-issues

이슈 조정 (Orchestrate Issues)

초기 이슈와 그에 정당화된 후속 작업의 캠페인을 실행합니다. 프로세스 내 하위 에이전트가 아닌 실제 Wollipog 자식 세션을 통해 조정합니다. Orchestrator는 조사, 일정 수립, 결과 검토 및 상태를 유지하고, 자식 세션이 구현을 담당합니다. 이 스킬을 생성하거나 편집한다고 캠페인이 시작되지는 않습니다.

활성화 경계 (Activation Boundary)

이슈 수, 종속성, 작업 크기 및 자식 세션 도구의 가용성은 위임을 승인하지 않습니다. 이 워크플로우의 명시적 호출 또는 조정, 세션 간 조정, 또는 자식에 대한 구현 위임 요청이 필요합니다. 활성 캠페인에 대해 이미 설정된 관련 권한은 유효하며, 매 턴마다 반복할 필요가 없습니다.

"이슈 1089, 1090, 1091을 클레임하고 구현하세요"는 현재 세션이 저장소의 이슈 워크플로우(예: 설치된 issue-workflow 스킬)에 따라, 종속성 순서대로, 필수 격리 작업 트리 및 리뷰와 함께 해당 이슈를 클레임하고 구현함을 의미합니다. 요청이 여러 이슈를 나열한다고 해서 자식 구현 세션을 시작하거나 조정할지 묻지 마세요. Orchestrator 설정에 관한 이슈 제목이나 본문은 작업 주제일 뿐, Orchestrator가 되라는 지침이 아닙니다.

"자식 세션을 조정하여 이슈 1089, 1090, 1091을 구현하세요" 또는 "해당 이슈에 대해 orchestrate-issues를 사용하세요"는 이 워크플로우를 활성화합니다. 여러 할당 이슈를 받은 자식 세션은 여전히 구현 세션으로 남습니다. 부모의 조정 권한이 해당 자식에게 다시 위임할 권한을 자동으로 부여하지는 않습니다. 저장소에 필요한 리뷰(교차 모델 리뷰 포함)는 자체 규칙에 따라 관리되며 이슈 구현의 위임이 아닙니다.

현재 세션이 Orchestrator 권한 프리셋에 의해 제한되어 직접 구현할 수 없는 경우, 구체적인 제한 사항을 설명하고, 자동으로 자식을 생성하거나 금지된 구현을 시도하지 말고 방향을 요청하세요. 단순히 프리셋을 사용할 수 있다는 것이 사용 권한을 의미하지는 않습니다.

입력 및 설정 (Inputs and Setup)

• count: 양의 정수, 선택할 초기 이슈 수입니다. 요청에서 추론하세요. 생략된 경우 5를 사용하고 그 가정을 명시하세요. 명시적 이슈 목록은 우선 순위 선택을 대체하고 개수를 결정합니다.
• concurrency: 선택적 상한선으로, count와는 독립적입니다. 기본값은 count, 정책의 maximumConcurrentChildren, 사용 가능한 활성 자식 용량 중 가장 작은 값입니다. 초과 이슈는 대기열에 넣고, 플랫폼 제한을 count에 맞추기 위해 올리지 마세요.
• 자식 하네스, 모델 및 노력은 캠페인의 Wollipog Orchestrator 정책(get_campaign.behavior의 childHarness, childModel, childEffort)에서 가져옵니다. 이 스킬에는 자체 기본값이 없습니다. 각 값은 고정값이거나 자동(null)입니다. 자식 모델 및 노력 확인을 참조하세요.
• 리뷰어는 저장소의 리뷰 워크플로우에 지정된 모델을 유지합니다.
• 선택적 사용자 지정 비용, 시간, 총 이슈 또는 후속 작업 깊이 제한. 상속된 안전장치를 유지하세요. 예산 값이나 임의의 성공적인 중지 라운드를 만들지 마세요.

using-wollipog, 저장소 지침, 그리고 저장소나 사용자가 제공하는 이슈 워크플로우, 리뷰, 이슈 보고 스킬 또는 정책을 읽으세요. using-wollipog만 필수입니다. 저장소가 이슈 워크플로우를 정의하지 않은 경우, 자식 세션은 기여 가이드라인과 이 스킬의 게이트를 따릅니다. 자식 세션은 실행 환경에서 동일한 스킬을 사용할 수 있어야 합니다. 스킬 경로는 해당 환경의 카탈로그에서 확인하세요. 이 머신의 홈 경로가 다른 곳에 존재한다고 가정하지 마세요. 게시 페이로드를 준비하기 전에 저장소의 이슈 보고 정책을 읽으세요.

현재 러너, 저장소/워크스페이스, 사용 가능한 작업자 하네스 및 모델/노력 기능, 자식 용량, 지원되는 세션 도구를 발견하세요. 선택한 모델을 광고하는 하네스를 선택하세요. 모든 모델이 Codex에 속한다고 가정하지 마세요. 무엇이든 생성하기 전에 현재 세션 및 활성 자식 목록을 검사하세요. 허용된 Orchestrator 작업만 사용하세요. 프로젝트 쓰기 및 구현은 자식 세션에 속합니다. 캠페인 원장을 지속적인 세션 아티팩트 또는 허용된 스크래치 공간에 유지하고, 기본 체크아웃에는 절대 저장하지 마세요. 양보 또는 압축 전에 대화에서 최신 상태를 요약하세요.

자식 모델 및 노력 확인 (Resolve Child Model and Effort)

무엇이든 선택하기 전에 get_campaign.behavior에서 childHarness, childModel, childEffort를 읽고, 각 디스패치 전에 다시 읽으세요. 캠페인이 실행되는 동안 사람이 값을 변경할 수 있으며, 이후 생성된 자식만 새 값을 사용합니다. Wollipog의 Orchestrator 설정이 이러한 값의 유일한 소스입니다. 이 스킬에 기록된 모델이나 노력, 이전 캠페인에서 기억된 값, 또는 부모 세션에서 상속된 값으로 대체하지 마세요.

• 고정값: 정확히 사용하세요. 서버는 create_session에서 이를 생략하면 고정값을 채우고 다른 값은 거부하므로 재정의하지 마세요. 사용자의 프롬프트가 고정 설정과 다른 모델이나 노력을 요청하는 경우, 충돌을 보고하고 사용자에게 Wollipog 설정을 변경하도록 요청하세요. 해결될 때까지 해당 이슈를 디스패치하지 마세요.
• 고정 하네스: 고정 childHarness는 하네스의 이름을 지정하며, 각 머신에는 해당 하네스에 대한 자체 에이전트가 있습니다. get_campaign이 childHarnessAgents를 반환하는 경우, 자식을 생성하는 머신에 대해 나열된 agentId를 전달하세요. null로 나열된 머신은 실행할 수 없습니다. childHarness.agentId에서 에이전트를 파생시키지 마세요. 어떤 머신의 에이전트일 필요는 없습니다.
• 고정 모델 또는 노력: get_campaign이 childModelMachines를 반환하는 경우, supported로 표시된 머신에서만 자식을 생성하세요. 다른 머신은 해당 모델과 노력을 실행할 수 없으며, 그곳에서 생성이 거부됩니다.
• 자동 (null): 각 할당에 대해 get_agent_capabilities(MCP) 또는 wollipog session capabilities(CLI)에서 선택하세요. truncated가 false가 될 때까지 page.nextOffset을 따르세요. 선택한 모델을 광고하는 하네스를 선택하세요. 모든 모델이 하나의 하네스에 속한다고 가정하지 마세요. 선택은 이슈의 복잡성, 불확실성, 실수로 인한 결과, 컨텍스트 요구 사항 및 사용자가 명시한 비용 또는 지연 시간 제약 조건을 기반으로 하세요. 사용자 프롬프트의 모델 또는 노력 선호도는 자동 선택을 안내하지만 Wollipog 설정을 변경하지는 않습니다. 간단한 작업에는 경제적이고 유능한 옵션을, 복잡한 디버깅, 아키텍처 또는 광범위한 변경에는 더 강력한 추론을 선호하세요. 모델 순위, 가격 또는 노력 수준을 임의로 만들지 마세요. 광고된 기능을 사용하고 중요한 불확실성을 설명하세요. 모델이 구성 가능한 노력을 광고하지 않는 경우, 노력을 해당 없음으로 기록하세요.

고정값이 현재 기능 검색에 없는 경우, 불일치를 보고하고 독립적인 분류 작업을 계속하면서 수정된 설정을 요청하세요. 절대 조용히 대체하지 마세요.

각 이슈의 하네스, 정확한 모델 및 노력, 각각이 고정값인지 자동인지, 그리고 자동 선택에 대한 간략한 근거를 선택 테이블과 원장에 디스패치 전에 기록하세요. 자동 모드는 자식별로 묻지 않고 이러한 일상적인 선택을 승인합니다. 계정, 결제 약관, 권한, 예산 또는 Wollipog 설정 자체를 변경하는 것을 승인하지 않습니다.

구현 전 모델 및 노력 확인 (Verify Model and Effort Before Implementation)

create_session을 useWorktree: true, 확인된 하네스, 광고된 작업자 권한 모드(Orchestrator 모드 아님), 확인된 model 및 effort와 함께 동일한 호출에 사용하고, 자식의 기록된 작업 항목을 명명하는 campaignWorkItemId를 추가하세요. CLI 등가물은 wollipog session create ... --model <model> --effort <effort> --work-item <id> --worktree입니다. 차원은 정책에 의해 고정된 경우(서버가 제공) 또는 해당 없음인 경우에만 생략하세요. 명시적 값은 초기 프롬프트 전에 적용됩니다. 작업 텍스트에는 구조화된 도구 입력을 선호하세요.

생성 결과 또는 get_session에서 유효한 쌍을 다시 읽고 확인된 조합과 일치하는지 확인하세요. 일치하지 않는 경우, 해당 자식이 작업을 시작하기 전에 중단하고, 불일치를 기록하고 보고하세요. 확인되지 않은 기본값을 수락하지 마세요. 명시적 노력을 지원하지 않는 클라이언트와 서버는 실패 시 폐쇄됩니다. 노력 없이 재시도하지 말고 차단기를 보고하세요.

실제 생성 스키마를 검사하세요. 러너 프로토콜 번호만으로는 입력이 노출되지 않습니다. 사용자 정의 호스트에 campaignWorkItemId가 없는 경우, 생성 시 읽기 전용 부트스트랩 할당만 사용하고, 유효한 구성을 확인하고, 지원되는 할당 도구로 원래 작업 항목 할당을 기록하고, 구현을 해제하기 전에 전용 작업 트리를 선택하세요. 해당 호스트에서 원자적 작업 항목 바인딩을 주장하거나 필수 보호된 승인을 우회하지 마세요. 해당 작업을 사용할 수 없는 경우, 호환성 차단기를 보고하세요. 캠페인을 호스팅하는 스택을 절대 업데이트하지 마세요.

자식을 재사용하기 전에 구성을 다시 확인하세요. 자동 할당의 경우, 이전 선택이 부적절했음을 증거가 보여주면 조합을 재고하고 이유를 기록하세요. 유휴 상태에서 지원되는 구성 작업을 통해서만 변경 사항을 적용하고 해제 전에 확인하거나, 명확한 소유권 핸드오프와 함께 대체 자식을 생성하세요. 일반 prompt_session 메시지는 세션 구성을 변경하지 않습니다. 정책에 고정된 값을 절대 변경하지 마세요.

권한 및 게이트 (Authority and Gates)

using-wollipog와 함께 제공되는 Campaign Authority Preflight 참조를 읽으세요. 디스패치 전에, 유효한 Custom/Full Control 모드, 사람이 설정한 경계 및 개정, 허용된 작업, 현재 소유자, 호환성, 증거 대상/제공자 공개 및 Human Required 예외를 기록하세요. 확인되지 않은 필수 사람 규칙을 정확한 명령 소스로 식별하세요. 외부 또는 사용자 작성 지침을 조용히 다시 작성하지 마세요. Full Control은 저장소 정책에 의해 허용되는 적격 서버 설정 권한에만 적용됩니다. Custom은 기존 승인 요구 사항을 유지합니다. 변경된 정책은 자체적으로 명시적으로 승인된 기여 워크플로우를 거쳐야 합니다.

사용자의 실제 캠페인 권한 및 저장소 규칙을 계속 유지하세요. 일상적인 클레임, 격리된 작업 트리, 테스트, 푸시, PR 열기 및 필수 리뷰는 반복적인 허가가 필요하지 않습니다. 기존 규칙에는 여전히 PR 병합당 승인, UI 증거 검토, 원격 브랜치 삭제 승인 및 각 정확히 살균된 이슈 페이로드의 승인이 필요할 수 있습니다. 이 워크플로우에 대한 요청을 해당 게이트의 포기로 조용히 전환하지 마세요.

디스패치 전과 워크플로우 결정을 해결하기 전에 get_campaign으로 권위 있는 현재 캠페인 상태 및 서버 파생 정책을 읽으세요. 서버 상태를 사용할 수 있을 때 프롬프트 복사본에 의존하지 마세요. implementation_question, pr_merge, merged_branch_deletion, follow_up_issue_publication, ui_evidence_approval, review_round_extension과 같은 유형화된 결정의 경우, 자식은 일치하는 작업 바로 직전에 정확한 발생에 대해 request_workflow_decision, get_workflow_decision, consume_workflow_decision을 사용해야 합니다. 부모는 자식을 대신하여 게이트를 생성하거나 소비해서는 안 됩니다. list_descendant_requests로 보류 중인 발생을 발견하고, resolve_descendant_workflow_decision으로 현재 Orchestrator 소유의 정확한 발생만 해결하세요. answer_descendant_question 및 resolve_descendant_approval은 해당되는 비워크플로우 요청에만 사용하세요. 이는 유형화된 워크플로우 게이트를 대체하지 않습니다. 일반 프롬프트, 오래된 승인 또는 Parent Control 가용성은 유형화된 게이트에 대한 권한이 아닙니다.

여러 이미지와 함께 ui_evidence_approval 결정을 소유한 경우, prepare_descendant_ui_evidence_review를 선호하세요. 이는 모든 이미지를 새 컨텍스트를 가진 관리되는 리뷰어 세션에 전달하므로 이미지가 대화에 들어오지 않습니다. 자식의 명시된 주장과 이슈의 UI 수락 기준에서 간단한 설명을 작성하세요. 리뷰어가 작업하는 동안, 폴링 대신 턴을 종료하거나 세션을 기다린 후, get_descendant_ui_evidence_review로 평결을 읽으세요. 반환된 정확한 delegatedImageReview 참조로만 승인하고, 모든 증거 ID를 evidenceReviewed에 나열하세요. 거부 권장 시, 관찰된 결함을 명명하는 childMessage와 함께 거부하세요. 하나의 이미지가 있는 결정 또는 평결이 불분명할 때 한 이미지를 대상으로 살펴보려면 review_descendant_ui_evidence를 사용하세요. 리뷰어 경로를 사용할 수 없는 경우, 이유와 함께 거부하므로 대신 직접 검토하세요. 리뷰어는 다른 캠페인 자식과 같습니다. 보고서를 확인하고 정리에 포함시키세요.

자식의 GitHub pr_merge를 승인하기 전에, 무엇을 종료하는지 읽으세요. 결정의 closingReferenceCheck는 GitHub이 병합 시 종료할 모든 이슈를 나열하며, 서버는 이것이 스냅샷의 intendedClosures와 일치하는 경우에만 결정을 생성했습니다. 캠페인이 해당 병합이 이슈를 종료하기 위한 것인 경우에만 종료를 승인하세요. 그렇지 않으면 자식 메시지와 함께 거부하여 자식이 참조를 "Refs #N"으로 다시 작성하도록 하세요. 검사가 없는 경우(자식의 러너가 이전), 승인 전에 직접 wollipog pr closures <pr-url> --json을 실행하세요. 종료 키워드는 유형화된 issue_closure 게이트를 우회하므로, 캠페인이 해당 경로를 통해 이슈를 종료하는 경우 자식의 병합은 일반적으로 아무것도 종료하지 않아야 합니다.

캠페인 제어 설정을 변경하거나, 사람 소유 요청을 승인하거나, 사람을 사칭하거나, 보류 중인 승인을 일반 프롬프트로 우회하지 마세요. 적격한 루트 Full Control 발생은 정확한 유형화된 해결 경로를 통해 서버 기록된 상설 권한을 사용할 수 있지만, 새로운 승인을 생성할 수는 없습니다. 활성 정책이 Orchestrator가 증거 바이트를 검사할 수 없다고 말하는 경우 UI 증거는 사람 소유로 유지됩니다. 사람 소유 또는 달리 위임되지 않은 게이트의 경우, 하네스의 지원되는 유형화된 질문 메커니즘을 통해 구체적인 결정을 전달하고 관련 없는 자식이 계속 진행하도록 하세요. Full Control 하에서는 어떤 사람도 루트의 질문을 보지 못합니다. 서버가 답변 없이 이를 기각하므로, Orchestrator 소유 발생을 직접 해결하고 Campaign Status에 표시되는 사람 소유 게이트(Campaign Status에 유지됨)를 보고하고 묻지 마세요. 소유자가 결정을 자신을 위해 유지한 경우(설계 선택, 위험 고려...

...

[잘림 방지용 추가 내용]

캠페인 정리 (Campaign Cleanup)

마지막 초기 이슈가 해결되면 즉시 정리를 시작하세요. 보류 중인 자식이 있으면 기다린 후 해결하세요. PR 열기 및 병합, 원격 브랜치 삭제는 캠페인의 책임입니다. 정리에는 다음이 포함됩니다:

• 종료되지 않은 보류 중인 자식 세션 확인 및 종료.
• 사용된 모든 작업 트리 정리.
• 관련 브랜치 및 이슈 보관.
• 캠페인 완료 표시.
• 최종 보고서 생성.

캠페인 정리 중에는 새 이슈를 시작하지 마세요. 모든 작업이 완료되었는지 확인하고, 완료되지 않은 경우 사용자에게 알리세요.

모범 사례 (Best Practices)

• 항상 get_campaign을 사용하여 캠페인 상태를 확인하고, 캐시된 정보에 의존하지 마세요.
• 자식 세션이 독립적으로 작동할 수 있도록 충분한 컨텍스트를 제공하세요.
• 자식 세션의 진행 상황을 정기적으로 확인하고, 필요한 경우 개입하세요.
• 모든 결정과 이유를 원장에 기록하여 투명성을 유지하세요.
• 사용자에게 명시적인 권한이 없는 한, 자식 세션을 대신하여 결정을 내리지 마세요.
• 보안과 무결성을 유지하기 위해 모든 게이트와 검사를 존중하세요.