@kurokeita/add-skill 1.17.2 → 1.18.0

package/dist/skills/gh-fix-ci/SKILL.md

@@ -21,7 +21,11 @@ Prereq: authenticate with the standard GitHub CLI once (for example, run `gh aut
 
 ## Quick start
 
-- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
+- Detect the interpreter first:
+  `PYTHON_BIN=$(command -v python || command -v python3 || true)`
+- If `PYTHON_BIN` is empty, skip the bundled script and use the manual `gh` fallback workflow.
+- Otherwise run:
+  `"$PYTHON_BIN" "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
 - Add `--json` if you want machine-friendly output for summarization.
 
 ## Workflow
@@ -34,7 +38,11 @@ Prereq: authenticate with the standard GitHub CLI once (for example, run `gh aut
    - If the user provides a PR number or URL, use that directly.
 3. Inspect failing checks (GitHub Actions only).
    - Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
-     - `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
+     - Resolve the interpreter first:
+       `PYTHON_BIN=$(command -v python || command -v python3 || true)`
+     - If `PYTHON_BIN` is set, run:
+       `"$PYTHON_BIN" "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"`
+     - If neither `python` nor `python3` is available, skip the bundled script and use the manual fallback below.
      - Add `--json` for machine-friendly output.
    - Manual fallback:
      - `gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow`
@@ -65,6 +73,6 @@ Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet
 
 Usage examples:
 
-- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"`
-- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json`
-- `python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40`
+- `PYTHON_BIN=$(command -v python || command -v python3 || true); test -n "$PYTHON_BIN" && "$PYTHON_BIN" "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"`
+- `PYTHON_BIN=$(command -v python || command -v python3 || true); test -n "$PYTHON_BIN" && "$PYTHON_BIN" "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json`
+- `PYTHON_BIN=$(command -v python || command -v python3 || true); test -n "$PYTHON_BIN" && "$PYTHON_BIN" "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40`

package/dist/skills/grill-me/SKILL.md

@@ -0,0 +1,9 @@
+---
+name: grill-me
+description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+---
+
+# Grill me
+
+Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
+If a question can be answered by exploring the codebase, explore the codebase instead.

package/dist/skills/prd-to-tasks/SKILL.md

@@ -0,0 +1,164 @@
+---
+name: prd-to-tasks
+description: >
+  Break a local PRD into independently grabbable implementation tasks using vertical slices, then save them under
+  .prd/{prd-name}/tasks/ in the current workspace. Use when the user wants to convert a PRD to tasks, break a spec
+  into actionable work, slice a PRD, or create implementation tasks from a local planning document. Do NOT trigger
+  for: writing PRDs, reviewing PRDs without task creation, or remote work item management systems.
+argument-hint: "[prd-name]"
+---
+
+# PRD to Tasks
+
+Break a local PRD into independently grabbable implementation tasks using vertical slices.
+
+Input location:
+
+- PRD directory: `.prd/{prd-name}/`
+- Source PRD: `.prd/{prd-name}/prd.md`
+
+Output location:
+
+- Tasks directory: `.prd/{prd-name}/tasks/`
+- Optional index: `.prd/{prd-name}/tasks/README.md`
+
+`{prd-name}` should be a filesystem-safe kebab-case slug. If the user provides a title instead, normalize it to a slug
+and state the slug you used.
+
+## Step 1: Locate the PRD
+
+If the user provided `$ARGUMENTS`, treat that as the PRD name and normalize it.
+
+If not, ask which PRD directory to use.
+
+Then:
+
+1. Confirm `.prd/{prd-name}/prd.md` exists
+2. Read it fully
+3. Check whether `.prd/{prd-name}/tasks/` already exists
+4. If task files already exist, summarize them and ask whether to overwrite, append, or regenerate selectively
+
+If the PRD does not exist, stop and tell the user exactly which path is missing.
+
+## Step 2: Explore the codebase
+
+If you have not already explored the relevant code in this conversation, do so now:
+
+1. Read top-level architecture guidance if present
+2. Search for code related to the PRD concepts
+3. Read nearby guidance files for affected subsystems
+4. Look for similar features and test patterns
+
+The PRD tells you *what* to build. The codebase tells you enough about *where* and *how* to create useful tasks.
+
+## Step 3: Draft vertical slices
+
+Break the PRD into **tracer bullet** tasks.
+
+### What is a tracer bullet?
+
+A tracer bullet is a thin vertical slice through the whole feature path. It proves that the relevant layers connect
+correctly end to end. It is not a horizontal "build all backend first, then all UI" slice.
+
+Prefer slices that are:
+
+- Independently verifiable
+- Demoable on their own
+- Thin and end to end
+- Ordered by dependency
+
+### HITL vs AFK
+
+Each slice should be marked:
+
+- `HITL`: needs human input, review, testing on real devices, design signoff, or external coordination
+- `AFK`: can be implemented and validated without waiting on a person
+
+### Vertical slice rules
+
+- Each slice should deliver a complete behavior, not one technical layer
+- Prefer many thin slices over a few broad ones
+- Use the PRD's module design to inform slicing, but do not create one task per module
+- Order slices so blockers come first
+
+## Step 4: Quiz the user
+
+Present the proposed slices as a numbered list. For each slice, include:
+
+- Title
+- Type: `HITL` or `AFK`
+- Blocked by
+- User stories covered
+
+Ask the user whether:
+
+- The granularity is right
+- The dependencies are correct
+- Any slices should be merged or split
+- The `HITL` versus `AFK` labels are accurate
+
+Iterate until approved.
+
+## Step 5: Write task files
+
+Only write files after the user approves the breakdown.
+
+Create `.prd/{prd-name}/tasks/` if needed.
+
+Create one Markdown file per task using zero-padded numeric prefixes:
+
+- `.prd/{prd-name}/tasks/01-{task-slug}.md`
+- `.prd/{prd-name}/tasks/02-{task-slug}.md`
+
+`{task-slug}` should be kebab-case and derived from the task title.
+
+Each task file should use this structure:
+
+```md
+# {Task title}
+
+- Type: AFK | HITL
+- Status: Proposed
+- Blocked by: None | 01-other-task
+- Source PRD: ../prd.md
+
+## What to Build
+
+Concise description of the vertical slice. Describe end-to-end behavior, not a layer-by-layer checklist.
+
+## Acceptance Criteria
+
+- [ ] Criterion 1
+- [ ] Criterion 2
+- [ ] Criterion 3
+
+## User Stories Addressed
+
+- User story 3
+- User story 7
+
+## Notes
+
+- Optional implementation hints grounded in the current codebase
+- Reference relevant modules or concepts, but avoid binding the task to fragile file-level details unless necessary
+```
+
+Also create or update `.prd/{prd-name}/tasks/README.md` with:
+
+- The PRD title
+- The approved slice list in dependency order
+- A short summary of each task
+
+## Important constraints
+
+- Do not modify `prd.md` unless the user asks
+- Do not delete existing task files unless the user explicitly approves replacement
+- If existing tasks overlap the proposed slices, call that out before writing duplicates
+
+## After writing
+
+Summarize:
+
+- The PRD slug used
+- The task files created or updated
+- Any existing task files that were preserved

package/dist/skills/test-driven-development/SKILL.md

@@ -1,389 +1,114 @@
 ---
-name: test-driven-development
-description: Use when implementing any feature or bugfix, before writing implementation code
+name: tdd
+description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
 ---
 
-# Test-Driven Development (TDD)
+# Test-Driven Development
 
-## Overview
+## Philosophy
 
-Write the test first. Watch it fail. Write minimal code to pass.
+**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
 
-**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
+**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
 
-**Violating the letter of the rules is violating the spirit of the rules.**
+**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
 
-## When to Use
+See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
 
-**Always:**
+## Anti-Pattern: Horizontal Slices
 
-- New features
-- Bug fixes
-- Refactoring
-- Behavior changes
+**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
 
-**Exceptions (ask your human partner):**
+This produces **crap tests**:
 
-- Throwaway prototypes
-- Generated code
-- Configuration files
+- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
+- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
+- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
+- You outrun your headlights, committing to test structure before understanding the implementation
 
-Thinking "skip TDD just this once"? Stop. That's rationalization.
+**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
 
-## The Iron Law
-
-```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
 ```
-
-Write code before the test? Delete it. Start over.
-
-**No exceptions:**
-
-- Don't keep it as "reference"
-- Don't "adapt" it while writing tests
-- Don't look at it
-- Delete means delete
-
-Implement fresh from tests. Period.
-
-## Red-Green-Refactor
-
-```dot
-digraph tdd_cycle {
-    rankdir=LR;
-    red [label="RED\nWrite failing test", shape=box, style=filled, fillcolor="#ffcccc"];
-    verify_red [label="Verify fails\ncorrectly", shape=diamond];
-    green [label="GREEN\nMinimal code", shape=box, style=filled, fillcolor="#ccffcc"];
-    verify_green [label="Verify passes\nAll green", shape=diamond];
-    refactor [label="REFACTOR\nClean up", shape=box, style=filled, fillcolor="#ccccff"];
-    next [label="Next", shape=ellipse];
-
-    red -> verify_red;
-    verify_red -> green [label="yes"];
-    verify_red -> red [label="wrong\nfailure"];
-    green -> verify_green;
-    verify_green -> refactor [label="yes"];
-    verify_green -> green [label="no"];
-    refactor -> verify_green [label="stay\ngreen"];
-    verify_green -> next;
-    next -> red;
-}
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+  ...
 ```
 
-### RED - Write Failing Test
-
-Write one minimal test showing what should happen.
-
-<Good>
-```typescript
-test('retries failed operations 3 times', async () => {
-  let attempts = 0;
-  const operation = () => {
-    attempts++;
-    if (attempts < 3) throw new Error('fail');
-    return 'success';
-  };
+## Workflow
 
-  const result = await retryOperation(operation);
+### 1. Planning
 
-  expect(result).toBe('success');
-  expect(attempts).toBe(3);
-});
+Before writing any code:
 
-```
-Clear name, tests real behavior, one thing
-</Good>
-
-<Bad>
-```typescript
-test('retry works', async () => {
-  const mock = jest.fn()
-    .mockRejectedValueOnce(new Error())
-    .mockRejectedValueOnce(new Error())
-    .mockResolvedValueOnce('success');
-  await retryOperation(mock);
-  expect(mock).toHaveBeenCalledTimes(3);
-});
-```
-
-Vague name, tests mock not code
-</Bad>
+- [ ] Confirm with user what interface changes are needed
+- [ ] Confirm with user which behaviors to test (prioritize)
+- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
+- [ ] Design interfaces for [testability](interface-design.md)
+- [ ] List the behaviors to test (not implementation steps)
+- [ ] Get user approval on the plan
 
-**Requirements:**
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
 
-- One behavior
-- Clear name
-- Real code (no mocks unless unavoidable)
+**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
 
-### Verify RED - Watch It Fail
+### 2. Tracer Bullet
 
-**MANDATORY. Never skip.**
+Write ONE test that confirms ONE thing about the system:
 
-```bash
-npm test path/to/test.test.ts
 ```
-
-Confirm:
-
-- Test fails (not errors)
-- Failure message is expected
-- Fails because feature missing (not typos)
-
-**Test passes?** You're testing existing behavior. Fix test.
-
-**Test errors?** Fix error, re-run until it fails correctly.
-
-### GREEN - Minimal Code
-
-Write simplest code to pass the test.
-
-<Good>
-```typescript
-async function retryOperation<T>(fn: () => Promise<T>): Promise<T> {
-  for (let i = 0; i < 3; i++) {
-    try {
-      return await fn();
-    } catch (e) {
-      if (i === 2) throw e;
-    }
-  }
-  throw new Error('unreachable');
-}
-```
-Just enough to pass
-</Good>
-
-<Bad>
-```typescript
-async function retryOperation<T>(
-  fn: () => Promise<T>,
-  options?: {
-    maxRetries?: number;
-    backoff?: 'linear' | 'exponential';
-    onRetry?: (attempt: number) => void;
-  }
-): Promise<T> {
-  // YAGNI
-}
-```
-Over-engineered
-</Bad>
-
-Don't add features, refactor other code, or "improve" beyond the test.
-
-### Verify GREEN - Watch It Pass
-
-**MANDATORY.**
-
-```bash
-npm test path/to/test.test.ts
+RED:   Write test for first behavior
+       ↓ RUN TESTS — confirm it fails for the right reason
+GREEN: Write minimal code to pass
+       ↓ RUN TESTS — confirm it passes
 ```
 
-Confirm:
-
-- Test passes
-- Other tests still pass
-- Output pristine (no errors, warnings)
-
-**Test fails?** Fix code, not test.
-
-**Other tests fail?** Fix now.
-
-### REFACTOR - Clean Up
-
-After green only:
-
-- Remove duplication
-- Improve names
-- Extract helpers
-
-Keep tests green. Don't add behavior.
-
-### Repeat
-
-Next failing test for next feature.
-
-## Good Tests
-
-| Quality | Good | Bad |
-|---------|------|-----|
-| **Minimal** | One thing. "and" in name? Split it. | `test('validates email and domain and whitespace')` |
-| **Clear** | Name describes behavior | `test('test1')` |
-| **Shows intent** | Demonstrates desired API | Obscures what code should do |
-
-## Why Order Matters
-
-**"I'll write tests after to verify it works"**
-
-Tests written after code pass immediately. Passing immediately proves nothing:
-
-- Might test wrong thing
-- Might test implementation, not behavior
-- Might miss edge cases you forgot
-- You never saw it catch the bug
-
-Test-first forces you to see the test fail, proving it actually tests something.
-
-**"I already manually tested all the edge cases"**
+This is your tracer bullet - proves the path works end-to-end.
 
-Manual testing is ad-hoc. You think you tested everything but:
+**You MUST run the test before writing any implementation.** A test that was never observed to fail might always pass vacuously, be testing the wrong thing, or be broken. The failure message tells you what the test is actually checking.
 
-- No record of what you tested
-- Can't re-run when code changes
-- Easy to forget cases under pressure
-- "It worked when I tried it" ≠ comprehensive
+### 3. Incremental Loop
 
-Automated tests are systematic. They run the same way every time.
+For each remaining behavior:
 
-**"Deleting X hours of work is wasteful"**
-
-Sunk cost fallacy. The time is already gone. Your choice now:
-
-- Delete and rewrite with TDD (X more hours, high confidence)
-- Keep it and add tests after (30 min, low confidence, likely bugs)
-
-The "waste" is keeping code you can't trust. Working code without real tests is technical debt.
-
-**"TDD is dogmatic, being pragmatic means adapting"**
-
-TDD IS pragmatic:
-
-- Finds bugs before commit (faster than debugging after)
-- Prevents regressions (tests catch breaks immediately)
-- Documents behavior (tests show how to use code)
-- Enables refactoring (change freely, tests catch breaks)
-
-"Pragmatic" shortcuts = debugging in production = slower.
-
-**"Tests after achieve the same goals - it's spirit not ritual"**
-
-No. Tests-after answer "What does this do?" Tests-first answer "What should this do?"
-
-Tests-after are biased by your implementation. You test what you built, not what's required. You verify remembered edge cases, not discovered ones.
-
-Tests-first force edge case discovery before implementing. Tests-after verify you remembered everything (you didn't).
-
-30 minutes of tests after ≠ TDD. You get coverage, lose proof tests work.
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
-| "Existing code has no tests" | You're improving it. Add tests for existing code. |
-
-## Red Flags - STOP and Start Over
-
-- Code before test
-- Test after implementation
-- Test passes immediately
-- Can't explain why test failed
-- Tests added "later"
-- Rationalizing "just this once"
-- "I already manually tested it"
-- "Tests after achieve the same purpose"
-- "It's about spirit not ritual"
-- "Keep as reference" or "adapt existing code"
-- "Already spent X hours, deleting is wasteful"
-- "TDD is dogmatic, I'm being pragmatic"
-- "This is different because..."
-
-**All of these mean: Delete code. Start over with TDD.**
-
-## Example: Bug Fix
-
-**Bug:** Empty email accepted
-
-**RED**
-
-```typescript
-test('rejects empty email', async () => {
-  const result = await submitForm({ email: '' });
-  expect(result.error).toBe('Email required');
-});
-```
-
-**Verify RED**
-
-```bash
-$ npm test
-FAIL: expected 'Email required', got undefined
 ```
-
-**GREEN**
-
-```typescript
-function submitForm(data: FormData) {
-  if (!data.email?.trim()) {
-    return { error: 'Email required' };
-  }
-  // ...
-}
-```
-
-**Verify GREEN**
-
-```bash
-$ npm test
-PASS
+RED:   Write next test
+       ↓ RUN TESTS — confirm new test fails, existing pass
+GREEN: Minimal code to pass
+       ↓ RUN TESTS — confirm all pass
 ```
 
-**REFACTOR**
-Extract validation for multiple fields if needed.
-
-## Verification Checklist
-
-Before marking work complete:
-
-- [ ] Every new function/method has a test
-- [ ] Watched each test fail before implementing
-- [ ] Each test failed for expected reason (feature missing, not typo)
-- [ ] Wrote minimal code to pass each test
-- [ ] All tests pass
-- [ ] Output pristine (no errors, warnings)
-- [ ] Tests use real code (mocks only if unavoidable)
-- [ ] Edge cases and errors covered
-
-Can't check all boxes? You skipped TDD. Start over.
+Rules:
 
-## When Stuck
+- One test at a time
+- Run tests after writing each test (confirm RED) and after each implementation step (confirm GREEN)
+- Only enough code to pass current test
+- Don't anticipate future tests
+- Keep tests focused on observable behavior
 
-| Problem | Solution |
-|---------|----------|
-| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |
-| Test too complicated | Design too complicated. Simplify interface. |
-| Must mock everything | Code too coupled. Use dependency injection. |
-| Test setup huge | Extract helpers. Still complex? Simplify design. |
+### 4. Refactor
 
-## Debugging Integration
+After all tests pass, look for [refactor candidates](refactoring.md):
 
-Bug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.
+- [ ] Extract duplication
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles where natural
+- [ ] Consider what new code reveals about existing code
+- [ ] Run tests after each refactor step
 
-Never fix bugs without a test.
+**Never refactor while RED.** Get to GREEN first.
 
-## Testing Anti-Patterns
-
-When adding mocks or test utilities, read @testing-anti-patterns.md to avoid common pitfalls:
-
-- Testing mock behavior instead of real behavior
-- Adding test-only methods to production classes
-- Mocking without understanding dependencies
-
-## Final Rule
+## Checklist Per Cycle
 
 ```
-Production code → test exists and failed first
-Otherwise → not TDD
+[ ] Test describes behavior, not implementation
+[ ] Test uses public interface only
+[ ] Test would survive internal refactor
+[ ] Code is minimal for this test
+[ ] No speculative features added
 ```
-
-No exceptions without your human partner's permission.

package/dist/skills/test-driven-development/deep-modules.md

@@ -0,0 +1,33 @@
+# Deep Modules
+
+From "A Philosophy of Software Design":
+
+**Deep module** = small interface + lots of implementation
+
+```
+┌─────────────────────┐
+│   Small Interface   │  ← Few methods, simple params
+├─────────────────────┤
+│                     │
+│                     │
+│  Deep Implementation│  ← Complex logic hidden
+│                     │
+│                     │
+└─────────────────────┘
+```
+
+**Shallow module** = large interface + little implementation (avoid)
+
+```
+┌─────────────────────────────────┐
+│       Large Interface           │  ← Many methods, complex params
+├─────────────────────────────────┤
+│  Thin Implementation            │  ← Just passes through
+└─────────────────────────────────┘
+```
+
+When designing interfaces, ask:
+
+- Can I reduce the number of methods?
+- Can I simplify the parameters?
+- Can I hide more complexity inside?

package/dist/skills/test-driven-development/interface-design.md

@@ -0,0 +1,35 @@
+# Interface Design for Testability
+
+Good interfaces make testing natural:
+
+1. **Accept dependencies, don't create them**
+
+   ```typescript
+   // Testable
+   function processOrder(order, paymentGateway) {}
+
+   // Hard to test
+   function processOrder(order) {
+     const gateway = new StripeGateway();
+   }
+   ```
+
+2. **Return results, don't produce side effects**
+
+   ```typescript
+   // Testable
+   function calculateDiscount(cart): Discount {}
+
+   // Hard to test
+   function applyDiscount(cart): void {
+     cart.total -= discount;
+   }
+   ```
+
+3. **Small surface area**
+   - Fewer methods = fewer tests needed
+   - Fewer params = simpler test setup
+
+4. **Keep test-only helpers out of production APIs**
+
+   If cleanup or inspection logic exists only for tests, put it in test utilities rather than adding methods to production classes. Production interfaces should reflect real runtime behavior, not test harness needs.

package/dist/skills/test-driven-development/mocking.md

@@ -0,0 +1,68 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint
+
+## Mock Faithfully
+
+When a boundary must be mocked, preserve the parts of reality the test depends on:
+
+- Include the full response shape that downstream code relies on, not just the fields used in the immediate assertion
+- Avoid mocking away side effects the behavior under test actually needs
+- If unsure what must remain real, run the test against the real path first and then mock the lowest external boundary

package/dist/skills/test-driven-development/refactoring.md

@@ -0,0 +1,10 @@
+# Refactor Candidates
+
+After TDD cycle, look for:
+
+- **Duplication** → Extract function/class
+- **Long methods** → Break into private helpers (keep tests on public interface)
+- **Shallow modules** → Combine or deepen
+- **Feature envy** → Move logic to where data lives
+- **Primitive obsession** → Introduce value objects
+- **Existing code** the new code reveals as problematic

package/dist/skills/test-driven-development/tests.md

@@ -0,0 +1,61 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```

package/dist/skills/write-prd/SKILL.md

@@ -0,0 +1,162 @@
+---
+name: write-prd
+description: >
+  Create a developer-focused PRD through user interview, codebase exploration, and module design, then save it
+  under .prd/{prd-name}/ in the current workspace. Use when the user wants to write a PRD, create a product
+  requirements document, plan a new feature, spec out work, or define requirements for implementation. Also
+  trigger when the user says things like "let's plan this feature", "I need a spec for...", "write requirements
+  for...", or "create a PRD for...". Do NOT trigger for: reviewing existing PRDs, creating child tasks from a PRD,
+  or general project management outside the local PRD directory.
+argument-hint: "[prd-name]"
+---
+
+# Write a PRD
+
+Create a developer-focused Product Requirements Document and save it to the local workspace instead of a remote tracker.
+The PRD captures the *what* and *why* of a feature, not line-level implementation details.
+
+During the interview phase, explicitly use the `grill-me` skill if it is available in the current workspace. Treat
+that skill as the driver for the questioning loop, while this skill remains responsible for codebase exploration,
+module design, PRD drafting, and filesystem output.
+
+Output location:
+
+- Directory: `.prd/{prd-name}/`
+- Primary document: `.prd/{prd-name}/prd.md`
+- Optional notes captured during planning: `.prd/{prd-name}/notes.md`
+
+`{prd-name}` should be a filesystem-safe kebab-case slug. If the user provides a title with spaces or punctuation,
+normalize it to kebab-case and tell the user which slug you used.
+
+You may skip steps if they are clearly unnecessary, but do not rush. The value of this skill is in forcing clarity.
+
+## Step 1: Establish the PRD target
+
+If the user provided `$ARGUMENTS`, treat that as the intended PRD name and normalize it to a slug.
+
+If not, ask for the PRD name before writing files.
+
+Before creating files:
+
+- Check whether `.prd/{prd-name}/` already exists
+- If it exists, read `prd.md` if present and summarize the current state
+- Ask whether the user wants to overwrite the PRD, revise it in place, or create a new slug
+
+## Step 2: Get the problem description
+
+Ask the user for a long, detailed description of the problem they want to solve and any candidate solutions they already
+have in mind.
+
+If an existing `.prd/{prd-name}/prd.md` exists, summarize it first so the user can correct or extend it instead of repeating
+context.
+
+## Step 3: Explore the codebase
+
+Before interviewing, ground yourself in the actual codebase:
+
+1. Read the top-level `README.md`, `AGENTS.md`, or other architectural guidance if present
+2. Search broadly for relevant terms, domain concepts, and adjacent implementations
+3. Read area-specific guidance files when relevant
+4. Look for similar features, patterns, and existing terminology
+
+Do not try to read everything. Use search-driven exploration to understand the current state well enough to ask informed
+questions and write an accurate PRD.
+
+## Step 4: Interview relentlessly
+
+Invoke the `grill-me` skill for this phase if available, then interview the user until you reach shared understanding.
+Walk down each branch of the design tree and resolve dependencies one by one.
+
+Ask one question at a time. Keep going until ambiguity is removed.
+
+Ask about:
+
+- Edge cases and failure scenarios
+- Existing behavior that must be preserved
+- What success looks like from the user's perspective
+- Who the end users are
+- Constraints from architecture, rollout, compatibility, or operations
+
+Continue exploring the codebase while interviewing. If a question can be answered by inspecting code, inspect code instead
+of asking the user.
+
+### Scope check
+
+If it becomes clear the work is too large for one PRD, tell the user and ask whether to narrow the scope or continue with
+a larger document that will later be split into multiple execution tracks.
+
+## Step 5: Sketch module design
+
+Sketch the major conceptual modules to build or modify. Look for opportunities to define **deep modules**:
+
+- Interfaces simpler than the implementation they hide
+- Testable in isolation
+- Internals can change without rippling outward
+
+Check that these modules match the user's expectations and ask which ones need stronger test coverage.
+
+## Step 6: Draft the PRD and get approval
+
+Write the PRD and show it to the user for approval before saving or overwriting `prd.md`.
+
+The PRD should be durable:
+
+- Do describe conceptual modules, responsibilities, interfaces, and data flow
+- Do describe architectural patterns and decisions
+- Do not reference specific file paths, class names, or step-by-step implementation procedures
+- Do not include code snippets unless the user explicitly asks for them
+
+Use this structure:
+
+```md
+# {Human-readable PRD title}
+
+## Problem Statement
+
+## Solution
+
+## User Stories
+1. As a ...
+
+## Module Design
+### {Module name}
+- Responsibility:
+- Interface:
+- Status: new | existing
+- Depth: deep | shallow
+
+## Implementation Decisions
+
+## Testing Decisions
+
+## Out of Scope
+
+## Open Questions
+```
+
+Omit `Open Questions` if none remain.
+
+## Step 7: Save to the filesystem
+
+Only save after the user approves the PRD.
+
+Create `.prd/{prd-name}/` if it does not exist.
+
+Write:
+
+- `.prd/{prd-name}/prd.md`: the approved PRD
+
+Optionally write:
+
+- `.prd/{prd-name}/notes.md`: short working notes, unresolved investigation points, or source references gathered during
+  discovery. Keep this concise and operational, not user-facing.
+
+Do not create extra files unless they add real value.
+
+## After saving
+
+Tell the user:
+
+- The slug used
+- The files created or updated
+- Whether this was a new PRD or a revision of an existing directory

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@kurokeita/add-skill",
-	"version": "1.17.2",
+	"version": "1.18.0",
 	"description": "CLI to install AI agent skills to various platforms",
 	"type": "module",
 	"bin": {

package/dist/skills/test-driven-development/testing-anti-patterns.md

@@ -1,316 +0,0 @@
-# Testing Anti-Patterns
-
-**Load this reference when:** writing or changing tests, adding mocks, or tempted to add test-only methods to production code.
-
-## Overview
-
-Tests must verify real behavior, not mock behavior. Mocks are a means to isolate, not the thing being tested.
-
-**Core principle:** Test what the code does, not what the mocks do.
-
-**Following strict TDD prevents these anti-patterns.**
-
-## The Iron Laws
-
-```
-1. NEVER test mock behavior
-2. NEVER add test-only methods to production classes
-3. NEVER mock without understanding dependencies
-```
-
-## Anti-Pattern 1: Testing Mock Behavior
-
-**The violation:**
-
-```typescript
-// ❌ BAD: Testing that the mock exists
-test('renders sidebar', () => {
-  render(<Page />);
-  expect(screen.getByTestId('sidebar-mock')).toBeInTheDocument();
-});
-```
-
-**Why this is wrong:**
-
-- You're verifying the mock works, not that the component works
-- Test passes when mock is present, fails when it's not
-- Tells you nothing about real behavior
-
-**your human partner's correction:** "Are we testing the behavior of a mock?"
-
-**The fix:**
-
-```typescript
-// ✅ GOOD: Test real component or don't mock it
-test('renders sidebar', () => {
-  render(<Page />);  // Don't mock sidebar
-  expect(screen.getByRole('navigation')).toBeInTheDocument();
-});
-
-// OR if sidebar must be mocked for isolation:
-// Don't assert on the mock - test Page's behavior with sidebar present
-```
-
-### Gate Function
-
-```
-BEFORE asserting on any mock element:
-  Ask: "Am I testing real component behavior or just mock existence?"
-
-  IF testing mock existence:
-    STOP - Delete the assertion or unmock the component
-
-  Test real behavior instead
-```
-
-## Anti-Pattern 2: Test-Only Methods in Production
-
-**The violation:**
-
-```typescript
-// ❌ BAD: destroy() only used in tests
-class Session {
-  async destroy() {  // Looks like production API!
-    await this._workspaceManager?.destroyWorkspace(this.id);
-    // ... cleanup
-  }
-}
-
-// In tests
-afterEach(() => session.destroy());
-```
-
-**Why this is wrong:**
-
-- Production class polluted with test-only code
-- Dangerous if accidentally called in production
-- Violates YAGNI and separation of concerns
-- Confuses object lifecycle with entity lifecycle
-
-**The fix:**
-
-```typescript
-// ✅ GOOD: Test utilities handle test cleanup
-// Session has no destroy() - it's stateless in production
-
-// In test-utils/
-export async function cleanupSession(session: Session) {
-  const workspace = session.getWorkspaceInfo();
-  if (workspace) {
-    await workspaceManager.destroyWorkspace(workspace.id);
-  }
-}
-
-// In tests
-afterEach(() => cleanupSession(session));
-```
-
-### Gate Function
-
-```
-BEFORE adding any method to production class:
-  Ask: "Is this only used by tests?"
-
-  IF yes:
-    STOP - Don't add it
-    Put it in test utilities instead
-
-  Ask: "Does this class own this resource's lifecycle?"
-
-  IF no:
-    STOP - Wrong class for this method
-```
-
-## Anti-Pattern 3: Mocking Without Understanding
-
-**The violation:**
-
-```typescript
-// ❌ BAD: Mock breaks test logic
-test('detects duplicate server', () => {
-  // Mock prevents config write that test depends on!
-  vi.mock('ToolCatalog', () => ({
-    discoverAndCacheTools: vi.fn().mockResolvedValue(undefined)
-  }));
-
-  await addServer(config);
-  await addServer(config);  // Should throw - but won't!
-});
-```
-
-**Why this is wrong:**
-
-- Mocked method had side effect test depended on (writing config)
-- Over-mocking to "be safe" breaks actual behavior
-- Test passes for wrong reason or fails mysteriously
-
-**The fix:**
-
-```typescript
-// ✅ GOOD: Mock at correct level
-test('detects duplicate server', () => {
-  // Mock the slow part, preserve behavior test needs
-  vi.mock('MCPServerManager'); // Just mock slow server startup
-
-  await addServer(config);  // Config written
-  await addServer(config);  // Duplicate detected ✓
-});
-```
-
-### Gate Function
-
-```
-BEFORE mocking any method:
-  STOP - Don't mock yet
-
-  1. Ask: "What side effects does the real method have?"
-  2. Ask: "Does this test depend on any of those side effects?"
-  3. Ask: "Do I fully understand what this test needs?"
-
-  IF depends on side effects:
-    Mock at lower level (the actual slow/external operation)
-    OR use test doubles that preserve necessary behavior
-    NOT the high-level method the test depends on
-
-  IF unsure what test depends on:
-    Run test with real implementation FIRST
-    Observe what actually needs to happen
-    THEN add minimal mocking at the right level
-
-  Red flags:
-    - "I'll mock this to be safe"
-    - "This might be slow, better mock it"
-    - Mocking without understanding the dependency chain
-```
-
-## Anti-Pattern 4: Incomplete Mocks
-
-**The violation:**
-
-```typescript
-// ❌ BAD: Partial mock - only fields you think you need
-const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' }
-  // Missing: metadata that downstream code uses
-};
-
-// Later: breaks when code accesses response.metadata.requestId
-```
-
-**Why this is wrong:**
-
-- **Partial mocks hide structural assumptions** - You only mocked fields you know about
-- **Downstream code may depend on fields you didn't include** - Silent failures
-- **Tests pass but integration fails** - Mock incomplete, real API complete
-- **False confidence** - Test proves nothing about real behavior
-
-**The Iron Rule:** Mock the COMPLETE data structure as it exists in reality, not just fields your immediate test uses.
-
-**The fix:**
-
-```typescript
-// ✅ GOOD: Mirror real API completeness
-const mockResponse = {
-  status: 'success',
-  data: { userId: '123', name: 'Alice' },
-  metadata: { requestId: 'req-789', timestamp: 1234567890 }
-  // All fields real API returns
-};
-```
-
-### Gate Function
-
-```
-BEFORE creating mock responses:
-  Check: "What fields does the real API response contain?"
-
-  Actions:
-    1. Examine actual API response from docs/examples
-    2. Include ALL fields system might consume downstream
-    3. Verify mock matches real response schema completely
-
-  Critical:
-    If you're creating a mock, you must understand the ENTIRE structure
-    Partial mocks fail silently when code depends on omitted fields
-
-  If uncertain: Include all documented fields
-```
-
-## Anti-Pattern 5: Integration Tests as Afterthought
-
-**The violation:**
-
-```
-✅ Implementation complete
-❌ No tests written
-"Ready for testing"
-```
-
-**Why this is wrong:**
-
-- Testing is part of implementation, not optional follow-up
-- TDD would have caught this
-- Can't claim complete without tests
-
-**The fix:**
-
-```
-TDD cycle:
-1. Write failing test
-2. Implement to pass
-3. Refactor
-4. THEN claim complete
-```
-
-## When Mocks Become Too Complex
-
-**Warning signs:**
-
-- Mock setup longer than test logic
-- Mocking everything to make test pass
-- Mocks missing methods real components have
-- Test breaks when mock changes
-
-**your human partner's question:** "Do we need to be using a mock here?"
-
-**Consider:** Integration tests with real components often simpler than complex mocks
-
-## TDD Prevents These Anti-Patterns
-
-**Why TDD helps:**
-
-1. **Write test first** → Forces you to think about what you're actually testing
-2. **Watch it fail** → Confirms test tests real behavior, not mocks
-3. **Minimal implementation** → No test-only methods creep in
-4. **Real dependencies** → You see what the test actually needs before mocking
-
-**If you're testing mock behavior, you violated TDD** - you added mocks without watching test fail against real code first.
-
-## Quick Reference
-
-| Anti-Pattern | Fix |
-|--------------|-----|
-| Assert on mock elements | Test real component or unmock it |
-| Test-only methods in production | Move to test utilities |
-| Mock without understanding | Understand dependencies first, mock minimally |
-| Incomplete mocks | Mirror real API completely |
-| Tests as afterthought | TDD - tests first |
-| Over-complex mocks | Consider integration tests |
-
-## Red Flags
-
-- Assertion checks for `*-mock` test IDs
-- Methods only called in test files
-- Mock setup is >50% of test
-- Test fails when you remove mock
-- Can't explain why mock is needed
-- Mocking "just to be safe"
-
-## The Bottom Line
-
-**Mocks are tools to isolate, not things to test.**
-
-If TDD reveals you're testing mock behavior, you've gone wrong.
-
-Fix: Test real behavior or question why you're mocking at all.