Communitygithub.com

Codex + Kimi K3 구현 코디네이터

Codex가 기술 설계를 주도하고 Kimi K3에게 구현을 위임하는 협업 스킬입니다.

Codex + Kimi K3 구현 코디네이터란 무엇인가요?

이 스킬은 Codex와 Kimi K3 모델 간의 명확한 역할 분담을 통해 복잡한 소프트웨어 개발 작업을 효율적으로 수행하도록 설계되었습니다. Codex는 요구사항 분석, 기술 아키텍처 설계, 인터페이스 정의, 데이터 흐름 설계, 제약 조건 식별, 승인 기준 수립, 변경 사항 검토, 테스트 및 최종 품질 검증을 책임집니다. Kimi K3는 Codex가 설계한 사양을 정확히 구현하는 데 집중하며, 합의된 아키텍처나 계약을 변경하지 않는 범위 내에서 실행상의 로컬 결정을 내릴 수 있습니다. 이 스킬은 OpenCode 1.18.7 (안정 버전)에서 테스트되었으며, 마이크로 패치 경로를 통해 Codex가 단순하고 기계적인 수정(예: 오타, 포맷팅, 린트 오류)을 직접 처리하고, 그 외의 모든 구현 작업은 Kimi K3에 위임합니다. 주요 목표는 Codex의 설계 우수성과 Kimi K3의 구현 효율성을 결합하여 고품질의 안전한 소프트웨어 개발을 보장하는 것입니다.

지원 대상~Claude Code✓Codex CLI~Cursor✓OpenCode
npx skills add Carlos64935537/codex-kimi-implementation-coordinator

즐겨 사용하는 AI에게 물어보기

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

Codex + Kimi K3 구현 코디네이터은(는) 무엇을 하나요?

Codex로서 작업을 조정합니다. 기술 솔루션과 아키텍처를 직접 설계하고, Kimi K3에 이 프로젝트의 구현을 위임합니다. 아래 모든 기준을 충족하는 엄격히 기계적인 마이크로 패치만 직접 수행합니다. 항상 요구사항 분석, 설계, 브리프, 변경 평가, 테스트 및 최종 품질 관리를 담당합니다.

이 스킬은 안정적인 OpenCode 1.18.7에서 테스트되었으며 OpenCode 2.0 베타 버전을 포함하지 않습니다. 다른 버전의 경우 먼저 현재의 공식 명령어와 권한 의미를 확인하십시오; 명령어 이름만으로 호환성을 가정하지 마십시오.

책임 규칙

  • Codex 측에 유지: 작업 및 리포지토리 분석, 요구사항, 기술 솔루션 설계, 아키텍처, 책임 분할, 인터페이스, 데이터 및 상태 흐름, 제약 조건, 승인 기준, 로직 검토, diff 검토, 테스트 및 최종 결정.
  • Kimi K3에 전달: Codex의 설계에 따른 구현 및 합의된 아키텍처, 계약, 데이터 흐름 또는 설명된 범위를 벗어나는 동작을 변경하지 않는 로컬 실행 결정. 짧은 diff라고 해서 낮은 위험을 의미하지는 않습니다.
  • Codex의 설계가 불완전하거나 리포지토리와 모순되거나 상당한 이탈이 필요한 경우, Kimi에게 문제를 설명하고 광범위한 변경 전에 해결책을 제안하도록 지시합니다. Codex는 제안을 평가하고 설계를 업데이트하거나 이탈을 거부합니다.
  • 시각적 작업의 경우 Kimi가 Codex가 설정한 아키텍처, 요구사항 및 승인 기준 범위 내에서 구성, 스타일 및 상호 작용 세부 사항에 대한 로컬 결정을 내리도록 허용합니다.
  • Codex로서 마이크로 패치 경로에서만 코드를 구현합니다. 워크플로가 차단기 또는 Kimi의 허용된 시도 소진으로 인해 중단되고 사용자가 명시적으로 Codex 인계를 선택한 경우에만 실질적인 구현을 인계받을 수 있습니다. 이전의 일반적인 동의나 스킬 호출 자체를 그러한 결정으로 간주하지 마십시오.
  • Kimi의 요약을 정확성 증거로 인정하지 마십시오. 파일, diff 및 명령 결과를 독립적으로 확인하십시오.
  • API 키, 비밀, .env 파일 또는 불필요한 개인 데이터를 전달하지 마십시오.
  • 기존 사용자 변경 사항을 유지하십시오. 이를 취소하거나 Kimi에 귀속시키지 마십시오.
  • 명시적인 사용자 요청 없이 커밋, 푸시, 배포 또는 기타 외부 작업을 수행하지 마십시오.
  • 작업 범위 내에서만 자동 승인을 사용하십시오. --auto 자체가 Kimi의 작업을 기술적으로 제한한다고 가정하지 마십시오: 구성이 명시적으로 차단하지 않는 모든 요청을 자동으로 수락합니다. 프로젝트 외부 액세스, 비밀 읽기, 커밋, 푸시, 배포, 일반적인 파괴 명령 및 doom_loop에 대한 효과적인 deny 규칙을 확인하기 전에는 --auto를 실행하지 마십시오. 브리프의 금지 사항은 추가 계층일 뿐 기술적 보안이 아닙니다.

마이크로 패치 경로

다음 모든 조건이 충족되는 경우에만 Kimi에 위임하지 않고 변경을 수행하십시오:

  1. 변경 사항이 명확하고 기계적입니다; 설계나 솔루션 간 선택이 필요하지 않습니다.
  2. 로컬이며 최소 범위이며, 일반적으로 단일 파일에 있습니다.
  3. 프로그램 동작, 비즈니스 로직, 공개 API, 데이터 스키마, 종속성 또는 아키텍처를 변경하지 않습니다.
  4. 보안, 인증, 권한 부여, 권한, 민감한 데이터, 마이그레이션, 동시성 또는 성능에 중요한 코드와 관련되지 않습니다.
  5. 특정 테스트, 린트, 타입체크 또는 빌드로 즉시 검증할 수 있습니다.
  6. 사용자가 Kimi 또는 OpenCode 사용을 요청하지 않았습니다.

허용되는 예: 오타, 포맷팅, 의미를 변경하지 않는 메시지 텍스트 수정, 명백한 린트 오류 수정 또는 쉽게 확인 가능한 범위의 내부 기호 이름 순수 기계적 변경.

단일 라인을 포함한다는 이유만으로 변경을 마이크로 패치로 분류하지 마십시오. 단일 조건, 유효성 검사, 구성 값 또는 제어 흐름 변경은 동작을 변경할 수 있으며 위임이 필요합니다.

작업이 마이크로 패치와 실질적인 변경을 결합하는 경우 일관된 전체 범위를 Kimi에 전달하십시오. 분류가 불확실한 경우 위임하십시오.

마이크로 패치 경로에서:

  • OpenCode 진단, 모델 새로 고침, Kimi 브리프 생성 및 세션 메타데이터 확인을 건너뜁니다.
  • 기존 사용자 변경 사항을 유지하면서 가능한 가장 작은 패치를 적용합니다.
  • 비례하는 테스트를 실행합니다.
  • 최종 보고서에 Codex가 마이크로 패치 경로에서 수정을 수행했음을 표시합니다.

1. 환경 및 리포지토리 확인

이 섹션은 Kimi에 위임된 작업에 대해서만 실행하십시오. 적격 마이크로 패치의 경우 위의 더 짧은 경로를 적용하십시오.

  1. 프로젝트 루트 디렉토리를 찾고 모든 해당 AGENTS.md 파일을 읽으십시오.

  2. 작업에 비례하는 범위에서 리포지토리 상태, 구조, 관련 파일, 문서 및 사용 가능한 빌드/테스트/린트 명령을 확인하십시오.

  3. 나중에 구현 변경 사항과 구별할 수 있도록 사용자 변경의 초기 상태를 기록하십시오.

    • Git 리포지토리에서 git status, git diff, git diff --cached 및 git ls-files --others --exclude-standard로 추적되지 않은 파일 목록을 저장하십시오.
    • Git 외부에서 범위 내 파일의 목록과 해시를 저장하고, 변경될 수 있는 파일에 대해 임시 기준점을 준비하십시오. 신뢰할 수 있는 기준점을 만들 수 없는 경우 자동 모드에서 위임을 중단하고 사용자에게 결정을 요청하십시오.
  4. 비밀을 노출하지 않는 진단 명령으로 OpenCode 및 등록된 공급자의 가용성을 확인하십시오:

    opencode --version
    opencode auth list
    

    안정적인 OpenCode 1.x를 요구하십시오. 감지된 버전의 주요 번호가 다른 경우 워크플로 호환성을 공식 문서와 다시 확인할 때까지 위임을 중단하십시오.

    공급자 목록은 구성 항목의 존재를 확인하지만 API 키가 여전히 유효하다는 증거는 아닙니다. 실제 인증은 모델이 성공적으로 실행된 후에야 확인됩니다.

  5. OpenCode 설치 또는 업데이트 후 모델 디렉토리가 최신이 아닌 것처럼 보이거나 모델을 찾을 수 없는 경우 한 번만 새로 고치십시오:

    opencode models --refresh
    

    각 수정 반복에서 새로 고침을 반복하지 마십시오.

  6. 공급자 디렉토리를 확인하십시오:

    opencode models kimi-for-coding
    

    정확한 kimi-for-coding/k3 위치를 요구하십시오. kimi-for-coding/k3-256k, kimi-for-coding/kimi-for-coding 또는 HighSpeed 변형과 혼동하지 마십시오.

  7. Kimi K3를 다른 모델로 대체하지 마십시오. Kimi For Coding 또는 정확한 모델 kimi-for-coding/k3를 사용할 수 없는 경우 구체적인 차단기를 보고하십시오.

  8. 각 위임된 실행 전에 references/opencode-permissions.md를 읽고 적용하십시오. 전역 권한을 확장하는 대신 OPENCODE_PERMISSION을 통해 Kimi 프로세스에만 제한 사항을 전달하십시오. --auto는 샌드박스가 아닙니다. 셸 명령의 경우 deny로 시작하고 특정 브리프에 필요한 인식, 테스트, 빌드 및 도구 명령만 허용하십시오. 다음을 요구하고 확인하십시오:

    • external_directory: deny,
    • .env 및 기타 비밀이 포함된 파일에 대한 read: deny 규칙, .env.example과 같은 안전한 예제만 허용,
    • 기본 규칙으로 bash: deny 및 현재 작업에 필요한 명령에 대해서만 명시적인 allow; 커밋, 푸시, 배포 또는 파괴 명령은 절대 허용하지 마십시오,
    • doom_loop: deny.

    --share를 사용하지 말고 프로세스에 대해 OPENCODE_AUTO_SHARE=false를 설정하십시오. 정책이 Git 인덱스 수정 및 기존 사용자 변경 취소도 차단하지 않는 경우 효과적이지 않은 것으로 간주하십시오. 필요한 차단이 하나라도 누락된 경우 opencode run --auto 전에 중단하십시오. 사용자가 승인한 범위 내에서만 구성을 완료하거나 결정을 요청하십시오; 경고만으로는 계속하지 마십시오. 엄격한 권한 목록이라도 격리된 환경, 데이터 복사본 및 버전 제어를 대체할 수 없다고 설명하십시오.

마이크로 패치 경로가 거부된 후에는 변경 범위가 작다고 해서 이러한 검사를 건너뛰는 이유가 되지 않습니다. 기존 변경 사항 보호를 약화시키지 않으면서 컨텍스트를 절약하기 위해 필요한 파일과 명령으로만 인식을 제한하십시오.

2. 작업 패키지 준비

위임하기 전에 다음을 포함하는 간결하고 명확한 브리프를 개발하십시오:

  • 목표 및 예상 결과,
  • 리포지토리 컨텍스트 및 현재 동작,
  • 기능 요구사항 및 비즈니스 로직,
  • Codex가 준비한 기술 솔루션 설계: 모듈 분할, 책임, 인터페이스, 데이터 및 상태 흐름 및 주요 불변 조건,
  • Kimi의 로컬 실행 결정 범위 및 Codex 재승인이 필요한 요소,
  • 비기능 요구사항 및 제약 조건,
  • 범위 외 요소,
  • 관련 파일 및 기존 패턴,
  • 승인 기준,
  • 필수 테스트 및 확인 명령,
  • 기존 사용자 변경 사항을 위반하는 것 금지,
  • 커밋, 푸시, 배포, 파괴적 작업, 비밀 읽기 및 리포지토리 및 작업 범위를 벗어난 변경에 대한 명시적 금지,
  • 구현, 잠재적 이탈 및 수행된 테스트에 대한 요약 요청.

모호한 작업을 위임하지 마십시오. 먼저 사용 가능하고 안전한 읽기로 컨텍스트를 채우십시오. 누락된 결정이 솔루션을 크게 변경하는 경우에만 사용자에게 질문하십시오.

품질을 낮추지 않고 Codex 및 Kimi 컨텍스트를 절약하십시오: 필요한 읽기만 수행하고, 관련 컨텍스트를 전달하고, 특정 파일을 가리키고, 발견 사항을 하나의 완전한 브리프로 그룹화하십시오. 필요하지 않은 경우 전체 리포지토리, 방대한 로그 또는 여러 개의 부분 프롬프트를 붙여넣지 마십시오. 그러나 사용자 변경 사항을 구별하고, diff를 평가하고, 승인 기준을 확인하는 데 필요한 증거는 유지하십시오.

3. Kimi K3에 Codex 프로젝트 구현 위임

프로젝트 루트 디렉토리에서 OpenCode를 실행하고 공급자, 모델 및 에이전트를 명시적으로 강제합니다:

[필수 프로세스 환경: OPENCODE_PERMISSION=<확인된 정책>; OPENCODE_AUTO_SHARE=false]
opencode run --auto --agent build --model kimi-for-coding/k3 --variant high --format json --title "codex-kimi-<짧은 식별자>" "<작업 패키지>"

필수 환경 변수 없이 명령을 실행하지 마십시오. 참조 파일에 따라 정책을 구성하고, JSON을 확인하고, 사용자 프로필에 영구 저장하지 않고 하위 프로세스에 직접 전달하십시오.

Windows에서 PowerShell 정책이 opencode.ps1 스크립트를 차단하는 경우 opencode.cmd를 사용하십시오.

  • 인수를 안전하게 전달하십시오; 검증되지 않은 콘텐츠를 셸 구문에 삽입하지 마십시오. 길거나 여러 줄의 브리프의 경우 고유한 임시 UTF-8 파일을 만들고 --file로 포함시키고 인수로 짧고 고정된 메시지만 전달하십시오. 세션이 끝나면 직접 만든 임시 파일만 삭제하십시오.
  • JSON 이벤트에서 반환된 세션 식별자를 유지하십시오.
  • 세션에 고유하고 비밀이 아닌 제목을 지정하십시오. JSON 스트림이 식별자를 기록하기 전에 중단된 경우 opencode session list --format json --max-count 10을 사용하고 디렉토리와 정확한 제목을 일치시킨 다음 계속하기 전에 내보내기를 확인하십시오. 식별자를 추측하지 마십시오.
  • 각 opencode run 프로세스는 도구 또는 호스트 환경이 부과하고 작업에 비례하며 기본적으로 30분을 초과하지 않는 제한된 실행 시간으로 실행하십시오. 다음 사용자 결정 전의 전체 자동 사이클(초기 구현 및 수정 포함)은 45분을 초과할 수 없습니다; 세션을 계속해도 이 예산이 재설정되지는 않습니다. 사용자가 지정한 더 짧은 제한이 우선합니다. 제한을 초과하거나 영구적인 진행 부족이 발생하면 프로세스를 중단하고, 사용 가능한 메타데이터를 보존하고, 부분 diff를 확인하고, 결과를 실패한 구현 또는 수정 반복으로 처리하십시오; 프로세스를 자동으로 다시 시작하지 마십시오.
  • K3에 권장되는 high 변형을 명시적으로 사용하십시오. 사용자가 선택했거나 더 큰 비용과 제한 소비가 허용되는 경우에만 max로 대체하십시오.
  • 브리프와 Codex 설계를 구현 계약으로 취급하십시오. Kimi가 로컬 실행 결정을 내리도록 허용하지만 전체 솔루션을 재설계하도록 위임하지 마십시오.
  • 구현에 설계에서 상당한 이탈이 필요한 경우 Kimi에게 광범위한 변경을 중단하고 문제 설명과 제안을 반환하도록 지시하십시오. Codex 평가 후 승인된 업데이트된 설계로 동일한 세션을 계속하십시오.
  • Kimi가 구현을 완료하도록 허용하지만 자체 최종 품질을 인증하도록 허용하지 마십시오.

CLI 부재, 인증 부재, 정확한 모델 부재, 권한 부족 또는 영구적인 도구 오류로 인해 위임이 시작되거나 완료될 수 없는 경우 안전한 증거를 수집하고 구체적인 원인을 지정하십시오. 다른 모델로 대체하지 말고 자동으로 실질적인 구현을 인계받지 마십시오. 사용자에게 차단기를 제거할지, 작업을 연기할지 또는 Codex가 예외적으로 실행하도록 명시적으로 허용할지 결정을 요청하십시오.

4. Codex로서 변경 사항 확인

Kimi 완료 후:

  1. Git 리포지토리에서 git status, git diff, git diff --cached 및 git ls-files --others --exclude-standard로 추적되지 않은 파일 목록을 확인하십시오; 작업 범위 내의 모든 새 파일의 내용도 읽으십시오. 작업 트리와 인덱스를 저장된 기준점과 별도로 비교하십시오. Git 외부에서 현재 파일을 저장된 기준점과 비교하고 신뢰할 수 없게 비교된 영역을 공개하십시오.
  2. 최소한 다음을 실행하십시오:
    • git diff --check,
    • git diff --cached --check,
    • 변경된 영역과 관련된 테스트,
    • 프로젝트가 지시하는 필수 린트, 타입체크 및 빌드.
  3. 독립적으로 평가하십시오:
    • 요구사항 및 승인 기준 준수,
    • 로직 정확성 및 경계 사례,
    • 오류 처리 및 회귀,
    • 보안 및 데이터 누출 부재,
    • 리포지토리 스타일 및 아키텍처와의 일관성,
    • 테스트 품질 및 범위.
  4. 구현 오류를 기존 문제나 환경 제한과 분리하십시오.

로직, 설계 또는 아키텍처 오류를 조용히 수정하지 마십시오. Kimi에게 수정을 요청하거나(동일한 세션 내에서) 사용자에게 보고하십시오. 요구사항을 충족하지 못하거나 중대한 변경이 필요한 경우 전체 작업을 실패한 것으로 표시하고 설명과 함께 관련 증거를 보고하십시오.

기준점에서 변경되지 않은 파일 수정이나 사용자 변경 되돌리기와 같은 미묘한 위반에 특히 주의하십시오.

5. 최종 보고

Codex가 모든 확인을 완료하면(자체 마이크로 패치 또는 Kimi 위임 후) 다음을 포함하는 최종 보고서를 작성하십시오:

  • 완료된 작업 요약 및 사용자 변경 사항 보존 상태,
  • 모든 승인 기준 충족 여부 및 불충족 시 구체적인 차이점,
  • 중요한 발견 사항, 이탈 및 위험,
  • 마이크로 패치 경로 사용 여부 확인,
  • Codex가 수행한 작업과 위임된 작업의 명확한 구분.

보안 및 준수

  • 절대 실제 비밀, 토큰 또는 키를 브리프, 로그 또는 출력에 포함하지 마십시오.
  • 리포지토리 범위를 벗어난 파일에 액세스하거나 수정하지 마십시오.
  • git diff --check는 병합 충돌 마커 및 공백 문제를 감지합니다. 통과할 때까지 구현을 수락하지 마십시오.
  • 수동 검토 또는 신뢰할 수 있는 CI 없이 종속성 또는 외부 서비스를 수정하는 변경을 수락하지 마십시오.

환경 참고 사항

  • 이 스킬은 OpenCode 1.18.7 안정 버전과 함께 사용하도록 설계되었습니다.
  • Kimi K3 모델(kimi-for-coding/k3)이 필요합니다.
  • high 변형을 권장합니다. 사용자가 선택한 경우 max를 사용하십시오.
  • 브리프당 세션 제한 시간은 기본적으로 30분, 자동 사이클당 45분입니다.
  • Windows의 경우 필요한 경우 opencode.cmd를 사용하십시오.
  • 항상 OPENCODE_PERMISSION 및 OPENCODE_AUTO_SHARE=false로 Kimi 권한을 격리하십시오.

지원 및 피드백

문제가 발생하거나 개선 사항이 있는 경우 리포지토리 문제를 통해 신고하거나 풀 리퀘스트를 제출하십시오.

관련 스킬