القائمة
Test-Driven Development - Escreva testes primeiro, sempre
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Especialista em produção e marketing de podcasts. Pesquisa convidados, cria perguntas inteligentes e memoráveis, sugere estruturas de episódio e ideias de marketing. Sempre aprende sobre o podcast do usuário primeiro. Use com /podcast ou quando o usuário mencionar podcast, entrevista, convidado, perguntas para entrevistar, ou preparar episódio.
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
Automatic agent selection and intelligent task routing. Analyzes user requests and automatically selects the best specialist agent(s) without requiring explicit user mentions.
API Design - Princípios RESTful e boas práticas
Padrões de arquitetura de software - Decisões OBJETIVAS sobre design de sistemas
| name | tdd-development |
| description | Test-Driven Development - Escreva testes primeiro, sempre |
| version | 1.0.0 |
| category | workflow |
| triggers | ["tdd","test","teste","testing","unit test","teste unitário","red green refactor","desenvolvimento guiado por testes"] |
| tools | [] |
| author | liquid-ai |
| based_on | obra/superpowers |
Esta skill implementa a disciplina de Test-Driven Development. TDD não é opcional — é mandatório para código confiável e manutenível.
Escreva o teste primeiro. Veja-o falhar. Escreva o código mínimo para passar.
Observar o teste falhar prova que o teste realmente valida algo significativo.
┌─────────────────────────────────────────┐
│ 1. Escreva um teste MÍNIMO que falha │
│ 2. Execute o teste │
│ 3. CONFIRME que ele falha │
│ 4. O teste deve falhar pelo motivo │
│ CORRETO (não por erro de sintaxe) │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ 1. Escreva o código MÍNIMO necessário │
│ 2. Não adicione funcionalidade extra │
│ 3. Execute o teste │
│ 4. CONFIRME que ele passa │
└─────────────────────────────────────────┘
┌─────────────────────────────────────────┐
│ 1. Melhore a qualidade do código │
│ 2. Remova duplicação │
│ 3. Melhore nomes e estrutura │
│ 4. Execute os testes novamente │
│ 5. CONFIRME que ainda passam │
└─────────────────────────────────────────┘
| Violação | Por Que é Proibido |
|---|---|
| Escrever código de produção antes do teste | Você não sabe se o código funciona |
| Pular a fase RED | Você não provou que o teste valida algo |
| Escrever múltiplos testes de uma vez | Perde o feedback rápido do ciclo |
| "Consertar" código que já existe sem teste | Está adivinhando, não verificando |
| Usar código escrito antes do teste | Delete e reescreva com TDD |
"É só um código simples, não precisa de teste"
"Vou testar depois"
"Já testei manualmente"
"O prazo está apertado"
"Já escrevi o código, seria desperdício deletar"
// ✅ CORRETO: Nome descritivo, uma asserção, arrange-act-assert
describe('Calculator', () => {
it('should add two positive numbers', () => {
// Arrange
const calculator = new Calculator();
// Act
const result = calculator.add(2, 3);
// Assert
expect(result).toBe(5);
});
});
// ❌ ERRADO: Múltiplas asserções, nome vago, sem estrutura clara
describe('Calculator', () => {
it('works', () => {
const calc = new Calculator();
expect(calc.add(2, 3)).toBe(5);
expect(calc.subtract(5, 3)).toBe(2);
expect(calc.multiply(2, 3)).toBe(6);
expect(calc.divide(6, 2)).toBe(3);
});
});
| Sinal | Problema |
|---|---|
| "Deixa eu só terminar esse código e depois escrevo o teste" | Violação direta do TDD |
| "Esse teste é óbvio, não precisa ver falhar" | Não provou que o teste funciona |
| "Vou escrever todos os testes primeiro" | Perdeu o ciclo de feedback |
| "O código já estava funcionando, só adicionei o teste" | Teste de confirmação, não TDD |
| "Não sei como testar isso" | Sinal de design acoplado |
| Situação | Solução |
|---|---|
| "Não sei que teste escrever" | Comece pelo comportamento mais simples possível |
| "O teste é muito difícil de escrever" | O código está muito acoplado. Simplifique o design |
| "Tenho muitos testes quebrando" | Você mudou muito código de uma vez. Volte atrás e faça mudanças menores |
| "O teste passa mas o comportamento está errado" | O teste não está testando o que deveria. Revise as asserções |
| "Não consigo fazer o teste falhar" | Você escreveu o código antes do teste. Delete o código e recomece |
1. Receba um requisito
↓
2. Escreva um teste que falha (RED)
↓
3. Confirme a falha
↓
4. Escreva código mínimo (GREEN)
↓
5. Confirme que passa
↓
6. Refatore se necessário (REFACTOR)
↓
7. Confirme que ainda passa
↓
8. Repita para o próximo requisito
# Watch mode - executa testes automaticamente
npm test -- --watch
# Coverage - verifica cobertura
npm test -- --coverage
# Single file
npm test -- path/to/test.spec.ts
"Código sem teste é código quebrado que ainda não descobrimos."
"TDD não é sobre testes. É sobre design. Os testes são um bônus."
"Se você não viu o teste falhar, você não sabe se ele funciona."
Esta skill deve ser ativada AUTOMATICAMENTE quando: