---
name: output-quality
description: Melhorar qualidade de artefatos e respostas SDD. Use ao criar ou revisar PRD, Tech Spec, Tasks, Refinement, Execution, Review, Memory, handoffs ou checkpoints para deixar o output decisão-primeiro, rastreável, objetivo, com evidências, matrizes, diagramas úteis e próximos passos claros.
---

# Output Quality SDD

## Objetivo

Transformar saída em artefato de decisão. O leitor deve entender o que mudou, por que importa, como validar e qual é o próximo passo sem garimpar parágrafos.

O formato deve ser provider-neutral: Markdown claro, tabelas simples, caminhos, comandos e evidências. Não dependa de recursos exclusivos de um modelo ou client.

## Princípios

- Decisão antes de detalhe: abra com conclusão, escopo e veredito quando houver.
- Evidência antes de adjetivo: cite comando, arquivo, linha, teste, screenshot, diagrama, PR, CI ou contrato.
- Rastreabilidade sempre: origem, estado atual, dono, evidências e próximo artefato.
- Complementos só quando ajudam: matriz, diagrama ou checklist não devem repetir o texto principal.
- Português do Brasil com acentuação preservada: títulos, seções, tabelas, Gherkin, labels de Mermaid/Excalidraw, copy, checkpoints, handoffs e memória não devem ser normalizados para ASCII.
- Progressive disclosure: resumo curto primeiro; detalhes técnicos depois.

## Pacote de saída

Use este pacote como camada extra sobre o contrato obrigatório do artefato:

```md
## Resumo executivo
- Decisão:
- Escopo:
- Estado:
- Próximo passo:

## Rastreabilidade
- Origem:
- Artefato atual:
- Evidências:
- Owner:

## Matriz de aceite e evidência
| Requisito | Critério | Evidência | Estado | Owner |
|---|---|---|---|---|

## Riscos e decisões abertas
| Item | Impacto | Mitigação | Decisão necessária |
|---|---|---|---|
```

## Complementos por etapa

- Idea/PRD: jornada principal, não objetivos, métricas, regras de negócio, sementes de Gherkin, perguntas abertas e `## Diagramas` com Mermaid/Excalidraw quando fluxo, estados ou decisões ficarem mais claros visualmente.
- Tech Spec: decisões arquiteturais, contratos, fluxos técnicos, matriz de dados, observabilidade, estratégia de testes e `## Diagramas` com arquitetura, sequence, state machine ou data flow ancorados no codebase real.
- Tasks: ordem sugerida, dependências, critérios em Gherkin, arquivos prováveis, validação e `## Prompts Agent` com prompt standalone por tarefa.
- Refinement: DoD, estimativa, flags/configurações, rollout, riscos e owner por pendência.
- Execution: arquivos alterados, decisões, testes executados, evidência manual e risco residual.
- Review: achados por severidade, veredito, evidências, lacunas e release readiness.
- Memory: decisões e aprendizados compactos com links, nunca transcrição integral.
- Checkpoint: resumo da decisão, critério para aprovar, evidências tipadas e consequência de cada resposta.

## Quando acionar outras skills

- Use `artifact-diagrams` quando relações, fluxos, estados, arquitetura ou dependências ficarem mais claros visualmente.
- Use `experience-design` quando a entrega afetar UI, UX, CLI/TUI, onboarding, formulários, estados ou copy de interface.
- Use `visual-review` antes de aprovar UI implementada ou handoff visual.
- Use `artifact-schemas` para validar seções obrigatórias antes de avançar.
- Use `checkpoints` quando o output pedir decisão humana.

## Gates de qualidade por artefato

- PRD aprovado precisa ter `Rastreabilidade`, requisitos testáveis, critérios Gherkin e `## Diagramas` com Mermaid útil ou justificativa explícita de `Não aplicável`.
- Tech Spec aprovada precisa ter `Rastreabilidade`, decisões técnicas, contratos/dados/testes e `## Diagramas` com pelo menos um mapa técnico útil ou justificativa explícita de `Não aplicável`.
- Tasks registradas precisam ter `Backlog`, `Dependências`, `Critérios de aceite`, `Definition of Done`, `Estratégia de testes`, `Ordem sugerida` e `Prompts Agent`.
- Cada prompt agent deve ser suficiente para um LLM sem memória da conversa executar a task no workspace: inclua origem, objetivo, escopo, arquivos prováveis, constraints, passos, validação, DoD e formato do relatório final.

## Regras

- Não infle artefatos com tabelas vazias; marque `não aplicável` quando necessário.
- Não invente evidência. Se não foi verificado, escreva `não verificado` e diga como verificar.
- Não duplique conteúdo entre Jira, Confluence, Git provider e artifact store local; grave ponteiros canônicos.
- Não remova acentos de texto humano em PT-BR. Use forma sem acento apenas para slugs, paths, branches, identificadores de código, variáveis de ambiente, comandos, schemas, campos de API ou contratos externos literais.
- Antes de concluir um artefato em PT-BR, faça uma revisão rápida de termos comuns que não podem sair sem acento, como `não`, `critérios`, `validação`, `experiência`, `usuário`, `decisão`, `evidência`, `próximo`, `mínimo`, `segurança` e `dependências`.
- Ao materializar Markdown, valide com `sdd validate-artifact <tipo> <arquivo.md>` quando houver schema.
