rebar-mcp 2.0.0 → 2.2.0

package/.claude/skills/{bmmibwetxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx → bmmoseokfxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bmmibwetxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+name: bmmoseokfxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 description: A test skill
 invocation: undefined
 context: undefined
 ---
 
-# bmmibwetxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+# bmmoseokfxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 A test skill
 

package/.claude/skills/{bmmibwjgvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx → bmmosewq3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bmmibwjgvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+name: bmmosewq3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 description: A test skill
 invocation: undefined
 context: undefined
 ---
 
-# bmmibwjgvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+# bmmosewq3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 A test skill
 

package/.claude/skills/{bmmibwsesxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx → bmmosf3hvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bmmibwsesxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+name: bmmosf3hvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 description: A test skill
 invocation: undefined
 context: undefined
 ---
 
-# bmmibwsesxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+# bmmosf3hvxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 A test skill
 

package/.claude/skills/{bmmibwxufxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx → bmmosfe4bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bmmibwxufxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+name: bmmosfe4bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 description: A test skill
 invocation: undefined
 context: undefined
 ---
 
-# bmmibwxufxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+# bmmosfe4bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
 
 A test skill
 

package/.claude/skills/bmmous2g0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: bmmous2g0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+description: A test skill
+invocation: undefined
+context: undefined
+---
+
+# bmmous2g0xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
+
+A test skill
+
+## Instructions
+
+<!-- Replace this with your skill instructions.
+Good skill instructions:
+1. Define the agent's role clearly
+2. Specify the exact output format
+3. List what to check/do step by step
+4. Include examples of good output
+-->
+

package/.claude/skills/{bnd-mmibweu3 → bnd-mmoseokj}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bnd-mmibweu3
+name: bnd-mmoseokj
 description: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 invocation: undefined
 context: undefined
 ---
 
-# bnd-mmibweu3
+# bnd-mmoseokj
 
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 

package/.claude/skills/{bnd-mmibwjh4 → bnd-mmosewq9}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bnd-mmibwjh4
+name: bnd-mmosewq9
 description: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 invocation: undefined
 context: undefined
 ---
 
-# bnd-mmibwjh4
+# bnd-mmosewq9
 
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 

package/.claude/skills/{bnd-mmibwsey → bnd-mmosf3i0}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bnd-mmibwsey
+name: bnd-mmosf3i0
 description: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 invocation: undefined
 context: undefined
 ---
 
-# bnd-mmibwsey
+# bnd-mmosf3i0
 
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 

package/.claude/skills/{bnd-mmibwxup → bnd-mmosfe4f}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: bnd-mmibwxup
+name: bnd-mmosfe4f
 description: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 invocation: undefined
 context: undefined
 ---
 
-# bnd-mmibwxup
+# bnd-mmosfe4f
 
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 

package/.claude/skills/bnd-mmous2g4/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: bnd-mmous2g4
+description: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+invocation: undefined
+context: undefined
+---
+
+# bnd-mmous2g4
+
+aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
+
+## Instructions
+
+<!-- Replace this with your skill instructions.
+Good skill instructions:
+1. Define the agent's role clearly
+2. Specify the exact output format
+3. List what to check/do step by step
+4. Include examples of good output
+-->
+

package/.claude/skills/{nl-mmibweus → nl-mmoseoky}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: nl-mmibweus
+name: nl-mmoseoky
 description: Line one
 Line two
 Line three
@@ -7,7 +7,7 @@ invocation: undefined
 context: undefined
 ---
 
-# nl-mmibweus
+# nl-mmoseoky
 
 Line one
 Line two

package/.claude/skills/{nl-mmibwjhf → nl-mmosewqr}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: nl-mmibwjhf
+name: nl-mmosewqr
 description: Line one
 Line two
 Line three
@@ -7,7 +7,7 @@ invocation: undefined
 context: undefined
 ---
 
-# nl-mmibwjhf
+# nl-mmosewqr
 
 Line one
 Line two

package/.claude/skills/{nl-mmibwsf7 → nl-mmosf3i7}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: nl-mmibwsf7
+name: nl-mmosf3i7
 description: Line one
 Line two
 Line three
@@ -7,7 +7,7 @@ invocation: undefined
 context: undefined
 ---
 
-# nl-mmibwsf7
+# nl-mmosf3i7
 
 Line one
 Line two

package/.claude/skills/{nl-mmibwxvq → nl-mmosfe4m}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: nl-mmibwxvq
+name: nl-mmosfe4m
 description: Line one
 Line two
 Line three
@@ -7,7 +7,7 @@ invocation: undefined
 context: undefined
 ---
 
-# nl-mmibwxvq
+# nl-mmosfe4m
 
 Line one
 Line two

package/.claude/skills/nl-mmous2gc/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: nl-mmous2gc
+description: Line one
+Line two
+Line three
+invocation: undefined
+context: undefined
+---
+
+# nl-mmous2gc
+
+Line one
+Line two
+Line three
+
+## Instructions
+
+<!-- Replace this with your skill instructions.
+Good skill instructions:
+1. Define the agent's role clearly
+2. Specify the exact output format
+3. List what to check/do step by step
+4. Include examples of good output
+-->
+

package/.claude/skills/test/", /"malicious/": /"true/SKILL.md"

@@ -5,65 +5,46 @@ invocation: undefined
 context: undefined
 ---
 
-## Test Writing Process
-
-### Step 1: Analyze What Needs Testing
-- Read the function/module signature, parameters, and return type
-- Identify the happy path (normal successful execution)
-- Identify error paths (what can go wrong?)
-- Identify edge cases (empty input, null, boundary values, max values)
-- Identify integration points (database calls, API calls, file system)
-
-### Step 2: Write Tests in This Order
-
-1. **Happy path test** — The most basic successful case
-2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
-3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
-4. **Error handling tests** — Network failures, database errors, file not found
-5. **Integration tests** — Full request/response cycle (if applicable)
-
-### Step 3: Test Structure
-
-Every test MUST follow this structure:
-
-```
-// Descriptive name that explains what is being tested and expected outcome
-test("createUser returns the created user with a generated ID when given valid input", async () => {
-  // ARRANGE: Set up test data and dependencies
-  const input = { name: "Test User", email: "test@example.com" };
-
-  // ACT: Execute the function under test
-  const result = await createUser(input);
-
-  // ASSERT: Verify the outcome
-  expect(result.id).toBeDefined();
-  expect(result.name).toBe("Test User");
-  expect(result.email).toBe("test@example.com");
-});
-```
-
-### Mandatory Test Categories
-
-For EVERY function, write tests covering:
-
-| Category | Example | Required? |
-|---|---|---|
-| Valid input, expected output | Normal successful operation | ALWAYS |
-| Missing required field | Omit a required parameter | ALWAYS |
-| Invalid type | Pass string where number expected | ALWAYS |
-| Empty input | Empty string, empty array, null | ALWAYS |
-| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
-| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
-| Not found | Requesting something that does not exist | WHEN APPLICABLE |
-| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
-| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
-| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
-
-### Rules
-- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
-- NEVER test implementation details — test behavior and outcomes
-- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
-- EVERY test must be independent — no test should depend on another test running first
-- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
-- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
-- NEVER write a test that always passes — verify your test fails before the implementation exists
+# Test Writer
+
+You write tests that catch real bugs, not tests that just check if the code runs.
+
+## Before Writing
+
+1. **Read existing tests** — find 2-3 test files to understand:
+   - Which testing framework (Jest, Vitest, pytest, JUnit, etc.)
+   - Test file naming convention (`.test.ts`, `.spec.ts`, `_test.go`, etc.)
+   - Test location (colocated vs. `__tests__/` vs. `test/`)
+   - Mocking patterns used (jest.mock, vi.mock, unittest.mock, etc.)
+   - Setup/teardown patterns (beforeEach, fixtures, etc.)
+
+2. **Read the code under test** — understand:
+   - All public functions and their signatures
+   - Edge cases: What happens with null/undefined/empty/zero/negative inputs?
+   - Error paths: What exceptions can be thrown?
+   - Side effects: Database calls, API calls, file system operations
+
+## Test Writing Rules
+
+### Coverage Strategy
+- **Happy path**: Normal inputs produce expected outputs
+- **Edge cases**: Empty strings, empty arrays, zero, negative numbers, max values
+- **Error cases**: Invalid inputs, network failures, permission errors
+- **Boundary conditions**: First item, last item, exactly at limits
+
+### Quality Standards
+- Each test has a descriptive name: `"returns empty array when user has no orders"`
+- One assertion per concept (not one assertion per test)
+- Tests are independent — no test relies on another test's side effects
+- Mock external dependencies (APIs, databases) — never make real calls
+- Use factories/fixtures for complex test data
+
+### Anti-Patterns to Avoid
+- Testing implementation details (internal method calls, private state)
+- Snapshot tests for logic (only use for UI rendering)
+- Tests that pass when the code is broken
+- Copy-pasting the implementation as the expected value
+
+## Output
+Place test files where the project convention expects them.
+Run the tests after writing to verify they pass.

package/.claude/skills/test-emoji-/360/237/230/200-skill/SKILL.md

@@ -5,65 +5,46 @@ invocation: undefined
 context: undefined
 ---
 
-## Test Writing Process
-
-### Step 1: Analyze What Needs Testing
-- Read the function/module signature, parameters, and return type
-- Identify the happy path (normal successful execution)
-- Identify error paths (what can go wrong?)
-- Identify edge cases (empty input, null, boundary values, max values)
-- Identify integration points (database calls, API calls, file system)
-
-### Step 2: Write Tests in This Order
-
-1. **Happy path test** — The most basic successful case
-2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
-3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
-4. **Error handling tests** — Network failures, database errors, file not found
-5. **Integration tests** — Full request/response cycle (if applicable)
-
-### Step 3: Test Structure
-
-Every test MUST follow this structure:
-
-```
-// Descriptive name that explains what is being tested and expected outcome
-test("createUser returns the created user with a generated ID when given valid input", async () => {
-  // ARRANGE: Set up test data and dependencies
-  const input = { name: "Test User", email: "test@example.com" };
-
-  // ACT: Execute the function under test
-  const result = await createUser(input);
-
-  // ASSERT: Verify the outcome
-  expect(result.id).toBeDefined();
-  expect(result.name).toBe("Test User");
-  expect(result.email).toBe("test@example.com");
-});
-```
-
-### Mandatory Test Categories
-
-For EVERY function, write tests covering:
-
-| Category | Example | Required? |
-|---|---|---|
-| Valid input, expected output | Normal successful operation | ALWAYS |
-| Missing required field | Omit a required parameter | ALWAYS |
-| Invalid type | Pass string where number expected | ALWAYS |
-| Empty input | Empty string, empty array, null | ALWAYS |
-| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
-| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
-| Not found | Requesting something that does not exist | WHEN APPLICABLE |
-| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
-| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
-| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
-
-### Rules
-- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
-- NEVER test implementation details — test behavior and outcomes
-- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
-- EVERY test must be independent — no test should depend on another test running first
-- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
-- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
-- NEVER write a test that always passes — verify your test fails before the implementation exists
+# Test Writer
+
+You write tests that catch real bugs, not tests that just check if the code runs.
+
+## Before Writing
+
+1. **Read existing tests** — find 2-3 test files to understand:
+   - Which testing framework (Jest, Vitest, pytest, JUnit, etc.)
+   - Test file naming convention (`.test.ts`, `.spec.ts`, `_test.go`, etc.)
+   - Test location (colocated vs. `__tests__/` vs. `test/`)
+   - Mocking patterns used (jest.mock, vi.mock, unittest.mock, etc.)
+   - Setup/teardown patterns (beforeEach, fixtures, etc.)
+
+2. **Read the code under test** — understand:
+   - All public functions and their signatures
+   - Edge cases: What happens with null/undefined/empty/zero/negative inputs?
+   - Error paths: What exceptions can be thrown?
+   - Side effects: Database calls, API calls, file system operations
+
+## Test Writing Rules
+
+### Coverage Strategy
+- **Happy path**: Normal inputs produce expected outputs
+- **Edge cases**: Empty strings, empty arrays, zero, negative numbers, max values
+- **Error cases**: Invalid inputs, network failures, permission errors
+- **Boundary conditions**: First item, last item, exactly at limits
+
+### Quality Standards
+- Each test has a descriptive name: `"returns empty array when user has no orders"`
+- One assertion per concept (not one assertion per test)
+- Tests are independent — no test relies on another test's side effects
+- Mock external dependencies (APIs, databases) — never make real calls
+- Use factories/fixtures for complex test data
+
+### Anti-Patterns to Avoid
+- Testing implementation details (internal method calls, private state)
+- Snapshot tests for logic (only use for UI rendering)
+- Tests that pass when the code is broken
+- Copy-pasting the implementation as the expected value
+
+## Output
+Place test files where the project convention expects them.
+Run the tests after writing to verify they pass.

package/.claude/skills/test-skill/SKILL.md

@@ -5,65 +5,46 @@ invocation: undefined
 context: undefined
 ---
 
-## Test Writing Process
-
-### Step 1: Analyze What Needs Testing
-- Read the function/module signature, parameters, and return type
-- Identify the happy path (normal successful execution)
-- Identify error paths (what can go wrong?)
-- Identify edge cases (empty input, null, boundary values, max values)
-- Identify integration points (database calls, API calls, file system)
-
-### Step 2: Write Tests in This Order
-
-1. **Happy path test** — The most basic successful case
-2. **Input validation tests** — Invalid inputs, missing required fields, wrong types
-3. **Edge case tests** — Empty arrays, zero values, very long strings, special characters
-4. **Error handling tests** — Network failures, database errors, file not found
-5. **Integration tests** — Full request/response cycle (if applicable)
-
-### Step 3: Test Structure
-
-Every test MUST follow this structure:
-
-```
-// Descriptive name that explains what is being tested and expected outcome
-test("createUser returns the created user with a generated ID when given valid input", async () => {
-  // ARRANGE: Set up test data and dependencies
-  const input = { name: "Test User", email: "test@example.com" };
-
-  // ACT: Execute the function under test
-  const result = await createUser(input);
-
-  // ASSERT: Verify the outcome
-  expect(result.id).toBeDefined();
-  expect(result.name).toBe("Test User");
-  expect(result.email).toBe("test@example.com");
-});
-```
-
-### Mandatory Test Categories
-
-For EVERY function, write tests covering:
-
-| Category | Example | Required? |
-|---|---|---|
-| Valid input, expected output | Normal successful operation | ALWAYS |
-| Missing required field | Omit a required parameter | ALWAYS |
-| Invalid type | Pass string where number expected | ALWAYS |
-| Empty input | Empty string, empty array, null | ALWAYS |
-| Boundary values | 0, -1, MAX_INT, very long string | WHEN APPLICABLE |
-| Duplicate/conflict | Creating something that already exists | WHEN APPLICABLE |
-| Not found | Requesting something that does not exist | WHEN APPLICABLE |
-| Unauthorized | Accessing without proper permissions | WHEN AUTH EXISTS |
-| Concurrent access | Two operations on same resource | WHEN APPLICABLE |
-| Error recovery | Service dependency fails | WHEN EXTERNAL DEPS EXIST |
-
-### Rules
-- Test file names MUST match source file: `user.service.ts` → `user.service.test.ts`
-- NEVER test implementation details — test behavior and outcomes
-- NEVER use `test("should work")` — test names must describe the specific scenario and expected outcome
-- EVERY test must be independent — no test should depend on another test running first
-- ALWAYS clean up test data (use beforeEach/afterEach or setup/teardown)
-- Mock external dependencies (databases, APIs, file system) — do not make real network calls in unit tests
-- NEVER write a test that always passes — verify your test fails before the implementation exists
+# Test Writer
+
+You write tests that catch real bugs, not tests that just check if the code runs.
+
+## Before Writing
+
+1. **Read existing tests** — find 2-3 test files to understand:
+   - Which testing framework (Jest, Vitest, pytest, JUnit, etc.)
+   - Test file naming convention (`.test.ts`, `.spec.ts`, `_test.go`, etc.)
+   - Test location (colocated vs. `__tests__/` vs. `test/`)
+   - Mocking patterns used (jest.mock, vi.mock, unittest.mock, etc.)
+   - Setup/teardown patterns (beforeEach, fixtures, etc.)
+
+2. **Read the code under test** — understand:
+   - All public functions and their signatures
+   - Edge cases: What happens with null/undefined/empty/zero/negative inputs?
+   - Error paths: What exceptions can be thrown?
+   - Side effects: Database calls, API calls, file system operations
+
+## Test Writing Rules
+
+### Coverage Strategy
+- **Happy path**: Normal inputs produce expected outputs
+- **Edge cases**: Empty strings, empty arrays, zero, negative numbers, max values
+- **Error cases**: Invalid inputs, network failures, permission errors
+- **Boundary conditions**: First item, last item, exactly at limits
+
+### Quality Standards
+- Each test has a descriptive name: `"returns empty array when user has no orders"`
+- One assertion per concept (not one assertion per test)
+- Tests are independent — no test relies on another test's side effects
+- Mock external dependencies (APIs, databases) — never make real calls
+- Use factories/fixtures for complex test data
+
+### Anti-Patterns to Avoid
+- Testing implementation details (internal method calls, private state)
+- Snapshot tests for logic (only use for UI rendering)
+- Tests that pass when the code is broken
+- Copy-pasting the implementation as the expected value
+
+## Output
+Place test files where the project convention expects them.
+Run the tests after writing to verify they pass.