Write blackbox tests

Skill cleudice/kiro-ai-team/skills/write-blackbox-tests

(Somente qa-blackbox) Escreve os testes de aceitação usando APENAS requirements.md e os contratos do design.md — proibido ler src/ e docs/context/. Use em paralelo à implementação, quando pedirem 'testes do PBI', 'testes de aceitação', 'cubra os critérios'.From its SKILL.md

Install

npx -y skills add cleudice/kiro-ai-team --skill write-blackbox-tests

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

22 days oldThe repository was created 22 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.

SKILL.md

2.9 KB, 789 tokens by cl100k_base, as published. Nobody here has run it

write-blackbox-tests

Restrições rígidas

Fontes permitidas: requirements.md, design.md (contratos), tech.md (como rodar testes). Proibido: qualquer arquivo de src/, diffs, conversa dos devs.
Precisa olhar o código para escrever o teste? → a spec está incompleta: devolver ao spec-analyst com a lacuna (contrato ausente, critério vago).

Passos

Pré-flight: confirmar o worktree do QA (.kiro/scripts/worktree.sh start <PBI> --qa já rodado — checkout SEM src/, branch qa/pbi/<ID>; peça ao orchestrator se não existir) — mesmo quando o design decidiu zero mudança em src/ e todas as tasks são suas. Nunca escrever teste no worktree do dev nem no working tree do repo principal: o checkout sem src/ é o que torna o black-box invariante física, não disciplina. Commite os testes na branch qa/pbi/<ID>; a mesclagem em pbi/<ID> acontece antes do merge-gate.
Mapear 1 critério EARS → ≥1 teste. Tabela de rastreabilidade R#.# → teste.
Escrever contra os contratos públicos do design (endpoint, interface, procedure) no framework de teste do repo.
Incluir casos de erro e borda declarados nos critérios.
Salvar: código no diretório de testes; especificação + rastreabilidade em docs/tests-spec/<slug>.md (nome exato — é o que check-gates.sh procura para o gate G1).
Quando nenhuma task de dev-* existir no PBI (design decidiu zero mudança de produção), você também é dono do gate G2 (verify-change) — rodar a suíte de verdade e produzir docs/reviews/<PBI>-verify.md (skill verify-change).

Saída — docs/tests-spec/<slug>.md

# Tests spec — <slug> (PBI-<id>)
Executor: qa-blackbox. Escrito só a partir de requirements.md/design.md.
## Rastreabilidade R#.# → teste
| Critério | Arquivo de teste | Testes |
| --- | --- | --- |
| R1.1, R1.2 | <Classe>Tests.cs | N |
## Fixtures (se houver)
<arquivo> — <propósito>
## Cobertura
Total de testes / critérios cobertos. Lacuna encontrada (contrato ausente, critério vago) → registrar aqui e devolver ao spec-analyst, nunca inventar.

Regras

Teste deve falhar de forma diagnóstica (mensagem aponta o critério violado).
Nunca ajustar teste para acomodar implementação — o sentido é o inverso.
Código de teste é código: nomes de classe/método, comentários e mensagens seguem o idioma do código-fonte real, não o idioma padrão do time nem da spec/brief. Detecte o idioma pelos contratos públicos já citados em design.md (nomes de tipo/método/parâmetro são cópia literal da API real) — nunca abra src/ só pra checar idioma, isso já viola a restrição rígida acima.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.