| name | suggest-guidelines |
| description | Investiga qualquer repositório com raciocínio de LLM, correlaciona Tech Radar, código, estrutura e decisões para sugerir guidelines arquiteturais pequenas. Use para descobrir padrões, bibliotecas, convenções, divergências e oportunidades de governança em qualquer linguagem ou stack. Nunca publica guideline ativa; candidatos permanecem hipóteses para revisão humana. |
Suggest Guidelines
Usar a capacidade investigativa da LLM como motor principal. Não limitar a
descoberta a tecnologias, linguagens, frameworks ou receitas previamente
catalogadas. Produzir guideline-candidate, nunca norma ativa.
Contratos
Ler antes de agir:
references/investigation-prompt.md: protocolo LLM-first obrigatório.references/discovery-contract.md: fronteira entre observação e prescrição.references/ranking.md: critérios de prioridade.references/epistemic-boundary.md: limites da mineração bottom-up.
Usar assets/guideline-candidate-template.yaml para persistência.
Fluxo
- Ler primeiro o Tech Radar, suas evidências, ADRs, candidatos e guidelines existentes.
- Investigar o repositório conforme
investigation-prompt.md.
- Formular hipóteses sobre tecnologias, padrões e práticas emergentes.
- Buscar evidência favorável, evidência contrária e lacunas para cada hipótese.
- Propor regras atômicas sem confundir recorrência com correção.
- Sugerir verificação manual, assistida por LLM ou determinística conforme a maturidade.
- Rankear e deduplicar semanticamente; usar scripts internos para integridade estrutural.
- Apresentar candidatos e incertezas antes de persistir em lote.
- Avaliar lacunas com
assess-readiness.mjs antes de pedir decisão humana.
- Registrar aprovação, rejeição ou complementação com
review-candidate.mjs.
Os scanners específicos são aceleradores opcionais de evidência. Nunca interromper
a investigação por não existir scanner para a stack encontrada e nunca tratar a
saída de um scanner como conclusão arquitetural.
Persistir um candidato somente com evidência localizável. Permitir hipótese
review.pending sem blip quando ela emerge de padrão estrutural. Antes de propor
aprovação, localizar blip compatível ou recomendar sua criação e decisão no Radar.
Candidato approved exige fator e applies-to para blip, além de ADR normativa.
Executar scripts Node internamente apenas para schema, IDs, deduplicação e grafo.
Não transferir comandos ao participante, salvo pedido explícito de diagnóstico.
Uma revisão registra revisor, data, justificativa e fingerprint do conteúdo. Se a
regra, evidência, fatores ou relações mudarem depois, exigir nova revisão em vez
de preservar uma aprovação obsoleta.
