Kimi Delegate

Quando Usar

• Você quer delegar uma tarefa de codificação limitada a um kimi implementador separado (Kimi Code) e depois revisar o diff dele.
• O usuário pediu explicitamente a delegação para este implementador.

Você é o orquestrador. Entregue uma tarefa de codificação limitada a um implementador separado - o Kimi Code CLI - depois revise o que ele produziu e aplique as mudanças você mesmo. Você escreve o briefing e toma o julgamento; o Kimi digita em sua própria sessão; você verifica e commita.

O loop precisa apenas de um comando de shell e acesso a arquivos, então qualquer orquestrador comparável pode controlá-lo.

Quando NÃO Usar

• A tarefa é pequena o suficiente para ser feita diretamente; o overhead da delegação não vale a pena.
• O CLI kimi não está instalado ou autenticado.
• Você precisa de um implementador somente leitura imposto pelo CLI. O Kimi Headless não tem modo somente leitura.

Pré-requisitos (verificar uma vez)

1. Instale o Kimi Code com brew install kimi-code no macOS/Linux, ou use o instalador nativo da documentação oficial do Kimi Code.
2. Autentique-se com kimi login (fluxo de código de dispositivo, sem TUI), ou use /login na TUI.
3. Confirme que kimi --version foi bem-sucedido.
4. Trabalhe em, ou aponte --cd para, o repositório git alvo.

Escolher o alias do modelo

O Kimi usa default_model de sua config.toml quando --model é omitido. Para escolher outro alias de modelo, passe --model <alias from your kimi config>. Aliases de modelo são chaves de configuração definidas pelo usuário; use uma que o humano configurou em vez de inventar uma.

O loop

Execute estas cinco etapas por tarefa. As etapas 1, 4 e 5 exigem julgamento; 2 e 3 são mecânicas.

1. Escreva o briefing

O Kimi vê apenas o texto que você envia mais o que ele pode inspecionar no workspace - sem histórico de chat ou contexto compartilhado. Inclua o objetivo, o estado atual, o que mudar, o que deixar intocado, os portões reais do projeto e um contrato de relatório. Diga ao Kimi para não commitar. Mantenha uma tarefa por briefing. Veja references/writing-the-brief.md.

2. Despachar

Use o helper incluso. Ele envolve o modo de prompt headless do Kimi, captura o fluxo de eventos estruturado e escreve result.json. (<skill-dir> é a pasta instalada contendo este SKILL.md.)

node "<skill-dir>/scripts/relay.mjs" --brief brief.txt --cd /path/to/repo
# choose a configured model alias:       add --model <alias from your kimi config>
# resume the most recent session:        add --resume-last  (delta brief only)
# resume a specific session:             add --session <id> (delta brief only)
# hard time limit (watchdog):            add --timeout 2h  (the 30m default suits short runs; implementation briefs routinely need 1-2h)
# see all options:                       node .../relay.mjs --help

O cwd do processo filho fixa o workspace. Use flags repetíveis de --add-dir apenas para diretórios de workspace extras. O relay escreve artefatos sob o diretório temporário do sistema por padrão e nunca commita. Veja references/dispatch-and-poll.md.

3. Aguardar a conclusão

O helper bloqueia até que o Kimi termine. Execute-o com a instalação de comando em segundo plano do orquestrador, ou coloque-o em segundo plano no shell e verifique result.json. Um erro de uso pré-execução sai com código 2 e não escreve resultado; um kimi ausente sai com código 127 e escreve status: "kimi_unavailable".

Confie no estado do processo e na árvore de trabalho em vez de uma exibição de progresso. Conclusão significa que o processo terminou e result.json existe. O relatório completo do Kimi é o campo finalMessage em result.json (também impresso por completo no stdout entre os marcadores de relatório).

4. Revisar - não confie no auto-relatório

Trate a mensagem final do Kimi e as alegações de portões como alegações:

• Re-execute os portões do projeto você mesmo.
• Leia o diff em relação ao briefing, começando com touchedFiles.
• Execute habilidades de guarda relevantes se instaladas.
• Faça migrações de ida e volta e use grep para referências pendentes após remoções ou renomeações.

Veja references/review-and-land.md.

5. Aplicar

O implementador edita a árvore de trabalho; o orquestrador commita. Commite apenas após os portões passarem e o diff estiver correto. Se for necessário refazer, envie um briefing de delta com --resume-last ou --session <id>, então revise novamente.

Autonomia e permissões

No modo headless -p, o Kimi sempre roda em modo de permissão automática e nunca pede aprovação. O Kimi rejeita --prompt combinado com --yolo, --auto, ou --plan, então o relay não passa nenhum deles e

…