# developer-quality

> Governar qualidade técnica transversal do Code Compass (gates de entrega, política de testes/contratos, lint, typecheck, cobertura e estabilidade de CI) quando o objetivo principal for elevar confiabilidade sistêmica entre módulos; não usar para bugfix com repro antes/depois, regressão localizada de mudança pontual ou smoke e2e de alteração específica (usar `developer-tester`) nem para implementação de feature de domínio.

- Author: Junior Martins
- Repository: juniormartinxo/code-compass
- Version: 20260208232228
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-09
- Source: https://github.com/juniormartinxo/code-compass
- Web: https://mule.run/skillshub/@@juniormartinxo/code-compass~developer-quality:20260208232228

---

---
name: developer-quality
description: Governar qualidade técnica transversal do Code Compass (gates de entrega, política de testes/contratos, lint, typecheck, cobertura e estabilidade de CI) quando o objetivo principal for elevar confiabilidade sistêmica entre módulos; não usar para bugfix com repro antes/depois, regressão localizada de mudança pontual ou smoke e2e de alteração específica (usar `developer-tester`) nem para implementação de feature de domínio.
---

# Developer Quality

## 1) Objetivo e Escopo
Garantir que mudanças em MCP server, indexer, infra e docs técnicas passem por validação proporcional ao risco com feedback rápido e reproduzível.

### Trigger policy
- Disparar quando o pedido mencionar testes, cobertura, regressão, lint, typecheck, pre-commit, qualidade de PR, estabilidade de pipeline ou contrato entre módulos.
- Disparar quando houver suspeita de quebra silenciosa ou necessidade de ampliar matriz de validação.
- Não disparar para implementar lógica de negócio principal sem foco de validação (delegar para skill de domínio: `developer-mcp-server`, `developer-indexer`, `developer-vector-db`, `developer-infra`, `developer-docs`).

## 2) Entradas esperadas
- Escopo da mudança e risco esperado (baixo/médio/alto).
- Componentes afetados (MCP server, indexer, Qdrant schema, infra).
- Estado atual de testes/lint/typecheck e lacunas conhecidas.
- Critério de aceite mínimo (ex.: sem regressão, contrato preservado, cobertura mínima).

## 3) Workflow (Discovery -> Plan -> Implement -> Validate -> Deliver)
1. Discovery
   - Mapear tipos de teste existentes e pontos sem cobertura.
   - Identificar contratos críticos que devem ser protegidos.
   - Consultar `references/checklist.md` para matriz mínima por risco.
2. Plan
   - Definir plano de validação incremental (rápido -> profundo).
   - Priorizar testes próximos da mudança antes de suites globais custosas.
3. Implement
   - Criar/ajustar testes unitários, integração, e2e e de contrato quando necessário.
   - Ajustar lint/typecheck/pre-commit de forma objetiva e sem ruído.
4. Validate
   - Executar comandos planejados e registrar resultado de cada etapa.
   - Confirmar ausência de regressão funcional e de compatibilidade.
5. Deliver
   - Entregar plano executado, artefatos de validação e próximos passos para cobertura remanescente.

## 4) DoD
- Mudança crítica tem teste automatizado cobrindo caminho feliz e falhas relevantes.
- Contratos entre módulos sensíveis têm validação explícita.
- Lint e typecheck passam sem ignorar erros novos.
- Regressões conhecidas estão bloqueadas por teste ou documentadas com plano de mitigação.
- Comandos de validação são reproduzíveis no ambiente local/CI.

## 5) Guardrails
- Não mascarar falhas com skips indiscriminados ou mocks irreais.
- Não inflar cobertura com testes sem assert relevante.
- Não quebrar suites existentes para aprovar mudança pontual.
- Não misturar refatoração ampla com correção de teste sem necessidade.
- Não criar `scripts/` nesta skill sem necessidade determinística comprovada.

## 6) Convenções de saída
- Sempre devolver: (1) plano de validação, (2) mudanças de teste/lint/typecheck, (3) comandos e resultados, (4) risco residual.
- Sempre indicar o que foi validado localmente e o que depende de CI.

## 7) Exemplos de uso (prompts)
- "Crie uma matriz mínima de testes para a nova tool MCP e evite regressões de contrato."
- "Ajuste lint e typecheck do módulo alterado sem mexer em áreas não relacionadas."
- "Adicione testes de integração para indexação incremental e operação no Qdrant."
- "Defina gates de qualidade para PR com foco em feedback rápido e confiável."
- "Padronize critérios globais de qualidade do CI e explicite quando acionar `developer-tester` para bugfix e regressão localizada."

## 8) Anti-exemplos (quando não usar)
- "Implementar endpoint/tool nova no NestJS" -> usar `developer-mcp-server`.
- "Refatorar algoritmo de chunking" -> usar `developer-indexer`.
- "Mudar configuração da collection Qdrant" -> usar `developer-vector-db`.
- "Escrever guia de onboarding técnico" -> usar `developer-docs`.
- "Reproduzir bug específico e criar teste antes/depois" -> usar `developer-tester`.
- "Executar smoke e2e de uma mudança pontual" -> usar `developer-tester`.