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

package/sddk/skills/software-requirements-specification/references/checklist-template.md

@@ -1,65 +1,65 @@
-# Template de Checklist para Entrevista de Especificação
+# Specification Interview Checklist Template
 
-Use este template para criar o Task artifact no início da entrevista. Adapte os tópicos conforme a natureza da feature (nem todos serão aplicáveis).
+Use this template to create the Task artifact at the beginning of the interview. Adapt the topics according to the nature of the feature (not all will be applicable).
 
-## Checklist Padrão
+## Default Checklist
 
 ```markdown
-# Checklist de Especificação — {Nome da Feature}
+# Specification Checklist — {Feature Name}
 
-## Contexto Geral
-- [ ] Objetivo e propósito da feature
-- [ ] Problema de negócio que resolve
-- [ ] Escopo (o que está DENTRO e FORA)
+## General Context
+- [ ] Feature objective and purpose
+- [ ] Business problem it solves
+- [ ] Scope (what's IN and OUT)
 
-## Atores e Personas
-- [ ] Usuários primários (quem usa diretamente)
-- [ ] Usuários secundários (afetados indiretamente)
-- [ ] Papéis e permissões (admin, user, guest, etc.)
+## Actors and Personas
+- [ ] Primary users (direct users)
+- [ ] Secondary users (indirectly affected)
+- [ ] Roles and permissions (admin, user, guest, etc.)
 
-## Requisitos Funcionais
-- [ ] Fluxo principal (happy path)
-- [ ] Fluxos alternativos
-- [ ] Fluxos de exceção / erro
-- [ ] Entradas necessárias (dados, formatos, validações)
-- [ ] Saídas esperadas (resultados, notificações, estados)
+## Functional Requirements
+- [ ] Main flow (happy path)
+- [ ] Alternative flows
+- [ ] Exception / error flows
+- [ ] Required inputs (data, formats, validations)
+- [ ] Expected outputs (results, notifications, states)
 
-## Regras de Negócio
-- [ ] Regras de validação
-- [ ] Regras de cálculo / processamento
-- [ ] Regras de estado / transição
-- [ ] Regras de limite / threshold
+## Business Rules
+- [ ] Validation rules
+- [ ] Calculation / processing rules
+- [ ] State / transition rules
+- [ ] Limit / threshold rules
 
-## Requisitos Não-Funcionais
-- [ ] Performance (tempo de resposta, throughput)
-- [ ] Segurança (autenticação, autorização, dados sensíveis)
-- [ ] Usabilidade (acessibilidade, responsividade)
-- [ ] Confiabilidade (disponibilidade, tolerância a falhas)
+## Non-Functional Requirements
+- [ ] Performance (response time, throughput)
+- [ ] Security (authentication, authorization, sensitive data)
+- [ ] Usability (accessibility, responsiveness)
+- [ ] Reliability (availability, fault tolerance)
 
 ## Interface
-- [ ] Telas / componentes visuais necessários
-- [ ] Integrações com APIs / serviços externos
-- [ ] Eventos / webhooks / notificações
+- [ ] Screens / visual components needed
+- [ ] Integrations with APIs / external services
+- [ ] Events / webhooks / notifications
 
-## Dependências
-- [ ] Dependências com outras features
-- [ ] Dependências com serviços externos
-- [ ] Dependências com dados pré-existentes
+## Dependencies
+- [ ] Dependencies with other features
+- [ ] Dependencies with external services
+- [ ] Dependencies with pre-existing data
 
-## Critérios de Aceitação
-- [ ] Critérios mensuráveis para cada requisito funcional
-- [ ] Cenários de teste que comprovam o funcionamento
+## Acceptance Criteria
+- [ ] Measurable criteria for each functional requirement
+- [ ] Test scenarios that prove functionality
 
-## Restrições e Premissas
-- [ ] Restrições técnicas (stack, plataforma, browser)
-- [ ] Restrições de negócio (regulatórias, compliance)
-- [ ] Premissas assumidas
+## Constraints and Assumptions
+- [ ] Technical constraints (stack, platform, browser)
+- [ ] Business constraints (regulatory, compliance)
+- [ ] Assumptions made
 ```
 
-## Instruções de Uso
+## Usage Instructions
 
-1. Ao iniciar a entrevista, crie o Task artifact com este checklist adaptado à feature
-2. Marque `[/]` quando iniciar a discussão de um tópico
-3. Marque `[x]` quando o tópico estiver completamente resolvido (sem ambiguidade)
-4. Adicione sub-itens conforme novos pontos surgirem durante a entrevista
-5. Não remova itens — se não aplicável, marque como `[x] N/A — {justificativa}`
+1. When starting the interview, create the Task artifact with this checklist adapted to the feature
+2. Mark `[/]` when you begin discussing a topic
+3. Mark `[x]` when the topic is fully resolved (no ambiguity)
+4. Add sub-items as new points emerge during the interview
+5. Do not remove items — if not applicable, mark as `[x] N/A — {justification}`

package/sddk/skills/software-requirements-specification/references/ieee-830-template.md

@@ -1,151 +1,151 @@
-# Template SRS — IEEE 830 / ISO/IEC/IEEE 29148:2018
+# SRS Template — IEEE 830 / ISO/IEC/IEEE 29148:2018
 
-Use este template como base para gerar o documento SRS. Adapte as seções conforme a complexidade da feature. Nunca remova seções — se não aplicável, marque como "N/A" com justificativa.
+Use this template as a base to generate the SRS document. Adapt sections according to the feature's complexity. Never remove sections — if not applicable, mark as "N/A" with justification.
 
 ---
 
-## Estrutura do Documento
+## Document Structure
 
 ```markdown
-# Especificação de Requisitos de Software (SRS)
-## {Nome da Feature}
+# Software Requirements Specification (SRS)
+## {Feature Name}
 
-**Versão**: 1.0
-**Data**: {data de criação}
-**Projeto**: {nome do projeto}
-**Feature**: {nome da feature}
+**Version**: 1.0
+**Date**: {creation date}
+**Project**: {project name}
+**Feature**: {feature name}
 
 ---
 
-## 1. Introdução
+## 1. Introduction
 
-### 1.1 Propósito
-Descrever o propósito deste documento e qual feature ele especifica.
+### 1.1 Purpose
+Describe the purpose of this document and which feature it specifies.
 
-### 1.2 Escopo
-Delimitação clara do que esta feature cobre e o que está FORA do escopo.
+### 1.2 Scope
+Clear delimitation of what this feature covers and what is OUT of scope.
 
-### 1.3 Definições, Acrônimos e Abreviações
-Glossário de termos específicos do domínio usados neste documento.
+### 1.3 Definitions, Acronyms, and Abbreviations
+Glossary of domain-specific terms used in this document.
 
-### 1.4 Referências
-Documentos externos referenciados (outros SRS, APIs, normas).
+### 1.4 References
+External documents referenced (other SRS, APIs, standards).
 
-### 1.5 Visão Geral do Documento
-Breve descrição da organização deste documento.
+### 1.5 Document Overview
+Brief description of how this document is organized.
 
 ---
 
-## 2. Descrição Geral
+## 2. General Description
 
-### 2.1 Perspectiva do Produto
-Como esta feature se encaixa no sistema maior. Dependências com outros módulos/features.
+### 2.1 Product Perspective
+How this feature fits into the larger system. Dependencies with other modules/features.
 
-### 2.2 Funções do Produto
-Resumo de alto nível das funcionalidades que a feature provê.
+### 2.2 Product Functions
+High-level summary of the functionalities the feature provides.
 
-### 2.3 Características dos Usuários
-Personas/atores que interagem com esta feature. Nível técnico esperado.
+### 2.3 User Characteristics
+Personas/actors that interact with this feature. Expected technical level.
 
-### 2.4 Restrições
-Limitações técnicas, regulatórias ou de negócio.
+### 2.4 Constraints
+Technical, regulatory, or business limitations.
 
-### 2.5 Premissas e Dependências
-O que está sendo assumido como verdade e depende de fatores externos.
+### 2.5 Assumptions and Dependencies
+What is being assumed as true and depends on external factors.
 
 ---
 
-## 3. Requisitos Funcionais
+## 3. Functional Requirements
 
-### RF-001: {Nome do Requisito}
-- **Descrição**: {O que o sistema deve fazer}
-- **Entrada**: {Dados de entrada esperados}
-- **Processamento**: {Lógica de negócio aplicada}
-- **Saída**: {Resultado esperado}
-- **Prioridade**: Alta | Média | Baixa
-- **Critério de Aceitação**: {Condições mensuráveis para considerar completo}
+### FR-001: {Requirement Name}
+- **Description**: {What the system must do}
+- **Input**: {Expected input data}
+- **Processing**: {Business logic applied}
+- **Output**: {Expected result}
+- **Priority**: High | Medium | Low
+- **Acceptance Criteria**: {Measurable conditions to consider it complete}
 
-### RF-002: {Nome do Requisito}
-(repetir estrutura para cada requisito funcional)
+### FR-002: {Requirement Name}
+(repeat structure for each functional requirement)
 
 ---
 
-## 4. Requisitos Não-Funcionais
+## 4. Non-Functional Requirements
 
 ### 4.1 Performance
-- Tempo de resposta esperado
-- Throughput mínimo
-- Limites de carga
-
-### 4.2 Segurança
-- Requisitos de autenticação/autorização
-- Proteção de dados sensíveis
-- Conformidade regulatória
-
-### 4.3 Usabilidade
-- Padrões de acessibilidade (WCAG nível)
-- Responsividade (dispositivos alvo)
-- Idiomas suportados
-
-### 4.4 Confiabilidade
-- Disponibilidade esperada
-- Tolerância a falhas
-- Estratégia de recovery
-
-### 4.5 Manutenibilidade
-- Padrões de código exigidos
-- Cobertura de testes mínima
-- Documentação necessária
+- Expected response time
+- Minimum throughput
+- Load limits
+
+### 4.2 Security
+- Authentication/authorization requirements
+- Sensitive data protection
+- Regulatory compliance
+
+### 4.3 Usability
+- Accessibility standards (WCAG level)
+- Responsiveness (target devices)
+- Supported languages
+
+### 4.4 Reliability
+- Expected availability
+- Fault tolerance
+- Recovery strategy
+
+### 4.5 Maintainability
+- Required code standards
+- Minimum test coverage
+- Required documentation
 
 ---
 
-## 5. Regras de Negócio
+## 5. Business Rules
 
-### RN-001: {Nome da Regra}
-- **Descrição**: {Regra de negócio}
-- **Condição**: {Quando se aplica}
-- **Ação**: {O que deve acontecer}
-- **Exceções**: {Casos onde não se aplica}
+### BR-001: {Rule Name}
+- **Description**: {Business rule}
+- **Condition**: {When it applies}
+- **Action**: {What must happen}
+- **Exceptions**: {Cases where it doesn't apply}
 
 ---
 
-## 6. Requisitos de Interface
+## 6. Interface Requirements
 
-### 6.1 Interfaces de Usuário
-Descrição das telas/componentes visuais necessários.
+### 6.1 User Interfaces
+Description of required screens/visual components.
 
-### 6.2 Interfaces de Software
-APIs, serviços externos, integrações com outros sistemas.
+### 6.2 Software Interfaces
+APIs, external services, integrations with other systems.
 
-### 6.3 Interfaces de Hardware
-Dispositivos, sensores, periféricos (se aplicável).
+### 6.3 Hardware Interfaces
+Devices, sensors, peripherals (if applicable).
 
 ---
 
-## 7. Matriz de Rastreabilidade
+## 7. Traceability Matrix
 
-| ID Requisito | Regra de Negócio | Critério de Aceitação | Prioridade |
+| Requirement ID | Business Rule | Acceptance Criteria | Priority |
 |:---|:---|:---|:---|
-| RF-001 | RN-001 | CA-001 | Alta |
+| FR-001 | BR-001 | AC-001 | High |
 
 ---
 
-## 8. Apêndices
+## 8. Appendices
 
-### 8.1 Diagrama de Casos de Uso
-(se aplicável)
+### 8.1 Use Case Diagram
+(if applicable)
 
-### 8.2 Protótipos / Wireframes
-(referências a mockups, se existirem)
+### 8.2 Prototypes / Wireframes
+(references to mockups, if they exist)
 
-### 8.3 Perguntas em Aberto
-(questões não resolvidas que precisam de follow-up)
+### 8.3 Open Questions
+(unresolved questions that need follow-up)
 ```
 
-## Regras de Preenchimento
+## Filling Rules
 
-1. **Cada requisito funcional DEVE ter critério de aceitação** — sem exceção
-2. **Requisitos devem ser testáveis** — se não pode ser verificado, não é um requisito válido
-3. **Use voz ativa** — "O sistema DEVE..." e não "Seria bom se o sistema..."
-4. **Priorize com MoSCoW** — Must/Should/Could/Won't ou Alta/Média/Baixa
-5. **IDs sequenciais** — RF-001, RF-002... / RN-001, RN-002... para rastreabilidade
+1. **Each functional requirement MUST have acceptance criteria** — no exceptions
+2. **Requirements must be testable** — if it can't be verified, it's not a valid requirement
+3. **Use active voice** — "The system SHALL..." not "It would be nice if the system..."
+4. **Prioritize with MoSCoW** — Must/Should/Could/Won't or High/Medium/Low
+5. **Sequential IDs** — FR-001, FR-002... / BR-001, BR-002... for traceability

package/sddk/skills/software-requirements-specification/references/socratic-interview-guide.md

@@ -1,96 +1,96 @@
-# Guia de Entrevista Socrática para Levantamento de Requisitos
+# Socratic Interview Guide for Requirements Gathering
 
-## Princípios do Pensamento Socrático Aplicado
+## Principles of Applied Socratic Thinking
 
-A entrevista socrática não busca respostas diretas — busca **clareza de pensamento**. O objetivo é guiar o stakeholder a articular exatamente o que precisa, eliminando suposições implícitas.
+The Socratic interview does not seek direct answers — it seeks **clarity of thought**. The goal is to guide the stakeholder to articulate exactly what they need, eliminating implicit assumptions.
 
-### Técnicas Fundamentais
+### Fundamental Techniques
 
-#### 1. Pergunta Clarificadora
-Usada quando uma resposta é vaga ou usa termos ambíguos.
+#### 1. Clarifying Question
+Used when an answer is vague or uses ambiguous terms.
 
-**Padrão**: "Quando você diz '{termo}', o que exatamente isso significa neste contexto?"
+**Pattern**: "When you say '{term}', what exactly does that mean in this context?"
 
-**Exemplos**:
-- Usuário: "O login deve ser seguro"
-- Agente: "Quando você diz 'seguro', você está se referindo a: autenticação multifator, criptografia de senhas, proteção contra brute force, ou todas essas?"
+**Examples**:
+- User: "The login should be secure"
+- Agent: "When you say 'secure', are you referring to: multi-factor authentication, password encryption, brute force protection, or all of these?"
 
-#### 2. Pergunta de Suposição
-Usada para expor premissas não declaradas.
+#### 2. Assumption Question
+Used to expose undeclared assumptions.
 
-**Padrão**: "Você está assumindo que {premissa}. Essa premissa é válida?"
+**Pattern**: "You're assuming that {assumption}. Is this assumption valid?"
 
-**Exemplos**:
-- Usuário: "O usuário faz login e acessa o dashboard"
-- Agente: "Você está assumindo que existe apenas um tipo de usuário. Existem diferentes papéis (admin, operador, visitante) com acessos diferentes?"
+**Examples**:
+- User: "The user logs in and accesses the dashboard"
+- Agent: "You're assuming there's only one type of user. Are there different roles (admin, operator, visitor) with different access levels?"
 
-#### 3. Pergunta de Contraponto
-Usada para testar a robustez de um requisito propondo cenários contrários.
+#### 3. Counterpoint Question
+Used to test the robustness of a requirement by proposing contrary scenarios.
 
-**Padrão**: "E se {cenário oposto ou edge case} acontecer? Como o sistema deve reagir?"
+**Pattern**: "What if {opposite scenario or edge case} happens? How should the system react?"
 
-**Exemplos**:
-- Usuário: "O sistema envia um email de confirmação"
-- Agente: "E se o email for inválido? E se o servidor de email estiver fora do ar? O usuário fica bloqueado ou pode prosseguir?"
+**Examples**:
+- User: "The system sends a confirmation email"
+- Agent: "What if the email is invalid? What if the email server is down? Is the user blocked or can they proceed?"
 
-#### 4. Pergunta de Consequência
-Usada para explorar impactos de uma decisão.
+#### 4. Consequence Question
+Used to explore the impacts of a decision.
 
-**Padrão**: "Se implementarmos {decisão}, qual seria o impacto em {aspecto relacionado}?"
+**Pattern**: "If we implement {decision}, what would be the impact on {related aspect}?"
 
-**Exemplos**:
-- Usuário: "Quero que o sistema permita upload de arquivos ilimitados"
-- Agente: "Se permitirmos uploads ilimitados, qual seria o impacto no custo de armazenamento e na performance do sistema? Devemos ter um limite por usuário?"
+**Examples**:
+- User: "I want the system to allow unlimited file uploads"
+- Agent: "If we allow unlimited uploads, what would be the impact on storage costs and system performance? Should we have a per-user limit?"
 
-#### 5. Pergunta de Priorização
-Usada para rankear requisitos quando há muitos.
+#### 5. Prioritization Question
+Used to rank requirements when there are many.
 
-**Padrão**: "Se você tivesse que lançar amanhã com apenas 3 funcionalidades, quais seriam?"
+**Pattern**: "If you had to launch tomorrow with only 3 features, which would they be?"
 
 ---
 
-## Fluxo da Entrevista
+## Interview Flow
 
-### Abertura (1-2 perguntas)
-Objetivo: Entender o contexto geral da feature.
+### Opening (1-2 questions)
+Goal: Understand the general context of the feature.
 
-- "Descreva em uma frase o que essa feature deve fazer"
-- "Quem são os principais usuários dessa feature?"
-- "Qual problema de negócio essa feature resolve?"
+- "Describe in one sentence what this feature should do"
+- "Who are the main users of this feature?"
+- "What business problem does this feature solve?"
 
-### Aprofundamento (N perguntas por tópico)
-Objetivo: Detalhar cada aspecto do checklist.
+### Deep Dive (N questions per topic)
+Goal: Detail each aspect of the checklist.
 
-Para cada tópico do checklist:
-1. Pergunte abertamente primeiro
-2. Use perguntas clarificadoras para respostas vagas
-3. Use perguntas de contraponto para edge cases
-4. Use perguntas de suposição para premissas implícitas
-5. Marque como `[x]` quando inequívoco
+For each checklist topic:
+1. Ask openly first
+2. Use clarifying questions for vague answers
+3. Use counterpoint questions for edge cases
+4. Use assumption questions for implicit premises
+5. Mark as `[x]` when unambiguous
 
-### Validação (2-3 perguntas finais)
-Objetivo: Garantir completude antes de gerar o documento.
+### Validation (2-3 final questions)
+Goal: Ensure completeness before generating the document.
 
-- "Revisando tudo que discutimos, há algum cenário que não cobrimos?"
-- "Existe alguma integração com sistema externo que não mencionamos?"
-- "Há alguma restrição regulatória ou de compliance que afeta essa feature?"
+- "Reviewing everything we discussed, are there any scenarios we didn't cover?"
+- "Is there any integration with an external system that we didn't mention?"
+- "Are there any regulatory or compliance restrictions that affect this feature?"
 
 ---
 
-## Sinais de Alerta (Não Aceitar)
+## Warning Signs (Do Not Accept)
 
-| Sinal | Ação |
+| Signal | Action |
 |:---|:---|
-| "Depois a gente vê isso" | Insistir — decisão adiada vira bug |
-| "É óbvio que..." | Questionar — o óbvio do stakeholder pode não ser do dev |
-| "Algo parecido com o sistema X" | Pedir detalhes — "parecido" é ambíguo |
-| "O usual" / "O padrão" | Definir explicitamente o que é "padrão" neste contexto |
-| Requisitos contraditórios | Apontar a contradição e pedir resolução |
-
-## Quando Encerrar um Tópico
-
-Um tópico está **concluído** quando:
-- A resposta é específica e mensurável
-- Não há interpretação alternativa possível
-- O critério de aceitação é verificável
-- Edge cases foram cobertos
+| "We'll figure that out later" | Insist — deferred decisions become bugs |
+| "It's obvious that..." | Question — what's obvious to the stakeholder may not be to the developer |
+| "Something similar to system X" | Ask for details — "similar" is ambiguous |
+| "The usual" / "The standard" | Explicitly define what "standard" means in this context |
+| Contradictory requirements | Point out the contradiction and request resolution |
+
+## When to Close a Topic
+
+A topic is **complete** when:
+- The answer is specific and measurable
+- There is no alternative interpretation possible
+- The acceptance criterion is verifiable
+- Edge cases have been covered