oil-oil/codex-team-mode

팀 모드

메인 스레드에서 작업을 주도하세요. 잡음이 많은 작업을 격리하고, 비용이 많이 드는 메인 에이전트 컨텍스트를 줄이며, 독립적인 작업을 병렬로 실행하거나 새로운 검토를 얻기 위해 가장 작고 유용한 하위 에이전트 세트를 사용하세요. 역할을 필수 파이프라인으로 전환하지 마십시오.

디스패치 게이트

모든 spawn_agent 호출은 반드시 agent_type을 Explorer, Executor, Complex Executor, 또는 Reviewer 중 정확히 하나로 명시적으로 전달해야 합니다.

• 절대 agent_type을 생략하거나 default를 전달하지 마십시오. default 프로필은 실패 시 폐쇄되는 디스패치 가드이지 작동하는 에이전트가 아닙니다.
• 프로필을 선택하기 위해 task_name을 절대 사용하지 마십시오. 이는 단지 하위 스레드에 레이블을 붙일 뿐입니다.
• 의도한 맞춤 프로필을 사용할 수 없는 경우, 메인 스레드에서 작업을 유지하거나 프로필을 수리하십시오. 묵시적으로 일반 하위 에이전트를 사용하지 마십시오.
• 하위 에이전트가 디스패치-가드 메시지를 반환하거나 그 추적에 default / subagent/unknown이 표시되는 경우, 해당 출력을 거부하고 의도한 맞춤 프로필을 명시적으로 선택한 후에만 다시 생성하십시오.

references/custom-agents.md는 네 가지 작업 프로필과 default 가드를 설치, 수리 또는 확인할 때에만 읽으십시오. 거기에 설명된 통제된 온보딩 자체 테스트는 팀 모드가 의도적으로 agent_type을 생략하는 유일한 경우입니다.

일회성 온보딩

일반 팀 모드 라우팅 중에는 에이전트 파일을 검사하거나, 온보딩 지침을 로드하거나, 설정 설명을 반복하지 마십시오. 활성화된 spawn_agent.agent_type 선택과 설명을 런타임 준비 증거로 취급하십시오. 네 가지 작업 프로필을 모두 사용할 수 있고 default가 디스패치 가드로 설명되는 경우, 언급하지 않고 온보딩을 건너뛰십시오.

필요한 프로필이나 가드를 사용할 수 없거나, 사용자가 명시적으로 설치, 수리, 확인, 이동, 비활성화 또는 사용자 정의를 요청하는 경우에만 references/custom-agents.md를 읽고 온보딩을 시작하십시오. 개인 또는 프로젝트 구성을 작성하기 전에 승인을 받으십시오. 성공적인 설정 또는 수리 후, 사용자에게 한 번 설치된 내용, 할당된 모델, 가드가 설치 범위 내에서 생략/기본 하위 에이전트 디스패치에 미치는 영향, 재시작 또는 새 작업이 필요한 시점, 네 가지 작업 프로필을 제거하지 않고 가드만 비활성화하거나 복원하는 방법을 알려주십시오.

필수 규칙

• 이 스킬이 활성화되면, 즉시 사용자 언어로 👾 접두사가 붙은 간략한 설명 업데이트를 하나 보내십시오. 한국어의 경우 👾 팀 모드를 시작합니다.라고 말하십시오. 다른 언어는 자연스럽게 번역하십시오. 작업당 한 번만 알리고, 모든 하위 에이전트 호출 전에 알리지 마십시오.
• 팀 모드를 활성화한다고 해서 반드시 하위 에이전트를 생성해야 하는 것은 아닙니다. 위임이나 독립적 검토가 비용 대비 이점이 없을 때는 명확하고, 짧고, 위험이 낮은 작업을 메인 스레드에 유지하십시오. 역할 순서를 채우기 위해 단순히 Executor나 Reviewer를 실행하지 마십시오.
• 각 생성 전에 유용한 병렬 처리, 컨텍스트 격리, 저비용 제한 실행, 또는 독립적 판단 중 하나의 실질적인 이점을 식별하십시오. 브리핑, 검사, 재작업 및 대기 시간을 조정 비용으로 계산하십시오. 명시적인 팀 모드 요청은 이 라우팅 가이드를 활성화하지만, 그 자체로 생성을 가치 있게 만들지는 않습니다.
• 모든 라우팅과 팬아웃은 메인 스레드에서 유지하십시오. 표준 팀 모드에서 하위 에이전트는 절대 하위 항목을 생성하지 않습니다. 증거, 산출물 또는 차단 요인을 상위 항목에 반환합니다. 재귀적 위임에 대한 명시적인 사용자 요청은 자체 권한, 깊이 및 사용 결정이 있는 별도의 범위 확장으로 취급하십시오.
• 기본적으로 그리고 새로운 Reviewer에게는 항상 fork_turns="none"을 사용하십시오.
• 해결되지 않은 사용자 의도, 제품, 편집, 아키텍처 및 안전 결정은 물론 최종 승인을 메인 스레드에 유지하십시오.
• 공유 산출물, 작업 트리 또는 변경 가능한 시스템 당 하나의 작성자를 유지하십시오. 병렬 작성자는 격리된 대상 또는 분리되고 안정적인 소유권이 필요합니다.
• 위임된 작업을 수락하기 전에 실제 산출물, 소스, diff 및 검증 출력을 검사하십시오.
• 하위 에이전트가 오류, 시간 초과 또는 중단되면 공유 산출물과 추적 증거를 검사한 후 재시도하십시오. 일시적 실패는 최대 한 번, 그리고 사용 가능한 결과가 없는 경우에만 재시도하십시오. 그렇지 않으면 메인 스레드에서 복구하거나 나머지 작업 범위를 재조정하십시오.
• 상위 작업의 실시간 권한 모드를 효과적인 하위 권한으로 취급하십시오. TOML만으로 읽기 전용 격리를 유추하지 마십시오. 권한 확인이 필요할 때는 참조의 온보딩 또는 진단 확인을 사용하십시오.

사용자가 팀 모드 자체를 평가하거나, 모델 또는 추론 노력을 비교하거나, 위임이 가치 있었는지 측정하도록 요청하는 경우, 시험을 설계하기 전에 references/evaluation.md를 읽으십시오.

디스패치 계약

모든 생성 전에 다음 레이블이 지정된 필드를 사용하여 브리핑을 간결하게 만드십시오:

• Outcome: 하위 에이전트가 반환해야 하는 독립적으로 완료 가능한 결과.
• Benefit: 이 부분을 메인 스레드에 유지하는 것보다 얻을 수 있는 실질적인 이점.
• Sources: 사실 작업에 필요한 모든 경로, URL, 데이터세트 또는 원시 산출물.
• Scope: 허용된 읽기 또는 쓰기, 소유권, 제외 사항 및 외부 작업 권한.
• Checks: 하위 에이전트가 책임지는 수락 기준 및 검증.
• Stop when: 턴을 종료하는 제한된 완료, 차단 요인 또는 증거 임계값.
• Return: 상위 에이전트가 기대하는 간결한 보고서 또는 산출물 형식.

Outcome, Benefit, 필요한 Sources, Checks 또는 Stop when이 누락된 상태에서 생성하지 마십시오. 독립적으로 완료할 수 없거나 예상 이득이 브리핑, 대기, 검사 및 가능한 재작업 비용을 초과하지 않는 경우 해당 부분을 메인 스레드에 유지하십시오.

Reviewer의 경우, 또한 하나의 구체적인 Unresolved risk, 검사할 정확한 Evidence, Checks already passed, 그리고 Do not repeat을 명시하십시오. 먼저 해당 패킷에서 결과를 요청하고, 중지 조건이 완전한 검토 이전에 도달하는 경우 사용 가능한 부분 판정을 요구하십시오.

작업 라우팅

• Explorer(Luna Medium): 중요하고 읽기 전용인 발견 작업에 사용하십시오. 개별 Explorer에게 독립적인 증거 조각을 제공하고 메인 스레드에서 해당 작업을 반복하지 마십시오.
• Executor(Luna High): 명확하고, 제한적이며, 위험이 낮고, 결정론적 검사가 있는 작업에 사용하십시오. 인계 비용이 직접 수행하는 것보다 더 많이 드는 경우 메인 스레드에서 작업을 유지하십시오.
• Complex Executor(Terra High): 메인 스레드가 아키텍처, 범위 및 검사를 고정한 후에 실질적인 일반 구현에 사용하십시오. 메인 스레드는 여전히 결과를 검사하고 수락합니다.
• 메인 스레드: 새로운 아키텍처, 취약하거나 시각적인 검증, 내보내기/컴파일러 설계, 보안 또는 롤백 판단이 필요하거나, 그럴듯한 거짓 성공 비용이 큰 경우 중요한 부분을 유지하십시오.
• Reviewer(Sol High): 신선하고 독립적인 판단이 필요한 하나의 구체적인 해결되지 않은 위험에 대해서만 사용하십시오. 검토를 자동적인 두 번째 패스로 만들지 마십시오.

발견 후, 메인 스레드가 직접 계속할지 또는 위임할지 선택하도록 하십시오. 제한된 실행, 컨텍스트 격리, 저비용, 유용한 병렬 처리 또는 독립적 판단이 명확한 가치를 창출하는 경우에만 위임하십시오.

작업 조정

• 최소한의 유용한 에이전트 수로 시작하십시오. 진정으로 독립적인 탐색, 분석, 테스트, 분류, 프로덕션 또는 검토만 병렬화하십시오. 단순히 에이전트를 바쁘게 유지하기 위해 중복 작업을 만들지 마십시오.
• 실행 전에 결과가 무엇이어야 하는지, 무엇을 건드릴 수 있는지, 무엇이 변경되지 않은 상태로 유지되어야 하는지, 완료가 어떻게 확인될 것인지 명확히 밝히십시오. 새로운 증거가 이러한 요구 사항과 충돌하는 경우 수정하십시오.
• 위험에 비례하여 검증하십시오. 모든 작업이 아니라 복잡하고, 중요하며, 확인하기 어려운 결과에 대해 독립적 검토를 사용하십시오.
• 통과된 검사를 증거로 재사용하십시오. 해당 검사의 무결성 또는 관련성 자체가 해결되지 않은 위험이 아닌 한, 다른 에이전트에게 광범위한 검증을 반복하도록 요청하지 마십시오.

컨텍스트 및 재사용

• 각각의 새로운 하위 에이전트에게 목표, 관련 소스 또는 경로, 범위, 권한, 제외 사항, 의도된 결과, 필요한 검사 및 반환 형식만 포함하는 간결하고 자체 포함된 브리핑을 제공하십시오. 절대 자격 증명을 복사하지 마십시오.
• fork_turns="none"을 사용하면 하위 에이전트가 상위 대화에서 아무것도 모른다고 가정하십시오. 사실적 주장에 필요한 모든 소스 산출물의 이름을 지정하십시오. 소스가 누락된 경우, 해당 경로를 제공하거나, 하위 에이전트를 해당 증거 수집으로 좁히거나, 소스 종속 부분을 메인 스레드에 유지하십시오.
• 새로운 작업이 동일한 작업, 주제, 비즈니스 영역, 하위 시스템, 산출물 또는 작업 스트림에 속하고 이전 컨텍스트가 여전히 유용한 경우 기존 Explorer 또는 Executor를 재사용하십시오. 새로운 목표와 변경된 제약 조건만 보내십시오.
• 이전 컨텍스트가 오래되었거나 잡음이 많거나, 역할 또는 권한이 변경되거나, 독립적 판단이 중요한 경우 새로 시작하십시오.
• Reviewer는 기존 보고서를 명확히 하기 위해서만 재사용하십시오. 새로운 검토 또는 수정된 작업 확인에는 새로운 Reviewer를 사용하십시오.
• Explorer에게 예상 결론을 제시하지 마십시오. Reviewer에게 이전 논쟁, 작성자, 의심되는 결과 또는 원하는 판정을 말하지 마십시오.

결과 처리

• 행동하기 전에 결과를 기본 소스, 산출물 및 의도된 결과에 대해 검증하십시오.
• 메인 스레드가 수락된 수정을 직접 적용하거나 범위, 컨텍스트, 비용 및 위험에 따라 위임하도록 하십시오.
• 위험 평가 결과에 따라 중요한 수정 후 독립적 검토가 필요할 경우, 업데이트된 산출물과 중립적 요구 사항만으로 새로운 Reviewer를 사용하십시오.
• Reviewer가 사용 가능한 반환 없이 Stop when 조건에 도달하면, 부분 판정을 한 번 요청한 후 중단하십시오. 추적 및 기존 증거를 검사하십시오. 자동으로 다른 Reviewer를 시작하지 마십시오.

로컬 사용량 검사

사용자가 모델 또는 하위 에이전트 소비량을 물을 때는 python3 scripts/usage_by_model.py를 실행하십시오. 활성 작업에는 --task-id current --by-agent --by-session을 사용하고, 더 넓은 기록에는 --days N 또는 --all을 사용하십시오. 구조화된 출력이 도움이 될 때는 --json을 사용하십시오. 처리된 토큰과 캐시되지 않은 입력, 캐시된 입력, 출력, 추론 출력 및 예상 크레딧을 보고하십시오. 크레딧 뒤에 토큰 합계를 숨기지 마십시오. 추론을 출력의 하위 집합으로, 처리된 토큰을 입력 + 출력으로 취급하여 캐시되거나 추론된 토큰이 이중으로 계산되지 않도록 하십시오. 보편적인 크레딧-토큰 변환을 제시하지 마십시오. 각 모델과 토큰 유형마다 요율이 다르기 때문에 번들된 요금 카드를 사용하고, 관찰된 처리된 토큰 당 크레딧 값을 워크로드별로 레이블을 지정하십시오. 이는 정상적인 라우팅의 일부가 아닌 온디맨드 진단입니다. 로컬 로그는 일시적이거나 사용할 수 없는 원격 세션을 제외하며, 설정된 크레딧은 표준 속도를 가정하고, 계정 한도에 대해서는 Codex /usage가 권위적이라고 보고하십시오.

안전장치

• 관련 없는 사용자 작업을 보존하고 적용 가능한 프로젝트, 도메인 및 도구 지침을 준수하십시오.
• 위임은 권한을 확장하지 않습니다. 사용자의 요청을 넘어 커밋, 게시, 배포, 메시지 전송, 외부 상태 변경 또는 민감한 데이터 처리를 하지 마십시오.
• 현재 또는 사실적 연구의 경우, 기본 소스를 선호하고, 관련 날짜를 기록하며, 증거를 인용하고, 사실과 추론을 구별하십시오.
• 개인 데이터 탐색은 좁게 유지하고 필요한 최소 증거만 반환하십시오.
• 가장 강력한 사용 가능한 증거를 바탕으로 상충되는 주장을 해결하고 사용자에게 하나의 일관된 결과를 반환하십시오.