القائمة
Use ao validar requisitos contra padrões da notação EARS. Aciona com "EARS", "requirement review", "revisão de requisitos", "requirement quality", "shall statement", "REQ-ID".
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use ao mapear capacidades de negócio, identificar sobreposições ou lacunas na empresa, ou alinhar investimentos de TI a resultados de negócio. Aciona com "capability map", "mapa de capacidades", "business capability", "domain map", "enterprise architecture".
Use ao rascunhar Architecture Decision Records, avaliar alternativas ou documentar trade-offs técnicos. Aciona com "ADR", "architecture decision", "decisão arquitetural", "trade-off", "pick between", "why did we choose".
Use quando uma nova pessoa de engenharia entra no time, durante onboarding em um codebase desconhecido, ou ao auditar se o time tem entendimento compartilhado. Aciona com "onboard", "onboarding", "context audit", "knowledge gap", "bus factor", "team understanding".
Use ao investigar consultas lentas, desenhar índices ou revisar planos de execução. Aciona com 'slow query', 'consulta lenta', 'explain plan', 'index', 'query tuning', 'N+1', 'table scan'.
Use ao planejar uma mudança de schema online, migração com zero downtime ou rollback de um deploy que alterou uma tabela. Aciona com 'migration', 'migração', 'ALTER TABLE', 'zero-downtime', 'expand-contract', 'backfill'.
Use quando um teste for intermitente, ao investigar instabilidade no CI, ao colocar um teste em quarentena, ou ao criar um dashboard de flaky tests. Aciona com 'flaky test', 'teste intermitente', 'flaky', 'quarantine', 'CI instável', 'flaky dashboard'.
| name | ears-validate |
| description | Use ao validar requisitos contra padrões da notação EARS. Aciona com "EARS", "requirement review", "revisão de requisitos", "requirement quality", "shall statement", "REQ-ID". |
| Padrão | Modelo |
|---|---|
| Ubiquitous | O <sistema> deverá <resposta>. |
| Event-driven | Quando <gatilho>, o <sistema> deverá <resposta>. |
| State-driven | Enquanto <estado>, o <sistema> deverá <resposta>. |
| Optional | Onde <feature estiver incluída>, o <sistema> deverá <resposta>. |
| Unwanted | Se <condição indesejada>, então o <sistema> deverá <mitigação>. |
| Complex | Enquanto <estado>, quando <gatilho>, o <sistema> deverá <resposta>. |
REQ-NNN.source_legacy: não vazio apontando para 01-arqueologia/legado-sifap/natural-programs/*.NSN, 01-arqueologia/legado-sifap/adabas-ddms/*.ddm ou [GREENFIELD] + justification.| Defeito | Exemplo | Correção |
|---|---|---|
| Ambíguo | "O sistema deve ser rápido." | "Quando uma pessoa usuária envia um formulário, o sistema deverá responder em até 500ms." |
| Composto | "Fazer login e enviar e-mail." | Dividir em dois requisitos. |
| Não testável | "O sistema deverá ser fácil de usar." | Substituir por métrica de UX mensurável. |
| Passivo | "Login deverá ser suportado." | "O sistema deverá aceitar autenticação por usuário/senha." |
### REQ-NNN (<pattern>)
<EARS statement>
**source_legacy**: 01-arqueologia/legado-sifap/natural-programs/<FILE>.NSN#L<start>-L<end>
_(ou `[GREENFIELD] <justificativa>` quando não houver paralelo legado)_
**Critérios de aceite**
- <criterion 1>
- <criterion 2>
**Rastreado a partir de**: US-NNN, ADR-NNN
**Prioridade**: P0 / P1 / P2
**Status**: proposto / aprovado / implementado / verificado
Rejeite qualquer requisito sem REQ-ID, classificação de padrão, critérios de aceitação ou source_legacy. O job de CI legacy-traceability em .github/workflows/spec-quality.yml aplica isso em todo PR.