| name | bug-fix |
| description | Use when the user (PO) asks to fix a Foundation bug by IRI — e.g. "fix bug foundation:Bug_123", "corrija o bug foundation:Bug_456", "resolva o bug <IRI>". Orchestrates the bug pipeline: `support` (investigation & technical dossier) → `architect` Modo Triagem **Briefing** (decide BE/FE/both and produce per-dev briefings) → dispatch `developer-backend` / `developer-frontend` with the briefings → `architect` Modo Triagem **Costura** (validate builds, consolidate `## Como testar`, move to Em Validação (QA)) → `qa` (validation gate before Concluído). Sub-agents cannot call other sub-agents in Claude — this skill (which runs in the main loop) IS the orchestrator. The PO never invokes devs directly; the bug is NEVER closed without QA validation. Always invoke this skill when the user mentions a bug IRI. |
Bug Fix
Skill que conduz um foundation:Bug por todo o pipeline do FOUNDATION, dentro do ciclo:
Pendente → [Support] Pronto para Dev → [Architect Triagem Brief] Em Progresso → [Devs] → [Architect Costura] Em Validação (QA) → [QA] Concluído
(↘ Mudança Pendente)
O PO nunca fala com dev direto; o bug nunca é fechado sem passar pelo qa.
Por que a skill orquestra todos os passos: o harness do Claude não permite que um sub-agente invoque outro sub-agente. O architect (e qualquer outro agente) é sub-agente. As skills, ao contrário, rodam no main loop e PODEM disparar sub-agentes. Por isso o Modo Triagem do architect foi dividido em Briefing (devolve prompts) e Costura (recebe retornos) — esta skill faz a ponte entre os dois e dispara os devs.
Pré-requisitos
A skill recebe a IRI do bug como argumento (ex. foundation:Bug_1780369248862). Se o usuário não informar, peça antes de prosseguir.
Como executar
Esta skill é o orquestrador completo do pipeline de bug. O PO não investiga, não distribui, não corrige, não fecha — só aciona.
Passo 1 — support produz o dossiê técnico
Invoque o agente support via Agent (subagent_type: support) com prompt auto-contido:
Bug: <IRI>
Tarefa: investigue conforme o protocolo do agente Support — reproduza o sintoma (ou descreva como reproduzir), siga a ordem CLAUDE.md (logs → mensagens → DB → código), formule causa provável, mapeie camadas afetadas e arquivos suspeitos (path:linha), persista o dossiê no Bug e mova para `foundation:Status_1773079329634` (Pronto para Desenvolvimento).
Não corrija código. Não invoque outros agentes. Reporte de volta a esta skill o dossiê + indicação do próximo passo.
Se o support parar (app não rodando, IRI inválido, bug sem evidência coletável), reporte ao usuário e aguarde.
Passo 2 — architect em Modo 3a (Triagem — Briefing)
Quando o support retorna com o bug em Pronto para Dev e dossiê preenchido, invoque o agente architect via Agent (subagent_type: architect):
Modo: Triagem de Bug — 3a Briefing
Bug: <IRI>
Tarefa: executar o Modo 3a (Briefing) do Modo Triagem conforme a sua persona:
- Ler o dossiê do `support` (causeAnalysis + stepsToReproduce + expectedBehavior + camadas afetadas).
- Decidir a fatia (developer-backend / developer-frontend / ambos).
- Mover o bug para `foundation:InProgress` via `replace_property_values`.
- Produzir um briefing PRONTO PARA EU DISPARAR a cada dev envolvido.
NÃO invoque os devs — eu (esta skill) faço isso. Devolva os briefings; eu disparo e reinvoco você em Modo 3b com os retornos.
Se o dossiê estiver incompleto, NÃO investigue — reporte para eu acionar o `support` de novo.
Reporte de volta a esta skill conforme o "Relatório final — Modo 3a" da sua definição.
Se o architect reportar que o dossiê está incompleto, retorne ao Passo 1.
Passo 3 — Disparar os devs com os briefings
O architect devolve os briefings + a fatia (BE / FE / ambos). Aplique:
- Apenas BE → invoque
developer-backend com o briefing.
- Apenas FE → invoque
developer-frontend com o briefing.
- Ambos → invoque
developer-backend e developer-frontend no MESMO bloco de tool calls (paralelo), cada um com o seu briefing.
Cada dev retorna o pacote no formato da sua persona (resumo do fix, arquivos path:linha, build verde, seção ## Como testar da fatia).
Build vermelho persistente após uma rodada de correção → leve ao Passo 4 com flag de blocker para o architect decidir (em geral retraindo para Mudança Pendente).
Passo 4 — architect em Modo 3b (Triagem — Costura)
Reinvoque o agente architect via Agent (subagent_type: architect) com os retornos dos devs:
Modo: Triagem de Bug — 3b Costura
Bug: <IRI>
Retornos dos devs (consolidados, no formato exato em que cada um devolveu):
### <Backend e/ou Frontend — conforme aplicável>
<colar os retornos completos>
Tarefa: executar o Modo 3b (Costura) conforme a sua persona:
- Validar que os builds estão verdes (vermelho de qualquer lado é blocker — me reporte).
- Concatenar `## Como testar` produzido pelo(s) dev(s) num único bloco anexado ao Bug (em `foundation:causeAnalysis` ou propriedade dedicada se existir).
- `add_property_values` em `foundation:changelog`: `<YYYY-MM-DD do contexto> — fix entregue. <BE/FE/ambos>: <arquivos>. Encaminhado ao QA.`
- `replace_property_values` em `foundation:hasStatus` ← `foundation:Status_1772600993751` (Em Validação (QA)).
Reporte de volta a esta skill conforme o "Relatório final — Modo 3b" da sua definição.
Passo 5 — qa valida e fecha (ou abre regressão)
Quando o architect retorna com o bug em Em Validação (QA), invoque o agente qa via Agent (subagent_type: qa):
Tarefa: valide o Bug <IRI> conforme o protocolo de validação de Bug do QA — rode a suíte (cargo test + npm run check), reproduza os stepsToReproduce e confirme que o sintoma não acontece mais e que o comportamento bate com `expectedBehavior`. Analise logs durante a reprodução.
Decisão:
- ✅ Sintoma não reproduz + comportamento esperado + suíte verde → fechar o bug em `foundation:Completed` com veredito QA em `causeAnalysis`.
- ❌ Ainda reproduz ou regressão nova → registrar Bug novo (regressão / fix incompleto) e devolver o original para `foundation:Status_1773581282341` (Mudança Pendente).
- ⚠️ Manual → manter Em Validação (QA) e pedir confirmação do usuário.
Se o bug estava ligado a uma US (`bugOfUserStory`), sinalize se a US precisa voltar para Em Validação também.
Não invoque outros agentes. Reporte de volta a esta skill o veredito.
Passo 6 — Reportar ao usuário
Repasse o veredito do QA ao usuário com convite explícito ao próximo passo:
- Veredito ✅ → bug fechado, nada a fazer.
- Veredito ❌ → bug novo registrado; rode
/bug-fix <IRI do novo bug> para reabrir o ciclo.
- Veredito ⚠️ → guia de teste manual; aguardar confirmação do usuário antes de fechar.
Regras
- NEVER invoque o
architect na esperança de que ele dispare os devs — o architect é sub-agente e NÃO pode invocar outros sub-agentes. Quem dispara é esta skill.
- NEVER invoque
developer-backend, developer-frontend ou support fora da ordem prescrita — support antes, architect (Briefing) depois, devs, architect (Costura), qa por último.
- NEVER feche o bug aqui — Concluído é responsabilidade exclusiva do
qa após validação.
- NEVER pule o
support mesmo que o bug pareça "óbvio" — o dossiê é o input do Arquiteto, não uma formalidade.
- NEVER pule o
qa mesmo que o fix pareça trivial — todo bug (e toda US) passa pelo QA antes de fechar.
- ALWAYS passe a IRI do bug exatamente como o usuário forneceu.
- ALWAYS passe ao Modo 3b os retornos dos devs na íntegra — o architect precisa do material bruto para validar builds e consolidar o
## Como testar.
- ALWAYS lembre-se: agentes (sub-agentes) NÃO podem invocar outros sub-agentes. Quem orquestra é esta skill, no main loop.
- ALWAYS responda ao usuário em português (CLAUDE.md).
