菜单
Skill que define como extrair padrões do código com confidence scoring. Use durante Discovery quando precisar identificar convenções, anti-padrões ou padrões idiomáticos do projeto. Cada padrão extraído deve vir com exemplo concreto do código (path:line).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Skill que constrói o Co-change Graph - "quando arquivo X muda, qual outro arquivo geralmente muda junto?". Use durante Discovery e em /fp:cochange. Baseado em git history. Detecta arquivos co-dependentes que devem ser editados juntos para evitar PRs incompletos. v0.3.0+ usa engine nativo Rust quando disponível (10-100x mais rápido).
Skill que detecta e instala o binário nativo first-plan-engine (Rust) na primeira invocação. Use quando algum command (cochange, hash, futuramente ast/index/search) for invocado e o binário não estiver presente. Oferece download via GitHub Releases. Plugin funciona sem o engine (graceful fallback), mas com ele fica 10-100x mais rápido.
Skill que extrai inteligência do git history - heatmap de atividade, ownership, branches/PRs in-flight. Use durante Discovery e em /fp:hot, /fp:owner, /fp:in-flight. Tudo via comandos git read-only.
Skill que define como o comando /fp:plan emite um plano detalhado para uma feature. Use quando precisar gerar plano que respeite a camada compilada, verifique duplicidade contra 09-features, identifique reuse e siga template em meta-templates/plan.md. Sempre pausa pedindo aprovação ao final.
Esta skill DEVE ser carregada em qualquer comando do plugin first-plan. Define o protocolo PLAN-FIRST (Discovery -> Plan -> Approval -> Execution -> Report), as 7 regras invioláveis e o comportamento esperado em cada fase. Ative quando o usuário invocar /fp:* ou mencionar "first-plan", "context compilation", "discovery layer", "spec-code reconciliation".
Skill que define o schema de proveniência e o sistema de freshness tracking para findings em .first-plan/. Use durante Discovery e refresh para registrar source (file:line@SHA), TTL, confidence inicial e cadeia de supersedeção. Aplica decay de confidence baseado em idade.
| name | first-plan-pattern-extraction |
| description | Skill que define como extrair padrões do código com confidence scoring. Use durante Discovery quando precisar identificar convenções, anti-padrões ou padrões idiomáticos do projeto. Cada padrão extraído deve vir com exemplo concreto do código (path:line). |
| version | 0.1.0 |
Como transformar observações do código em "padrões" registráveis em .first-plan/02-conventions/, 06-rationale/do.md, 06-rationale/dont.md.
Sem exemplo do código, sem padrão. Toda regra extraída precisa de pelo menos 1 exemplo concreto (path:line). Sem exemplo, vira pergunta em 08-meta/questions.md ou é descartada.
Para cada categoria (errors, naming, testing, etc), amostre arquivos representativos:
Limite: máx 50 arquivos lidos por categoria. Se ficar muito ruidoso, abortar com confidence baixa.
Em cada arquivo amostrado, busque:
func Handle...(ctx Context, req Request) (Response, error)")// don't use X, // use Y instead)Cada padrão candidato ganha confidence baseado em sinais convergentes:
| Sinal | Peso |
|---|---|
| 5+ ocorrências consistentes | +0.3 |
| 10+ ocorrências consistentes | +0.5 |
| Mesmo padrão em testes e código de produção | +0.2 |
| Comentário no codebase explicitamente preferindo o padrão | +0.2 |
| Documentado em README/CLAUDE.md/docs/ | +0.2 |
| Ocorre em código recente (últimos 90 dias) | +0.1 |
| Não tem variantes inconsistentes | +0.2 |
| Tem variantes inconsistentes (alguns fazem A, outros B) | -0.3 |
| Apenas 1-2 ocorrências | -0.4 |
| Apenas em código antigo (>1 ano sem update) | -0.2 |
| Conflita com outro padrão extraído | -0.3 |
Soma final clamped em [0.0, 1.0]. Threshold default 0.7.
Detectar via:
any em projeto TS estrito = sinal forte de "evitar any")// don't, // avoid, // nao usar, // removed becauseconsole.log foram trocados por logger.info em commits recentes)Confidence para anti-padrão tem regra extra: requerer pelo menos 2 sinais distintos para considerar válido.
Cada padrão extraído gera entrada no formato:
### Padrão: <nome>
- **Resumo:** <1 linha>
- **Por que existe (inferido):** <opcional, se houver evidência>
- **Exemplo:**
```<lang>
<trecho real do código>
Visto em: <path>:<line>
Sem o exemplo, **descartar o padrão ou rebaixar a pergunta**.
## Categorias e onde escrever
| Categoria | Arquivo de saída |
|-----------|------------------|
| Naming | `02-conventions/naming.md` |
| Errors | `02-conventions/errors.md` |
| Testing | `02-conventions/testing.md` |
| Logging | `02-conventions/logging.md` |
| DI | `02-conventions/di.md` |
| Security | `02-conventions/security.md` |
| Padrões positivos cross-cutting | `06-rationale/do.md` |
| Anti-padrões | `06-rationale/dont.md` |
| Decisões inferidas | `06-rationale/why.md` |
## Quando virar pergunta em vez de padrão
Se confidence < 0.7 mas o tópico é importante (e.g., naming convention é crítico):
1. Não escrever o padrão como verdade
2. Adicionar entrada em `08-meta/questions.md` com hipóteses A/B/C
3. Anotar em `02-conventions/<category>.md` que "convenção indeterminada - ver questions.md"
## Cuidados
- **Não inventar regras genéricas.** Se o projeto não tem padrão claro, o output é "indeterminado", não "use snake_case porque é a convenção da linguagem".
- **Não impor best practices externas.** Se o projeto usa `var` em vez de `let` em todo lugar, o padrão extraído é "use `var`", não "deveria usar `let`".
- **Variantes inconsistentes** são sinal de migração em curso ou de equipes desalinhadas. Reportar ambas, com nota de "variante minoritária possivelmente em migração".