3bb2f8f1c5
* chore: wire docs/agents config into AGENTS.md Agent skills section
Add the `## Agent skills` discovery block pointing the engineering
skills at the existing docs/agents/{issue-tracker,triage-labels,domain}.md
files (issue tracker, triage label mapping, single-context domain docs).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: rebrand to GSD Core and restructure docs with Diataxis
Reorganise the root README and docs/ around the Diataxis framework
(tutorials, how-to guides, reference, explanation), add new how-to
guides and schema references (STATE.md / CONTEXT.md / PLAN.md /
planning artifacts), and cross-link the whole set. Update the lone
legacy gsd-build reference to open-gsd; keep internal get-shit-done/
filesystem paths unchanged (directory rename tracked separately in
open-gsd/gsd-core#604). Regenerate the ja-JP, ko-KR, pt-BR and zh-CN
localised trees to mirror the new structure.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* docs: backfill changeset PR number (#605)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
5.1 KiB
Como verificar e publicar uma fase
Objetivo: Conduzir o trabalho executado pelo processo de testes de aceitação do usuário, diagnosticar e corrigir eventuais falhas e, em seguida, abrir um pull request com o corpo gerado automaticamente.
Pré-requisitos: A fase deve ter sido executada e possuir arquivos SUMMARY.md. Se a execução ainda não foi concluída, consulte Executar uma fase.
Executar os testes de aceitação do usuário
/gsd-verify-work 1
O GSD lê os arquivos SUMMARY.md da fase, extrai as entregas observáveis pelo usuário e guia você por elas uma de cada vez. Para cada ponto de verificação, ele apresenta o que deveria acontecer e pergunta se a realidade corresponde.
yes/y/ vazio → aprovado, avança para o próximo teste- Qualquer outra coisa → registrado como um problema; a severidade é inferida a partir da sua descrição
Você nunca precisa categorizar a severidade — o GSD a infere a partir das suas palavras ("trava" → bloqueador, "não funciona" → grave, "está estranho" → cosmético).
O progresso é gravado em .planning/phases/01-<name>/01-UAT.md e sobrevive a um /clear. Se uma sessão for interrompida, execute novamente /gsd-verify-work 1 e o GSD oferece a opção de retomar a partir do último ponto de verificação.
Quando falhas são encontradas: diagnóstico automático e planejamento de correção
Se algum teste reportar problemas, o GSD prossegue automaticamente:
- Diagnostica as causas raiz — cria agentes de depuração paralelos, um por problema, e atualiza o
UAT.mdcom as causas raiz. - Planeja o fechamento das lacunas — cria um
gsd-plannerno modo de fechamento de lacunas, que lê oUAT.md(com os diagnósticos) e escreve novos arquivosPLAN.md. - Verifica os planos de correção — cria um
gsd-plan-checkerpara garantir que os planos são executáveis. Se problemas forem encontrados, o planner e o checker iterarão até três vezes. - Apresenta o próximo passo — quando os planos passam pelo checker:
Plans verified and ready for execution.
`/clear` then `/gsd-execute-phase 1 --gaps-only`
Execute o comando sugerido para aplicar as correções e, em seguida, execute novamente /gsd-verify-work 1 para confirmar que tudo passa.
Quando todos os testes passam: publicar a fase
Quando todos os testes de aceitação passam (ou se esta é a primeira execução e nenhum problema é encontrado), a fase é marcada como concluída em ROADMAP.md e STATE.md automaticamente.
/gsd-ship 1
O GSD executa verificações de pré-voo (status de verificação, árvore de trabalho limpa, branch, remoto, autenticação da CLI gh), envia o branch e cria um PR:
/gsd-ship 1 # PR pronto para revisão
/gsd-ship 1 --draft # PR em rascunho — útil quando mais fases virão a seguir
O corpo do PR é montado automaticamente a partir dos artefatos de planejamento:
- Objetivo da fase em
ROADMAP.md - Resumos por plano dos arquivos
SUMMARY.mde seus arquivos principais - Requisitos atendidos (REQ-IDs)
- Status de verificação em
VERIFICATION.md - Decisões-chave em
STATE.md
Não é necessário escrever o corpo manualmente.
Opcional: revisão de código antes ou depois de publicar
/gsd-ship não executa uma revisão de código automaticamente, mas você pode incluir uma a qualquer momento:
Antes da verificação (identifica problemas antes dos testes de aceitação):
/gsd-code-review 1 # Revisão padrão
/gsd-code-review 1 --fix # Revisão com correção automática de achados Críticos + Avisos
Depois que o PR estiver aberto (para controlar a qualidade antes do merge):
/gsd-code-review 1 --depth=deep # Análise entre arquivos incluindo grafos de importação
Consulte Configurar revisão entre IAs para configurar o Gemini, Codex ou outros revisores para revisão de planos mais cedo no ciclo.
Opcional: criar um branch de PR limpo
Se o seu branch contiver commits de .planning/ que você não quer que os revisores vejam:
/gsd-pr-branch # Filtrar contra main
/gsd-pr-branch develop # Filtrar contra develop
/gsd-pr-branch cria um novo branch apenas com mudanças de código — commits de artefatos de planejamento são excluídos. Execute antes de /gsd-ship se a política de revisão da sua equipe exclui ruído de planejamento.
Encerrando um marco
Se esta foi a última fase do marco, execute a auditoria do marco e arquive-o:
/gsd-audit-milestone # Verificar se todos os requisitos foram entregues
/gsd-complete-milestone # Arquivar, criar tag git
/gsd-complete-milestone é o próximo passo natural após o merge do PR. Consulte O ciclo de fases para entender como a verificação e a publicação se encaixam no ciclo de vida completo do projeto.