القائمة
Metodologia de pensamento sequencial para decomposição estruturada e resolução de problemas complexos.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
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.
استنادا إلى تصنيف SOC المهني
| 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.