[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CHX5QE9RHMN4RE84QBXDV3":3,"skill-same:01M6CHX5QE9RHMN4RE84QBXDV3":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":25,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":53,"commitSha":54,"skillDirectory":55,"forksCount":56,"repositoryHtmlUrl":57,"repositoryHomepageUrl":58,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6CHX5QE9RHMN4RE84QBXDV3","test-writer",null,"[ADD v0.11.0] Write failing tests from spec (TDD RED phase)","MountainUnicorn\u002Fadd","MountainUnicorn","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F199411549?v=4","01M6CHRAWFWD275ANP1S2A0HXC","01M6CHRB0QE1678D913B438SAR",11,"MIT","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Ftest-writer\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",[26,27,28,29,30,31,32,33,34,35,36,37,38],"test","test writer","spec","tdd","telemetry","integration","e2e","Bash","Rules","grep","read","write","v0","2026-11-10 10:12:30",false,"---\ndescription: \"[ADD v0.11.0] Write failing tests from spec (TDD RED phase)\"\nargument-hint: \"specs\u002F{feature}.md [--ac AC-001,AC-002] [--type unit|integration|e2e]\"\nallowed-tools: [Read, Write, Glob, Grep, Bash]\nreferences: [\"skill-epilogue.md\", \"rules\u002Ftelemetry.md\"]\n---\n\n# ADD Test Writer Skill v0.11.0\n\nGenerate comprehensive failing tests from a feature specification. This is the RED phase of TDD — write tests before implementation.\n\n## Overview\n\nTest Writer converts acceptance criteria and user test cases from a spec into failing, runnable tests. The output is test files that:\n- Compile and execute but fail (RED state)\n- Have clear, descriptive names mapped to ACs\n- Cover all acceptance criteria and user test cases\n- Follow the project's test conventions\n- Are production-quality (good error messages, clear assertions)\n\n## Pre-Flight Checks\n\n1. **Verify spec file exists and is readable**\n   - Read the spec at the provided path\n   - Extract frontmatter: feature name, version, status\n\n2. **Parse acceptance criteria**\n   - Read the Acceptance Criteria section\n   - Extract each AC with its ID (AC-001, AC-002, etc.)\n   - Extract the criteria description and conditions\n\n3. **Parse user test cases**\n   - Read the User Test Cases section (if present)\n   - Extract each UT with ID (UT-001, UT-002, etc.)\n   - Note the setup, actions, and expected outcomes\n\n4. **Load test framework configuration**\n   - Read .add\u002Fconfig.json\n   - Identify test.framework (jest, pytest, vitest, mocha, pytest, etc.)\n   - Load test.convention (naming pattern, directory structure, imports)\n   - Check test.type to determine default test type\n\n5. **Identify test file location**\n   - Determine target directory from config (typically `tests\u002F` or `__tests__\u002F`)\n   - Determine file naming from convention\n   - Check if test file already exists; if so, append new tests\n\n6. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Analyze Acceptance Criteria\n\nFor each acceptance criterion:\n1. Extract the requirement statement\n2. Break down into testable assertions\n3. Identify input conditions, actions, and expected outputs\n4. Note any data setup required\n5. Consider both happy path and edge cases\n\nExample AC:\n```\nAC-001: When user clicks the \"Submit\" button with valid form data,\n        the form should POST to \u002Fapi\u002Fsubmit and display a success message.\n```\n\nMaps to tests:\n- `test_AC_001_submit_valid_data_posts_to_api`\n- `test_AC_001_submit_valid_data_displays_success_message`\n- `test_AC_001_submit_shows_error_on_network_failure` (edge case)\n\n### Step 2: Design Test Structure\n\nFor each AC, determine:\n1. **Test type** from --type flag or config default\n   - `unit`: Test individual functions\u002Fcomponents in isolation\n   - `integration`: Test feature interactions with other modules\n   - `e2e`: Test complete user workflows end-to-end\n2. **Test scope**: What needs to be mocked vs. real\n3. **Setup requirements**: Fixtures, test data, mocks\n4. **Assertions**: What the test verifies\n\n### Step 3: Generate Test Files\n\nCreate test file(s) following the framework conventions:\n\n**For Jest\u002FVitest (JavaScript\u002FTypeScript):**\n- File: `tests\u002F{feature}.test.ts` or `__tests__\u002F{feature}.test.js`\n- Import testing libraries and mocks\n- Use `describe()` blocks for AC grouping\n- Use `test()` or `it()` for individual test cases\n- Include setup\u002Fteardown with `beforeEach()`, `afterEach()`\n\nExample template:\n```typescript\nimport { describe, it, expect, beforeEach, afterEach } from 'vitest';\n\u002F\u002F imports for module under test\n\ndescribe('Feature Name', () => {\n  describe('AC-001: requirement statement', () => {\n    beforeEach(() => {\n      \u002F\u002F Setup for this AC\n    });\n\n    it('should test specific behavior', () => {\n      \u002F\u002F Arrange\n      const input = { \u002F* test data *\u002F };\n\n      \u002F\u002F Act\n      const result = functionUnderTest(input);\n\n      \u002F\u002F Assert\n      expect(result).toBe(expectedValue);\n    });\n  });\n});\n```\n\n**For pytest (Python):**\n- File: `tests\u002Ftest_{feature}.py`\n- Use `class Test{Feature}:` for grouping by AC\n- Use `def test_ac_NNN_description(self):` for test methods\n- Use `pytest.fixture` for setup\n- Use `assert` statements\n\nExample template:\n```python\nimport pytest\n# imports for module under test\n\nclass TestFeatureName:\n    \"\"\"Tests for Feature Name\"\"\"\n\n    @pytest.fixture\n    def setup(self):\n        # Setup fixture\n        yield\n        # Teardown\n\n    class TestAC001:\n        \"\"\"AC-001: requirement statement\"\"\"\n\n        def test_specific_behavior(self, setup):\n            # Arrange\n            input_data = { \u002F* test data *\u002F }\n\n            # Act\n            result = function_under_test(input_data)\n\n            # Assert\n            assert result == expected_value\n```\n\n### Step 4: Ensure Tests Fail\n\nAfter generating tests:\n1. **Attempt to compile\u002Frun tests**\n   ```bash\n   npm test          # for JavaScript\u002FTypeScript\n   python -m pytest  # for Python\n   ```\n\n2. **Verify they fail with clear messages**\n   - Every test must fail (exit code non-zero)\n   - Error messages should indicate missing implementation\n   - Examples:\n     - \"Cannot find module: '.\u002Ffeature'\" (module doesn't exist)\n     - \"NameError: name 'feature_function' is not defined\"\n     - \"AssertionError: undefined !== 'expected value'\"\n\n3. **If tests don't fail**\n   - Implementation may already exist (unexpected)\n   - Or test is incorrectly written (syntax error)\n   - Fix test syntax errors; if implementation exists, ask user to clarify\n\n### Step 4b: Capture RED snapshot (v0.9.0 — test-deletion guardrail)\n\nBefore returning control to the tdd-cycle orchestrator, capture the test surface\nsnapshot so Gate 3.5 can later detect deletions:\n\n```bash\npython3 ${CLAUDE_PLUGIN_ROOT}\u002F..\u002F..\u002Fscripts\u002Fcheck-test-count.py snapshot \\\n  --phase red \\\n  --cycle-id {N} \\\n  --spec-slug {slug} \\\n  --base-sha {cycle-base-sha} \\\n  --fail-on-empty\n```\n\nRequirements (AC-005, AC-006):\n- The snapshot file MUST be committed before exiting RED\n- Commit message: `test(red): snapshot {total_functions} tests for {slug}`\n- If `--fail-on-empty` reports zero tests, halt with the structured error\n  *\"RED phase produced no failing tests — TDD violation.\"*\n\nThe snapshot lives at `.add\u002Fcycles\u002Fcycle-{N}\u002Ftdd-{slug}-red.json` and captures: test\nfiles, function names, normalized body hashes, language, git base SHA, and phase-end\nSHA. `\u002Fadd:verify` Gate 3.5 reads this file alongside the GREEN snapshot to enforce\nthe test-deletion invariant. See `core\u002Frules\u002Ftdd-enforcement.md`.\n\n### Step 5: Document Test Mapping\n\nCreate a test mapping file: `tests\u002F{feature}-mapping.md`\n\n```markdown\n# Test Mapping for {Feature Name}\n\n## Acceptance Criteria Coverage\n\n| AC ID | Description | Test File | Test Function | Status |\n|-------|-------------|-----------|-----------------|--------|\n| AC-001 | requirement | tests\u002F{feature}.test.ts | test_AC_001_* | ✗ FAIL |\n| AC-002 | requirement | tests\u002F{feature}.test.ts | test_AC_002_* | ✗ FAIL |\n\n## User Test Cases Coverage\n\n| UT ID | Description | Test File | Test Function | Status |\n|-------|-------------|-----------|-----------------|--------|\n| UT-001 | scenario | tests\u002F{feature}.test.ts | test_UT_001_* | ✗ FAIL |\n\n## Notes\n- All tests are currently in RED state (failing)\n- Tests are ready for implementation in GREEN phase\n- No implementation code exists yet\n```\n\n## Test Naming Convention\n\nTests must follow the convention for traceability:\n\n```\ntest_AC_{id}_{description}_{condition}\n```\n\nExamples:\n- `test_AC_001_user_can_submit_valid_form`\n- `test_AC_001_submission_fails_with_empty_email`\n- `test_AC_002_success_message_shows_user_name`\n\n## Test Quality Standards\n\nEach test must:\n1. **Have a single responsibility** — test one behavior\n2. **Be independent** — no dependencies on other tests\n3. **Use clear names** — test name describes what's being tested\n4. **Follow Arrange-Act-Assert pattern**\n   - Arrange: Set up test data and mocks\n   - Act: Call the function or trigger the behavior\n   - Assert: Verify the outcome\n5. **Include setup\u002Fteardown** for dependencies\n6. **Have descriptive error messages** for assertions\n7. **Be fast** — unit tests in milliseconds, integration in seconds\n\n## Output Format\n\nUpon completion, output:\n\n```\n# Test Writing Complete (RED Phase) ✓\n\n## Feature\n{feature-name} v{spec-version}\n\n## Tests Generated\n- Total Tests: {count}\n- By Type:\n  - Unit Tests: {count}\n  - Integration Tests: {count}\n  - E2E Tests: {count}\n- All in RED state (failing as expected)\n\n## Acceptance Criteria Coverage\n- AC-001: ✓ Covered by {N} tests\n- AC-002: ✓ Covered by {N} tests\n... (all ACs listed)\n\n## Test Files Created\n- {test-file-path}\n- {test-file-path}\n\n## Coverage Status\n- Mapping file: tests\u002F{feature}-mapping.md\n- Ready for GREEN phase (implementation)\n\n## Next Steps\n1. Run \u002Fadd:implementer to write minimal code to pass tests\n2. Verify all tests pass\n3. Proceed to REFACTOR phase\n```\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Parse spec | Reading spec and acceptance criteria | Reading spec and acceptance criteria... |\n| Analyze framework | Analyzing test framework configuration | Analyzing test framework configuration... |\n| Write tests | Writing failing tests | Writing failing tests... |\n| Verify RED | Confirming tests fail as expected | Verifying tests fail (RED confirmed)... |\n\n## Error Handling\n\n**Spec parsing fails**\n- Verify spec YAML frontmatter is valid\n- Check AC format matches `AC-###: description`\n- Halt and ask user to fix spec format\n\n**Test file already exists**\n- Append new tests to existing file\n- Don't overwrite; preserve existing tests\n- Report which tests are new\n\n**Tests don't fail when run**\n- This indicates implementation may already exist\n- Verify the module path is correct\n- If implementation exists, ask user if they want to:\n  - Proceed to GREEN\u002FREFACTOR phases\n  - Or start fresh with new test file\n\n**Test framework not installed**\n- Provide guidance: \"Install jest with: npm install --save-dev jest\"\n- Don't halt; user will install and retry\n\n**Syntax errors in generated tests**\n- Review the generated code carefully\n- Fix imports, quotes, formatting\n- Re-run tests to verify they compile\n\n## Integration with TDD Cycle\n\n- This skill is invoked during the RED phase of \u002Fadd:tdd-cycle\n- Output becomes input to \u002Fadd:implementer (GREEN phase)\n- Test mapping is used by \u002Fadd:reviewer to verify spec compliance\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking).\n","# ADD Test Writer Skill v0.11.0\n\nGenerate comprehensive failing tests from a feature specification. This is the RED phase of TDD — write tests before implementation.\n\n## Overview\n\nTest Writer converts acceptance criteria and user test cases from a spec into failing, runnable tests. The output is test files that:\n- Compile and execute but fail (RED state)\n- Have clear, descriptive names mapped to ACs\n- Cover all acceptance criteria and user test cases\n- Follow the project's test conventions\n- Are production-quality (good error messages, clear assertions)\n\n## Pre-Flight Checks\n\n1. **Verify spec file exists and is readable**\n   - Read the spec at the provided path\n   - Extract frontmatter: feature name, version, status\n\n2. **Parse acceptance criteria**\n   - Read the Acceptance Criteria section\n   - Extract each AC with its ID (AC-001, AC-002, etc.)\n   - Extract the criteria description and conditions\n\n3. **Parse user test cases**\n   - Read the User Test Cases section (if present)\n   - Extract each UT with ID (UT-001, UT-002, etc.)\n   - Note the setup, actions, and expected outcomes\n\n4. **Load test framework configuration**\n   - Read .add\u002Fconfig.json\n   - Identify test.framework (jest, pytest, vitest, mocha, pytest, etc.)\n   - Load test.convention (naming pattern, directory structure, imports)\n   - Check test.type to determine default test type\n\n5. **Identify test file location**\n   - Determine target directory from config (typically `tests\u002F` or `__tests__\u002F`)\n   - Determine file naming from convention\n   - Check if test file already exists; if so, append new tests\n\n6. **Check for session handoff** — per the Session-Handoff Preflight in `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`\n\n## Execution Steps\n\n### Step 1: Analyze Acceptance Criteria\n\nFor each acceptance criterion:\n1. Extract the requirement statement\n2. Break down into testable assertions\n3. Identify input conditions, actions, and expected outputs\n4. Note any data setup required\n5. Consider both happy path and edge cases\n\nExample AC:\n```\nAC-001: When user clicks the \"Submit\" button with valid form data,\n        the form should POST to \u002Fapi\u002Fsubmit and display a success message.\n```\n\nMaps to tests:\n- `test_AC_001_submit_valid_data_posts_to_api`\n- `test_AC_001_submit_valid_data_displays_success_message`\n- `test_AC_001_submit_shows_error_on_network_failure` (edge case)\n\n### Step 2: Design Test Structure\n\nFor each AC, determine:\n1. **Test type** from --type flag or config default\n   - `unit`: Test individual functions\u002Fcomponents in isolation\n   - `integration`: Test feature interactions with other modules\n   - `e2e`: Test complete user workflows end-to-end\n2. **Test scope**: What needs to be mocked vs. real\n3. **Setup requirements**: Fixtures, test data, mocks\n4. **Assertions**: What the test verifies\n\n### Step 3: Generate Test Files\n\nCreate test file(s) following the framework conventions:\n\n**For Jest\u002FVitest (JavaScript\u002FTypeScript):**\n- File: `tests\u002F{feature}.test.ts` or `__tests__\u002F{feature}.test.js`\n- Import testing libraries and mocks\n- Use `describe()` blocks for AC grouping\n- Use `test()` or `it()` for individual test cases\n- Include setup\u002Fteardown with `beforeEach()`, `afterEach()`\n\nExample template:\n```typescript\nimport { describe, it, expect, beforeEach, afterEach } from 'vitest';\n\u002F\u002F imports for module under test\n\ndescribe('Feature Name', () => {\n  describe('AC-001: requirement statement', () => {\n    beforeEach(() => {\n      \u002F\u002F Setup for this AC\n    });\n\n    it('should test specific behavior', () => {\n      \u002F\u002F Arrange\n      const input = { \u002F* test data *\u002F };\n\n      \u002F\u002F Act\n      const result = functionUnderTest(input);\n\n      \u002F\u002F Assert\n      expect(result).toBe(expectedValue);\n    });\n  });\n});\n```\n\n**For pytest (Python):**\n- File: `tests\u002Ftest_{feature}.py`\n- Use `class Test{Feature}:` for grouping by AC\n- Use `def test_ac_NNN_description(self):` for test methods\n- Use `pytest.fixture` for setup\n- Use `assert` statements\n\nExample template:\n```python\nimport pytest\n# imports for module under test\n\nclass TestFeatureName:\n    \"\"\"Tests for Feature Name\"\"\"\n\n    @pytest.fixture\n    def setup(self):\n        # Setup fixture\n        yield\n        # Teardown\n\n    class TestAC001:\n        \"\"\"AC-001: requirement statement\"\"\"\n\n        def test_specific_behavior(self, setup):\n            # Arrange\n            input_data = { \u002F* test data *\u002F }\n\n            # Act\n            result = function_under_test(input_data)\n\n            # Assert\n            assert result == expected_value\n```\n\n### Step 4: Ensure Tests Fail\n\nAfter generating tests:\n1. **Attempt to compile\u002Frun tests**\n   ```bash\n   npm test          # for JavaScript\u002FTypeScript\n   python -m pytest  # for Python\n   ```\n\n2. **Verify they fail with clear messages**\n   - Every test must fail (exit code non-zero)\n   - Error messages should indicate missing implementation\n   - Examples:\n     - \"Cannot find module: '.\u002Ffeature'\" (module doesn't exist)\n     - \"NameError: name 'feature_function' is not defined\"\n     - \"AssertionError: undefined !== 'expected value'\"\n\n3. **If tests don't fail**\n   - Implementation may already exist (unexpected)\n   - Or test is incorrectly written (syntax error)\n   - Fix test syntax errors; if implementation exists, ask user to clarify\n\n### Step 4b: Capture RED snapshot (v0.9.0 — test-deletion guardrail)\n\nBefore returning control to the tdd-cycle orchestrator, capture the test surface\nsnapshot so Gate 3.5 can later detect deletions:\n\n```bash\npython3 ${CLAUDE_PLUGIN_ROOT}\u002F..\u002F..\u002Fscripts\u002Fcheck-test-count.py snapshot \\\n  --phase red \\\n  --cycle-id {N} \\\n  --spec-slug {slug} \\\n  --base-sha {cycle-base-sha} \\\n  --fail-on-empty\n```\n\nRequirements (AC-005, AC-006):\n- The snapshot file MUST be committed before exiting RED\n- Commit message: `test(red): snapshot {total_functions} tests for {slug}`\n- If `--fail-on-empty` reports zero tests, halt with the structured error\n  *\"RED phase produced no failing tests — TDD violation.\"*\n\nThe snapshot lives at `.add\u002Fcycles\u002Fcycle-{N}\u002Ftdd-{slug}-red.json` and captures: test\nfiles, function names, normalized body hashes, language, git base SHA, and phase-end\nSHA. `\u002Fadd:verify` Gate 3.5 reads this file alongside the GREEN snapshot to enforce\nthe test-deletion invariant. See `core\u002Frules\u002Ftdd-enforcement.md`.\n\n### Step 5: Document Test Mapping\n\nCreate a test mapping file: `tests\u002F{feature}-mapping.md`\n\n```markdown\n# Test Mapping for {Feature Name}\n\n## Acceptance Criteria Coverage\n\n| AC ID | Description | Test File | Test Function | Status |\n|-------|-------------|-----------|-----------------|--------|\n| AC-001 | requirement | tests\u002F{feature}.test.ts | test_AC_001_* | ✗ FAIL |\n| AC-002 | requirement | tests\u002F{feature}.test.ts | test_AC_002_* | ✗ FAIL |\n\n## User Test Cases Coverage\n\n| UT ID | Description | Test File | Test Function | Status |\n|-------|-------------|-----------|-----------------|--------|\n| UT-001 | scenario | tests\u002F{feature}.test.ts | test_UT_001_* | ✗ FAIL |\n\n## Notes\n- All tests are currently in RED state (failing)\n- Tests are ready for implementation in GREEN phase\n- No implementation code exists yet\n```\n\n## Test Naming Convention\n\nTests must follow the convention for traceability:\n\n```\ntest_AC_{id}_{description}_{condition}\n```\n\nExamples:\n- `test_AC_001_user_can_submit_valid_form`\n- `test_AC_001_submission_fails_with_empty_email`\n- `test_AC_002_success_message_shows_user_name`\n\n## Test Quality Standards\n\nEach test must:\n1. **Have a single responsibility** — test one behavior\n2. **Be independent** — no dependencies on other tests\n3. **Use clear names** — test name describes what's being tested\n4. **Follow Arrange-Act-Assert pattern**\n   - Arrange: Set up test data and mocks\n   - Act: Call the function or trigger the behavior\n   - Assert: Verify the outcome\n5. **Include setup\u002Fteardown** for dependencies\n6. **Have descriptive error messages** for assertions\n7. **Be fast** — unit tests in milliseconds, integration in seconds\n\n## Output Format\n\nUpon completion, output:\n\n```\n# Test Writing Complete (RED Phase) ✓\n\n## Feature\n{feature-name} v{spec-version}\n\n## Tests Generated\n- Total Tests: {count}\n- By Type:\n  - Unit Tests: {count}\n  - Integration Tests: {count}\n  - E2E Tests: {count}\n- All in RED state (failing as expected)\n\n## Acceptance Criteria Coverage\n- AC-001: ✓ Covered by {N} tests\n- AC-002: ✓ Covered by {N} tests\n... (all ACs listed)\n\n## Test Files Created\n- {test-file-path}\n- {test-file-path}\n\n## Coverage Status\n- Mapping file: tests\u002F{feature}-mapping.md\n- Ready for GREEN phase (implementation)\n\n## Next Steps\n1. Run \u002Fadd:implementer to write minimal code to pass tests\n2. Verify all tests pass\n3. Proceed to REFACTOR phase\n```\n\n## Progress Tracking\n\n**Tasks to create** (mechanics per `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md`):\n\n| Phase | Subject | activeForm |\n|-------|---------|------------|\n| Parse spec | Reading spec and acceptance criteria | Reading spec and acceptance criteria... |\n| Analyze framework | Analyzing test framework configuration | Analyzing test framework configuration... |\n| Write tests | Writing failing tests | Writing failing tests... |\n| Verify RED | Confirming tests fail as expected | Verifying tests fail (RED confirmed)... |\n\n## Error Handling\n\n**Spec parsing fails**\n- Verify spec YAML frontmatter is valid\n- Check AC format matches `AC-###: description`\n- Halt and ask user to fix spec format\n\n**Test file already exists**\n- Append new tests to existing file\n- Don't overwrite; preserve existing tests\n- Report which tests are new\n\n**Tests don't fail when run**\n- This indicates implementation may already exist\n- Verify the module path is correct\n- If implementation exists, ask user if they want to:\n  - Proceed to GREEN\u002FREFACTOR phases\n  - Or start fresh with new test file\n\n**Test framework not installed**\n- Provide guidance: \"Install jest with: npm install --save-dev jest\"\n- Don't halt; user will install and retry\n\n**Syntax errors in generated tests**\n- Review the generated code carefully\n- Fix imports, quotes, formatting\n- Re-run tests to verify they compile\n\n## Integration with TDD Cycle\n\n- This skill is invoked during the RED phase of \u002Fadd:tdd-cycle\n- Output becomes input to \u002Fadd:implementer (GREEN phase)\n- Test mapping is used by \u002Fadd:reviewer to verify spec compliance\n\nEnd-of-skill epilogue: follow `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fskill-epilogue.md` (observation + learning checkpoint + progress tracking).\n",{"references":44,"description":7,"allowed-tools":47,"argument-hint":52},[45,46],"skill-epilogue.md","rules\u002Ftelemetry.md",[48,49,50,51,33],"Read","Write","Glob","Grep","specs\u002F{feature}.md [--ac AC-001,AC-002] [--type unit|integration|e2e]","main","e335248c85d50f73919320bc138766eb413c5ee3","plugins\u002Fadd\u002Fskills\u002Ftest-writer",6,"https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd","https:\u002F\u002Fgetadd.dev","https:\u002F\u002Fgithub.com\u002FMountainUnicorn","2026-10-31 22:03:50",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add MountainUnicorn\u002Fadd --skill test-writer",{"tool":67,"command":68},"bunx","bunx skills add MountainUnicorn\u002Fadd --skill test-writer",{"tool":70,"command":71},"pnpm","pnpm dlx skills add MountainUnicorn\u002Fadd --skill test-writer","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Ftest-writer\u002FSKILL.md",true,[],[76,84,89,94,104,131],{"skillNo":77,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":39},"01M6CHXN68ZCGNXE9Q0K2T2RKX","add-verify","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-modified\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[82,83],"add verify","verify",{"skillNo":85,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":39},"01M6CHXJY4ZXKTNP0235A9KTNH","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fmanifest-missing\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[82,83],{"skillNo":90,"name":78,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":39},"01M6CHXG6NV1DBMWT2N6XE5555","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Ftests\u002Fhooks\u002Ffixtures\u002Fdoctor\u002Fhealthy\u002Fskills\u002Fadd-verify\u002FSKILL.md",[],[82,83],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":39},"01M6CHXDZFPEFBZ79GHP48S1BB","version","[ADD v0.11.0] Show installed version, project version, and upgrade status","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fversion\u002FSKILL.md",[],[96,35,101,30,33,34,102,36,38,103],"status","check","show",{"skillNo":105,"name":83,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":118,"publishedAt":39},"01M6CHXB5XG415PP88E0GACHP8","[ADD v0.11.0] Run quality gates — lint, types, tests, coverage, spec compliance","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fverify\u002FSKILL.md",[109,112,113],{"categoryNo":110,"categoryName":111,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[83,35,36,119,120,38,121,122,34,30,28,123,124,125,126,127,128,33,129,130],"coverage","fix","smoke","gate","quality gates","run","lint","ci","compliance","secrets","learning","quality",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":144,"publishedAt":39},"01M6CHX8JF3M3J8BKTBW604D37","ux","[ADD v0.11.0] Iterate on UI\u002FUX design before implementation — wireframes, flow validation, and design sign-off","https:\u002F\u002Fgithub.com\u002FMountainUnicorn\u002Fadd\u002Fblob\u002Fmain\u002Fplugins\u002Fadd\u002Fskills\u002Fux\u002FSKILL.md",[137,140,141],{"categoryNo":138,"categoryName":139,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},{"categoryNo":142,"categoryName":143,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000032","设计师",[133,145,146,147,148,30,28,33,149,34,35,36,37,150,38,151,152,153,154],"ui","file","figma","validation","system","edit","design-system","implementation","flow","design"]