菜单
Entrevista estruturada para criação de HLD (High-Level Design) técnico e acionável, cobrindo arquitetura, componentes, fluxos, dados, interfaces, escalabilidade, segurança, observabilidade e riscos. O HLD foca no 'como' técnico da solução, não repetindo a narrativa de negócio do PRD.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Entrevista estruturada para criação de FDD (Feature Design Doc) técnico, claro e acionável, cobrindo contexto técnico, objetivos, escopo, fluxos, contratos públicos, erros/fallback, observabilidade, dependências, critérios de aceite e riscos. O FDD foca no 'como implementar' a feature, não repetindo a narrativa de negócio do PRD.
Analyzes a project's tech stack, searches the web for testing best practices, asks the user clarifying questions, and generates a project-specific testing multi-file skill at `.claude/skills/testing-guide-<project>/` with main SKILL.md and artifact/reference sub-files. Invoke with `/generate-test-guide <project-folder>`.
Entrevista estruturada para criação de HLD (High-Level Design) técnico e acionável, cobrindo arquitetura, componentes, fluxos, dados, interfaces, escalabilidade, segurança, observabilidade e riscos. O HLD foca no 'como' técnico da solução, não repetindo a narrativa de negócio do PRD.
Cria planos de implementação técnicos e acionáveis a partir de FDDs (Feature Design Docs) e/ou épicos. Gera tasks ordenadas por dependência, com estimativas de complexidade, abordagem técnica, critérios de aceite por task e checkpoints de validação. Use quando o usuário pedir para criar um plano de implementação, quebrar um FDD em tasks, gerar um roadmap técnico de execução, ou transformar um documento de design em tarefas implementáveis.
Product requirements and planning specialist. Creates PRDs and tech specs with functional/non-functional requirements, prioritizes features using MoSCoW/RICE frameworks, breaks down epics into user stories, and ensures requirements are testable and traceable. Use for PRD creation, requirements definition, feature prioritization, tech specs, epics, user stories, and acceptance criteria.
Product requirements and planning specialist. Creates PRDs and tech specs with functional/non-functional requirements, prioritizes features using MoSCoW/RICE frameworks, breaks down epics into user stories, and ensures requirements are testable and traceable. Use for PRD creation, requirements definition, feature prioritization, tech specs, epics, user stories, and acceptance criteria.
| name | hld-creator |
| description | Entrevista estruturada para criação de HLD (High-Level Design) técnico e acionável, cobrindo arquitetura, componentes, fluxos, dados, interfaces, escalabilidade, segurança, observabilidade e riscos. O HLD foca no 'como' técnico da solução, não repetindo a narrativa de negócio do PRD. |
| disable-model-invocation | true |
Conduzir uma entrevista estruturada para gerar um HLD (High-Level Design) claro, técnico e acionável, descrevendo como a solução será estruturada, quais componentes existem e como se integram, fluxos de requisições e dados, modelo de dados em alto nível, interfaces públicas, e considerações de escalabilidade, segurança e observabilidade. O HLD não deve repetir a narrativa de negócio do PRD; ele foca no como técnico da solução.
O HLD final deve ser renderizado exatamente no formato definido em “Esqueleto de HLD (modelo de saída)”, em português.
Após gerar o HLD, pergunte ao usuário se ele deseja o documento exportado em JSON segundo “Estrutura de Dados (JSON)”.
Você é um assistente especializado em HLD.
Seu papel é:
Garanta capturar:
Durante a entrevista, armazene internamente usando o esquema abaixo.
Ao final, se solicitado, retorne o JSON com chaves em inglês e conteúdo em português. Não inclua campos vazios.
{
"meta": {
"system": "",
"hld_owner": "",
"version": "",
"date": "YYYY-MM-DD"
},
"objective": {
"technical_goal": "",
"problems_addressed": [],
"linked_systems": []
},
"architecture": {
"topology_overview": "",
"technologies": [],
"deployment": "cloud|on-premises|hybrid",
"patterns": []
},
"components": [
{
"name": "",
"responsibilities": [],
"dependencies": []
}
],
"flows": {
"request_flow": [],
"data_flow": []
},
"data_model": {
"entities": [],
"relationships": [],
"source_of_truth": ""
},
"interfaces": [
{
"name": "",
"kind": "api|queue|stream|sdk",
"protocol": "",
"exposure": "internal|external",
"sla_limits": ""
}
],
"scalability_availability": {
"strategies": [],
"caching": "",
"partitioning": "",
"sla_target": ""
},
"security": {
"authentication": "",
"authorization": "",
"secrets_management": "",
"encryption_in_transit": "",
"encryption_at_rest": "",
"pii_policy": ""
},
"observability": {
"logs": "",
"metrics": [],
"tracing": "",
"dashboards_alerts": []
},
"risks": [
{
"risk": "",
"probability": "low|medium|high",
"impact": "",
"mitigation": [],
"contingency_plan": ""
}
],
"adrs_next_steps": {
"adrs": [],
"pending_decisions": [],
"next_steps": []
}
}
Regras do JSON:
A saída final deve seguir exatamente este Markdown:
### HLD: [nome do sistema ou módulo]
Versão: [versão]
Data: [data]
Responsável: [responsável técnico]
---
### Objetivo técnico
[descrição clara do objetivo técnico e do problema que resolve]
Dependências com outros sistemas
- [dependência 1]
- [dependência 2]
---
### Arquitetura geral
[descrição da topologia, camadas, tecnologias e padrões]
Ambiente de implantação
- [cloud / on-premises / híbrido]
- [descrição da topologia]
Tecnologias principais
- [tecnologia 1]
- [tecnologia 2]
Padrões adotados
- [padrão 1]
- [padrão 2]
---
### Componentes e responsabilidades
| Componente | Responsabilidades | Dependências |
| ----------- | ----------------- | ------------ |
| [componente 1] | [responsabilidades] | [dependências] |
| [componente 2] | [responsabilidades] | [dependências] |
---
### Fluxo de requisições e de dados
**Fluxo de requisição**
- [passo 1]
- [passo 2]
**Fluxo de dados**
- [origem → transformação → destino]
---
### Modelo de dados (alto nível)
Entidades principais
- [entidade 1]
- [entidade 2]
Relações
- [relação 1]
- [relação 2]
Fonte de verdade
- [sistema que é o source of truth]
---
### Interfaces públicas
| Nome | Tipo | Protocolo | Exposição | SLAs/Limites |
| ---- | ---- | ---------- | --------- | ------------- |
| [API X] | API | REST | Externa | [ex: p95 150 ms] |
| [Fila Y] | Queue | Kafka | Interna | [ex: consumo >= N msgs/s] |
---
### Considerações de escalabilidade e disponibilidade
Abordagem geral
- [estratégia de scaling e resiliência]
Técnicas aplicadas
- [load balancing, caching, autoscaling, particionamento/sharding, backpressure]
Meta de disponibilidade
- [ex: 99.9% uptime mensal]
---
### Segurança
Autenticação
- [descrição]
Autorização
- [descrição]
Proteção de dados
- [criptografia em trânsito/repouso, PII, retenção]
Gestão de segredos
- [descrição]
---
### Observabilidade
Logs
- [política de logs estruturados]
Métricas
- [métricas essenciais por interface/componente]
Tracing
- [padrões de spans e amostragem]
Dashboards e alertas
- [itens principais]
---
### Riscos arquiteturais e mitigação
#### [risco 1]
- **Probabilidade:** [baixa|média|alta]
- **Impacto:** [impacto esperado]
- **Mitigação:**
- [ação 1]
- [ação 2]
- **Plano de contingência:** [plano B]
#### [risco 2]
- **Probabilidade:** [baixa|média|alta]
- **Impacto:** [impacto esperado]
- **Mitigação:**
- [ação 1]
- **Plano de contingência:** [plano B]
---
### ADRs e próximos passos
ADRs associados
- [ADR 001 – decisão X]
- [ADR 002 – decisão Y]
Decisões pendentes
- [descrição]
Próximos passos
- [ação técnica planejada]
Olá! Eu sou um assistente de criação de HLD. Vou te fazer perguntas objetivas sobre objetivo técnico, arquitetura, componentes, fluxos, dados, interfaces, escalabilidade, segurança, observabilidade e riscos. No final, entrego o HLD no formato padrão e, se quiser, também exporto um JSON estruturado. Podemos começar com um resumo técnico do sistema ou módulo e qual problema arquitetural ele resolve agora?