O GitHub anunciou em 10 de junho que o GitHub CLI passou a expor tipos de issue, subissues e dependências diretamente no terminal. A mudança chegou no gh v2.94.0 e reduz a necessidade de abrir o navegador ou escrever chamadas manuais para a API quando o trabalho precisa ser estruturado por hierarquia e bloqueios.
Segundo o GitHub Changelog, o comando gh issue agora consegue definir tipo de issue, associar parent e subissue, além de marcar relações de bloqueio como blocked-by e blocking. O gh issue view e o gh issue list também passaram a expor essas informações como campos JSON, o que importa para scripts e agentes que precisam ler o estado do trabalho sem raspar tela.
Em termos práticos, o GitHub CLI fica mais perto de ser uma interface completa para planejamento técnico. Antes, um time podia até criar issues pelo terminal, mas dependia do navegador ou de gh api para partes importantes da estrutura. Com a atualização, a mesma linha de comando passa a cobrir mais do fluxo de triagem, decomposição e acompanhamento.
O que mudou no gh issue
A mudança mais visível é a hierarquia. Subissues permitem quebrar uma entrega maior em partes menores sem perder a relação com o item principal. Isso ajuda em bugs amplos, iniciativas técnicas, migrações, tarefas de segurança e entregas que cruzam repositórios.
O suporte a tipos de issue também melhora a triagem. Quando uma organização define tipos, o GitHub CLI pode criar, editar e filtrar issues por esse campo. O time deixa de depender apenas de título e labels para separar bug, tarefa, melhoria, épico ou outro recorte interno.
As dependências completam o desenho. Ao marcar uma issue como bloqueada por outra, o backlog mostra ordem real de execução. Isso evita tratar tudo como fila plana. Para quem trabalha com automação, a informação também passa a ser legível em JSON, então um script pode identificar o que está bloqueado antes de tentar mover status, acionar CI ou cobrar responsável.
Terminal vira ponto de integração
A atualização parece pequena, mas muda o ponto de integração. O terminal é onde muitos desenvolvedores já fazem commit, review, release e diagnóstico. Também é a interface preferida de muitos agentes de código, porque permite operar com comandos versionáveis, logs e saídas estruturadas.
Quando o GitHub CLI entende hierarquia e dependência, um agente pode fazer perguntas melhores. Ele pode listar subissues de uma entrega, confirmar se a tarefa está bloqueada, abrir uma issue filha para um erro encontrado em teste ou atualizar metadados sem inventar uma estrutura paralela.
Isso não torna a automação automaticamente segura. Um comando que cria ou reorganiza issue ainda altera o fluxo de trabalho do time. O ganho está em ter uma interface oficial, auditável e previsível, em vez de scripts frágeis montados sobre endpoints soltos.
Hierarquia não substitui clareza
Subissue demais vira ruído. Se cada ajuste pequeno ganha três níveis de hierarquia, o time perde tempo mantendo o mapa. O bom uso começa por uma pergunta simples: essa divisão ajuda alguém a executar, revisar ou desbloquear o trabalho?
Em iniciativas técnicas, a hierarquia costuma funcionar quando o item pai descreve o resultado esperado e as subissues descrevem partes entregáveis. Uma migração de autenticação, por exemplo, pode ter subissues para inventário, alteração de backend, ajuste de frontend, teste de compatibilidade e rollout. Cada subissue precisa ter dono, critério de conclusão e relação clara com o item maior.
Dependências também precisam ser usadas com parcimônia. Elas são fortes quando indicam bloqueio real, como uma API que precisa existir antes da tela ou uma correção de schema antes do job de migração. Usar dependência para preferência vaga de ordem só cria fila artificial.
Como adotar sem bagunçar o backlog
Um bom começo é escolher uma única iniciativa em andamento e reorganizá-la com o novo suporte do GitHub CLI. O time pode criar um item principal, mover tarefas reais para subissues e marcar bloqueios que já existem. Depois disso, vale testar se a visualização pelo terminal ajuda ou atrapalha a rotina.
Para automações, o primeiro uso deve ser leitura. Antes de permitir que scripts alterem a hierarquia, eles podem apenas consultar campos JSON e gerar relatórios: issues bloqueadas sem atualização, subissues sem responsável, itens pais concluídos com filhos abertos ou tarefas prontas que continuam presas por dependência antiga.
Essa disciplina conversa com práticas de code review e refatoração: a ferramenta deve facilitar decisões, não esconder complexidade. O GitHub CLI agora oferece mais estrutura no terminal. O valor vem de transformar essa estrutura em fluxo simples, rastreável e útil para quem entrega software.
