IDD Skill: modelo de fluxo de trabalho de desenvolvimento orientado a issues

Para quem é

• Desenvolvedores e equipes pequenas que conduzem o desenvolvimento diário no próprio repositório Git e querem transformar "da issue ao merge" em um processo repetível: depois da importação, o agente de código com IA do repositório segue o fluxo descrito oficialmente — descobrir issues prontas, reivindicar a responsabilidade, implementar em um branch, abrir um PR, tratar o feedback de revisão, esperar o CI, fazer o merge conforme a política de merge escolhida no repositório e limpar. O projeto descreve esse fluxo como "portável": ele chega junto com o repositório, em vez de ficar preso a uma única ferramenta.
• Desenvolvedores que usam várias ferramentas de código com IA e não querem prender o processo a um único cliente: segundo a documentação oficial, o loop principal funciona no GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode e Antigravity CLI (antes Gemini CLI).
• Equipes que precisam de várias sessões de trabalho avançando issues diferentes em paralelo: a documentação oficial indica que a política padrão do modo distribuído é fully_autonomous_merge, que permite às sessões de trabalho ir até o merge; como as sessões se coordenam e evitam conflitos não é explicado oficialmente.
• O que confirmar antes de adotar: a página oficial não diz se há suporte a plataformas de hospedagem além do GitHub — ponto não confirmado; se a equipe não aceita merge totalmente automático, é preciso avaliar ou ajustar antes essa política padrão, e o modo de ajuste não é explicado oficialmente.

Primeira tentativa em 3 minutos

• Pré-requisitos: um repositório Git em que você possa criar branches e abrir PRs; e um ambiente com as dependências completas do loop listadas oficialmente — git, um gh CLI autenticado (ou uma integração GitHub MCP equivalente, basta uma das duas), jq e um cliente REST como curl.
• Onde e como instalar: não é preciso copiar arquivos manualmente. O caminho oficial é dar diretamente a instrução de importação ao agente de IA dentro do repositório de destino; o guia de onboarding cuida de copiar o template.
• Disparo: abra um agente compatível no repositório e digite literalmente esta instrução oficial:

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

• Mantenha a primeira tentativa em ações de baixo risco: peça ao agente para ler o guia do fluxo, listar as issues prontas existentes e explicar o plano para o próximo passo, sem reivindicar nada e sem alterar código. O ponto de partida oficial do loop é justamente "ler o guia, descobrir uma issue pronta, reivindicá-la"; enquanto não houver reivindicação, você pode interromper a qualquer momento.
• Sinal de sucesso: se o agente reproduz os pontos-chave do fluxo e lista com precisão as issues existentes, a importação e a leitura do guia funcionaram; os arquivos do template copiados para o repositório significam que o onboarding terminou. A documentação oficial não informa um caminho concreto: vale a saída real do agente (não confirmado).

Casos de uso

Caso 1: entregar uma issue pronta de ponta a ponta. Cenário: o backlog já tem issues marcadas como prontas e você quer validar o ciclo fechado da reivindicação ao merge. Instrua o agente: "Reivindique uma issue pronta e conclua a implementação." Ele percorrerá o loop oficial completo — ler o guia do fluxo, reivindicar a issue, implementar em um branch, abrir um PR, tratar o feedback de revisão, esperar o CI, fazer o merge conforme a política escolhida no repositório e limpar. Os marcos observáveis, em ordem: o branch aparece, o PR é criado, o status do CI muda, merge e limpeza do branch — cada passo corresponde a uma fase fixa do loop oficial. Sob a política padrão fully_autonomous_merge, a sessão de trabalho pode ir até o merge; antes da primeira execução, confirme que os gates de CI e a proteção de branches estão no lugar, ou deixe explícito na instrução que desta vez se para no PR.

Caso 2: apenas descobrir e planejar, sem mudar nada. Cenário: você quer primeiro avaliar se o processo serve ao repositório e ainda não pretende deixá-lo agir. Instrua o agente: "Leia o guia do fluxo, liste todas as issues prontas com uma ideia de implementação para cada uma e não reivindique nenhuma." Só a primeira metade do loop é usada (ler o guia, descobrir issues); nenhum branch ou PR é criado. Como uma issue é marcada como "pronta" não é explicado oficialmente: se o agente reportar uma lista vazia, confirme antes como os status das issues são rotulados no repositório. O resultado esperado é uma lista de issues e um plano de implementação em texto; a sua próxima instrução decide se se passa à implementação. Quando o plano parecer sólido, escolha uma issue e siga o caso 1 para o loop completo.

Limites de uso

• Efeitos colaterais e pontos de confirmação: a importação copia arquivos do template para o repositório; se apenas adiciona arquivos ou também altera os existentes não está dito oficialmente, então após importar revise primeiro a lista de alterações que o agente entregar. O loop completo cria branches, faz commits, abre PRs e avança até o merge sob a política padrão fully_autonomous_merge. Não é detalhado oficialmente quais ações pedem confirmação prévia: delimite explicitamente o escopo permitido em cada instrução.
• Acesso de rede e a comandos: o loop completo exige um gh CLI autenticado ou uma integração GitHub MCP equivalente, e cita clientes REST como curl — ou seja, o agente acessa as APIs do GitHub por meio dessas ferramentas durante o loop (ler issues, criar e fazer merge de PRs etc.). Quais endpoints exatamente e se há outros acessos de rede não é detalhado oficialmente.
• Ambiente de execução e pré-requisitos de cliente: a lista oficial diz que o loop principal funciona no GitHub Copilot, Claude Code, OpenAI Codex CLI, OpenCode e Antigravity CLI (antes Gemini CLI); se agentes fora da lista funcionam, se há requisitos extras de sistema operacional e se degrada quando faltam dependências não é explicado.
• Limites oficiais e incógnitas: o material oficial não menciona suporte a plataformas de hospedagem além do GitHub, nem quais outras políticas de merge existem além de fully_autonomous_merge nem como trocá-las; o comportamento de nova tentativa do agente após falha de CI também não está confirmado. Para esses detalhes, vale o texto do guia do fluxo importado no repositório.