Task preflight
Time de IA governado para o Kiro — agentes com papéis separados, specs EARS, testes black-box e gates mecânicos de merge, do ticket ao deploy.
npx -y skills add cleudice/kiro-ai-team --skill task-preflightAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 16 days oldThe repository was created 16 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Prepara o terreno antes da execução nativa das tasks do Kiro — confirma worktree/branch corretos e build/testes verdes — e faz checkpoint de build/teste após cada task marcada [x] no painel. NÃO substitui o "Start task" nativo do Kiro, que continua sendo quem implementa. Use quando disserem "vou começar as tasks do PBI X", "prepare o worktree", "checkpoint da task", ou logo após marcar uma task concluída no painel.
SKILL.md
3.2 KB, as published. Nobody here has run it
task-preflight
Por que este skill existe
O Kiro já executa tasks.md nativamente (botão "Start task" no painel da spec, task a task, marcando [x]). Este skill NÃO reimplementa esse loop — ele cobre só o que o nativo não garante sozinho: contexto de worktree e checkpoint de build/teste por task. A governança de fundo (nunca chutar, não aprovar o próprio trabalho) já vem do steering always (escalation-rules.md, quality-gates.md), injetado automaticamente em qualquer task, com ou sem este skill.
Pré-flight (antes de clicar no 1º "Start task")
- Confirmar que está no worktree/branch corretos:
git branch --show-currentdeve serpbi/<ID>(criado por.kiro/scripts/worktree.sh start <ID>). Branch errada → parar e corrigir antes de tocar em código. O hookpreflight-branch(SessionStart) já avisa isso sozinho no início da sessão se houver spec ativa numa branch que não épbi/*— trate o aviso como o gatilho pra rodar este passo, não como substituto dele. - Rodar o comando de build/teste do
tech.mddo projeto. Não está verde? Não é o PBI atual que deve resolver — escalar. - Carregar guidelines do stack +
docs/context/(eixos conventions/gotchas) se existirem. - Confirmar que
.kiro/specs/<slug>/tasks.mdexiste e está com os gates G1–G5 no final; atualizarstatus: em-devno briefdocs/issues/<ID>.md. - A partir daqui: use o painel do Kiro para "Start task" em cada item, na ordem do
tasks.md.
Checkpoint (depois de cada task marcada [x] no painel)
O hook task-checkpoint (PostTaskExec) roda build+testes automaticamente após cada task marcada [x] e só reporta se algo falhar — experimental: o trigger PostTaskExec ainda não foi confirmado contra um Kiro real (hooks/VERIFY.md); até lá, trate os passos abaixo como o caminho padrão, e o hook como reforço quando instalado (.kiro/hooks/task-checkpoint.json):
- Build + testes do módulo tocado → verdes antes de seguir para a próxima task.
- Revisar o diff da task: ficou dentro do escopo dela? Nada fora da task atual — melhoria oportunista vira nota em
docs/reviews/<PBI>-notes.md, não commit. - Implementação divergiu do design/requirements? PARAR e escalar (
escalation-rules.md) — nunca "adaptar silenciosamente" e seguir para a próxima task. - Task tocou testes do
qa-blackbox? Reprovação neles não se resolve editando o teste — ou a implementação está errada, ou a spec está errada; escalar no segundo caso.
Fim das tasks
Todo tasks.md marcado [x] → sair do loop nativo e seguir para verify-change (evidência real, não o "concluído" do painel).
Regras
- Este skill nunca substitui "Start task" — ele só cerca o loop nativo antes e depois.
- Sem worktree correto confirmado, não avance.