搭子.skill (Partner)

O que 搭子.skill (Partner) faz?

Meu Claude Code e Codex são os melhores do mundo.

Visão Geral

Use este skill para executar um fluxo de trabalho de codificação com dois agentes: Claude Code é o agente de planejamento, polimento e revisão de alto valor; Codex é o orquestrador externo e implementador principal. Mantenha o uso do Claude Code focado, pois ele pode ser cobrado por API.

Prefira uma única sessão de longa duração do Claude Code para tarefas pequenas e médias: peça ao Claude o plano, deixe o Codex implementar e, em seguida, retorne o resumo do diff e os arquivos principais para a mesma sessão do Claude para polimento de UI/interação e revisão final com /codex:review. Isso evita pagar para o Claude reconstruir o mesmo contexto do projeto e dá ao Claude continuidade suficiente para melhorar o trabalho.

Partner não é uma desculpa para delegar. O usuário continua sendo o proprietário, o Codex permanece responsável pelas evidências no repositório, e o Claude Code é tratado como um colaborador de alto valor cuja saída deve ser verificada.

Fluxo Padrão

1. Baseie-se no repositório alvo.

   • Entre no diretório concreto do projeto, não na raiz do agent-workbench.
   • Execute git status --short antes de iniciar o Claude Code.
   • Identifique se a tarefa é greenfield, com muitos recursos, com muita UI, apenas revisão ou depuração.

2. Inicie uma sessão do Claude Code para o loop de pensamento caro.

   • Para planejamento: inicie o Claude Code em um PTY e defina uma meta.
   • Use claude --permission-mode plan --name <nome-da-tarefa> por padrão.
   • Na sessão interativa, envie /goal <condição de conclusão clara>.
   • Peça ao Claude Code um plano de implementação concreto, critérios de aceitação e orientação de UI/interação.
   • Mantenha esta mesma sessão aberta para as passagens posteriores de polimento e revisão quando a tarefa não for muito grande.
   • Não inicie uma sessão separada apenas de revisão claude -p só porque o Codex terminou a implementação. Isso gasta tokens com contexto frio e enfraquece a continuidade do Claude.

3. Implemente principalmente com o Codex.

   • Converta o plano do Claude Code em uma pequena lista de verificação.
   • Faça as alterações de código diretamente no Codex, usando os padrões existentes do repositório.
   • Execute a verificação relevante mais rápida após edições arriscadas.
   • Mantenha o Claude Code fora de edições mecânicas em massa, correções de lint repetidas e loops de comando longos, a menos que o usuário solicite.

4. Envie o estado implementado de volta para a mesma sessão do Claude Code para polimento.

   • Use isso especialmente para frontend UI, qualidade de interação, sensação do produto, acessibilidade e estados de borda.
   • Envie uma carga útil limitada. Use references/handoff-template.md quando possível: o plano original, lista de arquivos alterados, git diff --stat, saída de teste/verificação, riscos, perguntas em aberto e apenas os trechos ou arquivos principais que o Claude precisa.
   • Peça descobertas priorizadas, não reescritas amplas.
   • O Codex aplica as correções aceitas e reexecuta as verificações.

5. Execute a revisão final a partir da mesma sessão do Claude Code.

   • No Claude Code, use /codex:review quando disponível.
   • Trate as descobertas primeiro como problemas de bug/risco/teste, depois sugestões de estilo.
   • O Codex corrige descobertas bloqueadoras, reexecuta verificações e relata o status final.
   • Termine com um Recibo de Sessão Partner para que o usuário possa verificar se o contexto do Claude Code foi reutilizado.

Estratégia de Sessão

• Tarefa pequena ou média: mantenha uma sessão do Claude Code aberta para planejar -> polir -> /codex:review.
• Trate uma nova sessão do Claude Code como cara. Abra uma apenas quando não houver uma sessão reutilizável, a sessão anterior estiver irrecuperável ou o usuário solicitar explicitamente uma passagem nova do Claude.
• Se a mesma sessão do Claude ficar presa em um prompt, espera de permissão ou estado ocioso, primeiro tente continuar ou retomar a mesma sessão com uma mensagem limitada. Não inicie uma revisão substituta a frio, a menos que o valor claramente supere o custo do contexto.
• Tarefa grande ou diff enorme: divida as sessões somente após o Codex produzir uma transferência compacta contendo o plano, os arquivos alterados, as principais decisões, os riscos conhecidos e os resultados das verificações.
• Se a mesma sessão do Claude ficar lenta, confusa ou com contexto pesado, feche-a e reinicie com uma transferência limitada somente após relatar a compensação de tokens.
• Não pule a fase de polimento do Claude para trabalho de UI/frontend, a menos que o usuário solicite explicitamente um loop mínimo mais rápido.
• Se /codex:review travar, expirar ou ficar preso em um prompt de permissão, registre isso como uma descoberta de monitoramento, pare o subprocesso/sessão travado e continue com a verificação do lado do Codex.
• Se o Claude Code não produzir polimento acionável, não continue solicitando-o cegamente. Capture o resultado vazio/de baixo sinal, execute a verificação do Codex e relate a limitação.
• claude -p não é o caminho Partner padrão. Use-o apenas para perguntas pontuais baratas onde perder o contexto da sessão anterior é aceitável.

Política de Permissão

• Padrão para --permission-mode plan para planejamento e permissões normais para revisão de implementação.
• Use skip/bypass apenas quando o usuário solicitar explicitamente skip, 最高权限, 全部允许, bypass ou quando o trabalho estiver dentro de uma worktree intencionalmente isolada.
• Para o modo skip, inicie o Claude Code com claude --permission-mode bypassPermissions --name <nome-da-tarefa> ou claude --dangerously-skip-permissions --name <nome-da-tarefa>.
• Antes de qualquer sessão skip, informe o caminho do repositório, o status atual do git, o escopo pretendido e a condição de parada.
• Nunca permita que o modo skip faça commit, push, deploy, envie mensagens, publique ou toque em segredos, a menos que o usuário dê uma instrução explícita separada.
• Nunca trate skip como permissão para ignorar evidências do repositório. skip altera as permissões do Claude Code, não o dever de verificação do Partner.
• Mantenha alterações de visibilidade do repositório, tags de release, publicação em registros e anúncios externos atrás de uma instrução de publicação explícita separada.

Regras de Roteamento

• Roteie para Claude Code: planejamento de arquitetura, estratégia de implementação, crítica de UI/interação, Revisão Codex final, trade-offs difíceis de produto.
• Roteie para Codex: scaffolding, implementação, edições de código de contexto longo, testes, correções de build, inspeção de repositório, monitoramento, resumos.
• Roteie de volta para a mesma sessão do Claude Code quando a qualidade da UI for importante ou a primeira implementação passar tecnicamente, mas ainda precisar de polimento de produto.
• Mantenha Kimi Work/Kimi Code Goal separado de /goal do Claude; o contexto anterior do "Goal mode" pode se referir a Kimi, não a Claude.

Portão de Validação

Use a catraca estilo Darwin em references/darwin-ratchet.md ao melhorar este fluxo de trabalho ou aplicá-lo a uma tarefa substancial:

• Altere uma dimensão do fluxo de trabalho por vez: planejamento, implementação, polimento de UI, revisão, monitoramento, permissões ou relatórios.
• Execute prompts de teste ou um miniloop real antes de considerar uma melhoria melhor.
• Não deixe que o mesmo agente seja o único criador e único juiz para alterações de alto risco.
• Mantenha a alteração somente quando as evidências do repositório melhorarem. Se regredir, use um revert revisável, não git reset --hard.
• Pare quando outro loop de prompt produzir sinal baixo ou <1 ponto de melhoria esperada.

Monitoramento

Para sessões ativas do Claude Code, leia references/monitoring.md. Prefira cinco sinais em vez de confiar apenas no texto do chat:

1. Saída PTY da sessão do Claude Code em execução.
2. Status da sessão claude agents --json --cwd <repo>.
3. Estrutura do transcript JSONL do Claude, sem despejar corpos de mensagens completos por padrão.
4. Arquivos de tarefas opcionais sob ~/.claude/tasks/<sessionId>/.
5. Evidência do repositório: git status --short, git diff --stat e verificações de teste/build relevantes.

Contrato de Saída

Ao relatar de volta ao usuário, inclua:

• Fase atual: planejamento, implementação Codex, polimento Claude, revisão ou correção final.
• ID da sessão do Claude Code quando existir.
• Arquivos alterados e verificações executadas.
• Descobertas de revisão corrigidas ou ainda em aberto.
• Se o trabalho está pronto para commit; não faça commit por padrão.
• Qualquer anomalia de monitoramento, como sessão ociosa, espera de permissão, saída de revisão vazia, nenhum diff ou verificação falhada.
• Um Recibo de Sessão Partner para fluxos de trabalho não triviais do Claude Code:

[Partner session receipt]
phase: <planning | codex implementation | claude polish | review | final fix>
claude_session: <sessionId or none>
claude_session_reused: <yes | no | n/a>
new_claude_p_sessions: <0 | count | unknown>
codex_passes: <number of implementation/fix passes>
checks: <commands run or not run>
anomalies: <none | permission wait | idle | empty review | failed check | other>

Não invente economia de tokens. Quando a telemetria exata de tokens não estiver disponível, relate comportamento verificável: mesma sessão do Claude Code reutilizada, nenhuma sessão nova claude -p, transferência limitada usada, verificações aprovadas.