[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M77RDREFJSVKFTGBAMEXCM6M":3,"skill-same:01M77RDREFJSVKFTGBAMEXCM6M":45},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":14,"repositoryHtmlUrl":27,"repositoryHomepageUrl":6,"ownerHtmlUrl":28,"ownerBlogUrl":6,"ownerDescription":29,"updatedAt":30,"install":31,"resources":44},"01M77RDREFJSVKFTGBAMEXCM6M","testing",null,"Testing workflow and quality standards for writing and running tests.\nUse when: (1) Writing new tests, (2) Adding a new feature that needs tests,\n(3) Modifying logic that has existing tests, (4) Before claiming a task is complete.","finewood2008\u002Fcentaurai-team","finewood2008","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F212194470?v=4","01M75HGRZJ31P9W3T90VHFS1X8","Finewood","01M77RC50EAM5Q4E71MX8JRG7P",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002F.claude\u002Fskills\u002Ftesting\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: testing\ndescription: |\n  Testing workflow and quality standards for writing and running tests.\n  Use when: (1) Writing new tests, (2) Adding a new feature that needs tests,\n  (3) Modifying logic that has existing tests, (4) Before claiming a task is complete.\n---\n\n# Testing Skill\n\nStandards and workflow for writing and running tests. Every feature must be tested.\n\n**Announce at start:** \"I'm using testing skill to ensure proper test coverage.\"\n\n## Trigger Conditions\n\n- Writing new tests for a feature or bug fix\n- Adding a new feature (must include tests)\n- Modifying logic that has existing tests (must update them)\n- Before claiming work is complete\n- Before committing code\n\n## Framework\n\n**Vitest 4** — configured in `vitest.config.ts`.\n\n## Test Structure\n\n```\ntests\u002F\n├── unit\u002F          # Individual functions, utilities, components\n├── integration\u002F   # IPC, database, service interactions\n├── regression\u002F    # Regression test cases\n└── e2e\u002F           # End-to-end tests (Playwright, playwright.config.ts)\n```\n\n## Two Test Environments\n\n| Environment      | When                              | File naming     |\n| ---------------- | --------------------------------- | --------------- |\n| `node` (default) | Main process, utilities, services | `*.test.ts`     |\n| `jsdom`          | DOM\u002Fbrowser-dependent code        | `*.dom.test.ts` |\n\n## Workflow\n\n### Step 1: Identify What to Test\n\nBefore writing tests, list the **riskiest scenarios** first:\n\n- What happens when the dependency returns `undefined` \u002F throws?\n- What happens at boundaries (empty list, max retries, past timestamp)?\n- What is most likely to break in production?\n\n### Step 2: Write Tests\n\nFollow these quality rules:\n\n**1. Describe behavior, not code structure**\n\n```typescript\n\u002F\u002F Wrong — describes implementation\nit('should call repo.getConversation', ...)\n\n\u002F\u002F Correct — describes behavior\nit('should return cached task without hitting repo on second call', ...)\nit('should reject with error when conversation does not exist', ...)\n```\n\n**2. Every describe block must cover at least one failure path**\n\nHappy-path-only tests leave the most dangerous code untested.\n\n**3. One behavior per test**\n\nKeep each `it()` focused. More than 3 `expect()` calls in one test is a signal it is testing too much at once.\n\n**4. Self-check**\n\nAfter writing a test, mentally delete the core logic it targets. If the test would still pass, rewrite it — it is not guarding anything.\n\n**5. Start from risk, not from coverage gaps**\n\nList scenarios most likely to produce bugs. Write those first. Coverage is the outcome, not the starting point.\n\n### Step 3: Run Tests\n\n```bash\nbun run test              # Run all tests (REQUIRED before every commit)\nbun run test:coverage     # Check coverage (before opening a PR)\n```\n\n### Step 4: Verify Coverage\n\n**Coverage target**: ≥ 80% for all source files matched by `vitest.config.ts` → `coverage.include` (currently `src\u002F**\u002F*.{ts,tsx}` plus a few scripts).\n\nNew source files are automatically included in coverage — no manual config changes needed. If a new file is accidentally excluded by a rule in `coverage.exclude`, remove it from the exclude list.\n\n### Step 5: Update Existing Tests\n\nWhen modifying logic, check if existing tests need updating:\n\n```bash\nbun run test -- --reporter=verbose   # See which tests pass\u002Ffail with names\n```\n\nIf a test fails because the behavior changed intentionally, update the test. If it fails unexpectedly, investigate.\n\n## Edge Case Checklist\n\nWhen testing a module, verify:\n\n- [ ] `null` \u002F `undefined` inputs handled\n- [ ] Empty arrays\u002Fobjects handled\n- [ ] Error thrown by dependencies handled\n- [ ] Boundary values (0, -1, max, empty string)\n- [ ] Async operations (timeout, rejection, cancellation)\n\n## Quick Checklist\n\nBefore submitting code:\n\n- [ ] New features have corresponding test cases\n- [ ] Modified logic has updated tests\n- [ ] `bun run test` passes\n- [ ] Tests describe **behavior**, not implementation\n- [ ] At least one failure path per describe block\n- [ ] New source files are not accidentally excluded by `coverage.exclude`\n- [ ] `bun run test:coverage` meets ≥ 80% target\n\n## Common Mistakes\n\n| Mistake                           | Correct                                       |\n| --------------------------------- | --------------------------------------------- |\n| Testing implementation details    | Test observable behavior                      |\n| Only testing happy path           | Must include at least one failure path        |\n| 5+ expects in one `it()`          | Split into separate tests                     |\n| Skipping tests for \"simple\" code  | Simple code breaks too — test the risky parts |\n| Writing tests after saying \"done\" | Tests are part of \"done\", not an afterthought |\n","# Testing Skill\n\nStandards and workflow for writing and running tests. Every feature must be tested.\n\n**Announce at start:** \"I'm using testing skill to ensure proper test coverage.\"\n\n## Trigger Conditions\n\n- Writing new tests for a feature or bug fix\n- Adding a new feature (must include tests)\n- Modifying logic that has existing tests (must update them)\n- Before claiming work is complete\n- Before committing code\n\n## Framework\n\n**Vitest 4** — configured in `vitest.config.ts`.\n\n## Test Structure\n\n```\ntests\u002F\n├── unit\u002F          # Individual functions, utilities, components\n├── integration\u002F   # IPC, database, service interactions\n├── regression\u002F    # Regression test cases\n└── e2e\u002F           # End-to-end tests (Playwright, playwright.config.ts)\n```\n\n## Two Test Environments\n\n| Environment      | When                              | File naming     |\n| ---------------- | --------------------------------- | --------------- |\n| `node` (default) | Main process, utilities, services | `*.test.ts`     |\n| `jsdom`          | DOM\u002Fbrowser-dependent code        | `*.dom.test.ts` |\n\n## Workflow\n\n### Step 1: Identify What to Test\n\nBefore writing tests, list the **riskiest scenarios** first:\n\n- What happens when the dependency returns `undefined` \u002F throws?\n- What happens at boundaries (empty list, max retries, past timestamp)?\n- What is most likely to break in production?\n\n### Step 2: Write Tests\n\nFollow these quality rules:\n\n**1. Describe behavior, not code structure**\n\n```typescript\n\u002F\u002F Wrong — describes implementation\nit('should call repo.getConversation', ...)\n\n\u002F\u002F Correct — describes behavior\nit('should return cached task without hitting repo on second call', ...)\nit('should reject with error when conversation does not exist', ...)\n```\n\n**2. Every describe block must cover at least one failure path**\n\nHappy-path-only tests leave the most dangerous code untested.\n\n**3. One behavior per test**\n\nKeep each `it()` focused. More than 3 `expect()` calls in one test is a signal it is testing too much at once.\n\n**4. Self-check**\n\nAfter writing a test, mentally delete the core logic it targets. If the test would still pass, rewrite it — it is not guarding anything.\n\n**5. Start from risk, not from coverage gaps**\n\nList scenarios most likely to produce bugs. Write those first. Coverage is the outcome, not the starting point.\n\n### Step 3: Run Tests\n\n```bash\nbun run test              # Run all tests (REQUIRED before every commit)\nbun run test:coverage     # Check coverage (before opening a PR)\n```\n\n### Step 4: Verify Coverage\n\n**Coverage target**: ≥ 80% for all source files matched by `vitest.config.ts` → `coverage.include` (currently `src\u002F**\u002F*.{ts,tsx}` plus a few scripts).\n\nNew source files are automatically included in coverage — no manual config changes needed. If a new file is accidentally excluded by a rule in `coverage.exclude`, remove it from the exclude list.\n\n### Step 5: Update Existing Tests\n\nWhen modifying logic, check if existing tests need updating:\n\n```bash\nbun run test -- --reporter=verbose   # See which tests pass\u002Ffail with names\n```\n\nIf a test fails because the behavior changed intentionally, update the test. If it fails unexpectedly, investigate.\n\n## Edge Case Checklist\n\nWhen testing a module, verify:\n\n- [ ] `null` \u002F `undefined` inputs handled\n- [ ] Empty arrays\u002Fobjects handled\n- [ ] Error thrown by dependencies handled\n- [ ] Boundary values (0, -1, max, empty string)\n- [ ] Async operations (timeout, rejection, cancellation)\n\n## Quick Checklist\n\nBefore submitting code:\n\n- [ ] New features have corresponding test cases\n- [ ] Modified logic has updated tests\n- [ ] `bun run test` passes\n- [ ] Tests describe **behavior**, not implementation\n- [ ] At least one failure path per describe block\n- [ ] New source files are not accidentally excluded by `coverage.exclude`\n- [ ] `bun run test:coverage` meets ≥ 80% target\n\n## Common Mistakes\n\n| Mistake                           | Correct                                       |\n| --------------------------------- | --------------------------------------------- |\n| Testing implementation details    | Test observable behavior                      |\n| Only testing happy path           | Must include at least one failure path        |\n| 5+ expects in one `it()`          | Split into separate tests                     |\n| Skipping tests for \"simple\" code  | Simple code breaks too — test the risky parts |\n| Writing tests after saying \"done\" | Tests are part of \"done\", not an afterthought |\n",{"name":5,"description":7},"team","a9a9464c62247a811d9231c636a0941e0fd9ae05",".claude\u002Fskills\u002Ftesting","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team","https:\u002F\u002Fgithub.com\u002Ffinewood2008","Founder & CEO of Centaur AI · Humans lead, AI executes — the Centaur Loop is the smallest work unit for building AI employees.","2026-07-14 22:41:28",{"source":8,"skillName":5,"commands":32,"prompt":42,"zipAvailable":43},[33,36,39],{"tool":34,"command":35},"npx","npx skills add finewood2008\u002Fcentaurai-team --skill testing",{"tool":37,"command":38},"bunx","bunx skills add finewood2008\u002Fcentaurai-team --skill testing",{"tool":40,"command":41},"pnpm","pnpm dlx skills add finewood2008\u002Fcentaurai-team --skill testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002F.claude\u002Fskills\u002Ftesting\u002FSKILL.md",true,[],[46,54,61,68,75,82],{"skillNo":47,"name":48,"nameZh":6,"description":49,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":51,"categories":52,"keywords":53,"publishedAt":19},"01M77RFHB8MZ42KXGPY38CXCAQ","团队周报","Use when generating structured weekly team reports from git commits, task boards, and meeting notes. Auto-aggregates work done, work planned, blockers, and metrics. Chinese output by default. Trigger on: weekly report, 周报, sprint review, 本周总结, team update, status report.","MIT","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-weekly-report\u002FSKILL.md",[],[],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M77RFBY70Q5R4YN8A3JD7X5G","中英互译","Use when translating content between Chinese and English for business, technical, or marketing purposes. Handles docs, emails, UI strings, marketing copy, and technical documentation with domain-aware terminology. Trigger on: 翻译, translate, 中译英, 英译中, i18n, localization, English version, 中文版.","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-translation\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M77RF6YBVG39A4QQQEGY8Q6N","社媒规划","Use when planning, drafting, or scheduling social media content for WeChat Official Account, Twitter\u002FX, and Xiaohongshu. Generates content calendars with platform-adapted copy, publishing schedules, and performance tracking. Trigger on: social media, 公众号, 推文, content calendar, 社媒, 发布计划.","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-social-planner\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M77RF2JR9BZ9QKXY101Z80F8","项目任务看板","Use when managing team projects, tasks, or sprint tracking with a lightweight markdown kanban board. Create, update, assign, and track tasks across team members without external tools. Trigger on: task board, kanban, sprint planning, assign task, task status, project progress.","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-project-tracker\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M77REYK38P4W54XQVFFV0GF2","新人入职","Use when onboarding a new team member to the company, project, or development environment. Covers environment setup, account provisioning, access permissions, first-day tasks, and knowledge base orientation. Trigger on: onboarding, 入职, new employee, 新人, setup workstation, 环境配置, first day.","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-onboarding\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":50,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M77RESXY98BF66BSTPZADB4W","会议纪要","Use when recording, structuring, or extracting action items from team meetings. Creates standardized meeting minutes with decisions, action items with owners and deadlines, and follow-up tracking. Trigger on: meeting notes, 会议纪要, meeting minutes, 开会记录, standup notes, decision log, 会议记录.","https:\u002F\u002Fgithub.com\u002Ffinewood2008\u002Fcentaurai-team\u002Fblob\u002Fteam\u002Fskills\u002Fbuiltin\u002Fteam\u002Fteam-meeting-minutes\u002FSKILL.md",[],[]]