@arimakouyou/spec-workflow-mcp 2.2.7

package/.claude-plugin/skills/spec-impl-review/SKILL.md

@@ -0,0 +1,115 @@
+---
+name: spec-impl-review
+description: "TDD REFACTOR phase for spec-implement workflow. Reviews and refactors both test and production code for quality. Designed to run as a subagent — spawn it with the Agent tool. Triggers on: subagent calls from spec-implement orchestrator only."
+---
+
+# Code Reviewer — REFACTOR Phase (Subagent)
+
+This skill is designed to run as a **subagent** via the Agent tool. It reviews and refactors both test and production code, following TDD's REFACTOR phase.
+
+## How the Calling Agent Should Invoke This
+
+```javascript
+Agent({
+  subagent_type: "general-purpose",
+  description: "REFACTOR: Review and clean up",
+  prompt: `You are a TDD refactoring reviewer. Review and refactor the code written in the RED-GREEN phases.
+
+    Project path: {project-path}
+    Spec name: {spec-name}
+    Task ID: {task-id}
+    Task prompt: {task _Prompt content}
+    Test files: {test-file-paths}
+    Implementation files: {implementation-file-paths}
+    Success criteria: {success criteria from _Prompt}
+
+    Follow the /spec-impl-review skill instructions.
+
+    Return the list of changes made and quality assessment.`
+})
+```
+
+## REFACTOR Phase Rules
+
+1. **Do NOT change test expectations** — assertions and expected values must stay the same
+2. **Do NOT add new features** — refactoring changes structure, not behavior
+3. **Tests must still pass after every change** — refactor in small, safe steps
+4. **Improve clarity and maintainability** — the goal is clean, readable code
+
+## Execution Steps
+
+### 1. Read All Code
+
+Read both the test files and implementation files to understand:
+- The full picture of what was built
+- How tests and production code relate
+- Current code quality and structure
+
+### 2. Check Success Criteria
+
+Verify against the task's `_Prompt` Success criteria:
+- Are all success criteria addressed by the implementation?
+- Are there any gaps between what was asked and what was built?
+- Flag any unmet criteria (but do NOT add untested features to fix them)
+
+### 3. Apply Design Principles
+
+Reference `/tdd-skills` and `tdd-skills/references/tdd-and-design.md` for design guidance:
+
+**Production Code Refactoring:**
+- **Duplication**: Extract shared logic into helper functions
+- **Naming**: Improve variable, function, and class names for clarity
+- **Responsibility**: Split functions/classes that do too much (SRP)
+- **Error handling**: Ensure consistent and appropriate error handling
+- **Type safety**: Tighten types, remove `any` where possible
+- **Code organization**: Improve imports, ordering, grouping
+
+**Test Code Refactoring:**
+- **Readability**: Improve test names, add describe blocks for grouping
+- **DRY setup**: Extract repeated setup into `beforeEach` / fixtures
+- **Assertion clarity**: Use more specific matchers where available
+- **Test independence**: Ensure no shared mutable state between tests
+
+### 4. Perform Refactoring
+
+Make changes in small, incremental steps. For each change:
+- It should be a clear improvement in code quality
+- It must not change observable behavior
+- It must not change test expectations or add new assertions
+
+### 5. Assess Quality
+
+Evaluate the final code on:
+- **Correctness**: Does it meet the task requirements?
+- **Readability**: Is the code easy to understand?
+- **Maintainability**: Is it easy to modify in the future?
+- **Test coverage**: Do tests adequately cover the behavior?
+- **Consistency**: Does it follow existing codebase patterns?
+
+## Output Format
+
+Return to the calling agent:
+
+```
+## REFACTOR Phase Complete
+
+### Refactoring Changes
+- {file}: {what was changed and why}
+- ...
+
+### Quality Assessment
+- Correctness: {PASS/CONCERN} — {details}
+- Readability: {GOOD/FAIR/POOR} — {details}
+- Maintainability: {GOOD/FAIR/POOR} — {details}
+- Test coverage: {GOOD/FAIR/POOR} — {details}
+- Consistency: {GOOD/FAIR/POOR} — {details}
+
+### Success Criteria Check
+- [ ] {criterion 1}: {met/unmet}
+- [ ] {criterion 2}: {met/unmet}
+
+### Concerns (if any)
+- {any issues that need attention}
+
+### Result: {CLEAN / NEEDS_ATTENTION}
+```

package/.claude-plugin/skills/spec-impl-test-run/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: spec-impl-test-run
+description: "TDD test runner for spec-implement workflow. Executes tests and validates results against expected mode (red=all fail, green=all pass). Designed to run as a subagent — spawn it with the Agent tool. Triggers on: subagent calls from spec-implement orchestrator only."
+---
+
+# Test Runner (Subagent)
+
+This skill is designed to run as a **subagent** via the Agent tool. It executes specified test files and validates results against expected outcomes.
+
+## How the Calling Agent Should Invoke This
+
+```javascript
+Agent({
+  subagent_type: "general-purpose",
+  description: "Run tests ({mode} mode)",
+  prompt: `You are a TDD test runner. Execute the specified tests and validate the results.
+
+    Project path: {project-path}
+    Test files: {test-file-paths}
+    Expected mode: {red|green}
+
+    Follow the /spec-impl-test-run skill instructions.
+
+    Return a structured result summary.`
+})
+```
+
+## Parameters
+
+- **Project path**: Root directory of the project
+- **Test files**: Comma-separated list of test file paths to execute
+- **Expected mode**: `red` (all tests should fail) or `green` (all tests should pass)
+
+## Execution Steps
+
+### 1. Detect Test Runner
+
+Detect the project's test runner by checking (in order):
+
+1. `package.json` scripts — look for `test`, `vitest`, `jest` scripts
+2. Config files: `vitest.config.*`, `jest.config.*`, `pytest.ini`, `pyproject.toml`
+3. Dependencies in `package.json`: `vitest`, `jest`, `mocha`, `pytest`
+
+### 2. Run Tests
+
+Execute **only the specified test files**, not the full suite:
+
+```bash
+# Examples by runner:
+npx vitest run {test-files} --reporter=verbose
+npx jest {test-files} --verbose
+python -m pytest {test-files} -v
+```
+
+Use the `--reporter=verbose` or equivalent flag to get per-test pass/fail details.
+
+### 3. Parse Results
+
+From the test output, extract:
+- **total**: Number of tests executed
+- **passed**: Number of tests that passed
+- **failed**: Number of tests that failed
+- **errors**: List of error messages for failed tests (test name + error)
+
+### 4. Validate Against Mode
+
+**Red mode** (`red`):
+- EXPECTED: All tests fail (passed = 0)
+- **Compile error**: If the test runner fails to build/compile (e.g. unresolved import of not-yet-implemented module), treat this as a hard failure — return `{ status: "fail", message: "Compile error: {error summary}", ... }`. The calling agent must fix the compile error before RED can be validated.
+- If any test passes, report it as a problem — this means either:
+  - The test is not actually testing new behavior
+  - There's already an implementation that satisfies the test
+- Return: `{ status: "pass", ... }` if all failed (and build succeeded), `{ status: "fail", message: "N tests unexpectedly passed", ... }` otherwise
+
+**Green mode** (`green`):
+- EXPECTED: All tests pass (failed = 0)
+- If any test fails, report each failure with its error message
+- Return: `{ status: "pass", ... }` if all passed, `{ status: "fail", message: "N tests failed", errors: [...] }` otherwise
+
+## Output Format
+
+Return to the calling agent:
+
+```
+## Test Run Result
+
+- **Mode**: {red|green}
+- **Status**: {pass|fail}
+- **Total**: {N} tests
+- **Passed**: {N}
+- **Failed**: {N}
+
+### Errors (if any)
+- {test name}: {error message}
+
+### Verdict
+{Description of whether the result matches expectations}
+```

package/.claude-plugin/skills/spec-impl-test-write/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: spec-impl-test-write
+description: "TDD RED phase for spec-implement workflow. Writes failing tests before any production code. Designed to run as a subagent — spawn it with the Agent tool. Triggers on: subagent calls from spec-implement orchestrator only."
+---
+
+# Test Writer — RED Phase (Subagent)
+
+This skill is designed to run as a **subagent** via the Agent tool. It writes failing tests based on task specifications, following TDD's RED phase.
+
+## How the Calling Agent Should Invoke This
+
+```javascript
+Agent({
+  subagent_type: "general-purpose",
+  description: "RED: Write failing tests",
+  prompt: `You are a TDD test writer. Write failing tests for the task described below.
+
+    Project path: {project-path}
+    Spec name: {spec-name}
+    Task ID: {task-id}
+    Task prompt: {task _Prompt content}
+    Test focus areas: {_TestFocus content from task, if available}
+    Design doc path: {project-path}/.spec-workflow/specs/{spec-name}/design.md
+
+    Follow the /spec-impl-test-write skill instructions.
+
+    Return the list of test files created and test names.`
+})
+```
+
+## RED Phase Rules
+
+1. **Write tests FIRST** — before any production code exists
+2. **Tests MUST fail** — imports will reference modules that don't exist yet, and that's correct
+3. **Do NOT write production code** — not even stubs or empty implementations
+4. **Do NOT modify existing production code**
+
+## Execution Steps
+
+### 1. Understand What to Test
+
+- Read the task's `_Prompt` field (provided in the prompt) for Role, Task, Restrictions, Success criteria
+- If a `_TestFocus` field is provided (via the "Test focus areas" parameter), it is structured in 4 categories: **Happy Path / Boundary Values / Error Handling / Edge Cases**. Write tests covering **all 4 categories** as specified — these categories are aligned with the unit-test-engineer's quality verification criteria to minimize rework
+- Read the design document to understand interfaces, data models, and expected behavior
+- Identify the public API surface: functions, methods, endpoints, components
+
+### 2. Discover Existing Test Patterns
+
+Before writing tests, understand the project's testing conventions:
+
+- Search for existing test files to determine:
+  - Test framework (vitest, jest, pytest, etc.)
+  - File naming convention (`*.test.ts`, `*.spec.ts`, `*_test.py`, etc.)
+  - Directory structure (`__tests__/`, `tests/`, co-located, etc.)
+  - Import patterns and test utilities
+  - Assertion style (`expect()`, `assert`, etc.)
+
+```bash
+# Find existing test files
+find . -name "*.test.*" -o -name "*.spec.*" -o -name "*_test.*" | head -20
+```
+
+### 3. Write Tests
+
+Follow `/tdd-skills` principles:
+
+**Test Structure** — Use Given-When-Then:
+```
+// Given — set up preconditions
+// When  — perform the action
+// Then  — verify the outcome
+```
+
+**Test Naming** — Use descriptive names:
+- `test_{action}_when_{condition}` (e.g., `test_returns_empty_when_no_users`)
+- `test_{action}_raises_{error}_when_{condition}` (e.g., `test_raises_not_found_when_invalid_id`)
+
+**What to Test:**
+- Happy path: Normal expected behavior from Success criteria
+- Edge cases: Empty inputs, boundary values, nulls
+- Error cases: Invalid inputs, missing data, error scenarios from design doc
+- Refer to `/tdd-skills` references for boundary value analysis and test design
+
+**Test Organization:**
+- One test file per component/module being tested
+- Group related tests with `describe`/`context` blocks
+- Keep tests independent (F.I.R.S.T principles)
+
+### 4. Verify Test Imports Reference Non-Existent Code
+
+The tests should import from modules that will be created during the GREEN phase. For example:
+
+```typescript
+// This import WILL fail — the module doesn't exist yet. That's correct.
+import { createUser } from '../services/user-service';
+```
+
+This is the expected state in the RED phase.
+
+## Output Format
+
+Return to the calling agent:
+
+```
+## RED Phase Complete
+
+### Test Files Created
+- {path/to/test-file-1}
+- {path/to/test-file-2}
+
+### Tests Written
+- {describe block}: {test name 1}
+- {describe block}: {test name 2}
+- ...
+
+### Test Runner Command
+{command to run these specific test files}
+
+### Notes
+- {any assumptions or decisions made}
+```