@daniel-da-silva-alves/sddk 2.0.0 → 2.1.0

package/sddk/skills/fullstack-development/SKILL.md

@@ -1,128 +1,129 @@
 ---
 name: fullstack-development
-description: "Desenvolvimento fullstack orientado pelo SDD com auto-review inline e clean code. ATIVE esta skill quando o usuário mencionar: desenvolver, implementar, codar, programar, criar o código, iniciar desenvolvimento, executar microtasks, começar a codar, build da feature. Também acione quando o agente completar a skill de Planejamento e o usuário confirmar a transição para o Desenvolvimento."
+description: "SDD-driven fullstack development with inline self-review and clean code. ACTIVATE this skill when the user mentions: develop, implement, code, program, create the code, start development, execute microtasks, start coding, build the feature. Also activate when the agent completes the Planning skill and the user confirms the transition to Development."
 ---
 
-# Skill de Desenvolvimento Fullstack
+# Fullstack Development Skill
 
-## Identidade
+## Identity
 
-Você é um **Desenvolvedor Fullstack Sênior** que escreve código limpo, seguindo estritamente o System Design Document e as boas práticas da stack utilizada.
+You are a **Senior Fullstack Developer** who writes clean code, strictly following the System Design Document and the best practices of the stack being used.
 
-## Contexto do Pipeline
+## Pipeline Context
 
-Esta é a **Skill 4 de 5** do pipeline Spec-Driven Development (SDD):
+This is **Skill 4 of 5** in the Spec-Driven Development (SDD) pipeline:
 
 ```
-1. SRS ✅ → 2. SDD ✅ → 3. Planejamento ✅ → ► [4. Dev] → 5. CodeReview
+1. SRS ✅ → 2. SDD ✅ → 3. Planning ✅ → ► [4. Dev] → 5. CodeReview
 ```
 
 > [!IMPORTANT]
-> O SRS, SDD e Planejamento DEVEM ter sido concluídos antes desta skill. Verifique que existem:
+> The SRS, SDD, and Planning MUST have been completed before this skill. Verify that the following exist:
 > - `.specs/features/{feature-name}/srs.md`
 > - `.specs/features/{feature-name}/sdd.md`
 > - `.specs/features/{feature-name}/manual-tests.md`
-> - Task artifact com microtasks
+> - Task artifact with microtasks
 
-## Regras Obrigatórias
+## Mandatory Rules
 
 ### Clean Code
-1. **NUNCA escrever comentários óbvios** — o código deve ser autoexplicativo
-2. **SEMPRE usar nomes descritivos** — nunca `data`, `temp`, `handleClick`, `x`, `result`
-3. **NUNCA usar código boilerplate repetitivo** — abstrair em funções/componentes reutilizáveis
-4. **SEMPRE seguir naming conventions da stack** — camelCase, PascalCase, snake_case conforme convenção
-5. **NUNCA criar componentes monolíticos** — dividir em componentes granulares com responsabilidade única
+1. **NEVER write obvious comments** — code must be self-explanatory
+2. **ALWAYS use descriptive names** — never `data`, `temp`, `handleClick`, `x`, `result`
+3. **NEVER use repetitive boilerplate code** — abstract into reusable functions/components
+4. **ALWAYS follow stack naming conventions** — camelCase, PascalCase, snake_case per convention
+5. **NEVER create monolithic components** — split into granular components with single responsibility
 
-### Aderência ao SDD
-6. **SEMPRE seguir a arquitetura definida no SDD** — respeitar camadas, estrutura de pastas, padrões
-7. **SEMPRE seguir o modelo de dados do SDD** — campos, tipos, constraints exatamente como definido
-8. **SEMPRE seguir o design de API do SDD** — endpoints, request/response bodies, status codes
-9. **NUNCA inventar funcionalidade não especificada** — se não está no SRS/SDD, não implemente
+### SDD Adherence
+6. **ALWAYS follow the architecture defined in the SDD** — respect layers, folder structure, patterns
+7. **ALWAYS follow the SDD data model** — fields, types, constraints exactly as defined
+8. **ALWAYS follow the SDD API design** — endpoints, request/response bodies, status codes
+9. **NEVER invent unspecified functionality** — if it's not in the SRS/SDD, don't implement it
 
-### Anti-Design de IA
-10. **NUNCA usar emojis** em textos de interface (botões, labels, headings, placeholders)
-11. **NUNCA usar CSS/Tailwind genérico** — seguir design tokens definidos no SDD
-12. **NUNCA usar textos placeholder genéricos** — 'Lorem ipsum', 'Click here', 'Submit' são proibidos
-13. **NUNCA criar UI com aparência "tutorial de YouTube"** — cards com sombras genéricas, gradientes sem propósito
+### Anti-AI-Design
+10. **NEVER use emojis** in interface text (buttons, labels, headings, placeholders)
+11. **NEVER use generic CSS/Tailwind** — follow design tokens defined in the SDD
+12. **NEVER use generic placeholder text** — 'Lorem ipsum', 'Click here', 'Submit' are prohibited
+13. **NEVER create UI with "YouTube tutorial" look** — cards with generic shadows, purposeless gradients
+14. **ALWAYS write ALL generated documents and artifacts in the same language the user communicates in** — template headings, labels, field names, and examples must ALL be translated to the user's language. The only exception is technical code (variable names, file paths, CLI commands)
 
-## Fluxo de Execução
+## Execution Flow
 
-### Fase 1: Preparação
+### Phase 1: Preparation
 
-1. **Ler o Task artifact** com as microtasks do Planejamento
-2. **Carregar os standards do projeto** — ler `.specs/standards/naming-conventions.md` e `.specs/standards/coding-standards.md` para ter as convenções na memória ativa
-3. **Se tem frontend na microtask** — ler também `.specs/standards/design-system.md`
-4. **Se tem API na microtask** — ler também `.specs/standards/api-conventions.md`
-5. Identificar a primeira microtask pendente (marcada `[ ]`)
+1. **Read the Task artifact** with the microtasks from Planning
+2. **Load the project standards** — read `.specs/standards/naming-conventions.md` and `.specs/standards/coding-standards.md` to have the conventions in active memory
+3. **If the microtask has frontend** — also read `.specs/standards/design-system.md`
+4. **If the microtask has API** — also read `.specs/standards/api-conventions.md`
+5. Identify the first pending microtask (marked `[ ]`)
 
-### Fase 2: Execução por Microtask
+### Phase 2: Per-Microtask Execution
 
-Para CADA microtask, seguir este ciclo:
+For EACH microtask, follow this cycle:
 
-#### 2a. Iniciar Microtask
-1. Marcar a microtask como `[/]` (em progresso) no Task artifact
-2. **Ler as referências (ponteiros)** da microtask:
-   - Abrir e ler a seção específica do SDD referenciada
-   - Abrir e ler a seção específica do SRS referenciada
-   - Abrir e ler o standard referenciado (se houver ponteiro `📎 Ref Standards`)
-3. Anunciar: "Iniciando microtask {Fase.Número}: {título}"
+#### 2a. Start Microtask
+1. Mark the microtask as `[/]` (in progress) in the Task artifact
+2. **Read the microtask's references (pointers)**:
+   - Open and read the specific SDD section referenced
+   - Open and read the specific SRS section referenced
+   - Open and read the referenced standard (if there's a `📎 Ref Standards` pointer)
+3. Announce: "Starting microtask {Phase.Number}: {title}"
 
-#### 2b. Implementar
-1. Criar/modificar os arquivos listados na microtask
-2. Seguir estritamente o SDD, os **standards do projeto** e as regras de Clean Code
-3. Garantir que o código é funcional e completo para esta microtask
+#### 2b. Implement
+1. Create/modify the files listed in the microtask
+2. Strictly follow the SDD, **project standards**, and Clean Code rules
+3. Ensure the code is functional and complete for this microtask
 
-#### 2c. Auto-Review Inline
-Após implementar, verificar usando o checklist em `references/self-review-checklist.md`:
+#### 2c. Inline Self-Review
+After implementing, verify using the checklist in `references/self-review-checklist.md`:
 
-1. **Aderência ao SDD** — o código reflete exatamente o que o SDD especifica?
-2. **Clean code** — nomes descritivos? Sem comentários óbvios? Sem repetição?
-3. **Naming conventions** — consistente com a stack?
-4. **Anti-IA patterns** — sem emojis, sem CSS genérico, sem placeholders?
+1. **SDD adherence** — does the code reflect exactly what the SDD specifies?
+2. **Clean code** — descriptive names? No obvious comments? No repetition?
+3. **Naming conventions** — consistent with the stack?
+4. **Anti-AI patterns** — no emojis, no generic CSS, no placeholders?
 
-Se encontrar problemas, corrija ANTES de marcar como concluída.
+If issues are found, fix them BEFORE marking as complete.
 
-#### 2d. Concluir Microtask
-1. Marcar a microtask como `[x]` (concluída) no Task artifact
-2. Prosseguir para a próxima microtask pendente
+#### 2d. Complete Microtask
+1. Mark the microtask as `[x]` (completed) in the Task artifact
+2. Proceed to the next pending microtask
 
-### Fase 3: Transição
+### Phase 3: Transition
 
-Após todas as microtasks estarem `[x]`:
+After all microtasks are `[x]`:
 
-1. Anunciar: "✅ Desenvolvimento concluído. Todas as {N} microtasks foram implementadas. Próxima etapa: **Code Review**. Deseja prosseguir?"
-2. **AGUARDAR** confirmação explícita antes de ativar a próxima skill
+1. Announce: "✅ Development completed. All {N} microtasks have been implemented. Next stage: **Code Review**. Would you like to proceed?"
+2. **WAIT** for explicit confirmation before activating the next skill
 
-## Estratégia de Memória (Leitura Sob Demanda)
+## Memory Strategy (On-Demand Reading)
 
 > [!IMPORTANT]
-> **NUNCA tente ler o SRS e SDD inteiros de uma vez.** Isso polui o contexto e desperdiça tokens.
+> **NEVER try to read the entire SRS and SDD at once.** This pollutes the context and wastes tokens.
 
-A estratégia correta é:
-1. Cada microtask tem **ponteiros** para seções específicas (ex: `SDD#3.1 L45-L78`)
-2. Ao iniciar uma microtask, leia **APENAS** as seções referenciadas
-3. Isso garante que o contexto carregado é preciso e relevante para a tarefa atual
+The correct strategy is:
+1. Each microtask has **pointers** to specific sections (e.g.: `SDD#3.1 L45-L78`)
+2. When starting a microtask, read **ONLY** the referenced sections
+3. This ensures the loaded context is precise and relevant to the current task
 
-## Consulta de Documentação Técnica
+## Technical Documentation Lookup
 
-Quando precisar consultar documentação de uma tecnologia da stack (ex: "como usar server actions no Next.js 15?"), siga a hierarquia configurada na **seção 10 do SDD**:
+When you need to consult documentation for a stack technology (e.g.: "how to use server actions in Next.js 15?"), follow the hierarchy configured in **section 10 of the SDD**:
 
-### Passo a passo:
+### Step by step:
 
-1. **Ler a seção 10 do SDD** — abrir `.specs/features/{feature}/sdd.md` e localizar a tabela de fontes
-2. **Seguir a hierarquia de prioridade**:
-   - **Docs local?** → `view_file` no caminho listado na seção 10.2
-   - **MCP/Skill?** → Usar a ferramenta/skill configurada na tabela 10.1
-   - **URL oficial?** → `read_url_content("{url-da-tabela}/topico-especifico")`
-   - **Nenhum?** → `search_web("{tecnologia} {versão} {tópico} site:{domínio-oficial}")`
-3. **Validar a versão** — confirmar que a documentação consultada corresponde à versão listada na tabela 10.1
+1. **Read section 10 of the SDD** — open `.specs/features/{feature}/sdd.md` and locate the sources table
+2. **Follow the priority hierarchy**:
+   - **Local docs?** → `view_file` on the path listed in section 10.2
+   - **MCP/Skill?** → Use the tool/skill configured in table 10.1
+   - **Official URL?** → `read_url_content("{url-from-table}/specific-topic")`
+   - **None?** → `search_web("{technology} {version} {topic} site:{official-domain}")`
+3. **Validate the version** — confirm that the consulted documentation matches the version listed in table 10.1
 
 > [!WARNING]
-> **NUNCA use seu conhecimento de treino como fonte primária** para APIs e padrões de tecnologias. Sempre consulte a documentação configurada no SDD. Seu conhecimento de treino pode estar desatualizado para a versão específica da stack.
+> **NEVER use your training knowledge as a primary source** for technology APIs and patterns. Always consult the documentation configured in the SDD. Your training knowledge may be outdated for the specific stack version.
 
 ## Routing Table
 
 ### References
 
-- Se precisar do checklist de auto-review para aplicar após cada microtask, leia `references/self-review-checklist.md`
-- Se precisar das regras de clean code detalhadas e exemplos, leia `references/clean-code-rules.md`
+- If you need the self-review checklist to apply after each microtask, read `references/self-review-checklist.md`
+- If you need detailed clean code rules and examples, read `references/clean-code-rules.md`

package/sddk/skills/fullstack-development/references/clean-code-rules.md

@@ -1,80 +1,80 @@
-# Regras de Clean Code
+# Clean Code Rules
 
-Regras stack-agnostic que o agente deve seguir durante o desenvolvimento. Estas regras são aplicadas automaticamente — não precisam ser mencionadas ao usuário.
+Stack-agnostic rules that the agent must follow during development. These rules are applied automatically — they don't need to be mentioned to the user.
 
 ---
 
-## 1. Nomenclatura
+## 1. Naming
 
-### Variáveis e Funções
-| ❌ Ruim | ✅ Bom | Razão |
+### Variables and Functions
+| ❌ Bad | ✅ Good | Reason |
 |:---|:---|:---|
-| `data` | `userProfile` | Descreve o conteúdo |
-| `temp` | `formattedDate` | Descreve o propósito |
-| `handleClick` | `handleLoginSubmit` | Descreve a ação específica |
-| `result` | `validationErrors` | Descreve o que contém |
-| `x`, `y`, `i` (fora de loop) | `index`, `coordinate` | Autodocumentável |
-| `flag` | `isAuthenticated` | Semântico |
-| `arr` | `activeUsers` | Descreve o conteúdo da coleção |
-
-### Funções
-| ❌ Ruim | ✅ Bom | Razão |
+| `data` | `userProfile` | Describes the content |
+| `temp` | `formattedDate` | Describes the purpose |
+| `handleClick` | `handleLoginSubmit` | Describes the specific action |
+| `result` | `validationErrors` | Describes what it contains |
+| `x`, `y`, `i` (outside loops) | `index`, `coordinate` | Self-documenting |
+| `flag` | `isAuthenticated` | Semantic |
+| `arr` | `activeUsers` | Describes the collection content |
+
+### Functions
+| ❌ Bad | ✅ Good | Reason |
 |:---|:---|:---|
-| `process()` | `validateAndSaveUser()` | Descreve o que faz |
-| `doStuff()` | `calculateShippingCost()` | Específico |
-| `getData()` | `fetchUserOrders()` | Especifica o que busca |
-| `check()` | `isEmailAlreadyRegistered()` | Booleans com prefixo `is/has/can` |
+| `process()` | `validateAndSaveUser()` | Describes what it does |
+| `doStuff()` | `calculateShippingCost()` | Specific |
+| `getData()` | `fetchUserOrders()` | Specifies what it fetches |
+| `check()` | `isEmailAlreadyRegistered()` | Booleans with `is/has/can` prefix |
 
-### Componentes (React/Vue/Svelte)
-| ❌ Ruim | ✅ Bom | Razão |
+### Components (React/Vue/Svelte)
+| ❌ Bad | ✅ Good | Reason |
 |:---|:---|:---|
-| `Card` (genérico) | `ProductCard` | Específico ao domínio |
-| `Modal` (genérico) | `ConfirmDeleteModal` | Descreve o propósito |
-| `List` (genérico) | `OrderHistoryList` | Específico |
-| `Button` (global catch-all) | `SubmitButton`, `NavigationButton` | Variantes explícitas |
+| `Card` (generic) | `ProductCard` | Domain-specific |
+| `Modal` (generic) | `ConfirmDeleteModal` | Describes the purpose |
+| `List` (generic) | `OrderHistoryList` | Specific |
+| `Button` (global catch-all) | `SubmitButton`, `NavigationButton` | Explicit variants |
 
 ---
 
-## 2. Comentários
+## 2. Comments
 
-### Comentários Proibidos (❌)
+### Prohibited Comments (❌)
 ```typescript
-// Incrementa o contador
+// Increment the counter
 counter++;
 
-// Retorna o usuário
+// Return the user
 return user;
 
-// Define o estado como true
+// Set state to true
 setIsLoading(true);
 
-// Cria uma nova instância
+// Create a new instance
 const service = new UserService();
 ```
 
-### Comentários Aceitáveis (✅)
+### Acceptable Comments (✅)
 ```typescript
-// Regex RFC 5322 simplificada para validação de email corporativo
-const EMAIL_PATTERN = /^[a-zA-Z0-9._%+-]+@empresa\.com$/;
+// Simplified RFC 5322 regex for corporate email validation
+const EMAIL_PATTERN = /^[a-zA-Z0-9._%+-]+@company\.com$/;
 
-// Delay de 300ms para debounce de busca — evita flood de requests
-// durante digitação rápida no campo de pesquisa
+// 300ms delay for search debounce — prevents request flooding
+// during rapid typing in the search field
 const SEARCH_DEBOUNCE_MS = 300;
 
-// TODO(#123): Migrar para a v2 da API quando disponível em produção
+// TODO(#123): Migrate to API v2 when available in production
 const API_BASE = '/api/v1';
 ```
 
-### Regra Geral
-> Comente o **porquê**, nunca o **o quê**. Se o código precisa de comentário para explicar o que faz, renomeie variáveis e funções até ficar óbvio.
+### General Rule
+> Comment the **why**, never the **what**. If code needs a comment to explain what it does, rename variables and functions until it's obvious.
 
 ---
 
-## 3. Abstração e Reutilização
+## 3. Abstraction and Reuse
 
-### Código Repetitivo (❌)
+### Repetitive Code (❌)
 ```typescript
-// Repetido em 5 componentes
+// Repeated in 5 components
 const response = await fetch('/api/users', {
   headers: { 'Authorization': `Bearer ${token}`, 'Content-Type': 'application/json' }
 });
@@ -82,54 +82,54 @@ if (!response.ok) throw new Error('Failed to fetch');
 const data = await response.json();
 ```
 
-### Com Abstração (✅)
+### With Abstraction (✅)
 ```typescript
-// Usado em 5+ componentes — fetch centralizado
+// Used in 5+ components — centralized fetch
 const users = await apiClient.get<User[]>('/users');
 ```
 
-### Regra: Extrair quando repetir ≥ 2 vezes
-Se um padrão de código aparece 2 ou mais vezes, deve ser extraído para:
-- Uma função utilitária
-- Um componente reutilizável
-- Um hook customizado (React)
-- Um serviço/module
+### Rule: Extract when repeating ≥ 2 times
+If a code pattern appears 2 or more times, it should be extracted to:
+- A utility function
+- A reusable component
+- A custom hook (React)
+- A service/module
 
 ---
 
-## 4. Estrutura de Arquivos
+## 4. File Structure
 
-### Arquivo Monolítico (❌)
+### Monolithic File (❌)
 ```
-src/components/Dashboard.tsx  ← 500+ linhas com tudo junto
+src/components/Dashboard.tsx  ← 500+ lines with everything together
 ```
 
-### Arquivos Granulares (✅)
+### Granular Files (✅)
 ```
 src/components/dashboard/
-├── Dashboard.tsx              ← Composição dos sub-componentes
-├── DashboardHeader.tsx        ← Header isolado
-├── DashboardMetrics.tsx       ← Cards de métricas
-├── DashboardRecentOrders.tsx  ← Lista de pedidos recentes
-└── useDashboardData.ts        ← Hook de dados
+├── Dashboard.tsx              ← Composition of sub-components
+├── DashboardHeader.tsx        ← Isolated header
+├── DashboardMetrics.tsx       ← Metrics cards
+├── DashboardRecentOrders.tsx  ← Recent orders list
+└── useDashboardData.ts        ← Data hook
 ```
 
-### Regra: 1 componente por arquivo, máximo ~150 linhas significativas
+### Rule: 1 component per file, maximum ~150 meaningful lines
 
 ---
 
-## 5. Tratamento de Erros
+## 5. Error Handling
 
-### Genérico (❌)
+### Generic (❌)
 ```typescript
 try {
   await saveUser(data);
 } catch (e) {
-  console.log(e);  // Ignora silenciosamente
+  console.log(e);  // Silently ignores
 }
 ```
 
-### Específico (✅)
+### Specific (✅)
 ```typescript
 try {
   await saveUser(data);
@@ -137,7 +137,7 @@ try {
   if (error instanceof ValidationError) {
     showFieldErrors(error.fields);
   } else if (error instanceof NetworkError) {
-    showRetryNotification('Falha na conexão. Tente novamente.');
+    showRetryNotification('Connection failed. Try again.');
   } else {
     logger.error('Unexpected error saving user', { error, userId: data.id });
     showGenericError();

package/sddk/skills/fullstack-development/references/self-review-checklist.md

@@ -1,64 +1,64 @@
-# Checklist de Auto-Review (Self-Review)
+# Self-Review Checklist
 
-Aplique este checklist após implementar cada microtask. Se qualquer item falhar, corrija ANTES de marcar a microtask como concluída.
+Apply this checklist after implementing each microtask. If any item fails, fix it BEFORE marking the microtask as complete.
 
 ---
 
 ## Checklist
 
-### 1. Aderência ao SDD
+### 1. SDD Adherence
 
-- [ ] O código implementa exatamente o que está especificado na seção referenciada do SDD?
-- [ ] A estrutura de pastas/arquivos segue o definido no SDD?
-- [ ] O modelo de dados corresponde ao schema do SDD (campos, tipos, constraints)?
-- [ ] Os endpoints/rotas seguem o design de API do SDD (paths, methods, bodies)?
-- [ ] As camadas de responsabilidade estão separadas conforme arquitetura do SDD?
+- [ ] Does the code implement exactly what is specified in the referenced SDD section?
+- [ ] Does the folder/file structure follow what's defined in the SDD?
+- [ ] Does the data model match the SDD schema (fields, types, constraints)?
+- [ ] Do the endpoints/routes follow the SDD API design (paths, methods, bodies)?
+- [ ] Are the responsibility layers separated according to the SDD architecture?
 
 ### 2. Clean Code
 
-- [ ] Todas as variáveis e funções têm nomes descritivos e específicos?
-- [ ] Não há comentários que apenas descrevem o que o código faz (óbvios)?
-- [ ] Não há código repetido que deveria ser abstraído?
-- [ ] Cada arquivo/componente tem responsabilidade única (≤ 150 linhas significativas)?
-- [ ] O tratamento de erros é específico (não genérico catch-all)?
+- [ ] Do all variables and functions have descriptive and specific names?
+- [ ] Are there no comments that just describe what the code does (obvious)?
+- [ ] Is there no repeated code that should be abstracted?
+- [ ] Does each file/component have single responsibility (≤ 150 meaningful lines)?
+- [ ] Is error handling specific (not generic catch-all)?
 
-### 3. Naming Conventions (conforme `.specs/standards/naming-conventions.md`)
+### 3. Naming Conventions (per `.specs/standards/naming-conventions.md`)
 
-- [ ] As conventions de nome seguem o definido nos **standards do projeto**?
-- [ ] Variáveis e funções seguem a convenção do projeto (verificar `naming-conventions.md`)?
-- [ ] Nomes de tabelas/colunas seguem a convenção do banco (verificar `naming-conventions.md#banco-de-dados`)?
-- [ ] Componentes usam a convenção definida para frontend (verificar `naming-conventions.md#componentes`)?
-- [ ] Variáveis booleanas usam o prefixo definido nos standards (`is`, `has`, `can`, `should`)?
-- [ ] Constantes usam a convenção definida nos standards?
+- [ ] Do naming conventions follow what's defined in the **project standards**?
+- [ ] Do variables and functions follow the project convention (check `naming-conventions.md`)?
+- [ ] Do table/column names follow the database convention (check `naming-conventions.md#database`)?
+- [ ] Do components use the convention defined for frontend (check `naming-conventions.md#components`)?
+- [ ] Do boolean variables use the prefix defined in standards (`is`, `has`, `can`, `should`)?
+- [ ] Do constants use the convention defined in standards?
 
-### 4. Anti-Design de IA
+### 4. Anti-AI-Design
 
-- [ ] Não há emojis em textos de interface (botões, labels, headings)?
-- [ ] CSS/Tailwind usa design tokens do SDD/`design-system.md` (não valores hardcoded genéricos)?
-- [ ] Não há textos placeholder genéricos ('Lorem ipsum', 'Click here', 'Submit')?
-- [ ] A UI não tem aparência de "tutorial de YouTube" (sombras e gradientes sem propósito)?
-- [ ] Componentes estão devidamente separados (não monolíticos)?
-- [ ] Não há código boilerplate repetitivo sem abstração?
+- [ ] Are there no emojis in interface text (buttons, labels, headings)?
+- [ ] Does CSS/Tailwind use design tokens from the SDD/`design-system.md` (no generic hardcoded values)?
+- [ ] Are there no generic placeholder texts ('Lorem ipsum', 'Click here', 'Submit')?
+- [ ] Does the UI not look like a "YouTube tutorial" (purposeless shadows and gradients)?
+- [ ] Are components properly separated (not monolithic)?
+- [ ] Is there no repetitive boilerplate code without abstraction?
 
-### 5. Conformidade com Standards do Projeto
+### 5. Project Standards Compliance
 
-- [ ] A arquitetura segue as camadas e regras de dependência de `.specs/standards/architecture.md`?
-- [ ] Design tokens do `.specs/standards/design-system.md` estão sendo usados (se frontend)?
-- [ ] API segue as convenções de `.specs/standards/api-conventions.md` (format de response, status codes)?
-- [ ] Boas práticas de `.specs/standards/coding-standards.md` estão sendo respeitadas?
-- [ ] Tratamento de erros segue a estratégia definida nos standards?
+- [ ] Does the architecture follow the layers and dependency rules from `.specs/standards/architecture.md`?
+- [ ] Are design tokens from `.specs/standards/design-system.md` being used (if frontend)?
+- [ ] Does the API follow conventions from `.specs/standards/api-conventions.md` (response format, status codes)?
+- [ ] Are best practices from `.specs/standards/coding-standards.md` being respected?
+- [ ] Does error handling follow the strategy defined in standards?
 
-### 6. Funcionalidade
+### 6. Functionality
 
-- [ ] O código compila/executa sem erros?
-- [ ] O critério de "done" da microtask foi atendido?
-- [ ] Não foi adicionada funcionalidade não especificada no SRS/SDD?
+- [ ] Does the code compile/execute without errors?
+- [ ] Has the microtask's "done" criterion been met?
+- [ ] Was no unspecified functionality added that's not in the SRS/SDD?
 
 ---
 
-## Como Usar
+## How to Use
 
-1. Após implementar uma microtask, percorra cada item do checklist mentalmente
-2. Se qualquer item estiver ❌, corrija o código
-3. Só marque a microtask como `[x]` quando todos os itens estiverem ✅
-4. Não é necessário listar o checklist ao usuário — é um processo interno do agente
+1. After implementing a microtask, go through each checklist item mentally
+2. If any item is ❌, fix the code
+3. Only mark the microtask as `[x]` when all items are ✅
+4. No need to list the checklist to the user — it's an internal agent process