@grimoire-cc/cli 0.13.3 → 0.14.0

package/packs/dev-pack/skills/grimoire.tdd-specialist/SKILL.md

@@ -1,248 +0,0 @@
----
-name: grimoire.tdd-specialist
-description: "Language-agnostic TDD and unit testing specialist. Use when writing unit tests, adding test coverage, doing test-driven development, or setting up test infrastructure in ANY language. Auto-detects project language and test framework. Supports pytest, jest, vitest, mocha, junit, go test, cargo test, xunit, and more. Triggers: tdd, test-driven, unit test, write tests, test coverage, red-green-refactor."
-version: 1.0.0
----
-
-# TDD Specialist
-
-Language-agnostic test-driven development and unit testing guidance. Works with any language — detects the project's test stack automatically and applies universal TDD principles.
-
-## Context
-
-Test-driven development produces cleaner designs, fewer bugs, and enables confident refactoring. AI-assisted TDD works best with a structured workflow: humans define goals and approve test plans, AI executes the implementation. This skill provides the knowledge base for that workflow.
-
-## Language & Framework Detection
-
-### Step 1: Detect Language
-
-Check for project manifest files to determine the primary language:
-
-| File | Language |
-|------|----------|
-| `package.json` | JavaScript / TypeScript |
-| `tsconfig.json` | TypeScript |
-| `pyproject.toml`, `setup.py`, `setup.cfg` | Python |
-| `go.mod` | Go |
-| `Cargo.toml` | Rust |
-| `*.csproj`, `*.sln` | C# / .NET |
-| `pom.xml`, `build.gradle`, `build.gradle.kts` | Java / Kotlin |
-| `Gemfile` | Ruby |
-| `mix.exs` | Elixir |
-| `Package.swift` | Swift |
-
-### Step 2: Detect Test Framework
-
-**Always check existing test files first** — match whatever the project already uses.
-
-If no existing tests, infer from config:
-
-- **JavaScript/TypeScript**: Check `package.json` devDependencies for `vitest`, `jest`, `mocha`. Default: Vitest for Vite projects, Jest otherwise.
-- **Python**: Check for `pytest` in dependencies or `[tool.pytest]` in `pyproject.toml`. Default: pytest.
-- **Go**: Built-in `testing` package. Check for `testify` in `go.mod`.
-- **Rust**: Built-in `#[test]`. Check for `mockall` in `Cargo.toml`.
-- **C#/.NET**: Check `.csproj` for xUnit/NUnit/MSTest references. **If `grimoire.dotnet-unit-testing` skill is available, defer to it.**
-- **Java/Kotlin**: Check for JUnit 5 (`junit-jupiter`), Mockito in build files. Default: JUnit 5 + Mockito.
-- **Ruby**: Check for `rspec` or `minitest` in Gemfile. Default: RSpec.
-
-### Step 3: Detect Conventions
-
-Read 2-3 existing test files to learn:
-- File naming convention (e.g., `test_*.py`, `*.test.ts`, `*_test.go`)
-- Directory structure (e.g., `tests/`, `__tests__/`, co-located)
-- Assertion style and helper patterns
-- Mocking approach
-
-## Workflow
-
-### Step 1: Analyze
-
-- Read the source code under test
-- Detect language and test framework (steps above)
-- Identify dependencies that need mocking/stubbing
-- Check for existing test patterns in the project
-- Understand the expected behavior and edge cases
-
-### Step 2: Plan (REQUIRES USER APPROVAL)
-
-Present test cases as **method/function names only**, grouped by category. Do NOT include test bodies.
-
-**Format:**
-
-```plain
-## Test Plan for [Module/Class.Method]
-
-**Language:** [detected] | **Framework:** [detected] | **File:** [proposed test file path]
-
-### Success Scenarios
-- test_process_order_with_valid_input_returns_success
-- test_process_order_with_discount_applies_correctly
-
-### Validation Failures
-- test_process_order_with_null_input_raises_value_error
-- test_process_order_with_empty_items_raises_validation_error
-
-### Error Handling
-- test_process_order_when_repository_fails_raises_service_error
-
-### Edge Cases
-- test_process_order_with_maximum_items_succeeds
-
-Do you approve this test plan? I will proceed only after your confirmation.
-```
-
-**STOP and WAIT for user approval before proceeding.**
-
-### Step 3: Write (ONLY after approval)
-
-Implement tests following:
-- Detected framework conventions
-- AAA (Arrange-Act-Assert) or Given-When-Then pattern
-- Language-idiomatic naming and style
-- Proper mocking/stubbing at boundaries
-
-### Step 4: Explain
-
-- Present the complete test file
-- Explain what each test validates
-- Highlight assumptions made
-- Suggest additional scenarios if relevant
-
-## Universal Testing Principles
-
-### Arrange-Act-Assert (AAA)
-
-Structure every test with clearly separated phases. Use comments for clarity:
-
-```python
-# Python / pytest
-def test_calculate_total_with_discount_applies_percentage():
-    # Arrange
-    cart = Cart(items=[Item(price=100), Item(price=50)])
-    discount = PercentageDiscount(10)
-
-    # Act
-    total = cart.calculate_total(discount)
-
-    # Assert
-    assert total == 135.0
-```
-
-```typescript
-// TypeScript / Vitest
-test('calculateTotal with discount applies percentage', () => {
-  // Arrange
-  const cart = new Cart([{ price: 100 }, { price: 50 }]);
-  const discount = new PercentageDiscount(10);
-
-  // Act
-  const total = cart.calculateTotal(discount);
-
-  // Assert
-  expect(total).toBe(135.0);
-});
-```
-
-```go
-// Go / testing
-func TestCalculateTotal_WithDiscount_AppliesPercentage(t *testing.T) {
-    // Arrange
-    cart := NewCart([]Item{{Price: 100}, {Price: 50}})
-    discount := NewPercentageDiscount(10)
-
-    // Act
-    total := cart.CalculateTotal(discount)
-
-    // Assert
-    assert.Equal(t, 135.0, total)
-}
-```
-
-### Test Naming
-
-Use the language-idiomatic convention:
-
-| Language | Convention | Example |
-|----------|-----------|---------|
-| Python | `test_method_scenario_expected` | `test_get_user_with_invalid_id_raises_not_found` |
-| JS/TS | descriptive string | `'getUser with invalid id throws NotFound'` |
-| Go | `TestMethod_Scenario_Expected` | `TestGetUser_WithInvalidId_ReturnsNotFound` |
-| Rust | `test_method_scenario_expected` | `test_get_user_with_invalid_id_returns_not_found` |
-| Java/C# | `MethodName_Scenario_ExpectedBehavior` | `GetUser_WithInvalidId_ThrowsNotFoundException` |
-| Ruby | descriptive string (RSpec) | `'raises NotFound for invalid id'` |
-
-### Test Isolation
-
-- Each test must be independent — no shared mutable state
-- Use setup/teardown (beforeEach, setUp, constructor) for fresh fixtures
-- Tests must pass in any order and in parallel
-- Never depend on external services, file system, or network in unit tests
-
-### Mocking Boundaries
-
-- Mock/stub at system boundaries only (databases, APIs, file system, clock)
-- Do NOT mock the class under test
-- Do NOT mock value objects or simple data structures
-- Prefer fakes/stubs over mocks when possible — verify state, not interactions
-- Use dependency injection to make code testable
-
-### One Assertion Focus
-
-Each test should verify ONE logical concept. Multiple `assert` calls are fine if they verify aspects of the same behavior:
-
-```python
-# Good — one concept (successful creation), multiple assertions
-def test_create_user_with_valid_data_returns_user():
-    user = create_user(name="Alice", email="alice@example.com")
-    assert user.name == "Alice"
-    assert user.email == "alice@example.com"
-    assert user.id is not None
-
-# Bad — testing two unrelated behaviors in one test
-def test_user_creation_and_deletion():
-    user = create_user(name="Alice")
-    assert user.id is not None
-    delete_user(user.id)
-    assert get_user(user.id) is None  # This is a separate test
-```
-
-### Test Behavior, Not Implementation
-
-Tests should verify WHAT the code does, not HOW it does it:
-
-```typescript
-// Good — tests the result
-expect(sort([3, 1, 2])).toEqual([1, 2, 3]);
-
-// Bad — tests that a specific algorithm was used
-expect(quickSort).toHaveBeenCalledWith([3, 1, 2]);
-```
-
-## Constraints
-
-### ALWAYS
-
-- ALWAYS detect language and framework before writing tests
-- ALWAYS check for existing test files and match their conventions
-- ALWAYS present test plan as method names ONLY before writing
-- ALWAYS ask for explicit approval: "Do you approve this test plan?"
-- ALWAYS use AAA pattern with section comments
-- ALWAYS use language-idiomatic naming conventions
-- ALWAYS isolate tests — no shared mutable state between tests
-
-### NEVER
-
-- NEVER write test implementations until user explicitly approves the plan
-- NEVER create production code — only test code
-- NEVER mock the class/module under test
-- NEVER write tests that depend on execution order
-- NEVER use real external services (databases, APIs) in unit tests
-- NEVER ignore existing project test conventions
-
-## Reference Materials
-
-For detailed guidance on specific topics:
-
-- **[Language Frameworks](reference/language-frameworks.md)** — Framework-specific patterns, assertions, and setup for each language
-- **[Anti-Patterns](reference/anti-patterns.md)** — Common testing mistakes and how to fix them
-- **[TDD Workflow Patterns](reference/tdd-workflow-patterns.md)** — Red-Green-Refactor, Transformation Priority Premise, when to use TDD

package/packs/dev-pack/skills/grimoire.tdd-specialist/reference/language-frameworks.md

@@ -1,388 +0,0 @@
-# Language & Framework Reference
-
-Quick-reference for each language's test ecosystem. Use this to apply framework-specific patterns after detecting the project's language.
-
-## Table of Contents
-
-- [JavaScript / TypeScript](#javascript--typescript)
-- [Python](#python)
-- [Go](#go)
-- [Rust](#rust)
-- [Java / Kotlin](#java--kotlin)
-- [C# / .NET](#c--net)
-- [Ruby](#ruby)
-
-## JavaScript / TypeScript
-
-### Frameworks
-
-| Framework | When to Use | Key Feature |
-|-----------|-------------|-------------|
-| **Vitest** | Vite projects, new TS projects | Fast, ESM-native, Jest-compatible API |
-| **Jest** | React (CRA), existing Jest projects | Mature ecosystem, wide adoption |
-| **Mocha + Chai** | Legacy projects, custom setups | Flexible, pluggable |
-| **Node test runner** | Node.js 20+, minimal deps | Built-in, zero dependencies |
-
-### Vitest / Jest Patterns
-
-```typescript
-import { describe, test, expect, vi, beforeEach } from 'vitest';
-
-describe('OrderService', () => {
-  let mockRepo: MockedObject<OrderRepository>;
-  let service: OrderService;
-
-  beforeEach(() => {
-    mockRepo = { save: vi.fn(), findById: vi.fn() };
-    service = new OrderService(mockRepo);
-  });
-
-  test('processOrder with valid order saves and returns id', async () => {
-    // Arrange
-    const order = createValidOrder();
-    mockRepo.save.mockResolvedValue({ id: '123' });
-
-    // Act
-    const result = await service.processOrder(order);
-
-    // Assert
-    expect(result.id).toBe('123');
-    expect(mockRepo.save).toHaveBeenCalledWith(order);
-  });
-
-  test('processOrder with invalid order throws ValidationError', async () => {
-    // Arrange
-    const order = createInvalidOrder();
-
-    // Act & Assert
-    await expect(service.processOrder(order)).rejects.toThrow(ValidationError);
-  });
-});
-```
-
-### File Conventions
-
-- `*.test.ts` / `*.spec.ts` (co-located or in `__tests__/`)
-- `vitest.config.ts` or `jest.config.ts` for configuration
-
-## Python
-
-### Frameworks
-
-| Framework | When to Use | Key Feature |
-|-----------|-------------|-------------|
-| **pytest** | Default choice, most projects | Fixtures, parametrize, plugins |
-| **unittest** | stdlib only, legacy projects | Built-in, class-based |
-
-### pytest Patterns
-
-```python
-import pytest
-from unittest.mock import Mock, AsyncMock, patch
-
-@pytest.fixture
-def mock_repo():
-    repo = Mock(spec=OrderRepository)
-    repo.save = AsyncMock(return_value=Order(id="123"))
-    return repo
-
-@pytest.fixture
-def service(mock_repo):
-    return OrderService(repository=mock_repo)
-
-async def test_process_order_with_valid_order_returns_id(service, mock_repo):
-    # Arrange
-    order = create_valid_order()
-
-    # Act
-    result = await service.process_order(order)
-
-    # Assert
-    assert result.id == "123"
-    mock_repo.save.assert_called_once_with(order)
-
-async def test_process_order_with_invalid_order_raises_validation_error(service):
-    # Arrange
-    order = create_invalid_order()
-
-    # Act & Assert
-    with pytest.raises(ValidationError, match="items cannot be empty"):
-        await service.process_order(order)
-
-@pytest.mark.parametrize("discount,expected", [
-    (0, 100.0),
-    (10, 90.0),
-    (50, 50.0),
-])
-def test_apply_discount_calculates_correctly(discount, expected):
-    assert apply_discount(100.0, discount) == expected
-```
-
-### File Conventions
-
-- `test_*.py` or `*_test.py` in `tests/` directory
-- `conftest.py` for shared fixtures
-- `pytest.ini` or `[tool.pytest.ini_options]` in `pyproject.toml`
-
-## Go
-
-### Frameworks
-
-| Framework | When to Use | Key Feature |
-|-----------|-------------|-------------|
-| **testing** (stdlib) | Always available | Built-in, no dependencies |
-| **testify** | Assertions + mocking | `assert`, `require`, `mock` packages |
-| **gomock** | Interface mocking | Code generation, strict expectations |
-
-### Go Patterns
-
-```go
-func TestProcessOrder_WithValidOrder_ReturnsID(t *testing.T) {
-    // Arrange
-    repo := new(MockOrderRepository)
-    repo.On("Save", mock.Anything).Return(&Order{ID: "123"}, nil)
-    service := NewOrderService(repo)
-
-    // Act
-    result, err := service.ProcessOrder(context.Background(), validOrder)
-
-    // Assert
-    require.NoError(t, err)
-    assert.Equal(t, "123", result.ID)
-    repo.AssertExpectations(t)
-}
-
-func TestProcessOrder_WithInvalidOrder_ReturnsError(t *testing.T) {
-    // Arrange
-    service := NewOrderService(nil)
-
-    // Act
-    _, err := service.ProcessOrder(context.Background(), invalidOrder)
-
-    // Assert
-    assert.ErrorIs(t, err, ErrValidation)
-}
-
-// Table-driven tests (Go idiom)
-func TestApplyDiscount(t *testing.T) {
-    tests := []struct {
-        name     string
-        price    float64
-        discount int
-        expected float64
-    }{
-        {"no discount", 100.0, 0, 100.0},
-        {"10 percent", 100.0, 10, 90.0},
-        {"50 percent", 100.0, 50, 50.0},
-    }
-    for _, tt := range tests {
-        t.Run(tt.name, func(t *testing.T) {
-            result := ApplyDiscount(tt.price, tt.discount)
-            assert.Equal(t, tt.expected, result)
-        })
-    }
-}
-```
-
-### File Conventions
-
-- `*_test.go` in the same package (or `_test` package for black-box)
-- `go test ./...` to run all tests
-- `testdata/` for test fixtures
-
-## Rust
-
-### Patterns
-
-```rust
-#[cfg(test)]
-mod tests {
-    use super::*;
-    use mockall::predicate::*;
-
-    #[test]
-    fn process_order_with_valid_order_returns_id() {
-        // Arrange
-        let mut mock_repo = MockOrderRepository::new();
-        mock_repo.expect_save()
-            .returning(|_| Ok(Order { id: "123".into() }));
-        let service = OrderService::new(Box::new(mock_repo));
-
-        // Act
-        let result = service.process_order(&valid_order());
-
-        // Assert
-        assert_eq!(result.unwrap().id, "123");
-    }
-
-    #[test]
-    fn process_order_with_invalid_order_returns_error() {
-        // Arrange
-        let service = OrderService::new(Box::new(MockOrderRepository::new()));
-
-        // Act
-        let result = service.process_order(&invalid_order());
-
-        // Assert
-        assert!(matches!(result, Err(ServiceError::Validation(_))));
-    }
-}
-```
-
-### File Conventions
-
-- Tests in `#[cfg(test)] mod tests` at bottom of source file (unit tests)
-- Integration tests in `tests/` directory
-- `cargo test` to run all
-
-## Java / Kotlin
-
-### Frameworks
-
-| Framework | When to Use | Key Feature |
-|-----------|-------------|-------------|
-| **JUnit 5** | Default choice | Modern, extensible, parameterized |
-| **Mockito** | Mocking | Intuitive API, wide adoption |
-| **AssertJ** | Fluent assertions | Readable, discoverable API |
-
-### JUnit 5 + Mockito Patterns
-
-```java
-@ExtendWith(MockitoExtension.class)
-class OrderServiceTest {
-    @Mock OrderRepository repository;
-    @InjectMocks OrderService service;
-
-    @Test
-    void processOrder_withValidOrder_returnsId() {
-        // Arrange
-        var order = createValidOrder();
-        when(repository.save(any())).thenReturn(new Order("123"));
-
-        // Act
-        var result = service.processOrder(order);
-
-        // Assert
-        assertThat(result.getId()).isEqualTo("123");
-        verify(repository).save(order);
-    }
-
-    @Test
-    void processOrder_withInvalidOrder_throwsValidationException() {
-        // Arrange
-        var order = createInvalidOrder();
-
-        // Act & Assert
-        assertThatThrownBy(() -> service.processOrder(order))
-            .isInstanceOf(ValidationException.class)
-            .hasMessageContaining("items cannot be empty");
-    }
-
-    @ParameterizedTest
-    @CsvSource({"0, 100.0", "10, 90.0", "50, 50.0"})
-    void applyDiscount_calculatesCorrectly(int discount, double expected) {
-        assertThat(applyDiscount(100.0, discount)).isEqualTo(expected);
-    }
-}
-```
-
-### File Conventions
-
-- `src/test/java/` mirroring `src/main/java/` structure
-- `*Test.java` suffix
-- `mvn test` or `gradle test`
-
-## C# / .NET
-
-**If the `grimoire.dotnet-unit-testing` skill is available, defer to it for full C#/.NET guidance.** It provides comprehensive xUnit, TUnit, Moq, and NSubstitute patterns.
-
-### Quick Reference (when dotnet skill is unavailable)
-
-| Framework | When to Use |
-|-----------|-------------|
-| **xUnit** | Default, most universal |
-| **NUnit** | If project already uses it |
-| **MSTest** | Microsoft-first shops |
-
-```csharp
-public class OrderServiceTests
-{
-    private readonly Mock<IOrderRepository> _mockRepo;
-    private readonly OrderService _sut;
-
-    public OrderServiceTests()
-    {
-        _mockRepo = new Mock<IOrderRepository>();
-        _sut = new OrderService(_mockRepo.Object);
-    }
-
-    [Fact]
-    public async Task ProcessOrder_WithValidOrder_ReturnsId()
-    {
-        // Arrange
-        var order = CreateValidOrder();
-        _mockRepo.Setup(r => r.SaveAsync(It.IsAny<Order>()))
-            .ReturnsAsync(new Order { Id = "123" });
-
-        // Act
-        var result = await _sut.ProcessOrderAsync(order);
-
-        // Assert
-        Assert.Equal("123", result.Id);
-    }
-}
-```
-
-### File Conventions
-
-- `Tests/` or `*.Tests/` project mirroring source structure
-- `*Tests.cs` suffix
-- `dotnet test` to run
-
-## Ruby
-
-### Frameworks
-
-| Framework | When to Use |
-|-----------|-------------|
-| **RSpec** | Default, most Ruby projects |
-| **Minitest** | stdlib, Rails default |
-
-### RSpec Patterns
-
-```ruby
-RSpec.describe OrderService do
-  let(:repository) { instance_double(OrderRepository) }
-  let(:service) { described_class.new(repository: repository) }
-
-  describe '#process_order' do
-    context 'with a valid order' do
-      it 'returns the order id' do
-        # Arrange
-        order = build(:order, :valid)
-        allow(repository).to receive(:save).and_return(Order.new(id: '123'))
-
-        # Act
-        result = service.process_order(order)
-
-        # Assert
-        expect(result.id).to eq('123')
-        expect(repository).to have_received(:save).with(order)
-      end
-    end
-
-    context 'with an invalid order' do
-      it 'raises ValidationError' do
-        order = build(:order, :invalid)
-        expect { service.process_order(order) }.to raise_error(ValidationError)
-      end
-    end
-  end
-end
-```
-
-### File Conventions
-
-- `spec/` directory mirroring `lib/` or `app/` structure
-- `*_spec.rb` suffix
-- `bundle exec rspec` to run