菜单
Metodologia de pensamento sequencial para decomposição estruturada e resolução de problemas complexos.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Drizzle ORM schema and database guide. Use when working with database schemas (src/database/schemas/*), defining tables, creating migrations, or database model code. Triggers on Drizzle schema definition, database migrations, or ORM usage questions.
Sistema de memória persistente baseado em arquivos e grafo de conhecimento. Agnóstico a modelo de IA. Use para manter contexto entre sessões.
Sistema de memória persistente baseado em arquivos e grafo de conhecimento. Agnóstico a modelo de IA. Use para manter contexto entre sessões.
| name | sequential-thinking |
| description | Metodologia de pensamento sequencial para decomposição estruturada e resolução de problemas complexos. |
| metadata | {"author":"realmquest","version":"1.0"} |
| argument-hint | Use Sequential Thinking para decompor problemas complexos em passos claros, documentar decisões e revisar conforme aprende. Ideal para planejamento de features, debugging e refatorações grandes. |
| compatibility | Funciona bem com TDD, Drizzle ORM, e práticas de documentação do projeto. Use para problemas que exigem planejamento além do código. |
| user-invocable | true |
Sequential Thinking é uma abordagem sistemática para decomposição e resolução de problemas complexos através de pensamento estruturado passo a passo. Em vez de tentar resolver tudo de uma vez, quebre o problema em etapas manejáveis, revise conforme aprende e explore alternativas quando necessário.
Use Sequential Thinking quando:
Sequential Thinking complementa TDD adicionando uma fase de planejamento estruturado:
Think (Sequential) → Red → Green → Refactor
Cada pensamento deve conter:
## Pensamento N/Total
**Contexto**: O que sabemos até agora?
**Objetivo**: O que este pensamento resolve?
**Decisão**: Qual caminho escolhemos e por quê?
**Próximo Passo**: O que vem depois?
[Marcar se é: Revisão | Ramificação | Conclusão]
"Adicionar endpoint de relatórios com filtros e paginação"
## Pensamento 1/5
**Contexto**: Precisamos de um endpoint /reports com filtros (data, status) e paginação.
**Objetivo**: Definir contrato da API e estrutura de dados.
**Decisão**:
- GET /api/reports?startDate=X&endDate=Y&status=Z&page=N&limit=M
- Response: { data: Report[], pagination: { page, limit, total } }
**Próximo Passo**: Definir schema e queries Drizzle.
---
## Pensamento 2/5
**Contexto**: Contrato definido, preciso do schema de dados.
**Objetivo**: Criar tabela `reports` e relações necessárias.
**Decisão**:
- Schema: id, title, status (enum), createdAt, userId (FK)
- Relação com users via Drizzle
- Migration via `bun run db:generate`
**Próximo Passo**: Escrever testes para a query.
---
## Pensamento 3/5 [REVISÃO do Pensamento 2]
**Contexto**: Percebi que relatórios precisam de soft delete (arquivamento).
**Objetivo**: Ajustar schema para suportar arquivamento.
**Decisão**:
- Adicionar campo `archivedAt` (nullable timestamp)
- Filtrar por padrão apenas não-arquivados
- Endpoint adicional: PATCH /reports/:id/archive
**Próximo Passo**: Atualizar migration e prosseguir com testes.
---
## Pensamento 4/5
**Contexto**: Schema pronto, hora de implementar queries.
**Objetivo**: Criar função em `lib/queries.ts` respeitando regras do projeto.
**Decisão**:
```typescript
export async function getReports(filters: ReportFilters) {
return db.query.reports.findMany({
where: and(
isNull(reports.archivedAt),
filters.status ? eq(reports.status, filters.status) : undefined,
filters.startDate ? gte(reports.createdAt, filters.startDate) : undefined
),
limit: filters.limit || 20,
offset: (filters.page - 1) * (filters.limit || 20),
orderBy: desc(reports.createdAt)
});
}
Próximo Passo: Escrever testes TDD para esta função.
Contexto: Queries prontas, testes escritos e passando. Objetivo: Integrar ao endpoint e validar. Decisão:
app/api/reports/route.tsunstable_cache e tag 'reports'
## Padrões de Integração
### Com TDD (Obrigatório)
### Com Drizzle ORM (Sem Raw SQL)
### Com Browser Automation (Chrome DevTools MCP)
## Template de Documento de Pensamento
Use este template ao planejar features complexas:
```markdown
# Feature: [Nome da Feature]
## Objetivo
[Descrição do que precisa ser feito]
## Contexto Inicial
- Restrições técnicas
- Dependências
- Padrões do projeto a seguir
---
## Pensamento 1/N
**Contexto**:
**Objetivo**:
**Decisão**:
**Próximo Passo**:
[Repetir para cada pensamento]
---
## Resumo de Decisões
- Decisão 1: [Por que foi tomada]
- Decisão 2: [Trade-offs considerados]
- Decisão N: [Alternativas descartadas]
## Checklist de Implementação
- [ ] Schema/migrations (se aplicável)
- [ ] Testes escritos (TDD Red)
- [ ] Implementação (TDD Green)
- [ ] Refatoração (TDD Refactor)
- [ ] Documentação TSDoc
- [ ] Validação manual/E2E
Revise um pensamento anterior quando:
Explore ramificações quando:
## Pensamento 3A/5 [RAMIFICAÇÃO: Abordagem com Cache]
**Decisão**: Usar Redis para cache de relatórios
**Trade-offs**: +Performance, +Complexidade, +Infra
## Pensamento 3B/5 [RAMIFICAÇÃO: Abordagem com Materialização]
**Decisão**: Tabela materializada com cron job
**Trade-offs**: +Simples, -Real-time, +Storage
## Pensamento 4/5 [CONSOLIDAÇÃO de 3A e 3B]
**Decisão Final**: Usar unstable_cache do Next.js (já disponível)
**Por quê**: Sem infra adicional, fácil invalidação, suficiente para escala atual
docs/decisions/feature-X.md| Prática | Como Sequential Thinking Ajuda |
|---|---|
| TDD | Planeje testes antes de escrever (Think → Red) |
| Drizzle ORM | Estruture queries evitando raw SQL desde o planejamento |
| TSDoc | Decisões complexas viram comentários documentados |
| Code Review | Decisões explícitas facilitam revisão contextual |
| Onboarding | Novos devs entendem por que código é assim |
"Usuários reportam timeout intermitente no endpoint /dashboard"
## Pensamento 1/4
**Contexto**: Timeout intermitente, não reproduzível localmente.
**Objetivo**: Coletar dados sobre o problema.
**Decisão**:
- Adicionar logging detalhado (query time, response size)
- Verificar APM para patterns (horários, usuários específicos)
**Próximo Passo**: Analisar logs de produção.
---
## Pensamento 2/4
**Contexto**: Logs mostram queries lentas quando usuário tem 10k+ registros.
**Objetivo**: Identificar query problemática.
**Decisão**: Query em `getDashboardData` faz N+1: busca usuário, depois 10k registros um a um.
**Próximo Passo**: Refatorar para usar `with` do Drizzle.
---
## Pensamento 3/4 [REVISÃO do Pensamento 2]
**Contexto**: Refatoração com `with` ainda lenta; problema é volume de dados.
**Objetivo**: Otimizar sem quebrar contrato da API.
**Decisão**:
- Adicionar paginação no dashboard (limit 50)
- Cache com `unstable_cache` por 5min, tag 'dashboard:userId'
- Índice composto em (userId, createdAt DESC)
**Próximo Passo**: Escrever migration e testes.
---
## Pensamento 4/4 [CONCLUSÃO]
**Contexto**: Otimizações implementadas e testadas.
**Resultado**:
- Response time: ~3s → ~200ms
- Testes cobrem paginação e cache invalidation
- Migration adiciona índice
- Documentado em TSDoc por que cache de 5min é suficiente
**Lições**: Sempre considerar escala ao desenhar queries; N+1 é armadilha comum com ORMs.
Sequential Thinking funciona bem quando:
Sequential Thinking é uma metodologia de decomposição de problemas que complementa TDD, Drizzle ORM e outras práticas do projeto. Use para pensar antes de codificar, mantendo rastreabilidade de decisões e permitindo revisão clara de caminhos de raciocínio.
Lembre-se: O objetivo não é burocratizar, mas estruturar pensamento complexo. Para problemas simples, vá direto ao código com TDD. Para problemas complexos, Sequential Thinking evita retrabalho e documenta o por quê das suas escolhas.