hbardet/batch-features

Funcionalidades em lote

A primeira metade do fluxo de trabalho. A outra metade é work-issue.

Você não está arquivando um despejo de backlog. Você está transformando ideias brutas em issues que um agente possa planejar sem refazer sua descoberta. Isso significa um debate por item, depois uma aprovação e só então arquivar.

Anuncie no início: "Estou usando o skill batch-features para transformar esta lista em issues."

Configuração

shared/ é o diretório ao lado deste skill — ~/.agents/skills/shared/ quando instalado, ou ../shared/ em um checkout. Se um caminho shared/... não resolver, use o outro.

1. Leia o repositório: AGENTS.md (ou CLAUDE.md) na raiz. Ele é vinculante para convenções.
2. Leia .agent-skills/config.json se existir; caso contrário, leia shared/config.md, faça as perguntas da primeira execução e escreva o arquivo.
3. Leia shared/tracker-adapter.md, shared/labels.md e shared/issue-template.md.
4. Detecte o rastreador. Observe labels e issues existentes para que os novos se encaixem.
5. Modelos. Verifique se o projeto já possui um modelo de issue (.gitlab/issue_templates/*.md, .github/ISSUE_TEMPLATE/*.md). Se sim, use-o e registre seu caminho na configuração como issueTemplate. Se não, anote que você oferecerá uma vez no final para confirmar o commit de shared/issue-template.md no projeto.

O debate

Trabalhe na lista um item de cada vez. Para cada um:

1. Reformule-o com suas próprias palavras: o que é, a quem atende, por que agora. Mantenha a redação original como uma citação literal em Intenção no corpo da issue — mesmo quando o resto estiver em inglês.
2. Proponha uma interpretação concreta. Não "o que você quer aqui?" mas "Eu interpreto isso como X, porque Y. Diga se você quis dizer Z."
3. Faça no máximo duas perguntas. Cada uma deve ser específica e cada uma deve trazer um padrão que o usuário possa aceitar com uma palavra. Faça a pergunta cuja resposta mais mudaria o que será construído. Se o usuário pediu uma análise completa, faça mais; caso contrário, duas.
4. Defina duas coisas: critérios de aceitação (cada um observável e verificável) e tipo (feature / fix / refactor / chore). Nada mais — sem tamanho, sem área, sem dependências.

Se um item não puder ser definido após o debate, marque-o como status::blocked com uma nota precisa de especificação em vez de adivinhar. Arquivar uma issue vaga é pior do que não arquivá-la.

Não passe ao arquivamento até que cada item tenha sido debatido.

A tabela de revisão

Após o último item, apresente uma única tabela para o lote inteiro:

| #  | Título | Tipo    |
|----|--------|---------|
| 1  | ...    | feature |

Em seguida, peça aprovação. O usuário pode editar títulos, remover itens ou alterar tipos. Nada é arquivado antes desta aprovação.

Arquivar as issues

Para cada item aprovado, na ordem que o usuário preferir (por padrão, ordem de criação):

1. Crie a issue com a CLI do rastreador, corpo a partir do modelo do projeto se houver, senão a partir de shared/issue-template.md. Títulos e corpos no language da configuração (padrão en).
2. Aplique labels: status::ready e kind::<kind>. Registre o número da issue.
3. Informe as URLs das issues.

Se a lista do usuário implicar uma ordenação ("X puis Y"), anote no corpo da issue em Notas — não crie uma relação de dependência nem label.

Se o projeto não tiver modelo de issue e o usuário aceitou sua oferta, faça commit de shared/issue-template.md no caminho esperado pelo rastreador uma vez, depois arquive. Não crie silenciosamente.

Relatório

Ao final, imprima:

• As URLs das issues, uma por linha.
• O resumo do lote: N arquivadas, M bloqueadas.
• Uma linha: "Para iniciar o trabalho, diga work-issue <n>."

Restrições rígidas

• Nenhuma issue é criada sem a aprovação da tabela de revisão.
• Nenhuma issue é criada com uma seção Critérios de aceitação ou Verificação vazia.
• Nenhuma issue é criada com escopo adivinhado: se for vaga após o debate, é status::blocked.
• Nunca reivindique uma issue ou inicie a implementação a partir deste skill; isso é função de work-issue.