@vodailoc/kilo-kit-mcp 1.1.0

package/skills/engineering/tdd-workflow/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: tdd-workflow
+description: Test-Driven Development workflow principles. RED-GREEN-REFACTOR cycle.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+---
+
+# TDD Workflow
+
+> Write tests first, code second.
+
+---
+
+## 1. The TDD Cycle
+
+```
+🔴 RED → Write failing test
+    ↓
+🟢 GREEN → Write minimal code to pass
+    ↓
+🔵 REFACTOR → Improve code quality
+    ↓
+   Repeat...
+```
+
+---
+
+## 2. The Three Laws of TDD
+
+1. Write production code only to make a failing test pass
+2. Write only enough test to demonstrate failure
+3. Write only enough code to make the test pass
+
+---
+
+## 3. RED Phase Principles
+
+### What to Write
+
+| Focus | Example |
+|-------|---------|
+| Behavior | "should add two numbers" |
+| Edge cases | "should handle empty input" |
+| Error states | "should throw for invalid data" |
+
+### RED Phase Rules
+
+- Test must fail first
+- Test name describes expected behavior
+- One assertion per test (ideally)
+
+---
+
+## 4. GREEN Phase Principles
+
+### Minimum Code
+
+| Principle | Meaning |
+|-----------|---------|
+| **YAGNI** | You Aren't Gonna Need It |
+| **Simplest thing** | Write the minimum to pass |
+| **No optimization** | Just make it work |
+
+### GREEN Phase Rules
+
+- Don't write unneeded code
+- Don't optimize yet
+- Pass the test, nothing more
+
+---
+
+## 5. REFACTOR Phase Principles
+
+### What to Improve
+
+| Area | Action |
+|------|--------|
+| Duplication | Extract common code |
+| Naming | Make intent clear |
+| Structure | Improve organization |
+| Complexity | Simplify logic |
+
+### REFACTOR Rules
+
+- All tests must stay green
+- Small incremental changes
+- Commit after each refactor
+
+---
+
+## 6. AAA Pattern
+
+Every test follows:
+
+| Step | Purpose |
+|------|---------|
+| **Arrange** | Set up test data |
+| **Act** | Execute code under test |
+| **Assert** | Verify expected outcome |
+
+---
+
+## 7. When to Use TDD
+
+| Scenario | TDD Value |
+|----------|-----------|
+| New feature | High |
+| Bug fix | High (write test first) |
+| Complex logic | High |
+| Exploratory | Low (spike, then TDD) |
+| UI layout | Low |
+
+---
+
+## 8. Test Prioritization
+
+| Priority | Test Type |
+|----------|-----------|
+| 1 | Happy path |
+| 2 | Error cases |
+| 3 | Edge cases |
+| 4 | Performance |
+
+---
+
+## 9. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Skip the RED phase | Watch test fail first |
+| Write tests after | Write tests before |
+| Over-engineer initial | Keep it simple |
+| Multiple asserts | One behavior per test |
+| Test implementation | Test behavior |
+
+---
+
+## 10. AI-Augmented TDD
+
+### Multi-Agent Pattern
+
+| Agent | Role |
+|-------|------|
+| Agent A | Write failing tests (RED) |
+| Agent B | Implement to pass (GREEN) |
+| Agent C | Optimize (REFACTOR) |
+
+---
+
+> **Remember:** The test is the specification. If you can't write a test, you don't understand the requirement.

package/skills/engineering/testing-patterns/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: testing-patterns
+description: Testing patterns and principles. Unit, integration, mocking strategies.
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash
+---
+
+# Testing Patterns
+
+> Principles for reliable test suites.
+
+---
+
+## 1. Testing Pyramid
+
+```
+        /\          E2E (Few)
+       /  \         Critical flows
+      /----\
+     /      \       Integration (Some)
+    /--------\      API, DB queries
+   /          \
+  /------------\    Unit (Many)
+                    Functions, classes
+```
+
+---
+
+## 2. AAA Pattern
+
+| Step | Purpose |
+|------|---------|
+| **Arrange** | Set up test data |
+| **Act** | Execute code under test |
+| **Assert** | Verify outcome |
+
+---
+
+## 3. Test Type Selection
+
+### When to Use Each
+
+| Type | Best For | Speed |
+|------|----------|-------|
+| **Unit** | Pure functions, logic | Fast (<50ms) |
+| **Integration** | API, DB, services | Medium |
+| **E2E** | Critical user flows | Slow |
+
+---
+
+## 4. Unit Test Principles
+
+### Good Unit Tests
+
+| Principle | Meaning |
+|-----------|---------|
+| Fast | < 100ms each |
+| Isolated | No external deps |
+| Repeatable | Same result always |
+| Self-checking | No manual verification |
+| Timely | Written with code |
+
+### What to Unit Test
+
+| Test | Don't Test |
+|------|------------|
+| Business logic | Framework code |
+| Edge cases | Third-party libs |
+| Error handling | Simple getters |
+
+---
+
+## 5. Integration Test Principles
+
+### What to Test
+
+| Area | Focus |
+|------|-------|
+| API endpoints | Request/response |
+| Database | Queries, transactions |
+| External services | Contracts |
+
+### Setup/Teardown
+
+| Phase | Action |
+|-------|--------|
+| Before All | Connect resources |
+| Before Each | Reset state |
+| After Each | Clean up |
+| After All | Disconnect |
+
+---
+
+## 6. Mocking Principles
+
+### When to Mock
+
+| Mock | Don't Mock |
+|------|------------|
+| External APIs | The code under test |
+| Database (unit) | Simple dependencies |
+| Time/random | Pure functions |
+| Network | In-memory stores |
+
+### Mock Types
+
+| Type | Use |
+|------|-----|
+| Stub | Return fixed values |
+| Spy | Track calls |
+| Mock | Set expectations |
+| Fake | Simplified implementation |
+
+---
+
+## 7. Test Organization
+
+### Naming
+
+| Pattern | Example |
+|---------|---------|
+| Should behavior | "should return error when..." |
+| When condition | "when user not found..." |
+| Given-when-then | "given X, when Y, then Z" |
+
+### Grouping
+
+| Level | Use |
+|-------|-----|
+| describe | Group related tests |
+| it/test | Individual case |
+| beforeEach | Common setup |
+
+---
+
+## 8. Test Data
+
+### Strategies
+
+| Approach | Use |
+|----------|-----|
+| Factories | Generate test data |
+| Fixtures | Predefined datasets |
+| Builders | Fluent object creation |
+
+### Principles
+
+- Use realistic data
+- Randomize non-essential values (faker)
+- Share common fixtures
+- Keep data minimal
+
+---
+
+## 9. Best Practices
+
+| Practice | Why |
+|----------|-----|
+| One assert per test | Clear failure reason |
+| Independent tests | No order dependency |
+| Fast tests | Run frequently |
+| Descriptive names | Self-documenting |
+| Clean up | Avoid side effects |
+
+---
+
+## 10. Anti-Patterns
+
+| ❌ Don't | ✅ Do |
+|----------|-------|
+| Test implementation | Test behavior |
+| Duplicate test code | Use factories |
+| Complex test setup | Simplify or split |
+| Ignore flaky tests | Fix root cause |
+| Skip cleanup | Reset state |
+
+---
+
+> **Remember:** Tests are documentation. If someone can't understand what the code does from the tests, rewrite them.

package/skills/engineering/testing-patterns/scripts/test_runner.py

@@ -0,0 +1,219 @@
+#!/usr/bin/env python3
+"""
+Test Runner - Unified test execution and coverage reporting
+Runs tests and generates coverage report based on project type.
+
+Usage:
+    python test_runner.py <project_path> [--coverage]
+
+Supports:
+    - Node.js: npm test, jest, vitest
+    - Python: pytest, unittest
+"""
+
+import subprocess
+import sys
+import json
+from pathlib import Path
+from datetime import datetime
+
+# Fix Windows console encoding
+try:
+    sys.stdout.reconfigure(encoding='utf-8', errors='replace')
+except:
+    pass
+
+
+def detect_test_framework(project_path: Path) -> dict:
+    """Detect test framework and commands."""
+    result = {
+        "type": "unknown",
+        "framework": None,
+        "cmd": None,
+        "coverage_cmd": None
+    }
+    
+    # Node.js project
+    package_json = project_path / "package.json"
+    if package_json.exists():
+        result["type"] = "node"
+        try:
+            pkg = json.loads(package_json.read_text(encoding='utf-8'))
+            scripts = pkg.get("scripts", {})
+            deps = {**pkg.get("dependencies", {}), **pkg.get("devDependencies", {})}
+            
+            # Check for test script
+            if "test" in scripts:
+                result["framework"] = "npm test"
+                result["cmd"] = ["npm", "test"]
+                
+                # Try to detect specific framework for coverage
+                if "vitest" in deps:
+                    result["framework"] = "vitest"
+                    result["coverage_cmd"] = ["npx", "vitest", "run", "--coverage"]
+                elif "jest" in deps:
+                    result["framework"] = "jest"
+                    result["coverage_cmd"] = ["npx", "jest", "--coverage"]
+            elif "vitest" in deps:
+                result["framework"] = "vitest"
+                result["cmd"] = ["npx", "vitest", "run"]
+                result["coverage_cmd"] = ["npx", "vitest", "run", "--coverage"]
+            elif "jest" in deps:
+                result["framework"] = "jest"
+                result["cmd"] = ["npx", "jest"]
+                result["coverage_cmd"] = ["npx", "jest", "--coverage"]
+                
+        except:
+            pass
+    
+    # Python project
+    if (project_path / "pyproject.toml").exists() or (project_path / "requirements.txt").exists():
+        result["type"] = "python"
+        result["framework"] = "pytest"
+        result["cmd"] = ["python", "-m", "pytest", "-v"]
+        result["coverage_cmd"] = ["python", "-m", "pytest", "--cov", "--cov-report=term-missing"]
+    
+    return result
+
+
+def run_tests(cmd: list, cwd: Path) -> dict:
+    """Run tests and return results."""
+    result = {
+        "passed": False,
+        "output": "",
+        "error": "",
+        "tests_run": 0,
+        "tests_passed": 0,
+        "tests_failed": 0
+    }
+    
+    try:
+        proc = subprocess.run(
+            cmd,
+            cwd=str(cwd),
+            capture_output=True,
+            text=True,
+            encoding='utf-8',
+            errors='replace',
+            timeout=300  # 5 min timeout for tests
+        )
+        
+        result["output"] = proc.stdout[:3000] if proc.stdout else ""
+        result["error"] = proc.stderr[:500] if proc.stderr else ""
+        result["passed"] = proc.returncode == 0
+        
+        # Try to parse test counts from output
+        output = proc.stdout or ""
+        
+        # Jest/Vitest pattern: "Tests: X passed, Y failed, Z total"
+        if "passed" in output.lower() and "failed" in output.lower():
+            import re
+            match = re.search(r'(\d+)\s+passed', output, re.IGNORECASE)
+            if match:
+                result["tests_passed"] = int(match.group(1))
+            match = re.search(r'(\d+)\s+failed', output, re.IGNORECASE)
+            if match:
+                result["tests_failed"] = int(match.group(1))
+            result["tests_run"] = result["tests_passed"] + result["tests_failed"]
+        
+        # Pytest pattern: "X passed, Y failed"
+        if "pytest" in str(cmd):
+            import re
+            match = re.search(r'(\d+)\s+passed', output)
+            if match:
+                result["tests_passed"] = int(match.group(1))
+            match = re.search(r'(\d+)\s+failed', output)
+            if match:
+                result["tests_failed"] = int(match.group(1))
+            result["tests_run"] = result["tests_passed"] + result["tests_failed"]
+        
+    except FileNotFoundError:
+        result["error"] = f"Command not found: {cmd[0]}"
+    except subprocess.TimeoutExpired:
+        result["error"] = "Timeout after 300s"
+    except Exception as e:
+        result["error"] = str(e)
+    
+    return result
+
+
+def main():
+    project_path = Path(sys.argv[1] if len(sys.argv) > 1 else ".").resolve()
+    with_coverage = "--coverage" in sys.argv
+    
+    print(f"\n{'='*60}")
+    print(f"[TEST RUNNER] Unified Test Execution")
+    print(f"{'='*60}")
+    print(f"Project: {project_path}")
+    print(f"Coverage: {'enabled' if with_coverage else 'disabled'}")
+    print(f"Time: {datetime.now().strftime('%Y-%m-%d %H:%M:%S')}")
+    
+    # Detect test framework
+    test_info = detect_test_framework(project_path)
+    print(f"Type: {test_info['type']}")
+    print(f"Framework: {test_info['framework']}")
+    print("-"*60)
+    
+    if not test_info["cmd"]:
+        print("No test framework found for this project.")
+        output = {
+            "script": "test_runner",
+            "project": str(project_path),
+            "type": test_info["type"],
+            "framework": None,
+            "passed": True,
+            "message": "No tests configured"
+        }
+        print(json.dumps(output, indent=2))
+        sys.exit(0)
+    
+    # Choose command
+    cmd = test_info["coverage_cmd"] if with_coverage and test_info["coverage_cmd"] else test_info["cmd"]
+    
+    print(f"Running: {' '.join(cmd)}")
+    print("-"*60)
+    
+    # Run tests
+    result = run_tests(cmd, project_path)
+    
+    # Print output (truncated)
+    if result["output"]:
+        lines = result["output"].split("\n")
+        for line in lines[:30]:
+            print(line)
+        if len(lines) > 30:
+            print(f"... ({len(lines) - 30} more lines)")
+    
+    # Summary
+    print("\n" + "="*60)
+    print("SUMMARY")
+    print("="*60)
+    
+    if result["passed"]:
+        print("[PASS] All tests passed")
+    else:
+        print("[FAIL] Some tests failed")
+        if result["error"]:
+            print(f"Error: {result['error'][:200]}")
+    
+    if result["tests_run"] > 0:
+        print(f"Tests: {result['tests_run']} total, {result['tests_passed']} passed, {result['tests_failed']} failed")
+    
+    output = {
+        "script": "test_runner",
+        "project": str(project_path),
+        "type": test_info["type"],
+        "framework": test_info["framework"],
+        "tests_run": result["tests_run"],
+        "tests_passed": result["tests_passed"],
+        "tests_failed": result["tests_failed"],
+        "passed": result["passed"]
+    }
+    
+    print("\n" + json.dumps(output, indent=2))
+    
+    sys.exit(0 if result["passed"] else 1)
+
+
+if __name__ == "__main__":
+    main()

package/skills/engineering/to-issues/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: to-issues
+description: Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
+---
+
+# To Issues
+
+Break a plan into independently-grabbable issues using vertical slices (tracer bullets).
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+### 1. Gather context
+
+Work from whatever is already in the conversation context. If the user passes an issue reference (issue number, URL, or path) as an argument, fetch it from the issue tracker and read its full body and comments.
+
+### 2. Explore the codebase (optional)
+
+If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
+
+### 3. Draft vertical slices
+
+Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
+
+Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an architectural decision or a design review. AFK slices can be implemented and merged without human interaction. Prefer AFK over HITL where possible.
+
+<vertical-slice-rules>
+- Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
+- A completed slice is demoable or verifiable on its own
+- Prefer many thin slices over few thick ones
+</vertical-slice-rules>
+
+### 4. Quiz the user
+
+Present the proposed breakdown as a numbered list. For each slice, show:
+
+- **Title**: short descriptive name
+- **Type**: HITL / AFK
+- **Blocked by**: which other slices (if any) must complete first
+- **User stories covered**: which user stories this addresses (if the source material has them)
+
+Ask the user:
+
+- Does the granularity feel right? (too coarse / too fine)
+- Are the dependency relationships correct?
+- Should any slices be merged or split further?
+- Are the correct slices marked as HITL and AFK?
+
+Iterate until the user approves the breakdown.
+
+### 5. Publish the issues to the issue tracker
+
+For each approved slice, publish a new issue to the issue tracker. Use the issue body template below. Apply the `needs-triage` triage label so each issue enters the normal triage flow.
+
+Publish issues in dependency order (blockers first) so you can reference real issue identifiers in the "Blocked by" field.
+
+<issue-template>
+## Parent
+
+A reference to the parent issue on the issue tracker (if the source was an existing issue, otherwise omit this section).
+
+## What to build
+
+A concise description of this vertical slice. Describe the end-to-end behavior, not layer-by-layer implementation.
+
+## Acceptance criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## Blocked by
+
+- A reference to the blocking ticket (if any)
+
+Or "None - can start immediately" if no blockers.
+
+</issue-template>
+
+Do NOT close or modify any parent issue.

package/skills/engineering/to-prd/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: to-prd
+description: Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
+---
+
+This skill takes the current conversation context and codebase understanding and produces a PRD. Do NOT interview the user — just synthesize what you already know.
+
+The issue tracker and triage label vocabulary should have been provided to you — run `/setup-matt-pocock-skills` if not.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the PRD, and respect any ADRs in the area you're touching.
+
+2. Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
+
+A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
+
+Check with the user that these modules match their expectations. Check with the user which modules they want tests written for.
+
+3. Write the PRD using the template below, then publish it to the project issue tracker. Apply the `needs-triage` triage label so it enters the normal triage flow.
+
+<prd-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this PRD.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</prd-template>