메뉴
Finaliza o desenvolvimento: verifica testes do perfil, gate de integridade do harness, coleta git diff real, gera PR estruturada, apresenta opcoes de merge/PR/descarte. HARD-GATE de revisao humana antes de salvar a PR.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | nemesis-finishing-branch |
| description | Finaliza o desenvolvimento: verifica testes do perfil, gate de integridade do harness, coleta git diff real, gera PR estruturada, apresenta opcoes de merge/PR/descarte. HARD-GATE de revisao humana antes de salvar a PR. |
Verificar conclusao, coletar evidencias de git diff real, gerar documentacao de PR estruturada, apresentar opcoes de disposicao da branch.
Texto unico espelhado nos dois repos. Comandos de verificacao e path da PR vem do perfil do repo (
.devin/rules/nemesis-repo-profile.md).
Esta skill NAO faz parte da fase autonoma do pipeline. Ela so executa mediante autorizacao explicita do Fernando, dada na PARADA UNICA (pos-validacao) ou depois dela. Ficar "tudo verde" na validacao NAO autoriza o finishing. Invocar sem autorizacao explicita = violacao do pipeline.
Anuncio de inicio: "Estou usando a skill nemesis-finishing-branch para finalizar o desenvolvimento."
Pre-requisitos: (1) todas as tarefas de implementacao completadas e validadas (Skill 4.5); (2) autorizacao explicita do Fernando para esta skill.
# Motor:
cd .nemesis && cargo check --workspace
cd .nemesis && cargo test --workspace
# Dashboard:
bun run lint
bunx tsc --noEmit
bun run build
Todos devem sair com exit code 0. Se qualquer um falhar:
nemesis-subagent-driven-developmentSe o git diff da entrega toca qualquer arquivo de harness (.devin/, .claude/skills/,
AGENTS.md, CLAUDE.md): executar o procedimento de espelhamento de
.devin/rules/nemesis-harness-integrity.md (os 3 comandos diff). Resultado precisa ser
ESPELHOS INTEGROS antes de gerar a PR. Deriva detectada = reconciliar via
nemesis-harness-sync (com o HARD-GATE dela) antes de continuar. Se o diff nao toca
harness, declarar "gate F10: nao se aplica" e seguir.
IMPORTANTE: Usar APENAS evidencias reais de git diff. NUNCA fabricar.
git branch --show-current
git diff --stat
git diff HEAD --name-only
git log --oneline -5
git diff HEAD # se necessario detalhe
Construir PR a partir de dados reais (git diff, stat, log). A PR DEVE conter todas as secoes abaixo, na ordem exata, incluindo a CLI Table com comandos, resultados e observacoes:
# PR_NNN: [Titulo Descritivo da Entrega]
## Objetivo
[1-4 linhas: o que foi feito e por que. Referencia a spec/plano.]
## Arquivos Afetados
- `<path>` [new|modified]
(Usar output EXATO de `git diff --stat`)
## Implementacoes Realizadas
### Arquivo: `<path>` (new|modified)
[O que foi criado/modificado em detalhe. Decisao tecnica. Padrao do perfil seguido.]
[Repetir para cada arquivo significativo]
## Criterios de Aceitacao
- [x] suite do perfil: PASS (listar cada comando)
- [x] Sem violacoes Nemesis
- [x] Gate F10 (harness): [INTEGROS | nao se aplica]
- [x] Codigo idiomatico na stack do perfil
## Beneficios
[Reuso, desacoplamento, seguranca, performance, enforcebilidade]
## Notas Adicionais
[Contexto adicional se relevante]
## CLI Table
> **IMPORTANTE**: A CLI Table contem APENAS comandos de VALIDACAO do projeto. NUNCA inclua
> comandos de analise como `git diff`, `git log`, `git status` ou similares. Esses sao
> ferramentas internas para coletar evidencias, nao validacoes do projeto.
| Command | Result (OK/FAIL) | Observations |
|---------|------------------|--------------|
| [comando 1 do perfil] | OK | [observacao] |
| [comando 2 do perfil] | OK | [observacao] |
| Pentest estatico (só-motor) | OK | [placar literal] |
| Pentest full live (só-motor) | OK | [placar literal] |
IMPORTANTE: O modelo acima e a ESTRUTURA. Substitua todos os valores pelos dados reais do seu git diff e das saidas literais desta sessao. Titulo com colon, secoes na ordem exata, um
### Arquivo:por arquivo significativo, output exato degit diff --statem bloco de codigo, criterios com checkboxes marcados, e sempre a CLI Table com comandos, resultados (OK/FAIL) e observacoes.
HARD-GATE: Apresentar PR completa (incluindo CLI Table). BLOQUEAR ate resposta de Fernando.
Perguntar:
PR gerada com base em git diff real. Revise acima. Aprovado?
Respostas validas: "sim", "pode", "aprovado", "ok", "prossiga"
Apos aprovacao, salvar no path de PRs do perfil (motor: Feature-Documentation/PR/;
dashboard: .devin/plans/), nome PR_NNN_nome-descritivo.md.
Antes de gravar: listar o conteudo do diretorio de PRs para determinar o proximo numero sequencial. NUNCA assumir um numero sem verificar. NUNCA criar numero repetido ou errado.
FERNANDO DECIDE o que fazer com a branch:
OPCOES DE DISPOSICAO:
1. MERGE NA BRANCH PRINCIPAL
Fernando executa: git merge <branch-name>
2. MANTER BRANCH PARA PR REVIEW EXTERNO
Branch fica aberta para pull request externo
3. DESCARTAR BRANCH
Fernando executa: git branch -D <branch-name>
Aguardando decisao de Fernando...
Skill anterior: nemesis-doc-sync (4.6) ou diretamente a PARADA UNICA
Final skill no pipeline Nemesis SDD
Aplica disciplina epistemica e analise critica em 2 pontos do SDD pipeline: antes de gravar a spec e antes de executar o plano. Garante que toda mudanca melhora o Nemesis sem regredir o que ja funciona, com evidencia empirica e sem bajulacao.
Trata documentacao como FEATURE. APOS a validacao (Skill 4.5) e ANTES do finishing (Skill 5), analisa o git diff da mudanca e decide se a superficie de doc do perfil (motor: README.md; dashboard: src/data/docs/*.json) precisa ser atualizada. Se nao, segue o fluxo. Se sim, reconcilia (codigo = verdade, regra do coeficiente, sem inserir por inserir), com HARD-GATE de revisao humana. Garante que a PR sempre contenha a documentacao sincronizada.
Verifica e reconcilia o espelhamento do harness (lei F10): roda o procedimento deterministico de nemesis-harness-integrity.md, apresenta a deriva arquivo a arquivo e reconcilia. Divergencia material tem HARD-GATE humano (o Fernando escolhe o canonico); copia comprovadamente antiga propaga-se a mais recente com reporte.
Compost de processo (lei F12): converte um erro de PROCESSO com custo material em post-mortem minimo (sintoma, causa verificada, lei violada ou ausente) e em proposta de emenda a regra/skill correspondente, com HARD-GATE humano. E o equivalente, para o harness, do que o redteam pipeline ja faz para o produto (gap vira Parte do pentest).
Converte request informal em especificacao tecnica estruturada para o Nemesis (motor Rust ou dashboard Next.js, conforme o perfil do repo). Auto-ativa quando Fernando descreve uma necessidade. NUNCA escreva codigo antes do design ser validado. No modo autonomo (default) o gate da spec e a analise critica (Skill 0, Ponto 1); a spec e gravada sem aguardar aprovacao humana.
Executa plano de implementacao tarefa por tarefa usando subagentes com contexto isolado. Pre-flight de postura na entrada. Two-stage review apos cada tarefa com revisor INDEPENDENTE (spec compliance depois code quality, verificacao rodada pelo revisor). Execucao continua sem pausas entre tarefas.