| name | userstory-implement |
| description | Use when the user (PO) asks to implement / develop a Foundation User Story that is already in status "Planejado" or "Pronto para Dev" — orchestrates execution by (1) calling the `architect` agent in Modo Execução **Briefing** to validate state, move the US to Em Progresso and produce per-dev briefings; (2) dispatching `developer-backend` and `developer-frontend` in parallel (or sequential when the plan says so) with the briefings; (3) calling the `architect` again in Modo Execução **Costura** with the dev returns to validate builds, consolidate `## Como testar` (merging UX's "Validação pelo usuário" checklist when present), log changelog and move the story to "Em Validação (QA)". Sub-agents cannot call other sub-agents in Claude — this skill (which runs in the main loop) IS the orchestrator. The PO never talks to devs directly; the skill mediates. Skill name follows entity-action convention. |
| disable-model-invocation | false |
Implement User Story
Skill que executa uma foundation:UserStory já planejada e a entrega para validação do QA, transitando dentro do ciclo de vida oficial:
Planejado / Pronto para Dev → Em Progresso → Em Validação (QA) → (QA valida) → Concluído
(↘ Mudança Pendente / Bloqueado / Rejeitado)
Esta skill cobre Planejado → Em Progresso → Em Validação (QA). A transição final para Concluído é responsabilidade do QA depois da validação do usuário.
Por que a skill orquestra os devs (em vez de o architect chamar): o harness do Claude não permite que um sub-agente invoque outro sub-agente. O architect é um sub-agente. As skills, ao contrário, rodam no main loop e PODEM disparar sub-agentes. Por isso o protocolo de Execução do architect foi dividido em Briefing (devolve prompts) e Costura (recebe retornos) — esta skill faz a ponte entre os dois.
Pré-requisitos
A skill recebe a IRI da User Story como argumento (ex. foundation:UserStory_1778074850125). Se o usuário não informar, peça antes de prosseguir.
Como executar
Passo 1 — Acionar o Arquiteto em Modo 2a (Briefing)
Invoque o agente architect via Agent (subagent_type: architect) com prompt auto-contido. Ele valida estado, move a US para Em Progresso, lê o implementationPlan e devolve briefings prontos por dev.
Modelo de prompt para o architect:
Modo: Execução — 2a Briefing
US: <IRI da User Story>
Tarefa: executar o Modo 2a (Briefing) do Modo Execução conforme a sua persona:
- Validar pré-condições (status em Planejado / Pronto para Dev; `implementationPlan` preenchido com seção "Fatia de execução").
- Mover a US para `foundation:InProgress` via `replace_property_values`.
- Ler `capability` / `benefit` / `acceptanceCriteria` / `implementationPlan` inteiros.
- Classificar a fatia (Backend / Frontend / ambos) a partir da seção "Fatia de execução" do plano.
- Produzir um briefing PRONTO PARA EU DISPARAR a cada dev envolvido — incluindo, no briefing do `developer-frontend`, a seção `## UX/UI` INTEIRA do plano (contrato visual).
- Indicar a ordem de disparo (paralelo / sequencial e por quê).
NÃO invoque os devs — eu (esta skill) faço isso. Devolva os briefings junto com a ordem; eu disparo e reinvoco você em Modo 2b com os retornos consolidados.
Se o plano estiver errado/incompleto, NÃO desvie — retraia para `foundation:Status_1773581282341` (Mudança Pendente) e reporte para eu devolver ao PO.
Reporte de volta a esta skill conforme o "Relatório final — Modo 2a" da sua definição.
Passo 2 — Disparar os devs conforme a ordem indicada
O architect devolve os briefings + a ordem. Aplique:
- Ordem: paralelo → invoque
developer-backend e developer-frontend no MESMO bloco de tool calls (paralelo real), cada um com o seu briefing.
- Ordem: sequencial (BE primeiro) → invoque
developer-backend sozinho; quando voltar, monte o briefing do developer-frontend substituindo o trecho "Contrato do backend (assinaturas…) " pelo trecho equivalente do retorno BE; só então invoque developer-frontend.
Cada dev retorna o pacote no formato da sua persona (resumo, arquivos path:linha, build verde, seção ## Como testar).
Se algum dev retornar com build vermelho ou pedindo replan:
- Build vermelho → reenvie ao mesmo dev pedindo correção (uma rodada de retry). Se ainda vermelho na segunda volta, leve ao Passo 4 com flag de blocker para o architect decidir.
- Pedido de replan (plano errado/incompleto) → vá direto ao Passo 4 com a observação; o architect retrai para Mudança Pendente.
Passo 3 — Acionar o Arquiteto em Modo 2b (Costura)
Reinvoque o agente architect via Agent (subagent_type: architect) com os retornos dos devs.
Modelo de prompt:
Modo: Execução — 2b Costura
US: <IRI da User Story>
Retornos dos devs (consolidados, no formato exato em que cada um devolveu):
### Backend (`developer-backend`)
<colar o retorno completo do dev BE — incluindo Resumo, Arquivos tocados, Build, ## Como testar (fatia backend)>
### Frontend (`developer-frontend`)
<colar o retorno completo do dev FE — incluindo Resumo, Arquivos tocados, Componentes reusados/criados, Aderência à spec UX, Build, ## Como testar (fatia frontend)>
(Omitir a seção que não se aplica se uma das fatias era "nenhuma".)
Tarefa: executar o Modo 2b (Costura) conforme a sua persona:
- Validar que os builds estão verdes (vermelho de qualquer lado é blocker — me reporte).
- Validar cobertura de AC (a soma das fatias cobre todos os AC).
- Consolidar `## Como testar` mesclando os itens da lista "Validação pelo usuário" da seção `## UX/UI` do plano, quando existir.
- Atualizar `foundation:changelog` via `add_property_values` com a entrega de hoje (data atual: <YYYY-MM-DD do contexto>).
- Persistir plano (com `## Como testar` consolidado) + status `foundation:Status_1772600993751` (Em Validação (QA)) numa única `replace_property_values`.
Reporte de volta a esta skill conforme o "Relatório final — Modo 2b" da sua definição.
Passo 4 — Lidar com blockers vindos do architect
Se o architect em Modo 2b sinalizar blocker (build vermelho persistente, cobertura de AC incompleta, plano divergente), repasse ao usuário com o briefing pronto para a correção (que vem do architect) e aguarde decisão antes de continuar.
Passo 5 — Reportar ao usuário
Repasse o relatório final do architect (Modo 2b) ao usuário tal qual, e acrescente um convite explícito:
"A US está em Em Validação (QA). Acione o agente qa para validar pelos passos da seção ## Como testar no implementationPlan."
Não faça commit nem push — /code-commit é skill separada e o usuário decide quando consolidar.
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 o
ux aqui — UX só entra no Planejamento. A spec dele já está no plano como contrato.
- NEVER mova status, edite o
implementationPlan ou rode cargo/npm aqui — tudo isso é responsabilidade do architect (status / plano) e dos devs (build).
- NEVER mova direto para
Concluído — quem fecha é o QA, depois da validação do usuário.
- ALWAYS respeite a ordem indicada pelo architect (paralelo vs sequencial).
- ALWAYS passe a IRI da US aos agentes exatamente como o usuário forneceu — não troque por outra US "parecida".
- ALWAYS passe ao Modo 2b os retornos dos devs na íntegra — o architect precisa do material bruto para validar builds, cobertura de AC 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).
