メニュー
Converte request informal em especificacao tecnica estruturada para Nemesis Framework Rust. Auto-ativa quando Fernando descreve uma necessidade. NUNCA escreva codigo antes do design ser aprovado.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | nemesis-specification-design |
| description | Converte request informal em especificacao tecnica estruturada para Nemesis Framework Rust. Auto-ativa quando Fernando descreve uma necessidade. NUNCA escreva codigo antes do design ser aprovado. |
Converter requests informais em especificacoes tecnicas estruturadas para o Nemesis Framework v2.0 Rust.
Anuncio de inicio: "Estou usando a skill nemesis-specification-design para gerar uma especificacao tecnica."
NAO execute qualquer skill de implementacao, NAO escreva codigo Rust, NAO use Agent nemesis-implementer ate que o design seja APRESENTADO e APROVADO por Fernando explicitamente.
Respostas validas de aprovacao: "sim", "pode", "aprovado", "ok", "prossiga", "continua"
Ler a paisagem do projeto para grounding da analise:
pwd
# Esperado: .../Nemesis_Defender_v0
cat CLAUDE.md | head -50
ls -la .nemesis/ | head -20
# Identificar qual crate(s) sera afetado
ls .nemesis/*/Cargo.toml
cat .nemesis/Cargo.toml | grep -A 20 "\[workspace\]"
Identificar: stack Rust, crates do workspace, padroes existentes, regras Nemesis.
Analisar o request de Fernando e gerar a especificacao COMPLETA em uma unica passagem. NAO fazer perguntas socraticas.
Mapa de traducao (informal → tecnica):
Disciplina epistemica:
Estrutura de especificacao (gerar completa de uma vez):
Exemplo de REQUEST:
REQUEST: Implementar novo visitor tree-sitter para deteccao de unsafe blocks em eBPF hooks
CATEGORY: Feature
PROBLEM:
- Atual: AST linter nao detecta unsafe blocks em contexto eBPF
- Esperado: Detectar unsafe blocks e classificar como violation da regra ebpf-no-unsafe
CONTEXT:
- Crate afetada: ast-linters
- Modulo: visitors/ebpf_unsafe_checker.rs (novo)
- Dependencia: tree-sitter crate ja existe e configurada
- Assumpcao: regra "ebpf-no-unsafe" ja existe em .nemesis/ast-linters/src/rules.rs
REQUIREMENTS:
1. Criar novo visitor `EbpfUnsafeChecker` que herda de `TreeSitterVisitor`
2. Implementar metodo `visit_unsafe_block(&self, node: Node) -> Vec<Violation>`
3. Retornar lista de violations com severity=HIGH, rule_id="ebpf-no-unsafe"
4. Integrar visitor em pipeline de validacao em lib.rs
5. Adicionar testes em tests/ebpf_unsafe_test.rs
FILES INVOLVED:
- .nemesis/ast-linters/src/lib.rs (modify, adicionar visitor ao pipeline)
- .nemesis/ast-linters/src/visitors/ebpf_unsafe_checker.rs (create)
- .nemesis/ast-linters/tests/ebpf_unsafe_test.rs (create, testes)
- .nemesis/ast-linters/Cargo.toml (verify dependencias)
RESTRICTIONS:
- Somente Rust, nenhum arquivo .ts/.js
- Deve compilar: cargo check -p ast-linters PASS
- Nao quebrar testes existentes: cargo test -p ast-linters PASS
- Seguir naming convention: snake_case para funcoes, PascalCase para structs
- Nao modificar .nemesis/hooks/ (requer maintenance mode)
EXPECTED DELIVERY:
- Novo visitor compilado e integrado
- cargo check -p ast-linters: PASS
- cargo test -p ast-linters: PASS (incluindo novos testes)
- Detecta unsafe blocks em arquivo de teste Rust
VERIFICATION:
$ cd .nemesis && cargo check -p ast-linters
$ cd .nemesis && cargo test -p ast-linters
HARD-GATE: Apresentar a especificacao completa. BLOQUEAR todas as acoes ate resposta de Fernando.
Perguntar: "A especificacao reflete sua intencao? Quer ajustar algum ponto?"
Se Fernando pedir ajustes: Revisar especificacao e re-apresentar.
Se Fernando aprovar (sim, pode, ok, etc): Prosseguir para Step 4.
Apos aprovacao, salvar em arquivo:
Path: Feature-Documentation/SPECS/SPEC_NNN_nome-descritivo.md
Numero: auto-increment a partir de specs existentes (001, 002, 003, ...)
Comando de verificacao:
ls Feature-Documentation/SPECS/SPEC_*.md | sort | tail -3
Arquivo markdown contendo a especificacao completa aprovada.
Apos especificacao aprovada por Fernando:
pre-writing-rule-control para validacao de regrasnemesis-writing-plansAplica 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.
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.
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.