@arimakouyou/spec-workflow-mcp 2.2.7

package/.claude-plugin/skills/tdd-skills/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: tdd-skills
+description: "TDD principles and practices based on t-wada's teachings. Covers Red-Green-Refactor cycle, test structure, test doubles, boundary value testing, and design through TDD. Use when implementing tests, designing test strategies, or practicing TDD — regardless of language or framework."
+---
+
+**TDD Skills Active**
+
+# TDD Skills
+
+TDD principles and practices based on t-wada's (Takuto Wada) teachings.
+
+## Core Principle
+
+**TDD is a programming technique, not a testing technique.**
+
+> "TDD transforms anxiety into boredom." — t-wada
+
+## Red-Green-Refactor Cycle
+
+```
+RED:      Write a failing test
+  ↓
+GREEN:    Make it pass with minimal code
+  ↓
+REFACTOR: Clean up without changing behavior
+  ↓
+RED:      Next test...
+```
+
+### Green Strategies
+
+1. **Fake It**: Return a constant first (safest)
+2. **Triangulation**: Generalize from multiple test cases
+3. **Obvious Implementation**: Implement directly when the solution is clear
+
+Details: [references/green-strategies.md](references/green-strategies.md)
+
+## Test Structure (Given-When-Then)
+
+```
+// Given — set up preconditions
+// When  — perform the action
+// Then  — verify the outcome
+```
+
+## Test Naming
+
+| Pattern | Example |
+|---------|---------|
+| `test_{action}_when_{condition}` | `test_returns_empty_when_no_users` |
+| `test_{action}_raises_{error}_when_{condition}` | `test_raises_not_found_when_invalid_id` |
+
+## Test Types
+
+| Type | Target | Mocking | Speed |
+|------|--------|---------|-------|
+| Unit | Domain, Use Case | All deps | Fast |
+| Integration | API, Repository | DB connection | Slow |
+
+## Test Doubles
+
+| Type | Purpose |
+|------|---------|
+| Stub | Return fixed values |
+| Mock | Verify interactions |
+| Fake | Lightweight implementation (e.g., in-memory store) |
+
+Details: [references/test-doubles.md](references/test-doubles.md)
+
+## F.I.R.S.T Principles
+
+- **F**ast: Tests run quickly
+- **I**ndependent: No test depends on another
+- **R**epeatable: Same result every run
+- **S**elf-Validating: Pass/fail without manual inspection
+- **T**imely: Written before production code
+
+## Troubleshooting
+
+| Problem | Solution |
+|---------|----------|
+| Can't verify mock calls | Use spec-based mocks (e.g., `Mock(spec=Port)` in Python, typed mocks in TS) |
+| Fixture loading errors | Ensure test config files are in the correct directory |
+| Async test failures | Use the appropriate async test decorator/runner for your framework |
+
+## References
+
+| Priority | Document |
+|----------|----------|
+| High | [green-strategies.md](references/green-strategies.md) — Green strategies |
+| High | [test-design.md](references/test-design.md) — Boundary value analysis |
+| Mid | [test-patterns.md](references/test-patterns.md) — Test patterns |
+| Mid | [test-doubles.md](references/test-doubles.md) — Test doubles |
+| Low | [advanced-techniques.md](references/advanced-techniques.md) — Advanced techniques |
+| Low | [tdd-and-design.md](references/tdd-and-design.md) — TDD and design |

package/.claude-plugin/skills/tdd-skills/references/advanced-techniques.md

@@ -0,0 +1,49 @@
+# Advanced TDD Techniques
+
+## Dealing with Uncertain Specifications
+
+When specs are vague, start with concrete examples rather than abstract tests. Write a test for the simplest specific case, then expand.
+
+**Bad**: `test_calculate_price` (too abstract, unclear what to assert)
+**Good**: `test_calculate_price_single_item_no_discount` (concrete, actionable)
+
+## Applying TDD to Legacy Code
+
+1. Write characterization tests that capture current behavior
+2. Refactor in small steps under test protection
+3. Add new features using TDD
+
+Characterization tests don't assert "correct" behavior — they assert "current" behavior, creating a safety net for refactoring.
+
+## When Tests Get Complex
+
+Complex tests signal complex code. Respond by:
+1. Extracting test helper methods
+2. Using Builder / Factory patterns for test data
+3. Splitting the class under test (Single Responsibility)
+
+## Anti-patterns
+
+### 1. Skipping the test
+Write the test first. Always.
+
+### 2. Steps too large
+If a test requires implementing multiple things at once, break it into smaller tests.
+
+### 3. Testing trivial getters/setters
+Test behavior, not data access. If a getter just returns a field, it doesn't need a dedicated test.
+
+### 4. Testing private methods directly
+Test through the public API. If a private method is complex enough to need its own test, it likely belongs in a separate class.
+
+### 5. Test interdependence
+Each test must work in isolation. No shared mutable state between tests.
+
+## TODO List Technique
+
+Keep a running list of test cases to write. Check them off as you go. Add new ideas as they arise during implementation.
+
+Benefits:
+- Stay focused on the current test
+- Don't lose ideas
+- Visible progress

package/.claude-plugin/skills/tdd-skills/references/green-strategies.md

@@ -0,0 +1,70 @@
+# Green Strategies
+
+Three strategies to make a failing test pass as quickly as possible.
+
+## 1. Fake It
+
+**Safest approach. Return a constant to make the test pass first.**
+
+```
+// Test: empty collection should have zero total
+// Implementation: return 0  (hardcoded constant)
+```
+
+When to use:
+- Implementation path is unclear
+- Complex logic is needed
+- Building confidence in small steps
+
+## 2. Triangulation
+
+**Generalize from multiple test cases.**
+
+Process:
+1. First test → Fake It (return constant)
+2. Add second test that breaks the constant
+3. Generalize to pass both tests
+4. Add more tests if needed
+
+```
+Test 1: empty → total is 0       →  return 0
+Test 2: one item(100) → total 100  →  return sum(items)
+```
+
+When to use:
+- Unclear how to generalize
+- Want tests to drive the design
+- Need to avoid premature abstraction
+
+## 3. Obvious Implementation
+
+**Fastest but riskiest. Implement the real solution directly.**
+
+When to use:
+- Solution is trivially clear
+- Simple logic
+- Experienced with the problem domain
+
+**If the test fails after "obvious" implementation, immediately fall back to Fake It.**
+
+## Decision Flow
+
+```
+Is the implementation obvious?
+  ├─ Yes → Try Obvious Implementation
+  │         ├─ Passes → Done
+  │         └─ Fails  → Fall back to Fake It
+  └─ No  → Start with Fake It
+            ├─ One test  → Keep the fake
+            └─ Multiple tests → Triangulate to generalize
+```
+
+## Summary
+
+| Strategy | Speed | Safety | When |
+|----------|-------|--------|------|
+| Fake It | Slow | High | Default choice, when unsure |
+| Triangulation | Medium | High | Complex generalization |
+| Obvious Implementation | Fast | Low | Only when trivially clear |
+
+**When in doubt, Fake It. When experienced, go Obvious. When complex, Triangulate.**

package/.claude-plugin/skills/tdd-skills/references/tdd-and-design.md

@@ -0,0 +1,48 @@
+# TDD and Design
+
+## TDD Is Also a Design Technique
+
+Practicing TDD naturally leads to:
+
+1. **YAGNI**: Only implement what tests require
+2. **Single Responsibility**: Testable classes have clear responsibilities
+3. **Dependency Inversion**: Test doubles push you toward interface-based design
+4. **Loose Coupling**: Testable code has low coupling
+
+## Testable vs Untestable Design
+
+**Untestable** — direct dependencies on external systems (DB connections, HTTP clients, file system, clock) created inside the class.
+
+**Testable** — dependencies injected through constructor/method parameters, allowing test doubles to be substituted.
+
+## Design Benefits from TDD
+
+### 1. Clear Interfaces
+Writing tests first forces you to design a usable API from the caller's perspective.
+
+### 2. Responsibility Separation
+When a test becomes complex, the class under test has too many responsibilities. Split it.
+
+### 3. Loose Coupling
+Using test doubles naturally decouples components through interfaces/protocols.
+
+## Testability Principles
+
+### Inject external dependencies
+Don't create dependencies internally. Accept them via constructor or parameters.
+
+### Separate side effects from logic
+Pure computation in one function, I/O in another. Test the pure part directly.
+
+### Make behavior deterministic
+Inject sources of non-determinism (time, randomness, UUIDs) so tests can control them.
+
+## Design Patterns That Emerge from TDD
+
+- **Strategy**: Injected behavior → naturally testable with different strategies
+- **Repository**: Abstracted data access → swap real DB for in-memory Fake
+- **Factory**: Complex object creation → isolated and testable
+
+> "Writing good tests naturally leads to good design." — t-wada
+
+**TDD = Design-Driven Development**

package/.claude-plugin/skills/tdd-skills/references/test-design.md

@@ -0,0 +1,43 @@
+# Test Design
+
+## Boundary Value Analysis
+
+Bugs cluster around boundaries. Always test values at and around each boundary.
+
+Example — age categories (0-17: minor, 18-64: adult, 65+: senior):
+- Test 17, 18 (minor/adult boundary)
+- Test 64, 65 (adult/senior boundary)
+
+## Equivalence Partitioning
+
+Group inputs that produce the same behavior, then test one representative from each group plus all boundary values.
+
+Example — discount tiers (0-999: 0%, 1000-4999: 5%, 5000+: 10%):
+- Representative: 500, 3000, 10000
+- Boundaries: 999, 1000, 4999, 5000
+
+## Test Naming
+
+Use a consistent pattern that makes the test's purpose clear from the name:
+
+| Pattern | Example |
+|---------|---------|
+| `test_{subject}_{condition}_{expected}` | `test_total_when_cart_empty_returns_zero` |
+| `test_{action}_raises_{error}_when_{condition}` | `test_add_item_raises_error_when_negative_price` |
+
+The name should explain what went wrong when the test fails.
+
+## Error / Exception Testing
+
+Always test error paths, not just happy paths:
+- Invalid inputs
+- Boundary violations
+- Resource unavailability
+- Verify both error type and error message content
+
+## Summary
+
+- Always test boundary values
+- Use equivalence partitioning for efficiency
+- Clear, descriptive naming
+- Don't forget error cases

package/.claude-plugin/skills/tdd-skills/references/test-doubles.md

@@ -0,0 +1,53 @@
+# Test Doubles
+
+Isolate external dependencies to make tests fast and deterministic.
+
+## Five Types
+
+### 1. Dummy
+Fills a required parameter but is never actually used.
+
+### 2. Stub
+Returns fixed values. Use when you need to control what a dependency returns.
+
+Use for: DB results, API responses, config values.
+
+### 3. Spy
+Records calls for later verification. Use when you need to check that something happened (e.g., email sent, event emitted).
+
+### 4. Mock
+Sets expectations upfront and verifies interactions. Use when call verification is the point of the test.
+
+**Mock vs Spy**: Mock verifies behavior expectations. Spy records and you assert later.
+
+### 5. Fake
+A lightweight working implementation (e.g., in-memory repository). Use for complex state interactions where stubs are too simple.
+
+## Selection Guide
+
+```
+What are you testing?
+  ├─ Return value only        → Stub
+  ├─ Was it called?           → Mock
+  ├─ Call history/details     → Spy
+  ├─ Complex state transitions → Fake
+  └─ Unused parameter         → Dummy
+```
+
+| Scenario | Recommended | Reason |
+|----------|-------------|--------|
+| External API call | Stub / Mock | Fixed response, call verification |
+| Database access | Fake / Stub | Speed, state management |
+| Side effects (email, logs) | Spy / Mock | Verify it happened |
+| Random values / time | Stub | Deterministic results |
+| Complex business logic | Fake | Realistic behavior |
+
+## Anti-pattern: Over-mocking
+
+When everything is a mock, the test verifies nothing meaningful. Use real objects for the code under test; only mock external boundaries (I/O, network, time).
+
+> "Prefer Stubs over Mocks. State verification is superior to behavior verification." — Martin Fowler
+
+## Principle
+
+**Use the simplest test double that works. When in doubt, start with a Stub.**

package/.claude-plugin/skills/tdd-skills/references/test-patterns.md

@@ -0,0 +1,40 @@
+# Test Patterns
+
+## Test Fixtures
+
+Shared setup for tests. Use your framework's fixture mechanism (e.g., `@pytest.fixture`, `beforeEach`, `@BeforeEach`) to create common test data.
+
+## Test Data Builder
+
+Build complex objects fluently with sensible defaults. Only specify the fields relevant to each test.
+
+```
+builder = UserBuilder().with_name("Alice").with_role("admin").build()
+```
+
+Benefits:
+- Tests highlight what matters, hide what doesn't
+- Easy to create variations
+- Centralized default values
+
+## Parameterized Tests
+
+Run the same test logic with multiple inputs. Use your framework's parameterization support (e.g., `@pytest.mark.parametrize`, `test.each`, `@ParameterizedTest`).
+
+Best for: boundary values, equivalence classes, truth tables.
+
+## One Concept Per Test
+
+Each test should verify one logical concept. Multiple assertions are fine if they all verify the same concept.
+
+**Bad**: One test that checks creation, update, and deletion.
+**Good**: Separate tests for each operation.
+
+**Exception**: Multiple assertions verifying one concept (e.g., checking both status code and response body of a single API call) are fine in one test.
+
+## Summary
+
+- Fixtures for shared setup
+- Builder pattern for flexible test data
+- Parameterization to reduce duplication
+- One concept per test

package/.claude-plugin/skills/tdd-skills-rust/SKILL.md

@@ -0,0 +1,128 @@
+---
+name: tdd-skills-rust
+description: >
+  Rust-specific version of tdd-skills. Provides TDD principles and Rust implementation patterns based on t-wada's teachings.
+  Covers the Red-Green-Refactor cycle, test implementation using Rust testing features (#[test], mockall, rstest),
+  trait-based test double design, and boundary value test design.
+  Use when implementing tests, designing tests, or practicing TDD in Rust projects.
+---
+
+# TDD Skills (Rust)
+
+> For foundational principles, see the language-agnostic `/tdd-skills`. This skill focuses on Rust-specific implementation patterns.
+
+Provides TDD principles and practices based on the teachings of t-wada (Takuto Wada), aligned with Rust language features.
+
+## Pre-check: Know-how Reference
+
+Read relevant know-how such as testing from the Know-how INDEX under the `feedback-loop` rule.
+Incorporate checklists and counter-examples into your test design.
+
+## The Essence of TDD
+
+TDD is a "programming technique," not a "technique for writing tests."
+
+> "TDD is the art of turning anxiety into boredom." - t-wada
+
+## Red-Green-Refactor Cycle
+
+```
+Red:      Write a failing test
+  ↓
+Green:    Make it pass with minimal code
+  ↓
+Refactor: Refactor
+  ↓
+Red:      Next test...
+```
+
+### Green Strategies (3 Types)
+
+1. **Fake It**: Return a constant first (safest)
+2. **Triangulation**: Generalize from multiple tests
+3. **Obvious Implementation**: Implement directly when the solution is clear
+
+Details: [references/green-strategies.md](references/green-strategies.md)
+
+## Test Structure (Given-When-Then)
+
+```rust
+#[cfg(test)]
+mod tests {
+    use super::*;
+    use mockall::predicate::*;
+
+    #[test]
+    fn get_user_returns_entity_when_exists() {
+        // Given
+        let mut mock_repo = MockUserRepository::new();
+        mock_repo
+            .expect_find_by_id()
+            .with(eq(123))
+            .returning(|_| Ok(Some(User { id: 123, name: "Alice".into() })));
+        let query = UserQueryService::new(Box::new(mock_repo));
+
+        // When
+        let result = query.get_user_by_id(123).unwrap();
+
+        // Then
+        assert_eq!(result.id, 123);
+    }
+}
+```
+
+## Test Naming Conventions
+
+| Pattern | Example |
+|----------|-----|
+| `{action}_when_{condition}` | `returns_empty_when_no_users` |
+| `{action}_with_{input}` | `calculates_total_with_multiple_items` |
+| `fails_when_{condition}` | `fails_when_invalid_id` |
+
+In Rust, test functions do not require a `test_` prefix (identified by the `#[test]` attribute).
+However, if used by convention, apply it consistently.
+
+## Test Types
+
+| Type | Target | Test Doubles | Speed |
+|------|------|-------------|------|
+| Unit | Domain, UseCase | trait-based mock/fake | Fast |
+| Integration | API, Repository | Test DB + transaction | Slow |
+
+## Test Doubles
+
+| Type | Purpose | Rust Implementation |
+|------|------|-------------|
+| Stub | Return fixed values | trait impl or `mockall`'s `returning()` |
+| Mock | Verify calls | `mockall`'s `expect_*()` |
+| Fake | Lightweight implementation | `HashMap`-based InMemoryRepository |
+
+Details: [references/test-doubles.md](references/test-doubles.md)
+
+## F.I.R.S.T Principles
+
+- **F**ast: Fast
+- **I**ndependent: Independent
+- **R**epeatable: Repeatable
+- **S**elf-Validating: Self-validating
+- **T**imely: Write before production code
+
+## Troubleshooting
+
+| Problem | Solution |
+|------|--------|
+| Mock type mismatch | Apply `#[automock]` to the trait, inject via `Box<dyn Trait>` |
+| async tests not running | Use `#[tokio::test]` |
+| Data interference between tests | Use `test_transaction` to rollback |
+| Slow compilation | Isolate test-only code with `#[cfg(test)]` |
+
+## Detailed References
+
+| Document | Contents |
+|------------|------|
+| [green-strategies.md](references/green-strategies.md) | Green strategy details and practical examples |
+| [test-design.md](references/test-design.md) | Boundary value analysis and equivalence partitioning |
+| [test-patterns.md](references/test-patterns.md) | Fixtures and parameterized tests |
+| [test-doubles.md](references/test-doubles.md) | Types of test doubles and when to use them |
+| [tdd-and-design.md](references/tdd-and-design.md) | The effect of TDD on design |
+| [advanced-techniques.md](references/advanced-techniques.md) | Legacy code handling and anti-patterns |