specification authoring, clarification, constitution, planning, tasks, analysis, checklist, or implementation from specs/
Repository model
.specify/ stores templates, scripts, and constitution.
specs/<feature-branch>/ stores feature artifacts.
OpenCode command entrypoints live in .opencode/commands/.
GitHub Copilot discovery surfaces live in .github/prompts/ and .github/agents/.
Antigravity discovery surfaces live in .gemini/commands/.
Safe parity rules
Keep all writes inside this repository.
Never let Speckit automation rewrite home-dir configs or unrelated governance files.
関連 Skill
Generated context summaries belong in .specify/context/ and should remain repo-local.
GitHub issue export for Speckit must use gh.
Fluxo recomendado obrigatorio
Sempre que o usuario pedir Speckit para nova feature ou qualquer atividade orientada por especificacao, siga este fluxo.
Nunca pule para um comando tardio se os artefatos previos exigidos nao existirem ou estiverem desatualizados.
Fase 0 - Ownership e superficie ativa
Resolver o repositorio dono antes de qualquer acao.
Se estiver em hub/roteador, encaminhar para o repo filho antes de qualquer write.
Usar as superficies nativas da ferramenta ativa: .opencode/commands/, .github/prompts/, .github/agents/ e .gemini/commands/.
Fase 1 - Preflight e contexto
Ler preflight, instrucoes e skills obrigatorias do repo dono.
Confirmar safe parity, .specify/, specs/ e feature branch alvo.
Se for continuidade, localizar e revisar os artefatos existentes antes de criar novos.
Fase 2 - Constituicao
Rodar /speckit.constitution quando a constituicao nao existir, estiver desatualizada, ou quando a solicitacao alterar regras de governanca/operacao.
Fase 3 - Especificacao
Para nova feature ou mudanca de escopo, rodar /speckit.specify com o melhor enunciado funcional disponivel.
Garantir spec.md e checklist de requisitos da feature.
Fase 4 - Clarificacao
Rodar /speckit.clarify ate remover ambiguidades criticas.
Nao avancar com pendencias criticas de escopo, seguranca, permissao, UX ou compliance.
Fase 5 - Planejamento
Rodar /speckit.plan apenas com spec valida.
Garantir research.md, data-model.md, contracts/, quickstart.md e contexto repo-local quando aplicavel.
Fase 6 - Decomposicao
Rodar /speckit.tasks.
Se o repo expuser /speckit.taskstoissues e o usuario quiser sincronizar issues, executar depois de tasks usando gh.
Fase 7 - Gate de qualidade antes da implementacao
Rodar /speckit.analyze.
Rodar /speckit.checklist.
Corrigir bloqueios antes de /speckit.implement.
Fase 8 - Implementacao
Rodar /speckit.implement apenas depois que spec, plan, tasks e gates estiverem coerentes.
Manter todos os writes dentro do repo dono.
Fase 9 - Fechamento obrigatorio
Executar validacoes do repo (build, testes, smoke, etc.).
Executar o toolkit completo de governanca quando existir no workspace/repo dono:
./tools/governance/scan-secrets.sh
python3 ./tools/governance/sync-instructions.py
python3 ./tools/governance/audit-compliance.py
Finalizar com code review e cross-validation baseados em evidencias.
Regra para pedidos parciais
Se o usuario pedir apenas /speckit.plan, /speckit.tasks, /speckit.analyze, /speckit.checklist ou /speckit.implement, primeiro valide se os artefatos upstream obrigatorios existem e ainda estao coerentes.
Se faltar prerequisito, execute ou atualize a etapa anterior necessaria antes de continuar.
Para nova feature, o caminho completo recomendado e /speckit.constitution -> /speckit.specify -> /speckit.clarify -> /speckit.plan -> /speckit.tasks -> /speckit.analyze -> /speckit.checklist -> /speckit.implement.
Mandatory final code review, cross-validation, and factual integrity
Apply the canonical final gate from CLAUDE.md before marking work complete.