---
name: project-discovery
description: Descobrir e documentar profundamente o contexto operacional de qualquer projeto antes de rodar a pipeline SDD. Use ao instalar a camada em um novo repositório, antes da primeira feature brownfield, ao preencher sdd.config.yaml, ao gerar recomendações de skills/rules por tecnologia, ou quando stack, comandos, arquitetura, paths, testes, CI, integrações e riscos ainda não são confiáveis.
---

# Project Discovery SDD

## Objetivo

Criar um retrato operacional verificável do projeto para que PRD, Tech Spec, Tasks, Execution, Review e Memory partam da realidade do repositório, não de suposições. O discovery também deve indicar quais skills, rules e seções de `AGENTS.md`/`CLAUDE.md` tornam o projeto mais fácil de operar nas próximas features.

## Procedimento

1. Leia `sdd.config.yaml` quando existir; em projetos instalados sem config, use `.sdd/sdd.config.example.yaml`; no repo da camada, use `templates/project-discovery.md` como fonte do formato.
2. Faça inventário read-only com `sdd discover --json --dry-run` quando disponível, `rg --files`, manifests, lockfiles, workspaces, docs, CI, scripts, testes, migrations, infra, adapters, env examples, entrypoints e arquivos de agente.
3. Detecte stack e fronteiras: apps/packages, frontend, backend, API, mobile, desktop, dados/ML, infra, bibliotecas, CLIs, jobs, workers, contratos e integrações externas.
4. Derive comandos reais dos manifests e docs. Verifique apenas comandos seguros e baratos quando o contexto permitir; se não rodar, registre como "não verificado" com motivo.
5. Mapeie arquitetura e operação: camadas, roteamento, dados, auth, erros/logs, observabilidade, deploy, branch/PR/MR, CI, ownership, test strategy e convenções locais.
6. Classifique riscos recorrentes: segurança/segredos, dados/privacidade, migrações, performance, disponibilidade, deploy, integrações, brownfield, monorepo, provider/modelo e UX quando houver interface.
7. Mapeie linguagem de domínio: `CONTEXT.md`, `CONTEXT-MAP.md`, ADRs e divergências de termos que precisem de checkpoint.
8. Mapeie code intelligence opcional: CodeGraph, Lexa, índice existente, comandos sugeridos e fallback `rg`.
9. Rode `sdd context recommend` para obter recomendações determinísticas por tecnologia; quando houver orquestração nomeada, use `sdd context materialize --name "<orquestracao>"` para revisar boundaries, arquivos alvo, bloqueios e blocos esperados antes de qualquer `--write`.
10. Gere recomendações materializáveis de contexto: skills em `.agents/skills/<nome>/SKILL.md`, espelhos Claude quando úteis, rules para Cursor/Antigravity, trechos curtos para `AGENTS.md`, deltas específicos de `CLAUDE.md` e `AGENTS.md` locais para boundaries claros.
11. Produza saída no formato de `.sdd/templates/project-discovery.md` ou `templates/project-discovery.md`, incluindo `Inventário técnico detalhado`, `Recomendações de skills e regras` e `Visualizações e documentação HTML`.
12. Inclua capability map com `code-intelligence`, `execution-discipline`, `domain-language`, `architecture-deepening` e skills visuais quando UI/landing/redesign existirem.
13. Quando não for dry-run, materialize Markdown e HTML: com orquestração nomeada, salve em `docs/<slug-da-orquestracao>/00-project-discovery.md` com estado `recorded` e gere `docs/<slug-da-orquestracao>/00-project-discovery.html`; sem nome explícito, use o fallback `docs/sdd-orchestration/00-project-discovery.md` e `docs/sdd-orchestration/00-project-discovery.html`.

## Heurística de cobertura

- Manifests e lockfiles: `package.json`, `pnpm-workspace.yaml`, `pyproject.toml`, `requirements.txt`, `Cargo.toml`, `go.mod`, `pom.xml`, `build.gradle`, `Gemfile`, `composer.json`, `*.csproj`, `pubspec.yaml`, `Package.swift`.
- Execução e entrada: CLIs, apps, rotas, handlers, controllers, workers, jobs, scripts, targets, main files e containers.
- Dados e contratos: migrations, schemas, OpenAPI/GraphQL, Prisma/Drizzle/Alembic, protobuf, fixtures, seeds, env vars e secrets.
- Qualidade: testes unitários/integrados/e2e, lint, typecheck, build, storybook, visual QA, CI e coverage.
- Operação: deploy, feature flags, observabilidade, logs, métricas, Sentry, analytics, filas, webhooks, cron e runbooks.

## Saída obrigatória

- Identidade e stack do projeto.
- Paths de código, testes, docs, migrations, infra, config e artefatos SDD.
- Inventário técnico detalhado com manifests, entrypoints reais, componentes, camadas, CI, deploy, env vars redigidas, contratos, integrações e evidências.
- Comandos verificados, comandos não verificados e comandos ausentes.
- Padrões de arquitetura e teste.
- Riscos, checkpoints adicionais e evidências mínimas de review.
- Regras de quando usar Refinement e Agent Teams.
- Recomendações de skills e regras específicas da stack, com sinais observados.
- Linguagem de domínio, ADRs, code intelligence opcional e fallback usado.
- Capability map por stage com fontes externas atribuídas.
- Visualizações Mermaid no Markdown e HTML standalone com stack, paths, comandos, riscos, pipeline e capability map.
- Contexto curto para próximos agentes.
- Caminho local salvo quando fizer parte de uma orquestração.

## Regras

- Não invente comando; derive de arquivos reais ou marque como ausente.
- Se não conseguir validar algo, registre como risco ou pendência.
- Não confunda ausência de sinal com inexistência; registre "não encontrado no inventário".
- Não copie segredos, tokens ou valores sensíveis; cite nomes de variáveis e arquivos redigidos.
- Não altere código nesta skill; discovery é read-only.
