Skills

god

Installation
SKILL.md

GOD — Skill Orquestradora

Skill principal do framework GOD. Orquestra o ciclo de vida de uma task: da inicialização até a entrega. Tem awareness de todas as sub-skills e roteia o usuário para a skill correta.

Ciclo de vida de uma task (v9 — spec-first)

install → spec → [publish-spec] → init → plan → implement → pack-up
           ↑                              ↑        ↑           ↑
        review                         review   review      review
        (spec)                         (plan)  (update)  (execution)

Mudança v9: spec passa a rodar antes do init. Isso torna a spec o gate de entrada (precede commit/branch) e permite validação externa antes de qualquer trabalho de execução. Tasks triviais (typo, copy, dep upgrade) usam init {cod} --type=trivial direto, sem spec.

  1. install — Configura o projeto (executar apenas uma vez). Pergunta specs_path (onde a spec da task vai morar) e cria GOD/config.md.
  2. spec — Entry point do fluxo na v9. Aceita input bruto direto (Jira/texto livre), busca dados em Jira/Figma, detecta perfil da task (trivial/normal/critical), faz Q&A focada em escopo, escreve REQs em EARS, ACs com IDs estáveis, cenários e NFRs em <specs_path>/tasks/{cod}.md. Roda review --spec. Em modo batch (chamado por init-tree), gera spec rascunho sem Q&A.
  3. publish-spec (opcional, sugerido em perfil critical) — Publica spec em Jira/Slack/stdout pra validar com stakeholder antes do init.
  4. init — Cria estrutura de execução em GOD/tasks/{cod}/ (plan.md vazio + status.md apontando pra spec, phase specified). Não toca em git. Aceita --type=trivial que pula spec inteira pra mudanças cosméticas.
  5. plan — Lê a spec pronta. Detecta single vs multi-project, resolve branch+base, escreve o plano focado em HOW (arquitetura, arquivos, passos), referenciando ACs. Não toca em escopo nem em git.
  6. implement — Cria a(s) branch(es) da task no git, executa o plano. Roda freshness check estendido (v9): se a spec foi atualizada via update-spec, lista ACs alterados, cruza com coverage.md e oferece reabrir passos relacionados. Consulta a spec durante a escrita. Após escrever código, valida contra learned-patterns.md.
  7. pack-up — Finaliza a task (review, commit, push, PR). Carimba spec_version_delivered no PR + link do {cod}-changelog.md se houve mudança de escopo durante a task.

Variante de entrada:

  • init-tree — variante de inicialização em lote: recebe um nó-raiz do Jira (Epic, Story, Task com subtasks), desce a árvore, cria pastas de contexto pra nós internos e gera specs rascunho pra cada folha em <specs_path>/tasks/{cod}.md (modo batch da skill spec). Não cria estrutura de execução por folha — o usuário roda spec {cod} interativo pra refinar e init {cod} quando pronto.

Ferramentas auxiliares (não são parte do fluxo linear):

  • review — Revisa qualidade em 3 modos: spec (--spec com semântica profunda; --quick pra só lint), descrição+spec vs plano (--plan), plano vs execução com cobertura de ACs (--execution). A partir da v8.1, cada modo delega pra subagent isolado com contexto fresco — fresh eyes sem viés de auto-validação. v10.3: modo configurável via peer_review_default em GOD/config.md (valores: subagent default, inline, skip). Flags CLI --subagent/--inline/--skip overridem pontual.
  • publish-spec — Publica/republica a spec em destinos configuráveis (Jira, Slack, stdout, custom). Auxiliar manual ao hook after spec.
  • coverage — Gera matriz "AC × validação" pra uma task dentro do fluxo do GOD. Parseia // covers: AC-X em testes + lê coverage.md (validações manuais). Usado pelo pack-up e review --execution, ou manual a qualquer momento. Tolerante por design — ACs órfãos viram alerta visual, decisão fica do dev.
  • status — Dashboard de tasks em andamento e suas fases
  • update-spec (v9) — Aplica mudança de escopo na spec de uma task que já passou por init. Pergunta motivo, edita spec, bumpa spec_version, escreve delta em <specs_path>/tasks/{cod}-changelog.md. Próximo implement detecta drift (freshness check estendido) e oferece reabrir passos.
  • update-plan — Atualiza o plano durante a implementação quando surgem mudanças
  • pause — Pausa uma task em andamento, registra observação opcional no changelog.md e marca paused: true no status. Pode ser invocada pelo usuário ou por implement/plan quando detectam barreira
  • resume — Retoma uma task pausada, carrega contexto do changelog, remove paused do status e delega de volta à skill da fase ativa
  • learn — Transforma uma task executada em conhecimento reutilizável (ativação explícita pelo usuário). Numa mesma invocação executa duas ações em sequência: (1) escreve entrada da task em GOD/knowledge.md; (2) pergunta ao usuário por regras generalizáveis e as anexa em GOD/learned-patterns.md. Marca learned: true no status.md sem alterar phase
  • clean-up — Arquiva tasks em packed-up cujos PRs já foram mergiados (move para GOD/tasks/.archived/). Oferece rodar learn antes de arquivar tasks ainda não aprendidas
  • code-like-me — Implementação cirúrgica que segue padrões do projeto (usada como flag do implement)
  • upgrade — Migra instalações do GOD de uma versão para outra (expansível por versão)

Delegação pra sub-skills/_lib/ (v10.2)

A partir da v10.2, processos puramente determinísticos (parsing de comentários, lint estrutural, atualização de YAML, geração de tabelas) são feitos por scripts Python em sub-skills/_lib/ em vez do LLM. Economiza tokens significativamente.

Padrão de delegação (sub-skills referenciam este padrão; não repetir lógica em cada SKILL.md):

  1. Verificar python3 ≥ 3.8 disponível: command -v python3 && python3 -c 'import sys; sys.exit(0 if sys.version_info >= (3, 8) else 1)'.
  2. Verificar script existe: [ -f sub-skills/_lib/<script>.py ].
  3. Rodar via Bash: python3 sub-skills/_lib/<script>.py <args>. Capturar stdout (JSON) e stderr separados.
  4. Se exit 0 → parsear JSON da stdout, usar resultado.
  5. Se exit != 0 ou exception → avisar usuário UMA vez com ⚠️ Script {nome} falhou (exit {code}): {stderr resumido}. Caindo pro fallback LLM. e seguir o caminho fallback documentado na própria skill.
  6. Se python3 ausente → seguir fallback silenciosamente (instalar python3 já foi sugerido pelo install ou doctor).

Garantia crítica: falha de script NUNCA interrompe o processo da skill. Skill sempre tem caminho fallback funcional via LLM. Scripts são otimização, não dependência rígida.

Scripts disponíveis:

Script Função Skills que delegam
parse_coverage.py Matriz AC × validação a partir do diff/repo coverage, pack-up, review --execution
parse_rules.py Parser de // rule: BR-X no diff (v10) pack-up, review --execution
parse_spec.py Extrai frontmatter + REQs + ACs da spec plan, implement, review
validate_spec.py Lint estrutural da spec (REQ tem AC, IDs, palavras-tabu) spec passo 8.5, review --spec
freshness_check.py Compara spec_version atual × spec_version_consumed plan, implement
update_status.py Read-modify-write de status.md spec, init, plan, implement, pack-up, learn, pause, resume, update-spec
gen_pr_description.py Markdown do PR description a partir de JSON pack-up

Todos os scripts: Python 3.8+ stdlib only. Cross-platform (macOS, Linux, WSL). Rodar python3 <script>.py --help pra ver argumentos.

Padrão de context blob (v10.4)

A partir da v10.4, skills do fluxo principal podem passar artefatos pré-lidos pra sub-skills/subagents em vez de cada um ler do disco. Reduz leituras redundantes (mesmo status.md lido 3x numa execução de pack-up vira 1x).

Quando usar

Skills que orquestram outras skills/subagents:

  • pack-up — chama coverage, review --execution. Carrega context no início e passa adiante.
  • spec — chama review --spec. Pode passar context (input bruto, dados Jira, knowledge consultado).
  • plan — chama review --plan. Pode passar context (spec, description).

Estrutura do context blob

JSON serializável com chaves específicas por skill. Exemplo pra pack-up:

{
  "task": "PROJ-123",
  "status": "<conteúdo de GOD/tasks/PROJ-123/status.md>",
  "plan": "<conteúdo de plan.md>",
  "spec": "<conteúdo da spec, se cabe inline>",
  "spec_path": "docs/specs/tasks/PROJ-123.md",
  "coverage": "<conteúdo de coverage.md, se existe>",
  "patterns": "<conteúdo de GOD/patterns.md>",
  "hooks": "<conteúdo relevante de hooks.md>"
}

Threshold pra arquivos grandes (lazy via path)

Pra evitar prompt gigante:

Se um arquivo > 8000 chars (~2000 tokens):
  - NÃO incluir o conteúdo no context blob
  - Incluir apenas o path (ex: "spec_path": "...")
  - Sub-skill/subagent decide se lê tudo ou faz scan parcial
Senão:
  - Incluir conteúdo inline

Threshold é heurístico, não rígido. Skill chamadora decide.

Como sub-skill consome

Sub-skills/subagents ficam flexíveis — aceitam context inline mas têm fallback pra ler do disco. Padrão:

1. Verificar se context foi passado (chave existe e não é vazia).
2. Se sim: usar direto, sem invocar Read.
3. Se não: ler do disco (caminho original v10.3).

Garantia: retrocompat preservada. Invocação sem context blob continua funcionando.

Como subagent recebe

Skill chamadora invoca Agent tool com prompt que inclui o context:

Agent({
  description: "Review execution PROJ-123",
  prompt: """
  CONTEXTO PRÉ-CARREGADO (não invoque Read pra estes arquivos):
  
  === status.md ===
  {context.status}
  
  === plan.md ===
  {context.plan}
  
  ...
  
  INSTRUÇÕES:
  {prompt original do modo}
  """
})

Subagent reconhece o cabeçalho === arquivo === e usa o conteúdo direto. Pra arquivos não pré-carregados (ex: arquivos do diff em --execution), continua usando Bash/Read normalmente.

Hooks do fluxo

Cada step do fluxo principal (init, spec, plan, implement, pack-up) executa hooks opcionais antes e depois de sua lógica principal, lidos de GOD/hooks.md. Se o slot estiver com skip-hook, pula. Se tiver instruções em linguagem natural, a skill executa.

A partir da v7: a skill spec ganhou hooks dedicados (before spec e after spec). Caso de uso típico do after spec: publicar a spec recém-criada como comentário no Jira ou mensagem no Slack pra que PM/UX/CTO fiquem sabendo automaticamente, sem depender de eles abrirem o repo.

Ferramentas auxiliares (learn, update-plan, review, status, pause, resume, code-like-me, publish-spec, upgrade) não têm hooks.

Mapa de sub-skills

Skill Localização Quando usar
install sub-skills/install/SKILL.md Primeira vez no projeto — configura GOD
spec sub-skills/spec/SKILL.md Entry point do fluxo (v9) — produzir a spec canônica antes do init. Modos: interativo (default), batch (chamado por init-tree), --review-feedback (incorpora feedback antes do init), --quick (skip semântica). v10.1: roda análise heurística pré-Q&A (detecção de excessos/gaps via heuristics.md), self-validação inline, oferece feature split, aceita --target pra publicar direto.
init sub-skills/init/SKILL.md Criar estrutura de execução pós-spec. Aceita --type=trivial pra mudanças cosméticas que pulam spec.
init-tree sub-skills/init-tree/SKILL.md Começar em lote via árvore do Jira (Epic/Story + subtasks). Gera specs rascunho, não cria estrutura de execução por folha.
publish-spec sub-skills/publish-spec/SKILL.md Publicar/republicar a spec em targets externos (Jira, Slack, stdout) — manual
coverage sub-skills/coverage/SKILL.md Gerar matriz AC × validação pra uma task. Manual ou via pack-up/review
plan sub-skills/plan/SKILL.md Planejar a implementação técnica (HOW)
implement sub-skills/implement/SKILL.md Executar o plano. Freshness check estendido (v9) detecta drift de spec via changelog.
pack-up sub-skills/pack-up/SKILL.md Finalizar e entregar a task. Carimba spec_version_delivered no PR.
review sub-skills/review/SKILL.md (v10.4) Wrapper de roteamento — delega pra review-spec/review-plan/review-execution. Mantém invocação review --modo retrocompatível
review-spec sub-skills/review-spec/SKILL.md (v10.4) Verificações específicas do modo --spec (estrutura + lint + semântica).
review-plan sub-skills/review-plan/SKILL.md (v10.4) Verificações específicas do modo --plan (cobertura ACs, scope creep, considerações arquiteturais).
review-execution sub-skills/review-execution/SKILL.md (v10.4) Verificações específicas do modo --execution (passos executados, cobertura, BRs anotadas).
status sub-skills/status/SKILL.md Ver estado das tasks
doctor sub-skills/doctor/SKILL.md (v10.2) Diagnóstico do ambiente: python3, git, gh, MCPs, GOD/ consistência, scripts em _lib/, tasks ativas. Read-only.
update-spec sub-skills/update-spec/SKILL.md (v9) Aplicar mudança de escopo na spec pós-init. Bumpa spec_version, escreve em {cod}-changelog.md
update-plan sub-skills/update-plan/SKILL.md Alterar plano durante implementação
pause sub-skills/pause/SKILL.md Pausar task em andamento e registrar observação
resume sub-skills/resume/SKILL.md Retomar task pausada e continuar
learn sub-skills/learn/SKILL.md Transformar task executada em conhecimento
clean-up sub-skills/clean-up/SKILL.md Arquivar tasks em packed-up com PRs mergiados
code-like-me sub-skills/code-like-me/SKILL.md Flag do implement para código cirúrgico
upgrade sub-skills/upgrade/SKILL.md Migrar instalação entre versões do GOD

Roteamento inteligente

Quando o usuário interagir, identifique a intenção e delegue para a sub-skill correta:

Intenção do usuário Sub-skill
"instalar", "configurar", "setup" install
"nova task", "iniciar task", código do Jira, link do Jira, "criar spec", "spec da task", "escrever spec", "escopo", "requisitos da task", "critérios de aceitação" spec (entry point v9)
"task trivial", "typo", "trocar copy", "atualizar dep" + código identificador init --type=trivial
"criar estrutura da task", "iniciar execução", "init", quando spec já foi feita init
"init em lote", "iniciar epic", "iniciar várias tasks", "subtasks do jira", "criar tasks da árvore" init-tree
"feedback do PM antes do init", "stakeholder respondeu", "incorporar feedback pré-init" spec --review-feedback
"spec mudou", "PM mudou de ideia", "mudança de escopo", "update spec", "atualizar spec depois do init" update-spec
"publicar spec", "republicar spec", "compartilhar spec", "publish spec" publish-spec
"cobertura", "coverage", "que ACs estão testados", "matriz de cobertura", "AC sem teste" coverage
"planejar", "criar plano", "como implementar" plan
"implementar", "executar", "codar", "desenvolver" implement
"finalizar", "entregar", "pack up", "commitar e subir PR" pack-up
"status", "como estão as tasks", "dashboard" status
"doctor", "god doctor", "checar god", "verificar instalação", "está tudo ok?", "diagnosticar god", "o que falta no setup" doctor
"mudar o plano", "atualizar plano", "o plano mudou" update-plan
"pause", "pausar", "pausar task", "tô travado", "parar aqui", "retomo depois" pause
"resume", "retomar", "continuar task", "voltar na task", "destravei" resume
"registrar aprendizado", "learn", "o que aprendi", "transformar em conhecimento" learn
"clean-up", "limpar tasks", "arquivar tasks", "remover tasks concluídas", "arrumar a casa" clean-up
"upgrade", "atualizar god", "migrar god", "v1 para v2" upgrade
"migrate", "migrar do gdd", "migrar gdd para god", "tenho o gdd instalado" upgrade

Verificação de versão instalada

Antes de delegar para qualquer sub-skill exceto install e upgrade, verificar:

  1. Existe GOD/VERSION?

    • Se não existe e GDD/ existe (pasta da skill antiga) → instalação legada da skill GDD. Alertar o usuário e sugerir upgrade (ou migrate) para migrar de GDD para GOD. Não executar a skill solicitada até a migração rodar.
    • Se não existe e GOD/ existe (sem VERSION) → instalação v1. Alertar o usuário e sugerir upgrade antes de prosseguir. Não executar a skill solicitada até o upgrade rodar.
    • Se não existe e nem GOD/ nem GDD/ existem → sugerir install.
    • Se existe → ler o valor.

  2. Valor de GOD/VERSION corresponde à versão atual do GOD (v10)?

    • Sim → prosseguir com a skill solicitada.
    • Não → alertar o usuário e sugerir upgrade.

Verificação de pré-requisitos

Antes de delegar para uma sub-skill, verifique se os pré-requisitos foram cumpridos:

Sub-skill Pré-requisitos
install Nenhum (se GOD/ já existe, sugerir upgrade em vez de reinstalar)
spec GOD/ deve existir na versão atual. Aceita input bruto direto (não exige description.md). Precisa ler GOD/config.md para resolver specs_path — se ausente, usar default docs/specs/. Modo --review-feedback exige <specs_path>/tasks/{cod}.md existente e GOD/tasks/{cod}/status.md ausente (init ainda não rodou). Modo batch é programático (chamado por init-tree).
init <specs_path>/tasks/{cod}.md deve existir (spec rodou) — exceto em --type=trivial, que dispensa. Se nenhum existir, orientar spec {cod} ou init {cod} --type=trivial.
init-tree GOD/ deve existir na versão atual; MCP Atlassian disponível e autenticado; specs_path resolvível
publish-spec Spec deve existir em <specs_path>/tasks/{cod}.md. Targets desconhecidos exigem definição em hooks.md como # publish-spec target: <nome>
coverage <specs_path>/tasks/{cod}.md deve existir (spec criada). Se ausente, retorna "não aplicável" silenciosamente
plan GOD/tasks/{cod}/status.md deve ter spec_path populado e ser não-trivial. Se ausente, sugerir rodar spec + init. Precisa ler GOD/patterns.md para resolver branch
implement GOD/tasks/{cod}/plan.md deve estar preenchido e status.md deve ter branch e branch_base populados (plan executado). Em modo trivial, plan é pulado e implement resolve a branch. Se algo essencial faltar, sugerir rodar plan primeiro
pack-up Deve haver alterações no git para commitar (implement executado). Se não houver, informar o usuário
update-spec GOD/tasks/{cod}/status.md deve existir (init executado) e <spec_path> ainda apontar pra arquivo válido. Se status.md ausente, sugerir spec --review-feedback em vez
doctor Nenhum — skill é read-only e detecta o que existe no ambiente
update-plan GOD/tasks/{cod}/plan.md deve existir e estar preenchido
pause GOD/tasks/{cod}/status.md deve existir e phase ≠ packed-up; não deve estar já pausada
resume GOD/tasks/{cod}/status.md deve existir com paused: true
learn Task deve ter pelo menos um commit registrado (pack-up executado)
clean-up GOD/tasks/ deve existir; gh CLI instalado e autenticado
status GOD/ deve existir
upgrade GOD/ deve existir (skill detecta versão automaticamente)

Recuperação e continuação

Se o usuário retorna após uma interrupção:

  1. Verificar estado atual — Rodar status internamente para entender onde parou
  2. Checar pausa antes de qualquer coisa — Ler GOD/tasks/{cod}/status.md (campo paused):
    • Se paused: true → sugerir resume antes de qualquer outra skill. O contexto da pausa está em changelog.md e resume cuida da retomada
  3. Identificar fase — Se a task não está pausada, ler o campo phase e sugerir o próximo passo:
    • initialized (legacy v8) → sugerir spec
    • specified → sugerir plan (ou implement se profile=trivial)
    • planned → sugerir implement
    • implementing → sugerir continuar o implement ou rodar update-plan se o plano mudou; rodar update-spec se a spec mudou
    • implemented → sugerir pack-up
    • packed-up:
      • Se learned: false → sugerir learn (opcional) e depois clean-up quando os PRs forem mergiados
      • Se learned: true → sugerir clean-up quando os PRs forem mergiados
  4. Fallback — Se status.md não existir (task criada antes da spec rodar, fluxo v9 normal), inferir pelos artefatos:
    • <specs_path>/tasks/{cod}.md existe → spec já rodou, sugerir init {cod} pra criar estrutura de execução
    • Nada existe → sugerir spec {cod} (entry point v9) ou init {cod} --type=trivial se for cosmético
    • Casos legacy v8: GOD/tasks/{cod}/description.md existe mas spec ainda não → sugerir spec {cod} (vai ler o description.md por retrocompat); plan.md preenchido mas sem alterações no git → implement; alterações não commitadas → pack-up
    • PR já criado → task finalizada
  5. Sugerir próximo passo — Informar o usuário onde parou e qual skill rodar

Comando: help

Quando o usuário pedir ajuda, disser "help", "o que posso fazer?", "como funciona?" ou qualquer variação:

  1. Verificar se o projeto já foi instalado — checar se GOD/ existe
  2. Verificar versão — checar GOD/VERSION; se desatualizada, sugerir upgrade antes de tudo
  3. Verificar se há tasks em andamento — checar GOD/tasks/
  4. Montar resposta contextual:

Se o projeto NÃO foi instalado:

👋 **Bem-vindo ao GOD — Goal Oriented Development!**

O GOD orquestra o ciclo completo de uma task: da spec à entrega do PR.

🚀 **Para começar, rode `install`** — isso vai configurar o projeto criando a pasta GOD/ com:
  • VERSION — versão instalada (atualmente v10)
  • config.md — configuração local (specs_path: onde a spec da task vai morar)
  • knowledge.md — registro de tasks finalizadas (escrito apenas pelo `learn`)
  • patterns.md — convenções do projeto (branch, commit, PR, ações finais)
  • learned-patterns.md — regras generalizáveis escopadas (geral/linguagem/projeto), escritas pelo `learn` após revisão de PR e aplicadas pelo `implement` após a escrita de código
  • hooks.md — pontos de extensão por step (before/after de spec, init, plan, implement, pack-up)
  • tasks/ — pasta onde cada task terá plan e status (sem `description.md` em v9 — o input bruto vai pra spec)

A v9 entregou **Spec-first + spec viva**:
  • Spec passa a ser o entry point do fluxo: `spec → [publish-spec] → init → plan → implement → pack-up`. Spec rejeitada não polui o repo com branch órfã.
  • 3 perfis de task: `trivial` (cosmético, pula spec via `init --type=trivial`), `normal` (sem publish-spec automático), `critical` (sugere publish-spec antes do init).
  • `update-spec`: muda escopo pós-init, bumpa `spec_version`, escreve em `<specs_path>/tasks/{cod}-changelog.md`. `implement` detecta drift via freshness check estendido.
  • `pack-up` carimba `spec_version_delivered` no PR + link do changelog se houve mudança.

A v10 entrega **Architecture advisor + Domain rules** (artefatos opcionais e configuráveis):
  • `principles_path` (default `GOD/principles.md`) — princípios duradouros do projeto. `plan` lê e gera bloco "Considerações arquiteturais" sinalizando desvios sem bloquear.
  • `architecture_path` (default `GOD/architecture.md`) — padrões "preferidos mas negociáveis". Lido junto com principles. Flags `--skip-architecture`, `--refactor`, `--preserve` no `plan`.
  • `domains_path` (default `<specs_path>/domains/`) — pasta com arquivos `<dominio>.md`, BRs com IDs derivados do `domain:` do frontmatter (ex: `BR-PAYMENTS-007`). Agnóstico ao projeto.
  • `spec` sugere `applicable_rules` no frontmatter da spec baseado em description (heurística + confirmação).
  • `implement` sugere comentário `// rule: BR-X — descrição` no código onde a invariante é enforced.
  • `pack-up` injeta tabela "BRs aplicáveis × anotadas" no PR (similar à matriz de cobertura da v8).
  • Tudo opcional: quem não ativar (deixar paths vazios em `config.md`), fluxo segue silenciosamente.

A v10.1 (patch transversal) unifica a skill `spec` com qualidades antes restritas à skill global `god-spec`:
  • Análise heurística pré-Q&A: detecta excessos (HOW dentro do WHAT — pseudo-código, framework leak, schema técnico) e gaps (NFRs ausentes, ator não nomeado, cenários de erro). Tabelas em `sub-skills/spec/heuristics.md`.
  • Q&A focada apenas em gaps detectados — não pergunta blocos completos quando o input já cobre.
  • Seção `## Notas técnicas (input pro plan)` no template — preserva pseudo-código que veio no input sem contaminar REQs/ACs.
  • Self-validação inline antes de delegar pro `review --spec` — corrige trivial sozinha (auto-numerar IDs, adicionar NFRs com placeholders, mover framework leak).
  • Feature/subtask split inline — quando heurística detecta feature, oferece quebrar em spec pai + N subtasks (alternativa ao `init-tree` quando a árvore Jira ainda não existe).
  • Flag `--target jira/slack/file/stdout/clipboard` — após escrever spec canônica, publica adicionalmente no destino (delega pra `publish-spec` internamente).
  • Apresentação ASCII no relatório final.
  • Resultado: **uma fonte única** pra escrever bem o WHAT — `god-spec` global continua existindo só como wrapper offline pra projetos sem GOD instalado.

Tudo da v6/v7/v8/v9 segue funcionando: spec extraída, review semântico, freshness check, publish-spec, rastreabilidade AC × validação, spec viva.

Após instalar, preencha o `patterns.md` com as convenções do seu projeto. Os hooks e os artefatos da v10 (principles/architecture/domains) são opcionais.

Integrações opcionais (não obrigatórias):
  • Jira (Atlassian MCP) — busca automática de tasks
  • Figma (Figma MCP) — análise de design durante planejamento

Se a instalação está em versão antiga:

⚠️ **GOD detectado em versão anterior**

A versão atual é v10 mas sua instalação está em {versão-detectada}.

Rode `upgrade` para migrar sua estrutura automaticamente — seus valores (patterns, tasks, knowledge) são preservados.

Se o projeto JÁ foi instalado, está na versão atual e NÃO há tasks:

📋 **GOD — Pronto para começar!**

Seu projeto está configurado. Para iniciar sua primeira task (v9 — spec-first):

1. `spec` — Entry point. Passe o link/código do Jira ou descreva a task manualmente
   → Aceita input direto (sem `init` antes). Busca dados em Jira/Figma, faz Q&A focada em escopo
   → Detecta perfil: `trivial` (pula spec), `normal` (default), `critical` (sugere publish-spec antes do init)
   → Escreve REQs em EARS, ACs com IDs estáveis, cenários e NFRs em `<specs_path>/tasks/{cod}.md`
   → Roda `review --spec` antes de finalizar
   → Modo `--review-feedback`: incorpora feedback do stakeholder antes do init (incrementa spec_version)
   → Modo `batch` (chamado por `init-tree`): gera spec rascunho sem Q&A
   → Para mudança trivial (typo, copy, dep upgrade): pule pra `init {cod} --type=trivial` direto

2. `publish-spec` *(opcional, sugerido em perfil critical)* — Publica spec pra validação externa
   → Targets configuráveis (Jira, Slack, stdout, custom)
   → Use antes do `init` quando quiser travar a spec com PM/UX

3. `init` — Cria estrutura de execução pós-spec
   → `GOD/tasks/{cod}/` com plan.md vazio + status.md apontando pra spec
   → Lê o `profile` da spec pra coerência de fase
   → Aceita `--type=trivial` que dispensa spec (mudança cosmética)

4. `plan` — Lê a spec e produz o plano técnico
   → Consulta knowledge, lê CLAUDE.md/ARCHITECTURE.md, resolve branch
   → Foca exclusivamente em HOW (arquitetura, arquivos, passos)
   → Cada passo do plano referencia ACs específicos da spec

5. `implement` — Cria a(s) branch(es) no git e executa o plano
   → **Freshness check estendido (v9)**: se a spec foi atualizada via `update-spec`, lê o changelog, cruza ACs alterados com `coverage.md` e oferece reabrir passos
   → Por padrão aplica `code-like-me`. Use `--skip-code-like-me` pra desativar
   → Anota `// covers: AC-X` nos testes (v8 — alimenta a matriz de cobertura)
   → Verifica contra `learned-patterns.md`

6. `pack-up` — Finaliza e entrega
   → Review (com cobertura de ACs em v8), commit, push, PR
   → Carimba `spec_version_delivered` no PR + link do `{cod}-changelog.md` se houve mudança durante a task

Ferramentas auxiliares (quando precisar):
  • `init-tree` — Iniciar em lote via árvore Jira (gera specs rascunho em batch)
  • `update-spec` *(v9)* — Aplicar mudança de escopo pós-init (bumpa spec_version, escreve em changelog)
  • `update-plan` — Alterar plano durante implementação
  • `publish-spec` — Publicar/republicar spec em targets externos
  • `coverage` — Matriz AC × validação pra uma task (manual ou via pack-up)
  • `status` — Ver dashboard de tasks
  • `pause` / `resume` — Pausar e retomar uma task em andamento
  • `learn` — Transformar task em conhecimento (ativação explícita)
  • `clean-up` — Arquivar tasks em `packed-up` cujos PRs já foram mergiados
  • `upgrade` — Migrar para versão mais nova do GOD

Se há tasks em andamento:

Rodar status internamente e apresentar o dashboard junto com a sugestão do próximo passo:

📋 **GOD — Você tem tasks em andamento!**

{dashboard do status}

💡 Sugestão: {próximo passo baseado na fase da task mais recente}

Fluxo v9 (spec-first):
  • `spec`         — **Entry point** (escopo, ACs, cenários, NFRs em `<specs_path>/tasks/{cod}.md`)
  • `publish-spec` — Publicar pra validar com stakeholder (sugerido em perfil critical)
  • `init`         — Criar estrutura de execução apontando pra spec. `--type=trivial` pula spec
  • `init-tree`    — Iniciar em lote via árvore Jira (specs rascunho em batch)
  • `plan`         — Criar plano técnico (arquitetura, arquivos, passos — referencia ACs)
  • `implement`    — Executar o plano (cria a branch no git, freshness check estendido)
  • `pack-up`      — Finalizar e entregar (commit + PR com `spec_version_delivered` + link do changelog)

Ferramentas auxiliares:
  • `update-spec`  — *(v9)* Mudança de escopo pós-init: bumpa spec_version, escreve em changelog
  • `update-plan`  — Alterar plano durante implementação
  • `coverage`     — Matriz AC × validação pra uma task (v10.2: delega pra script Python quando disponível)
  • `learn`        — Transformar task em conhecimento (ativação explícita)
  • `clean-up`     — Arquivar tasks em `packed-up` cujos PRs já foram mergiados
  • `status`       — Ver dashboard completo
  • `doctor`       — *(v10.2)* Diagnóstico do ambiente: python3, git, gh, MCPs, GOD/ consistência. Read-only.
  • `pause`        — Pausar task em andamento e registrar observação no changelog
  • `resume`       — Retomar task pausada
  • `upgrade`      — Migrar para versão mais nova do GOD
Related skills

More from davidsgoncalves/goal-oriented-development

Installs
15
Repository
davidsgoncalves…elopment
GitHub Stars
1
First Seen
Apr 16, 2026
Security Audits
Gen Agent Trust HubPass
SocketPass
SnykPass