@andespindola/crow-skills 0.23.0 → 0.25.0

package/skills/crow-spec/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: crow-spec
-description: "Transforme uma decisão de produto em uma especificação enxuta, fatias de release e critérios testáveis. Não conduz pesquisa de mercado."
+description: "Transforme uma decisão de produto em uma especificação enxuta, fatias de release e critérios testáveis. Não conduz pesquisa de mercado: investigar o problema é de crow-discovery, e escrever ou rodar a suíte a partir do critério é de crow-qa."
 ---
 
 # Escopo e critérios de aceite
@@ -18,8 +18,9 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 1. Escolha a menor forma útil: issue para mudança pequena; PRD curto quando há múltiplos públicos, riscos ou decisões. Não preencha seções sem função.
 2. Defina usuário, outcome, fluxo, regras, métricas disponíveis e fora de escopo. Marque hipóteses e dúvidas no ponto onde afetam a decisão; sem poder perguntar, registre-as como pendência com opções e não afirme que foram encaminhadas. Pedidos fora do objetivo cabem numa linha em fora de escopo.
 3. Mapeie a jornada e recorte uma fatia vertical que entregue valor observável. Dependências técnicas são tarefas de suporte, não histórias artificiais de usuário.
-4. Escreva um critério de aceite por requisito, com precondição, ação e resultado observável. Inclua erros, autorização, estado vazio e recuperação pertinentes ao fluxo; os que não decorrem de requisito declarado ficam marcados PROPOSTO.
-5. Priorize com o método adequado aos dados disponíveis. Ordene dependências e explicite o que depende de descoberta; roadmap não vira promessa de data.
+4. Escreva um critério de aceite por requisito, com precondição, ação e resultado observável. Inclua erros, autorização, estado vazio e recuperação pertinentes ao fluxo; os que não decorrem de requisito declarado ficam marcados PROPOSTO. Diga também o que não pode piorar, com medida que já é coletada.
+5. Leia [critério e fatia](references/criterio-e-fatia.md) ao escrever o critério e ao recortar o release: afirmação de grau sem valor não é resultado, mais de um gatilho ou resultado no mesmo critério é sinal de divisão, o papel específico substitui "usuário", a fatia atravessa o caminho inteiro de um recorte pequeno, e o critério fica executável para `crow-qa` sem citar ferramenta de teste.
+6. Priorize com o método adequado aos dados disponíveis. Ordene dependências e explicite o que depende de descoberta; roadmap não vira promessa de data.
 
 ## Saída e aceite
 

package/skills/crow-spec/references/criterio-e-fatia.md

@@ -0,0 +1,27 @@
+# critério e fatia
+
+Leia ao escrever critério de aceite e ao recortar release. Critério que ninguém consegue executar é prosa; fatia que só entrega valor quando a próxima chegar é tarefa disfarçada de release.
+
+## Critério verificável
+
+Cada critério diz em que estado o sistema está, o que acontece, e o que passa a ser observável depois — e quem vai verificar consegue fazer isso sem perguntar nada a você. Afirmação de grau precisa do valor e de onde ele é medido: "mais rápido", "melhor experiência", "estável" e "intuitivo" não são resultados, são opiniões sobre o resultado. Se o requisito declarado não traz o número, o critério traz o que é observável sem ele (a mensagem exibida, o registro gravado, o acesso recusado) e a meta numérica fica marcada como pendente de quem decide, não inventada.
+
+Um gatilho e um resultado por critério. Mais de um gatilho no mesmo critério esconde dois comportamentos; mais de um resultado esconde dois requisitos. Nos dois casos o sinal é de divisão, e a divisão vem antes de escrever o critério. Resultado negativo também é critério: o que o sistema recusa, o que não grava, o que não aparece para quem não tem permissão. Caso sem requisito declarado que o sustente entra marcado como PROPOSTO.
+
+Nomeie o papel que exerce a ação. "Usuário" cobre papéis com permissões e necessidades diferentes e produz critério que não decide nada; o papel específico decide. O motivo do requisito não repete a ação: se o "para que" só reescreve o "o que", o requisito não registra por que vale construí-lo.
+
+## Guardrail
+
+Além da medida que deve melhorar, diga o que não pode piorar: a conversão a montante, o tempo de resposta do fluxo vizinho, o volume de chamado de suporte, a taxa de erro de quem já usava. Entrega que move a métrica alvo degradando a vizinha não cumpriu o requisito, e sem o guardrail escrito ninguém vai olhar. Use só medidas que já existem e são coletadas; guardrail que depende de instrumentação inexistente é pendência nomeada, com quem a implementa.
+
+## Fatia que entrega valor sozinha
+
+A fatia atravessa o caminho inteiro de um recorte pequeno do problema: alguém consegue fazer algo de ponta a ponta e o resultado é observável sem a próxima fatia. Recorte por camada técnica — uma fatia de interface e outra de serviço — não entrega nada sozinho e só desloca a integração para o fim.
+
+Os recortes que costumam funcionar: uma etapa do fluxo em vez do fluxo todo; uma variação de regra em vez de todas; um tipo de dado ou de entrada em vez do conjunto; uma integração externa por vez; o caminho feliz antes da recuperação, quando a falha parcial é aceitável e está declarada. Quando nenhum deles se aplica porque o problema ainda tem incógnita, o recorte certo é um experimento curto para resolver a incógnita, declarado como experimento — não como história de usuário.
+
+Valide o recorte contra três perguntas: cada fatia entrega valor observável por si; a soma das fatias cobre o requisito original, sem perda silenciosa; e nenhuma fatia depende de outra terminar inteira para começar. Dependência inevitável é ordem explícita, não história artificial. Fatia de dois dias não precisa de divisão: dividir o que já é pequeno cria dependência e cerimônia sem ganho.
+
+## O limite com quem testa
+
+Esta skill entrega o critério; `crow-qa` escolhe as camadas, decide o que vira teste automatizado e escreve a suíte. Não especifique arquivo de teste, framework ou nível de cobertura aqui — critério amarrado a uma ferramenta de teste trava a decisão de quem é dona dela. Garanta que o critério é executável: se `crow-qa` não consegue derivar o caso a partir dele, ele não está pronto.

package/skills/crow-threat-model/SKILL.md

@@ -18,9 +18,13 @@ Se pedido, documentação ou requisitos se contradizem, nomeie o conflito com a
 1. Mapeie ativos e fluxos de dados/instruções, indicando onde mudam identidade, autoridade e confiança. Integração fora do escopo continua sendo fronteira: registre quais dados a cruzam.
 2. Para cada fronteira relevante, descreva quem consegue influenciar qual entrada e qual efeito indevido poderia obter. Use STRIDE como lente, não como lista para preencher sem contexto.
 3. Priorize por impacto e viabilidade demonstráveis ou marcados como hipótese, com o rótulo em cada risco; se faltam fatos, registre a informação necessária.
-4. Vincule cada risco a controle, responsável e verificação observável. Identifique também disponibilidade, abuso de negócio, integrações e recuperação pertinentes.
+4. Vincule cada risco a controle, responsável, verificação observável e estado (aberto, mitigado, aceito ou transferido). Risco mitigado só fecha com a verificação do controle conferida ou pendente com quem confere. Ameaça aceita fica registrada com quem aceitou, justificativa, impacto residual e data de revisão; não some do registro. Identifique também disponibilidade, abuso de negócio, integrações e recuperação pertinentes.
 5. Atualize apenas as partes afetadas por mudanças; entregue cenários ao implementador e ao QA sem se declarar um pentest executado.
 
+## Detalhes condicionais
+
+- Leia [ciclo-ameaca.md](references/ciclo-ameaca.md) ao fechar o registro: estado de cada ameaça, tratamento de risco aceito, fronteiras de confiança que escapam, calibração por ator e encadeamento.
+
 ## Saída e aceite
 
 Entregue **threat-register** na resposta final (memória ou ledger externo não contam; não escreva no projeto), conciso e com: alvo/revisão; mudanças ou achados por item, com arquivo:linha; evidência (comando e saída resumida) rotulada como observado, inferido ou simulado; conflitos e decisões pendentes; descartados (controles corretos verificados, credenciais fictícias e falsos positivos) com motivo; não verificado; próximo responsável.

package/skills/crow-threat-model/references/ciclo-ameaca.md

@@ -0,0 +1,15 @@
+# ciclo da ameaça
+
+Leia ao fechar o registro, para que cada ameaça vire item verificável e nenhuma suma.
+
+Cada risco tem estado explícito: aberto, mitigado, aceito ou transferido. Risco mitigado só fecha quando a verificação observável do controle existe e foi conferida ou está marcada como pendente com quem confere. Modelo que lista ameaças sem controle, responsável e verificação é prosa, não registro.
+
+Ameaça aceita não some: registre quem aceitou, a justificativa, o impacto residual e a data de revisão. Sem isso, a aceitação vira esquecimento e reaparece como surpresa na próxima mudança. Risco transferido (para provedor, seguro, outro time) nomeia o destino e o que continua sob seu controle.
+
+Fronteira de confiança costuma ficar invisível onde a mudança de confiança é implícita. Varra as que mais escapam: serviços de times ou repositórios diferentes; limite entre contêiner e host, entre pods e entre namespaces; segmentos de rede (VPC, subnet, security group); contas ou assinaturas de nuvem distintas; a cadeia de CI/CD (origem, build, registro, deploy); e a borda entre seu código e SDK, biblioteca ou interpretador embarcado de terceiro. Cada cruzamento é um ponto onde autenticação, autorização e validação precisam valer.
+
+Calibre probabilidade pela capacidade e motivação do ator, não por sensação: não iguale um script kiddie com exploit público a um ator com zero-day e orçamento ilimitado. Se faltam fatos para situar o ator, marque o risco como hipótese.
+
+Modele também o encadeamento, não só a ameaça por elemento: descreva como um defeito de baixo impacto vira degrau para o próximo até o efeito que importa. STRIDE é a lente por elemento; o caminho encadeado mostra o alcance real.
+
+Mapeamento a TTP de ATT&CK é opcional e serve para correlação com inteligência; use quando o dono acompanha ATT&CK, sem transformar o registro em preenchimento de identificadores.