@polymorphism-tech/morph-spec 2.4.0 → 3.0.0

package/content/.claude/skills/{specialists → level-2-domains/quality}/testing-specialist.md

@@ -1,126 +1,126 @@
-# Testing Specialist
-
-> **Layer:** 2 | **Load:** on-keyword | **Keywords:** test, testing, mock, fake, simulation, unit test, integration test
-
-Especialista em testes, mocking e simulação para projetos .NET.
-
-## Strategy
-
-| Level | What | Tools |
-|-------|------|-------|
-| **Unit** | Business logic, domain, handlers | xUnit + Moq + FluentAssertions |
-| **Integration** | API flows, DB operations | WebApplicationFactory + TestContainers |
-| **Component** | Blazor rendering, events | bUnit |
-| **E2E** | Critical user journeys | Playwright (if needed) |
-
-**Focus:** Critical/complex code. Don't aim for 100%, aim for value. Cover edge cases and error paths.
-
----
-
-## Core Patterns
-
-### AAA (Arrange-Act-Assert)
-
-```csharp
-[Fact]
-public async Task CreateOrder_Should_ReturnSuccess_When_ValidInput()
-{
-    // Arrange
-    var command = new CreateOrderCommand { CustomerId = 1, Items = [...] };
-    var handler = new CreateOrderHandler(_mockRepo.Object);
-    // Act
-    var result = await handler.Handle(command, CancellationToken.None);
-    // Assert
-    result.IsSuccess.Should().BeTrue();
-}
-```
-
-### Naming Convention
-```
-[Method]_Should_[ExpectedResult]_When_[Condition]
-```
-
-### Test Data Builders
-Use builder pattern for complex test entities: `new OrderBuilder().WithCustomer(123).WithStatus(Completed).Build()`
-
-### Mocking (Moq)
-```csharp
-var mockRepo = new Mock<IOrderRepository>();
-mockRepo.Setup(r => r.GetByIdAsync(It.IsAny<int>())).ReturnsAsync(new Order { Id = 1 });
-mockRepo.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Once);
-```
-
-### Integration Tests (WebApplicationFactory)
-Replace real DB with in-memory in `ConfigureServices`, use `CreateClient()` for HTTP calls.
-
-### bUnit (Blazor)
-`RenderComponent<Counter>()` → `Find("button").Click()` → assert `TextContent`.
-
----
-
-## Libraries
-
-| Library | Purpose | NuGet |
-|---------|---------|-------|
-| xUnit | Test framework | `xunit` |
-| Moq | Mocking | `Moq` |
-| FluentAssertions | Readable assertions | `FluentAssertions` |
-| Bogus | Fake data | `Bogus` |
-| TestContainers | DB containers | `Testcontainers` |
-| Respawn | DB reset | `Respawn` |
-| WireMock | HTTP mocking | `WireMock.Net` |
-| bUnit | Blazor testing | `bunit` |
-
-## Folder Structure
-
-```
-tests/
-├── Unit/{Domain,Application,Builders}/
-├── Integration/{Api,Fixtures}/
-└── E2E/
-```
-
-## Anti-Patterns
-1. **Fragile tests** — test behavior, not implementation
-2. **Slow tests** — use mocks, not real DB for unit tests
-3. **Coupled tests** — each test independent
-4. **Vague assertions** — use specific FluentAssertions
-5. **Giant setup** — extract to builders/fixtures
-
----
-
-## Simulation of External Services
-
-> **Ref:** `.claude/skills/checklists/simulation-checklist.md` for complete checklist
-
-### Key Rules
-
-| Mock Type | Characteristic | DI Lifetime |
-|-----------|---------------|-------------|
-| **Stateful** (Dictionary, List) | Keeps data between calls | `Singleton` |
-| **Stateless** | No state | `Scoped` |
-
-```csharp
-// ❌ Stateful with Scoped = loses state between requests
-services.AddScoped<IReplicateClient, FakeReplicateClient>();
-// ✅ Stateful with Singleton
-services.AddSingleton<IReplicateClient, FakeReplicateClient>();
-```
-
-**Before implementing mocks:** Map ALL dependencies (interfaces, transitive deps, lifetimes).
-
----
-
-## Checklists
-
-### Per Test Type
-| Target | Test |
-|--------|------|
-| Entity/Domain | Creation validation, state transitions (valid + invalid), invariants |
-| Handler/Service | Happy path, invalid input, not found (404), auth error, timeout |
-| API | Status codes, response body, request validation, auth |
-| Blazor Component | Initial render, user events, states (loading/error/empty), form validation |
-
----
-
-*MORPH-SPEC by Polymorphism Tech*
+# Testing Specialist
+
+> **Layer:** 2 | **Load:** on-keyword | **Keywords:** test, testing, mock, fake, simulation, unit test, integration test
+
+Especialista em testes, mocking e simulação para projetos .NET.
+
+## Strategy
+
+| Level | What | Tools |
+|-------|------|-------|
+| **Unit** | Business logic, domain, handlers | xUnit + Moq + FluentAssertions |
+| **Integration** | API flows, DB operations | WebApplicationFactory + TestContainers |
+| **Component** | Blazor rendering, events | bUnit |
+| **E2E** | Critical user journeys | Playwright (if needed) |
+
+**Focus:** Critical/complex code. Don't aim for 100%, aim for value. Cover edge cases and error paths.
+
+---
+
+## Core Patterns
+
+### AAA (Arrange-Act-Assert)
+
+```csharp
+[Fact]
+public async Task CreateOrder_Should_ReturnSuccess_When_ValidInput()
+{
+    // Arrange
+    var command = new CreateOrderCommand { CustomerId = 1, Items = [...] };
+    var handler = new CreateOrderHandler(_mockRepo.Object);
+    // Act
+    var result = await handler.Handle(command, CancellationToken.None);
+    // Assert
+    result.IsSuccess.Should().BeTrue();
+}
+```
+
+### Naming Convention
+```
+[Method]_Should_[ExpectedResult]_When_[Condition]
+```
+
+### Test Data Builders
+Use builder pattern for complex test entities: `new OrderBuilder().WithCustomer(123).WithStatus(Completed).Build()`
+
+### Mocking (Moq)
+```csharp
+var mockRepo = new Mock<IOrderRepository>();
+mockRepo.Setup(r => r.GetByIdAsync(It.IsAny<int>())).ReturnsAsync(new Order { Id = 1 });
+mockRepo.Verify(r => r.SaveAsync(It.IsAny<Order>()), Times.Once);
+```
+
+### Integration Tests (WebApplicationFactory)
+Replace real DB with in-memory in `ConfigureServices`, use `CreateClient()` for HTTP calls.
+
+### bUnit (Blazor)
+`RenderComponent<Counter>()` → `Find("button").Click()` → assert `TextContent`.
+
+---
+
+## Libraries
+
+| Library | Purpose | NuGet |
+|---------|---------|-------|
+| xUnit | Test framework | `xunit` |
+| Moq | Mocking | `Moq` |
+| FluentAssertions | Readable assertions | `FluentAssertions` |
+| Bogus | Fake data | `Bogus` |
+| TestContainers | DB containers | `Testcontainers` |
+| Respawn | DB reset | `Respawn` |
+| WireMock | HTTP mocking | `WireMock.Net` |
+| bUnit | Blazor testing | `bunit` |
+
+## Folder Structure
+
+```
+tests/
+├── Unit/{Domain,Application,Builders}/
+├── Integration/{Api,Fixtures}/
+└── E2E/
+```
+
+## Anti-Patterns
+1. **Fragile tests** — test behavior, not implementation
+2. **Slow tests** — use mocks, not real DB for unit tests
+3. **Coupled tests** — each test independent
+4. **Vague assertions** — use specific FluentAssertions
+5. **Giant setup** — extract to builders/fixtures
+
+---
+
+## Simulation of External Services
+
+> **Ref:** `.claude/skills/checklists/simulation-checklist.md` for complete checklist
+
+### Key Rules
+
+| Mock Type | Characteristic | DI Lifetime |
+|-----------|---------------|-------------|
+| **Stateful** (Dictionary, List) | Keeps data between calls | `Singleton` |
+| **Stateless** | No state | `Scoped` |
+
+```csharp
+// ❌ Stateful with Scoped = loses state between requests
+services.AddScoped<IReplicateClient, FakeReplicateClient>();
+// ✅ Stateful with Singleton
+services.AddSingleton<IReplicateClient, FakeReplicateClient>();
+```
+
+**Before implementing mocks:** Map ALL dependencies (interfaces, transitive deps, lifetimes).
+
+---
+
+## Checklists
+
+### Per Test Type
+| Target | Test |
+|--------|------|
+| Entity/Domain | Creation validation, state transitions (valid + invalid), invariants |
+| Handler/Service | Happy path, invalid input, not found (404), auth error, timeout |
+| API | Status codes, response body, request validation, auth |
+| Blazor Component | Initial render, user events, states (loading/error/empty), form validation |
+
+---
+
+*MORPH-SPEC by Polymorphism Tech*

package/content/.claude/skills/level-3-technologies/README.md

@@ -0,0 +1,7 @@
+# Level 3: Technologies
+
+Technology-specific implementation patterns.
+
+**Purpose:** Skills for specific technologies (EF Core, Blazor, Hangfire, SignalR, etc.).
+
+**To be populated in Phase 8/9.**

package/content/.claude/skills/level-4-patterns/README.md

@@ -0,0 +1,7 @@
+# Level 4: Patterns
+
+Architectural and design patterns.
+
+**Purpose:** Skills for specific patterns (CQRS, Event Sourcing, DDD, Repository, etc.).
+
+**To be populated later.**

package/content/.claude/skills/specialists/prompt-engineer.md

@@ -0,0 +1,189 @@
+# Prompt Engineer
+
+Especialista em engenharia de prompts para LLMs e sistemas de IA. Use PROATIVAMENTE ao construir features de IA, melhorar performance de agentes ou criar system prompts.
+
+## Responsabilidades
+
+1. Criar prompts otimizados para LLMs
+2. Aplicar técnicas avançadas de prompting
+3. Definir formatos de output estruturados
+4. Otimizar prompts existentes
+5. Adaptar prompts para diferentes modelos
+
+## Triggers
+
+Keywords: `prompt`, `prompting`, `system prompt`, `few-shot`, `chain-of-thought`, `llm prompt`, `agent prompt`, `engenharia de prompt`
+
+## Áreas de Expertise
+
+### Otimização de Prompts
+
+- Seleção few-shot vs zero-shot
+- Raciocínio chain-of-thought
+- Role-playing e definição de perspectiva
+- Especificação de formato de output
+- Definição de constraints e limites
+
+### Arsenal de Técnicas
+
+- Constitutional AI principles
+- Recursive prompting
+- Tree of thoughts
+- Self-consistency checking
+- Prompt chaining e pipelines
+
+### Otimização por Modelo
+
+- **Claude**: Ênfase em helpful, harmless, honest
+- **GPT**: Estrutura clara e exemplos
+- **Open models**: Necessidades específicas de formatação
+- **Modelos especializados**: Adaptação de domínio
+
+## Processo de Otimização
+
+1. Analisar caso de uso pretendido
+2. Identificar requisitos e constraints chave
+3. Selecionar técnicas de prompting apropriadas
+4. Criar prompt inicial com estrutura clara
+5. Testar e iterar baseado em outputs
+6. Documentar padrões efetivos
+
+## Formato de Output Obrigatório
+
+**IMPORTANTE:** SEMPRE que criar qualquer prompt, DEVE exibir o texto completo. NUNCA apenas descreva um prompt.
+
+### O Prompt
+```
+[Exibir texto completo do prompt aqui]
+```
+
+### Notas de Implementação
+- Técnicas chave usadas
+- Por que essas escolhas foram feitas
+- Outcomes esperados
+
+## Deliverables
+
+- **O texto do prompt** (exibido completo, formatado)
+- Explicação das escolhas de design
+- Guidelines de uso
+- Exemplos de outputs esperados
+- Benchmarks de performance
+- Estratégias de tratamento de erro
+
+## Padrões Comuns
+
+### Estrutura System/User/Assistant
+```
+<system>
+[Contexto e personalidade]
+</system>
+
+<user>
+[Input do usuário]
+</user>
+```
+
+### Tags XML para Seções Claras
+```xml
+<context>
+[Background information]
+</context>
+
+<instructions>
+[What to do]
+</instructions>
+
+<output_format>
+[Expected format]
+</output_format>
+```
+
+### Outros Padrões
+- Formatos de output explícitos
+- Raciocínio passo-a-passo
+- Critérios de auto-avaliação
+
+## Exemplo de Output
+
+Quando solicitado a criar prompt para code review:
+
+### O Prompt
+```
+You are an expert code reviewer with 10+ years of experience. Review the provided code focusing on:
+1. Security vulnerabilities
+2. Performance optimizations
+3. Code maintainability
+4. Best practices
+
+For each issue found, provide:
+- Severity level (Critical/High/Medium/Low)
+- Specific line numbers
+- Explanation of the issue
+- Suggested fix with code example
+
+Format your response as a structured report with clear sections.
+```
+
+### Notas de Implementação
+- Usa role-playing para estabelecer expertise
+- Fornece critérios de avaliação claros
+- Especifica formato de output para consistência
+- Inclui requisitos de feedback acionável
+
+## Técnicas Avançadas
+
+### Few-Shot Prompting
+```
+Here are examples of good responses:
+
+Example 1:
+Input: [example input]
+Output: [example output]
+
+Example 2:
+Input: [example input]
+Output: [example output]
+
+Now process this:
+Input: [actual input]
+```
+
+### Chain-of-Thought
+```
+Think through this step by step:
+1. First, identify...
+2. Then, analyze...
+3. Finally, conclude...
+
+Show your reasoning before giving the final answer.
+```
+
+### Self-Consistency
+```
+Generate 3 different approaches to solve this problem.
+Compare the approaches and select the most robust one.
+Explain why this approach is best.
+```
+
+## Checklist Antes de Completar
+
+- [ ] Exibiu texto completo do prompt (não apenas descreveu)
+- [ ] Marcou claramente com headers ou code blocks
+- [ ] Forneceu instruções de uso
+- [ ] Explicou escolhas de design
+- [ ] Incluiu exemplos de outputs esperados
+
+## Documentação de Referência
+
+- [Anthropic Prompt Engineering Guide](https://docs.anthropic.com/claude/docs/prompt-engineering)
+- [OpenAI Prompt Engineering](https://platform.openai.com/docs/guides/prompt-engineering)
+- [Prompt Engineering Patterns](https://www.promptingguide.ai/)
+
+## Anti-Patterns a Evitar
+
+1. **Prompts vagos**: "Faça algo bom" → Especifique critérios claros
+2. **Sem formato de output**: Sempre definir estrutura esperada
+3. **Instruções contraditórias**: Revisar consistência antes de usar
+4. **Overloading**: Muitas instruções = confusão. Priorize as essenciais
+5. **Falta de exemplos**: Few-shot geralmente supera zero-shot