[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CP2F6BSAPF0F7G5K4VWMMA":3,"skill-same:01M6CP2F6BSAPF0F7G5K4VWMMA":78},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":57,"install":58,"resources":71},"01M6CP2F6BSAPF0F7G5K4VWMMA","tdd",null,"Enforces strict test-driven development -- write a failing test first, implement minimal code to pass, then refactor. Use when implementing a feature, fixing a bug, adding behavior, refactoring, or any time production code will be written or changed. Also use when the user says \"write tests\", \"add tests\", \"TDD\", or \"test first\". DO NOT TRIGGER for throwaway prototypes, generated code, or config-only changes unless the user explicitly requests TDD.","shousper\u002Fclanker-kit","shousper","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1144345?v=4","01M6CP153W30NV9J1XT8K98G4J","Corey McGregor","01M6CP157WFP2WEFX4TJH7JVPG",5,"MIT","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Ftdd\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[5,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"do","implement","bug","minimal","only","use","generated","user","behavior","write","refactoring","first","refactor","Production","code","development","config","write tests","test","2026-11-10 10:12:30",false,"---\nname: tdd\ndescription: Enforces strict test-driven development -- write a failing test first, implement minimal code to pass, then refactor. Use when implementing a feature, fixing a bug, adding behavior, refactoring, or any time production code will be written or changed. Also use when the user says \"write tests\", \"add tests\", \"TDD\", or \"test first\". DO NOT TRIGGER for throwaway prototypes, generated code, or config-only changes unless the user explicitly requests TDD.\n---\n\n# Test-Driven Development (TDD)\n\n## Overview\n\nWrite the test first. Watch it fail. Write minimal code to pass.\n\n**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.\n\n## When to Use\n\n**Always:**\n- New features\n- Bug fixes\n- Refactoring\n- Behavior changes\n\n**Exceptions (ask your human partner):**\n- Throwaway prototypes\n- Generated code\n- Configuration files\n\n## Hard Gate: No Production Code Without a Failing Test First\n\nWrite code before the test? Delete it and start over.\n\nThis is the one rule that cannot bend. Code written before a test is untestable by definition — you've already been influenced by the implementation. Keeping it \"as reference\" or \"adapting\" it while writing tests means the tests describe what you built, not what you need. The test can't catch bugs in logic you've already committed to.\n\nDelete means delete. Implement fresh from tests.\n\n## Red-Green-Refactor\n\n```dot\ndigraph tdd_cycle {\n    rankdir=LR;\n    red [label=\"RED\\nWrite failing test\", shape=box, style=filled, fillcolor=\"#ffcccc\"];\n    verify_red [label=\"Verify fails\\ncorrectly\", shape=diamond];\n    green [label=\"GREEN\\nMinimal code\", shape=box, style=filled, fillcolor=\"#ccffcc\"];\n    verify_green [label=\"Verify passes\\nAll green\", shape=diamond];\n    refactor [label=\"REFACTOR\\nClean up\", shape=box, style=filled, fillcolor=\"#ccccff\"];\n    next [label=\"Next\", shape=ellipse];\n\n    red -> verify_red;\n    verify_red -> green [label=\"yes\"];\n    verify_red -> red [label=\"wrong\\nfailure\"];\n    green -> verify_green;\n    verify_green -> refactor [label=\"yes\"];\n    verify_green -> green [label=\"no\"];\n    refactor -> verify_green [label=\"stay\\ngreen\"];\n    verify_green -> next;\n    next -> red;\n}\n```\n\n### RED - Write Failing Test\n\nWrite one minimal test showing what should happen.\n\n\u003CGood>\n```typescript\ntest('retries failed operations 3 times', async () => {\n  let attempts = 0;\n  const operation = () => {\n    attempts++;\n    if (attempts \u003C 3) throw new Error('fail');\n    return 'success';\n  };\n\n  const result = await retryOperation(operation);\n\n  expect(result).toBe('success');\n  expect(attempts).toBe(3);\n});\n```\nClear name, tests real behavior, one thing\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\ntest('retry works', async () => {\n  const mock = jest.fn()\n    .mockRejectedValueOnce(new Error())\n    .mockRejectedValueOnce(new Error())\n    .mockResolvedValueOnce('success');\n  await retryOperation(mock);\n  expect(mock).toHaveBeenCalledTimes(3);\n});\n```\nVague name, tests mock not code\n\u003C\u002FBad>\n\n**Requirements:**\n- One behavior\n- Clear name\n- Real code (no mocks unless unavoidable)\n\n### Verify RED - Watch It Fail\n\nRun the test before writing any implementation. A test you haven't watched fail could be testing the wrong thing, passing for the wrong reason, or not exercising the code path you think it does.\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm:\n- Test fails (not errors)\n- Failure message is expected\n- Fails because feature missing (not typos)\n\n**Test passes?** You're testing existing behavior. Fix test.\n\n**Test errors?** Fix error, re-run until it fails correctly.\n\n### GREEN - Minimal Code\n\nWrite simplest code to pass the test.\n\n\u003CGood>\n```typescript\nasync function retryOperation\u003CT>(fn: () => Promise\u003CT>): Promise\u003CT> {\n  for (let i = 0; i \u003C 3; i++) {\n    try {\n      return await fn();\n    } catch (e) {\n      if (i === 2) throw e;\n    }\n  }\n  throw new Error('unreachable');\n}\n```\nJust enough to pass\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\nasync function retryOperation\u003CT>(\n  fn: () => Promise\u003CT>,\n  options?: {\n    maxRetries?: number;\n    backoff?: 'linear' | 'exponential';\n    onRetry?: (attempt: number) => void;\n  }\n): Promise\u003CT> {\n  \u002F\u002F YAGNI\n}\n```\nOver-engineered\n\u003C\u002FBad>\n\nDon't add features, refactor other code, or \"improve\" beyond the test.\n\n### Verify GREEN - Watch It Pass\n\nRun the test again after implementation. This confirms the code actually satisfies the test, not just that it compiles. It also catches regressions in other tests.\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm:\n- Test passes\n- Other tests still pass\n- Output pristine (no errors, warnings)\n\n**Test fails?** Fix code, not test.\n\n**Other tests fail?** Fix now.\n\n### REFACTOR - Clean Up\n\nAfter green only:\n- Remove duplication\n- Improve names\n- Extract helpers\n\nKeep tests green. Don't add behavior.\n\n### Repeat\n\nNext failing test for next feature.\n\n## Good Tests\n\n| Quality | Good | Bad |\n|---------|------|-----|\n| **Minimal** | One thing. \"and\" in name? Split it. | `test('validates email and domain and whitespace')` |\n| **Clear** | Name describes behavior | `test('test1')` |\n| **Shows intent** | Demonstrates desired API | Obscures what code should do |\n\n## Why Order Matters\n\nThe distinction between test-first and test-after isn't ritual — it changes what the tests prove.\n\n**Tests written after code pass immediately.** A test that has never failed proves nothing: it might test the wrong thing, test implementation details instead of behavior, or miss edge cases you forgot. Watching a test fail first proves it actually detects the absence of the feature.\n\n**\"I already manually tested all the edge cases\"** — Manual testing is ad-hoc. There's no record of what you tested, it can't be re-run when code changes, and it's easy to forget cases under pressure. Automated tests are systematic and repeatable.\n\n**\"Deleting X hours of work is wasteful\"** — The time is already gone (sunk cost). The real waste is keeping code you can't trust. Rewriting with TDD takes comparable time but produces code backed by tests that have proven they catch failures.\n\n**\"TDD is dogmatic, being pragmatic means adapting\"** — TDD is the pragmatic choice. It finds bugs before commit, prevents regressions, documents behavior, and enables safe refactoring. Skipping it means debugging in production, which is slower.\n\n**\"Tests after achieve the same goals\"** — Tests-after answer \"what does this code do?\" Tests-first answer \"what should this code do?\" Tests-after are biased by your implementation — you test what you built, not what's required. Tests-first force edge case discovery before implementing.\n\n## Recognizing When You've Left TDD\n\nThese patterns indicate the test-first cycle has been broken. When you notice one, return to the hard gate: delete implementation code and start from a failing test.\n\n- Code written before test\n- Test written after implementation\n- Test passes immediately (never failed)\n- Can't explain why test failed\n- Tests deferred to \"later\"\n- Rationalizing \"just this once\"\n- Keeping implementation code \"as reference\"\n\n| Common excuse | Why it doesn't hold |\n|---------------|---------------------|\n| \"Too simple to test\" | Simple code breaks too, and the test takes 30 seconds. |\n| \"Need to explore first\" | Exploration is fine — throw it away and start with TDD. |\n| \"Test is hard to write\" | Hard to test usually means hard to use. Listen to the test and simplify the design. |\n| \"Existing code has no tests\" | You're improving it now. Add tests for the code you're changing. |\n\n## Example: Bug Fix\n\n**Bug:** Empty email accepted\n\n**RED**\n```typescript\ntest('rejects empty email', async () => {\n  const result = await submitForm({ email: '' });\n  expect(result.error).toBe('Email required');\n});\n```\n\n**Verify RED**\n```bash\n$ npm test\nFAIL: expected 'Email required', got undefined\n```\n\n**GREEN**\n```typescript\nfunction submitForm(data: FormData) {\n  if (!data.email?.trim()) {\n    return { error: 'Email required' };\n  }\n  \u002F\u002F ...\n}\n```\n\n**Verify GREEN**\n```bash\n$ npm test\nPASS\n```\n\n**REFACTOR**\nExtract validation for multiple fields if needed.\n\n## Verification Checklist\n\nBefore marking work complete:\n\n- [ ] Every new function\u002Fmethod has a test\n- [ ] Watched each test fail before implementing\n- [ ] Each test failed for expected reason (feature missing, not typo)\n- [ ] Wrote minimal code to pass each test\n- [ ] All tests pass\n- [ ] Output pristine (no errors, warnings)\n- [ ] Tests use real code (mocks only if unavoidable)\n- [ ] Edge cases and errors covered\n\nCan't check all boxes? Go back and fill the gaps before continuing.\n\n## When Stuck\n\n| Problem | Solution |\n|---------|----------|\n| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |\n| Test too complicated | Design too complicated. Simplify interface. |\n| Must mock everything | Code too coupled. Use dependency injection. |\n| Test setup huge | Extract helpers. Still complex? Simplify design. |\n\n## Debugging Integration\n\nBug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.\n\nFixing bugs without a test means you can't prove the fix works or detect if the bug returns.\n\n## Testing Anti-Patterns\n\nWhen adding mocks or test utilities, read `testing-anti-patterns.md` in this directory to avoid common pitfalls:\n- Testing mock behavior instead of real behavior\n- Adding test-only methods to production classes\n- Mocking without understanding dependencies\n","# Test-Driven Development (TDD)\n\n## Overview\n\nWrite the test first. Watch it fail. Write minimal code to pass.\n\n**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.\n\n## When to Use\n\n**Always:**\n- New features\n- Bug fixes\n- Refactoring\n- Behavior changes\n\n**Exceptions (ask your human partner):**\n- Throwaway prototypes\n- Generated code\n- Configuration files\n\n## Hard Gate: No Production Code Without a Failing Test First\n\nWrite code before the test? Delete it and start over.\n\nThis is the one rule that cannot bend. Code written before a test is untestable by definition — you've already been influenced by the implementation. Keeping it \"as reference\" or \"adapting\" it while writing tests means the tests describe what you built, not what you need. The test can't catch bugs in logic you've already committed to.\n\nDelete means delete. Implement fresh from tests.\n\n## Red-Green-Refactor\n\n```dot\ndigraph tdd_cycle {\n    rankdir=LR;\n    red [label=\"RED\\nWrite failing test\", shape=box, style=filled, fillcolor=\"#ffcccc\"];\n    verify_red [label=\"Verify fails\\ncorrectly\", shape=diamond];\n    green [label=\"GREEN\\nMinimal code\", shape=box, style=filled, fillcolor=\"#ccffcc\"];\n    verify_green [label=\"Verify passes\\nAll green\", shape=diamond];\n    refactor [label=\"REFACTOR\\nClean up\", shape=box, style=filled, fillcolor=\"#ccccff\"];\n    next [label=\"Next\", shape=ellipse];\n\n    red -> verify_red;\n    verify_red -> green [label=\"yes\"];\n    verify_red -> red [label=\"wrong\\nfailure\"];\n    green -> verify_green;\n    verify_green -> refactor [label=\"yes\"];\n    verify_green -> green [label=\"no\"];\n    refactor -> verify_green [label=\"stay\\ngreen\"];\n    verify_green -> next;\n    next -> red;\n}\n```\n\n### RED - Write Failing Test\n\nWrite one minimal test showing what should happen.\n\n\u003CGood>\n```typescript\ntest('retries failed operations 3 times', async () => {\n  let attempts = 0;\n  const operation = () => {\n    attempts++;\n    if (attempts \u003C 3) throw new Error('fail');\n    return 'success';\n  };\n\n  const result = await retryOperation(operation);\n\n  expect(result).toBe('success');\n  expect(attempts).toBe(3);\n});\n```\nClear name, tests real behavior, one thing\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\ntest('retry works', async () => {\n  const mock = jest.fn()\n    .mockRejectedValueOnce(new Error())\n    .mockRejectedValueOnce(new Error())\n    .mockResolvedValueOnce('success');\n  await retryOperation(mock);\n  expect(mock).toHaveBeenCalledTimes(3);\n});\n```\nVague name, tests mock not code\n\u003C\u002FBad>\n\n**Requirements:**\n- One behavior\n- Clear name\n- Real code (no mocks unless unavoidable)\n\n### Verify RED - Watch It Fail\n\nRun the test before writing any implementation. A test you haven't watched fail could be testing the wrong thing, passing for the wrong reason, or not exercising the code path you think it does.\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm:\n- Test fails (not errors)\n- Failure message is expected\n- Fails because feature missing (not typos)\n\n**Test passes?** You're testing existing behavior. Fix test.\n\n**Test errors?** Fix error, re-run until it fails correctly.\n\n### GREEN - Minimal Code\n\nWrite simplest code to pass the test.\n\n\u003CGood>\n```typescript\nasync function retryOperation\u003CT>(fn: () => Promise\u003CT>): Promise\u003CT> {\n  for (let i = 0; i \u003C 3; i++) {\n    try {\n      return await fn();\n    } catch (e) {\n      if (i === 2) throw e;\n    }\n  }\n  throw new Error('unreachable');\n}\n```\nJust enough to pass\n\u003C\u002FGood>\n\n\u003CBad>\n```typescript\nasync function retryOperation\u003CT>(\n  fn: () => Promise\u003CT>,\n  options?: {\n    maxRetries?: number;\n    backoff?: 'linear' | 'exponential';\n    onRetry?: (attempt: number) => void;\n  }\n): Promise\u003CT> {\n  \u002F\u002F YAGNI\n}\n```\nOver-engineered\n\u003C\u002FBad>\n\nDon't add features, refactor other code, or \"improve\" beyond the test.\n\n### Verify GREEN - Watch It Pass\n\nRun the test again after implementation. This confirms the code actually satisfies the test, not just that it compiles. It also catches regressions in other tests.\n\n```bash\nnpm test path\u002Fto\u002Ftest.test.ts\n```\n\nConfirm:\n- Test passes\n- Other tests still pass\n- Output pristine (no errors, warnings)\n\n**Test fails?** Fix code, not test.\n\n**Other tests fail?** Fix now.\n\n### REFACTOR - Clean Up\n\nAfter green only:\n- Remove duplication\n- Improve names\n- Extract helpers\n\nKeep tests green. Don't add behavior.\n\n### Repeat\n\nNext failing test for next feature.\n\n## Good Tests\n\n| Quality | Good | Bad |\n|---------|------|-----|\n| **Minimal** | One thing. \"and\" in name? Split it. | `test('validates email and domain and whitespace')` |\n| **Clear** | Name describes behavior | `test('test1')` |\n| **Shows intent** | Demonstrates desired API | Obscures what code should do |\n\n## Why Order Matters\n\nThe distinction between test-first and test-after isn't ritual — it changes what the tests prove.\n\n**Tests written after code pass immediately.** A test that has never failed proves nothing: it might test the wrong thing, test implementation details instead of behavior, or miss edge cases you forgot. Watching a test fail first proves it actually detects the absence of the feature.\n\n**\"I already manually tested all the edge cases\"** — Manual testing is ad-hoc. There's no record of what you tested, it can't be re-run when code changes, and it's easy to forget cases under pressure. Automated tests are systematic and repeatable.\n\n**\"Deleting X hours of work is wasteful\"** — The time is already gone (sunk cost). The real waste is keeping code you can't trust. Rewriting with TDD takes comparable time but produces code backed by tests that have proven they catch failures.\n\n**\"TDD is dogmatic, being pragmatic means adapting\"** — TDD is the pragmatic choice. It finds bugs before commit, prevents regressions, documents behavior, and enables safe refactoring. Skipping it means debugging in production, which is slower.\n\n**\"Tests after achieve the same goals\"** — Tests-after answer \"what does this code do?\" Tests-first answer \"what should this code do?\" Tests-after are biased by your implementation — you test what you built, not what's required. Tests-first force edge case discovery before implementing.\n\n## Recognizing When You've Left TDD\n\nThese patterns indicate the test-first cycle has been broken. When you notice one, return to the hard gate: delete implementation code and start from a failing test.\n\n- Code written before test\n- Test written after implementation\n- Test passes immediately (never failed)\n- Can't explain why test failed\n- Tests deferred to \"later\"\n- Rationalizing \"just this once\"\n- Keeping implementation code \"as reference\"\n\n| Common excuse | Why it doesn't hold |\n|---------------|---------------------|\n| \"Too simple to test\" | Simple code breaks too, and the test takes 30 seconds. |\n| \"Need to explore first\" | Exploration is fine — throw it away and start with TDD. |\n| \"Test is hard to write\" | Hard to test usually means hard to use. Listen to the test and simplify the design. |\n| \"Existing code has no tests\" | You're improving it now. Add tests for the code you're changing. |\n\n## Example: Bug Fix\n\n**Bug:** Empty email accepted\n\n**RED**\n```typescript\ntest('rejects empty email', async () => {\n  const result = await submitForm({ email: '' });\n  expect(result.error).toBe('Email required');\n});\n```\n\n**Verify RED**\n```bash\n$ npm test\nFAIL: expected 'Email required', got undefined\n```\n\n**GREEN**\n```typescript\nfunction submitForm(data: FormData) {\n  if (!data.email?.trim()) {\n    return { error: 'Email required' };\n  }\n  \u002F\u002F ...\n}\n```\n\n**Verify GREEN**\n```bash\n$ npm test\nPASS\n```\n\n**REFACTOR**\nExtract validation for multiple fields if needed.\n\n## Verification Checklist\n\nBefore marking work complete:\n\n- [ ] Every new function\u002Fmethod has a test\n- [ ] Watched each test fail before implementing\n- [ ] Each test failed for expected reason (feature missing, not typo)\n- [ ] Wrote minimal code to pass each test\n- [ ] All tests pass\n- [ ] Output pristine (no errors, warnings)\n- [ ] Tests use real code (mocks only if unavoidable)\n- [ ] Edge cases and errors covered\n\nCan't check all boxes? Go back and fill the gaps before continuing.\n\n## When Stuck\n\n| Problem | Solution |\n|---------|----------|\n| Don't know how to test | Write wished-for API. Write assertion first. Ask your human partner. |\n| Test too complicated | Design too complicated. Simplify interface. |\n| Must mock everything | Code too coupled. Use dependency injection. |\n| Test setup huge | Extract helpers. Still complex? Simplify design. |\n\n## Debugging Integration\n\nBug found? Write failing test reproducing it. Follow TDD cycle. Test proves fix and prevents regression.\n\nFixing bugs without a test means you can't prove the fix works or detect if the bug returns.\n\n## Testing Anti-Patterns\n\nWhen adding mocks or test utilities, read `testing-anti-patterns.md` in this directory to avoid common pitfalls:\n- Testing mock behavior instead of real behavior\n- Adding test-only methods to production classes\n- Mocking without understanding dependencies\n",{"name":5,"description":7},"main","ffcb87b7a18526a98eccab20c8c12526bb10af96","shared\u002Fskills\u002Ftdd",2,"https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit","https:\u002F\u002Fgithub.com\u002Fshousper","2026-10-27 23:43:43",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add shousper\u002Fclanker-kit --skill tdd",{"tool":64,"command":65},"bunx","bunx skills add shousper\u002Fclanker-kit --skill tdd",{"tool":67,"command":68},"pnpm","pnpm dlx skills add shousper\u002Fclanker-kit --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Ftdd\u002FSKILL.md",true,[72],{"path":73,"resourceType":74,"resourceTypeDesc":75,"sizeBytes":76,"sourceHtmlUrl":77},"testing-anti-patterns.md","REFERENCE","参考文档",8251,"https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fskills\u002Ftdd\u002Ftesting-anti-patterns.md",[79,113,137,153,172,185],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":96,"publishedAt":46},"01M6CP3FKPXFKQBY5979X2W9GN","writing-docs","Use when creating or editing documentation of any kind, including Markdown, RST, or HTML pages, READMEs, design docs, ADRs, changelogs, docstrings, and comment blocks. Covers document purpose, headings, paragraphs, lists, procedures, notices, cross-references, code samples, placeholders, example data, and word choice for technical writing.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fwriting\u002Fskills\u002Fwriting-docs\u002FSKILL.md",[85,88,91],{"categoryNo":86,"categoryName":87,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":89,"categoryName":90,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":92,"categoryName":93,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[97,98,99,100,101,102,41,103,104,105,106,107,108,32,109,110,111,112],"writing","docs","writing docs","design","technical writing","documentation","data","markdown","Word","choice","editing","technical","html","example","document","references",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":46},"01M6CP3CHHC5S3FG5DS38W6PP8","work","Runs the story worker loop in a story-workflow project — claim ready stories, implement each in its own worktree, close through verification gates, repeat until the goal is met or the loop stalls. Use when asked to \"work the board\", \"complete all stories\", \"work on epic st-XXXX\", \"pick up the next story\", \"start a worker\", or to resume or continue a story run — and when a loop re-prompt names the next story in a session that started the loop. DO NOT TRIGGER without .agents\u002Fshousper-stories\u002Fconfig.json (use stories:setup first), for decomposing a spec into stories (stories:plan), or to stop a run (stories:cancel).","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fwork\u002FSKILL.md",[],[115,120,43,121,122,123,124,125,126,127,128,129,130,131,132,133,134,27,135,136],"workflow","run","verification","worktree","start","loop","plan","work on","pick","verification gates","session","ready","up","goal","stop","claim","next",{"skillNo":138,"name":139,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":46},"01M6CP39QNRN136HV0F62TMS7P","using-stories","Compressed story-workflow rulebook, injected automatically at session start (including after compaction) in projects with .agents\u002Fshousper-stories\u002Fconfig.json. Use when unsure of the workflow rules mid-session, when asked \"how does the story workflow work here\", or for a story CLI quick reference. DO NOT TRIGGER in projects without .agents\u002Fshousper-stories\u002Fconfig.json, to set up the workflow (stories:setup), to file stories (stories:plan), or to run the loop (stories:work).","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fusing-stories\u002FSKILL.md",[],[144,145,120,43,146,121,124,147,148,125,126,149,150,151,115,130,32,132,152,27],"using stories","cli","quick reference","SET","how","projects","json","Rules","reference",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":162,"publishedAt":46},"01M6CP36Y3D5S74HQQX62D6SMC","setup","Interactive onboarding that turns a repo into a story-workflow project — merge-mode choice, verification gates with test-runner detection, gitignore wiring, optional project-specific reviewer personas. Use when asked to \"set up the story workflow\", \"adopt stories\", \"story init\", \"install the story board\", or when stories:plan \u002F stories:work is wanted but .agents\u002Fshousper-stories\u002Fconfig.json does not exist yet. DO NOT TRIGGER when .agents\u002Fshousper-stories\u002Fconfig.json already exists (use stories:plan to file work, stories:work to execute it), for creating individual stories, or for project scaffolding unrelated to the story workflow.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fsetup\u002FSKILL.md",[159],{"categoryNo":160,"categoryName":161,"taxonomyType":94,"taxonomyTypeDesc":95},"01JBSEEDCAT000000000000038","人力资源",[155,120,45,163,122,164,147,106,165,115,166,129,167,32,132,27,168,169,170,171],"init","file","reviewer","repo","interactive","personas","runner","gitignore","test-runner",{"skillNo":173,"name":126,"nameZh":6,"description":174,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":175,"categories":176,"keywords":177,"publishedAt":46},"01M6CP33ZJE0SNZAK43Z5RGPDQ","Decomposes a spec or approved design into epics and stories on the story board — sized, dependency-ordered, gated, human-approved, then filed via the story CLI. Use in a project with .agents\u002Fshousper-stories\u002Fconfig.json when there is a design doc (often from kit:brainstorming), spec, requirements file, or feature request to break down; it replaces kit:writing-plans in the workflow chain for story-based projects. Also use for \"file stories\", \"break this into stories\", \"populate the board\". DO NOT TRIGGER in projects without .agents\u002Fshousper-stories\u002Fconfig.json (use kit:writing-plans), for executing stories (stories:work), or for filing a single discovered-work story mid-loop (plain story create).","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fplan\u002FSKILL.md",[],[126,100,97,145,178,120,43,179,180,164,125,149,150,181,115,182,32,183,27,184],"spec","brainstorming","create","design doc","board","dependency","gated",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":191,"publishedAt":46},"01M6CP31SH1DH78VYHRKEW8HK7","cancel","Stops an active story loop and reports where the board stands. Use when asked to \"stop the loop\", \"cancel the story run\", \"halt autonomous story work\", \"kill the worker loop\", or when a runaway run must be shut down. DO NOT TRIGGER for closing a single story (that is story done inside stories:work), for deleting or archiving stories, or for removing the story workflow from a project.","https:\u002F\u002Fgithub.com\u002Fshousper\u002Fclanker-kit\u002Fblob\u002Fmain\u002Fshared\u002Fstories\u002Fskills\u002Fcancel\u002FSKILL.md",[],[187,120,121,125,115,182,192,32,193,194,134,195,27,196],"autonomous","reports","Story","kill","done"]