-# Dev Workflows
+

-**Workflows de agente como arquivos SKILL.md**: frontend, backend, arquitetura e code review de segurança que nunca pulam a verificação.
+
+
+
+
-[](LICENSE)
-[](qa/wf_quality_harness.py)
-[](https://agentskills.io)
-[](https://github.com/evandrodevbr/dev-workflows/pulls)
+[Issues](https://git.evandro.dev.br/evandro/dev-workflows/issues) · [Inventário de skills](docs/SKILLS.md) · [Aviso das skills vendorizadas](skills/NOTICE.md) · [Como contribuir](CONTRIBUTING.md)
-Transforme seu agente de código num processo repetível e verificável. Cada workflow define fases, passos de verificação concretos, comandos reais e regras duras. O agente entrega trabalho que dá pra *checar*, não só *afirmar*.
-
-**🇺🇸 [Read this in English](README.md)**
+[English](README.md) · **Português (BR)**
----
+Saída do harness depois de instalar os workflows e as skills vendorizadas no layout do Hermes (execução real; `impeccable` é uma skill de terceiros que não foi instalada, por isso o harness sai com código 1):
-## Por quê
+```console
+$ cd qa && python wf_quality_harness.py
+wf-frontend score= 385.5 refs=18 sem_match=['impeccable'] fases_sem_verif=[]
+wf-backend score= 424.0 refs=15 sem_match=[] fases_sem_verif=[]
+wf-architecture score= 413.7 refs=11 sem_match=[] fases_sem_verif=[]
+wf-security-review score= 390.0 refs=14 sem_match=[] fases_sem_verif=[]
-Agente é ótimo pra gerar código e péssimo pra admitir que não sabe. Este projeto resolve a segunda parte.
-
-Cada workflow força o agente a **provar** o trabalho em cada fase:
-
-- **Passos de verificação**: rodar build, rodar testes, chamar a API, consultar o registry. Não "acho que funciona".
-- **Critérios de aceite**: portões com checkbox que precisam estar marcados pra fase fechar.
-- **Regras duras**: "nunca faça merge com build vermelho", "nunca afirme 'sem CVE' sem consultar o OSV.dev".
-- **Harness de QA**: um placar que mede a qualidade dos workflows de forma objetiva, mais meta-testes que corrompem o harness pra provar que ele detecta regressão.
-
-## Sumário
-
-- [Workflows](#workflows)
-- [Segurança: não confie no cutoff de treino](#segurança-não-confie-no-cutoff-de-treino)
-- [Skills usadas e seus donos](#skills-usadas-e-seus-donos)
-- [Começo rápido](#começo-rápido)
-- [O harness de QA](#o-harness-de-qa)
-- [Testes de qualidade e ganhos medidos](#testes-de-qualidade-e-ganhos-medidos)
-- [Estrutura do repositório](#estrutura-do-repositório)
-- [Licença](#licença)
-
-## Workflows
-
-| Workflow | Arquivo | Cobre |
-|---|---|---|
-| 🎨 **Frontend / UI** | [workflows/wf-frontend.md](workflows/wf-frontend.md) | Direção de design antes do código, anti-AI-slop, performance React, QA visual de PDFs |
-| ⚙️ **Backend / API** | [workflows/wf-backend.md](workflows/wf-backend.md) | Contrato antes do handler, defaults seguros, auditoria OWASP, testes + caça de bugs adversarial |
-| 🏗️ **Arquitetura** | [workflows/wf-architecture.md](workflows/wf-architecture.md) | Requisitos mensuráveis, diagramas C4, ADRs, threat modeling, revisão |
-| 🛡️ **Security review** | [workflows/wf-security-review.md](workflows/wf-security-review.md) | Code review (front + back), CVEs conhecidas **e** consulta ao vivo de novas |
-| 📄 **README** | [workflows/wf-readme.md](workflows/wf-readme.md) | Criar/auditar/reescrever READMEs grounded nos fatos reais do repo |
-
-Cada arquivo é um `SKILL.md` padrão. A `description` no frontmatter é o gatilho: quando o contexto do agente bate, o workflow carrega sozinho. Funciona no [Hermes Agent](https://hermes-agent.nousresearch.com), Claude Code e qualquer coisa que leia o formato Agent Skills.
-
-## Segurança: não confie no cutoff de treino
-
-O conhecimento de CVEs de um modelo para na data do treinamento. Qualquer coisa divulgada depois disso, ele nunca viu, então "não tem vulnerabilidade" vindo de memória é um chute, não resposta.
-
-O workflow de segurança nasceu desse fato:
-
-```
-Código/diff → SCOPE → HUNT (CVEs conhecidas) → CONSULT (fontes vivas) → CODE REVIEW → REPORT + GATE
- │ │
- │ └─ OSV.dev · GitHub Advisory DB · NVD
- └──────────────┘
+TOTAL: 1613.2 / 400.0 (403.3%)
```
-Todo security review **precisa** consultar fontes vivas e carimbar a data. Review sem fonte e sem data vence na hora.
+## O que é
-## Skills usadas e seus donos
+Cinco workflows de agente escritos como arquivos `SKILL.md` padrão. A `description` no frontmatter de cada um é o gatilho: o workflow carrega quando o contexto do agente bate com ela. O corpo dos workflows está em português.
-Os workflows carregam essas skills por contexto. Os três pilares do security review vêm de fontes primárias de segurança (OWASP, OSV.dev, UnitOne SecuritySkills), não da memória de um modelo.
+| Workflow | Arquivo | Fases | Cobre |
+|---|---|---|---|
+| Frontend / UI | [`wf-frontend.md`](workflows/wf-frontend.md) | DESIGN, BUILD, REVIEW | Direção de design antes do código, anti-AI-slop, performance React, QA visual de PDFs |
+| Backend / API | [`wf-backend.md`](workflows/wf-backend.md) | PLAN, BUILD, SECURITY, TEST + BUG HUNT | Contrato antes do handler, defaults seguros, auditoria OWASP, testes e caça de bugs adversarial |
+| Arquitetura | [`wf-architecture.md`](workflows/wf-architecture.md) | REQUIREMENTS, DESIGN, DOCS, REVIEW | Requisitos mensuráveis, diagramas C4, ADRs, threat modeling |
+| Security review | [`wf-security-review.md`](workflows/wf-security-review.md) | SCOPE, HUNT, CONSULT, CODE REVIEW, REPORT + GATE | Code review de front e back, CVEs conhecidas e consulta ao vivo das novas |
+| README | [`wf-readme.md`](workflows/wf-readme.md) | SCAN, CLASSIFY, AUDIT ou DRAFT, GENERATE, VERIFY + VALIDATE | Criar, auditar ou reescrever READMEs com base em fatos reais do repositório |
-### 🛡️ Security review: os três pilares
+O repositório também vendoriza dez skills de segurança em [`skills/`](skills/NOTICE.md) e traz um harness de QA em [`qa/`](qa).
-_Vendorizadas em `skills/` — ver [`skills/NOTICE.md`](skills/NOTICE.md) pra origem exata e licença._
+## Por que usar
-| Skill | O que faz | Dono |
+Agente gera código bem e admite que não sabe muito mal. Cada workflow obriga o agente a provar o trabalho em cada fase:
+
+- **Passos de verificação:** rodar o build, rodar os testes, chamar a API, consultar o registry.
+- **Critérios de aceite:** checkboxes que precisam estar marcados para a fase fechar.
+- **Regras duras:** "nunca faça merge com build vermelho", "nunca afirme 'sem CVE' sem consultar o OSV.dev".
+
+Não use se você quer skills autossuficientes. Os workflows de frontend, backend, arquitetura e README carregam skills de terceiros que não estão neste repositório, o de segurança também espera duas skills locais que não foram vendorizadas, e o harness de QA só lê o layout do Hermes Agent.
+
+## Como funciona
+
+O workflow de segurança parte de um fato: o conhecimento de CVEs de um modelo para na data do treinamento, então "sem vulnerabilidades" vindo da memória é chute.
+
+1. **SCOPE** define o alvo antes da auditoria.
+2. **HUNT** checa CVEs conhecidas nas dependências (`safedeps` consulta o OSV.dev para um `pacote@versão`).
+3. **CONSULT** busca vulnerabilidades novas em fontes vivas: OSV.dev, GitHub Advisory DB e NVD.
+4. **CODE REVIEW** revisa o código de front e back contra OWASP Top 10 e ASVS.
+5. **REPORT + GATE** entrega o relatório com fontes e data carimbadas e decide.
+
+O harness de QA pontua `wf-frontend`, `wf-backend`, `wf-architecture` e `wf-security-review` (não o `wf-readme`) em mais de 30 critérios estáticos extraídos de cada `SKILL.md`: estrutura, passos numerados por fase, verbos de verificação, skills referenciadas e densidade de AI-isms. O `test_tests.py` tem meta-testes que quebram o harness de propósito e conferem se a nota muda.
+
+