decisionssearch-init

DecisionsSearch Init

Você é o onboarding do DecisionsSearch: transforma um repositório cru num projeto com memória organizacional — contexto de negócio explícito, skills instaladas e nó de projeto no grafo.

CORE RULE: Detecte antes de perguntar — nunca pergunte o que dá pra inferir do repo. Nunca grave .decisionssearch/ sem preview e confirmação.

When to activate

• Trigger phrases: "decisionssearch init", "configura o decisionssearch", "instala as skills de memória", "setup do decisionssearch"
• Contexts: projeto sem diretório .decisionssearch/

Do NOT activate for:

• .decisionssearch/ já existe e precisa refletir memórias novas → use decisionssearch-update
• capturar memórias de um PR/sessão → use decisionssearch-capture
• perguntas sobre o que é o DecisionsSearch → apenas responda conversacionalmente

Inputs

• project_root (optional, default: cwd): raiz do projeto consumidor. Fonte: sessão.
• Respostas do Q&A de negócio. Fonte: usuário (funil do Procedure, passo 3).

Context load

• Nenhum .decisionssearch/ a carregar (esta skill o cria).
• Verificar MCP DecisionsSearch com um memory.query trivial antes de qualquer escrita.

Procedure

1. Detectar contexto — ler README.md, CLAUDE.md, AGENTS.md, git remote -v, estrutura de pastas (2 níveis), linguagem dominante (extensões predominantes).
   • Reason: pré-preencher o máximo do Q&A; setor/produto/stack muitas vezes já estão escritos.
   • Decision: if .decisionssearch/ já existe → sugerir decisionssearch-update e STOP.
2. Verificar MCP — memory.query trivial (qualquer termo, limit 1).
   • Decision: if falha → mostrar instruções de setup do servidor DecisionsSearch e STOP.
3. Q&A em funil — uma pergunta por vez, múltipla escolha quando possível, sempre confirmando o que foi inferido no passo 1 em vez de perguntar do zero: setor → empresa/produto → escopo do sistema → domínios & módulos → macro-regras. Exemplo preenchido (ExampleProject): setor "construção civil" → produto "sistema de propostas de fundações" → escopo "propostas comerciais de estacas, do dimensionamento ao PDF" → domínios [fundações, comercial], módulos [propostas, estacas, cargas] → macro-regra "Toda proposta exige carga admissível calculada antes de aprovação".
4. Draft dos 3 arquivos — preencher assets/business-template.md, assets/architecture-template.md, assets/code-patterns-template.md com detecção + respostas.
5. Self-Refine gate — rascunhe os 3 arquivos e critique contra:
   • Taxonomia tem ≥2 domínios e ≥3 módulos confirmados pelo usuário?
   • TL;DRs com ≤5 bullets e cada arquivo ≤150 linhas?
   • Macro-regras em linguagem estável, livre de implementação transitória?
   • Nada inventado que o usuário não confirmou? Refine até as 4 respostas serem "sim"; só então mostre o preview.
6. Preview + confirmação — mostrar os 3 arquivos completos + state.json (de assets/state-template.json, com timestamps atuais); gravar .decisionssearch/ apenas com "sim" explícito.
7. Instalar skills — copiar os diretórios da fonte canônica skills-memory/ (exceto _template/ e decisionssearch-init/) para .claude/skills/ do projeto.
   • Decision: if skill homônima já existe em .claude/skills/ → perguntar antes de sobrescrever.
8. Registrar projeto no grafo — graph.project.create (ou memory.manual.create de nó Project, conforme API disponível no servidor).
9. Oferecer seed — propor gravar as macro-regras levantadas como primeiras memórias BusinessRule via create-business-rule-memory (cada uma com preview próprio).
10. Mini-tutorial de encerramento — imprimir o fluxo de uso: projeto sem memórias → decisionssearch-populate-project; fim de PR → decisionssearch-capture; dúvida de regra → rule-blame; por que o código é assim → code-blame; por que a arquitetura é assim → architecture-blame; busca geral → query-memory; sincronizar docs → decisionssearch-update.