sivaprasadreddy/sdd-skills

SDD: Init docs/project.md

Você é um arquiteto de software sênior analisando um projeto para produzir seu documento de contexto.

Pré-condições

Verifique se docs/project.md já existe.

Se existir: Pergunte ao usuário:

"docs/project.md já existe. Deseja regenerá-lo? Isso substituirá o arquivo atual."

Aguarde a confirmação. Se o usuário disser não, pare e peça para editá-lo manualmente. Se o usuário confirmar, prossiga com o processo completo abaixo.

Se não existir: Prossiga imediatamente.

---

Processo

1. Detectar a Pilha Tecnológica

Examine a raiz do projeto e a árvore de código-fonte em busca de arquivos de build e configuração para detectar automaticamente o máximo possível:

O que encontrar	Onde procurar
Linguagem e versão	pom.xml (<java.version>), build.gradle/build.gradle.kts (jvmToolchain, sourceCompatibility), .java-version, pyproject.toml, package.json (engines), go.mod, Cargo.toml
Framework	Dependências em pom.xml / build.gradle — Spring Boot, Quarkus, Micronaut, FastAPI, Express, Django, Rails, etc.
Ferramenta de build	Presença de pom.xml (Maven), gradlew (Gradle), package.json (npm/yarn/pnpm), Makefile, pyproject.toml (Poetry/Hatch)
Banco de dados	Dependências ou arquivos de configuração — spring.datasource em application.properties/application.yml, DATABASE_URL em .env.example, serviços no docker-compose
ORM / acesso a dados	Dependências — Hibernate/JPA, Spring Data, SQLAlchemy, Prisma, TypeORM, GORM, Diesel
Migrações	Dependências ou diretórios — Flyway, Liquibase, Alembic, db/migrate/ (Rails), Prisma migrate
Mensageria	Dependências ou serviços no docker-compose — Kafka, RabbitMQ, SQS, Redis Streams
Bibliotecas de teste	Dependências de escopo de teste — JUnit 5, Mockito, Testcontainers, RestAssured, pytest, Jest, Vitest, RSpec
Outras bibliotecas	Dependências notáveis restantes — Spring Security, MapStruct, Lombok, Resilience4j, OpenAPI, etc.

Leia docker-compose.yml ou docker-compose.yaml se presente — geralmente revela a pilha de banco de dados, mensageria e cache.

2. Detectar Arquitetura e Convenções

Explore a estrutura da árvore de código-fonte:

• Identifique a estrutura de diretórios de alto nível (ex.: src/main/java, src/, app/, lib/)
• Deduza o padrão arquitetural a partir dos nomes de pacotes/diretórios:
  • Pacotes nomeados controller, service, repository → Em Camadas
  • Pacotes nomeados domain, application, infrastructure, adapter → Hexagonal / Limpa
  • Pacotes nomeados por módulos de negócio (ex.: order, payment, user) cada um contendo camadas → Monólito Modular
  • Múltiplos serviços de alto nível, cada um com seu próprio arquivo de build → Microsserviços
• Identifique o nome do pacote base (ex.: com.example.myapp)
• Procure por GlobalExceptionHandler, @RestControllerAdvice, ou manipulador de erros equivalente
• Procure por um prefixo de caminho REST base em controladores ou configurações (ex.: /api/v1)
• Observe qualquer configuração de segurança (ex.: SecurityConfig, anotações de autenticação, configuração JWT)

3. Fazer Perguntas Esclarecedoras

Algumas informações não podem ser detectadas de forma confiável. Faça ao usuário as seguintes perguntas em uma única mensagem agrupada — não as faça uma de cada vez:

Analisei o projeto. Antes de escrever docs/project.md, preciso de alguns detalhes:

1. **Nome e missão do projeto:** O que esta aplicação faz e quem a utiliza?
   (1-2 frases são suficientes — este é o parágrafo do "por que existimos".)

2. **Padrão arquitetural:** Com base na estrutura do código-fonte, acredito que este projeto usa [padrão detectado].
   Isso está correto, ou você descreveria de forma diferente?

3. **Convenções principais:** Existem convenções que o Agente de IA deve seguir que não são óbvias a partir do código?
   Por exemplo: regras de nomenclatura, requisitos de autenticação por endpoint, formato de resposta de erro, estilo de paginação.

4. **Dependências aprovadas:** Existem restrições sobre quais bibliotecas podem ser adicionadas?
   (Se não, listarei as dependências detectadas como aprovadas por padrão.)

Ajuste ou omita as perguntas 2 a 4 se você já tiver alta confiança a partir da varredura do código-fonte.

Aguarde as respostas do usuário antes de escrever o arquivo.

4. Escrever docs/project.md

Crie o diretório docs/ se não existir. Escreva docs/project.md com esta estrutura, preenchida com sua análise e as respostas do usuário:

# Projeto: <Nome>

## Missão
<Um parágrafo sobre o que esta aplicação faz e a quem atende.>

## Pilha Tecnológica
- Linguagem: <linguagem e versão>
- Framework: <framework e versão>
- Ferramenta de build: <ferramenta>
- Banco de dados: <banco de dados e versão, se conhecido>
- ORM: <ORM / biblioteca de acesso a dados>
- Migrações: <ferramenta de migração, ou "nenhuma">
- Mensageria: <sistema de mensageria, ou "nenhum">
- Testes: <bibliotecas de teste>
- Outros: <outras bibliotecas notáveis>

## Arquitetura
<Descreva o padrão: Em Camadas / Hexagonal / DDD / Monólito Modular / Microsserviços>
<Descreva a estrutura de pacotes com um exemplo, ex.:>
<  com.exemplo.<modulo>.<camada>  →  com.exemplo.usuario.controller, com.exemplo.usuario.service>

## Convenções
- Nomenclatura de pacotes: <convenção>
- Caminho base REST: <caminho base, ex. /api/v1>
- Tratamento de erros: <mecanismo, ex. GlobalExceptionHandler via @RestControllerAdvice>
- Autenticação: <requisito de autenticação padrão, ex. todos os endpoints requerem autenticação, a menos que anotados com @Public>
- <Quaisquer outras convenções fornecidas pelo usuário>

## Dependências Aprovadas
<Lista com marcadores das bibliotecas aprovadas para uso. Qualquer item fora desta lista requer uma sinalização antes de ser adicionado.>

Não deixe nenhum texto de espaço reservado (tokens entre colchetes angulares) na saída — preencha cada campo ou omita a linha se realmente desconhecido.

5. Confirmar

Após escrever o arquivo:

• Mostre ao usuário um resumo do que foi detectado automaticamente versus o que foi fornecido por ele
• Diga para revisar docs/project.md e corrigir qualquer coisa que parecer errada
• Lembre-o de manter este arquivo atualizado conforme a pilha evolui — é a entrada principal para todas as outras skills SDD
• Peça para executar /sdd-analyse <descrição da funcionalidade> para iniciar a primeira funcionalidade