SkillEngenhariaSíntese

Síntese e Priorização do Diagnóstico

Consolida achados de dívida técnica em um mapa priorizado por risco, impacto e esforço, pronto para planejamento.

Em:Diagnóstico de Dívida Técnica Crítica
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo

Em uma frase.

Consolidar todos os achados das etapas anteriores do diagnóstico — contexto de negócio, mapa de dependências, relatório de complexidade e registro de riscos — em um diagnóstico priorizado por risco × impacto × esforço, com recomendação de ação por componente e sumário executivo legível por stakeholders não-técnicos.

Aplicação

Quando
faz sentido.

Usar
  • Como Etapa 5 (final) do workflow de Diagnóstico de Dívida Técnica Crítica.
  • Quando as análises individuais estão prontas mas o time precisa de uma visão consolidada para tomar decisões.
  • Quando é necessário comunicar a situação da dívida técnica para PMs, CTOs ou stakeholders de negócio.
Não usar
  • Para sintetizar feedback de code review de PRs — use writing-structured-feedback.
  • Quando apenas uma dimensão foi analisada (só complexidade ou só dependência) — a síntese exige as 4 dimensões.
  • Como substituto de análise — esta skill sintetiza, não analisa. As etapas anteriores são obrigatórias.
Prompt

Instruções
para a IA.

Passo 1 — Cruzar dimensões de análise por componente

Para cada componente identificado nos relatórios anteriores, criar uma visão cruzada:

| Componente | Complexidade (CC) | Acoplamento (Ca/Ce) | Churn | Risco (score) | Impacto de negócio | Guardrails OK? |

|------------|-------------------|---------------------|-------|---------------|--------------------|----| | ... | ... | ... | ... | ... | ... | Sim/Não |

Componentes que são "vermelhos" em 3+ dimensões são os candidatos mais urgentes a intervenção.

Passo 2 — Calcular score de priorização por componente

Para cada componente, calcular um score composto que equilibre:

- **Risco (R):** Score da matriz de riscos (1-25). Peso: 40%.

- **Impacto (I):** Quanto o negócio é afetado pela dívida neste componente (1-5, baseado na ficha de contexto). Peso: 35%. - **Esforço inverso (E):** Quanto de esforço a refatoração requer (5=baixo esforço, 1=esforço enorme). Peso: 25%.

**Fórmula:** `Score = (R/25 × 0.4) + (I/5 × 0.35) + (E/5 × 0.25)`

Scores próximos de 1.0 são prioridade máxima (alto risco, alto impacto, esforço gerenciável). Scores próximos de 0.0 podem ser adiados.

Passo 3 — Classificar recomendação de ação por componente

Com base no score e nas análises, classificar cada componente em uma das ações:

- **Refatorar (urgente):** Score ≥ 0.7. Complexidade alta + risco alto + impacto no negócio. Deve entrar no plano imediatamente.

- **Refatorar (planejado):** Score 0.4-0.7. Significativo mas gerenciável. Planejar para os próximos sprints. - **Isolar:** Qualquer score, mas acoplamento muito alto. Antes de refatorar, encapsular atrás de uma interface estável. - **Monitorar:** Score < 0.4. Complexo mas estável (baixo churn, bons testes). Não intervir agora, revisitar em 6 meses. - **Reescrever (projeto separado):** Quando a refatoração incremental é inviável — acoplamento tóxico, sem testes, sem invariantes testáveis. Requer decisão de produto.

Passo 4 — Identificar dependências entre ações

Algumas refatorações só podem começar depois de outras:

- Componente A precisa ser isolado antes de Componente B ser refatorado (porque B depende de A).

- Guardrails ausentes precisam ser implementados antes de qualquer mudança nos componentes de risco ≥ 15. - Testes de contrato precisam existir antes de mudar APIs consumidas por outros times.

Produzir um grafo de precedência simples que indique a ordem viável.

Passo 5 — Produzir sumário executivo para stakeholders

Redigir um sumário de 1 página que qualquer PM ou CTO entenda:

```

## Diagnóstico de Dívida Técnica — [Nome do Módulo]

Situação Atual

[2-3 frases: o módulo faz X para o negócio, está com dívida técnica em Y dimensões, isso está causando Z problemas concretos]

Impacto no Negócio

- [Problema 1]: está custando [tempo/dinheiro/risco] porque [evidência]. - [Problema 2]: ... - [Problema 3]: ...

Recomendação

[Ação principal recomendada com timeline estimada]

Próximos Passos

1. [Ação imediata] 2. [Ação curto prazo] 3. [Ação médio prazo] ```

Passo 6 — Produzir diagnóstico técnico completo

Consolidar tudo em um documento técnico detalhado:

```

## Diagnóstico Técnico Completo — [Nome do Módulo]

1. Sumário Executivo

[Passo 5]

2. Ranking de Componentes por Prioridade

| # | Componente | Score | Ação recomendada | Justificativa | |---|-----------|-------|------------------|---------------| | 1 | ... | ... | ... | ... |

3. Grafo de Precedência

[Lista ou diagrama de dependências entre ações]

4. Guardrails Ausentes (bloqueadores)

[Lista de ações de segurança que devem ser implementadas antes de refatorar]

5. Estimativa de Esforço Bruta

| Ação | Componentes | Esforço estimado | Risco | |------|-------------|-----------------|-------| | ... | ... | ... | ... |

6. Anexos

- Ficha de contexto completa - Mapa de dependências - Relatório de complexidade - Registro de riscos ```

---
Constelação

Onde
ela vive.

Workflows que usam
Bundles que incluem