[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWEJD606FG3DBBRM0W4DKW":3,"skill-same:01M6KWEJD606FG3DBBRM0W4DKW":72},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":14,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":56,"updatedAt":57,"install":58,"resources":71},"01M6KWEJD606FG3DBBRM0W4DKW","write-tests",null,"Test implementation skill for HypermediaEngine. Takes a confirmed test plan from design-test-cases and produces compilable, runnable xUnit tests following project conventions. Validates coverage quality through mutation testing. Invoked by the sqa-engineer agent after the test plan is approved.","rafsanulhasan\u002FHypermediaEngine","rafsanulhasan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2341142?v=4","01M6KW2HWPTZWK051N7B0HTBVG","Rafsanul Hasan","01M6KW2J0N3613382MF5DRN79H",0,"GPL-3.0","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-tests\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"tests","write tests","write","read","for","mutation","project","mutation testing","engineer","coverage","edit","testing","xunit","quality","plan","Bash","test plan","project conventions","test","design","2026-11-10 10:12:30",false,"---\nname: write-tests\ndescription: Test implementation skill for HypermediaEngine. Takes a confirmed test plan from design-test-cases and produces compilable, runnable xUnit tests following project conventions. Validates coverage quality through mutation testing. Invoked by the sqa-engineer agent after the test plan is approved.\nmodel: claude-opus-4-7\ntools: Read, Write, Edit, Grep, Glob, Bash, TodoWrite\n---\n\nYou are executing the `write-tests` skill on behalf of the sqa-engineer agent. Your job is to implement the confirmed test plan as working, convention-compliant xUnit test code. This skill expects a confirmed test plan as input — test case design is handled by the `design-test-cases` skill. Do not redesign test strategy here; implement what the plan specifies.\n\n## Input\n\nThe calling agent will pass:\n- A confirmed test plan produced by the `design-test-cases` skill\n- The component under test (file path and class name)\n\n## Process\n\n### Phase 0 — Context Load (silent, no user interaction)\n\nBefore writing any code:\n\n1. Read `CLAUDE.md` to internalize conventions.\n2. Invoke `Skill(\"manage-memory\", args: \"sqa-engineer\")` to load prior knowledge about test fixtures and patterns.\n3. Read the confirmed test plan in full — every TC specification is a work item.\n4. Locate the test project using Glob. Read several existing test files to internalize:\n   - Test framework (xUnit)\n   - Assertion library in use\n   - Test double approach (NSubstitute, hand-rolled, etc.)\n   - Naming convention\n   - Fixture and setup patterns (`IClassFixture`, constructors, `[ClassFixture]`)\n5. Add every TC from the plan as a `TodoWrite` item before writing a single line of code.\n\n---\n\n### Phase 1 — Test Implementation\n\nImplement each TC from the confirmed plan in order. For every test file written:\n\n#### Structure\n\nUse Arrange \u002F Act \u002F Assert in every test method:\n\n```csharp\n[Fact]\npublic async Task MethodName_StateUnderTest_ExpectedBehavior()\n{\n    \u002F\u002F Arrange\n    ...\n\n    \u002F\u002F Act\n    ResultType result = await sut.MethodNameAsync(input, ct);\n\n    \u002F\u002F Assert\n    ...\n}\n```\n\n#### Naming\n\nThree-part names that read as a specification: `MethodName_StateUnderTest_ExpectedBehavior`\n\n- `Validate_WhenAuthHeaderIsMissing_ReturnsErrorResult`\n- `Dispatch_WhenHandlerSucceeds_ReturnsPopulatedData`\n- `Process_WhenTokenIsCancelled_ThrowsOperationCanceledException`\n\n#### Convention checklist (apply to every test file)\n\n- [ ] Explicit type declarations: `MyService sut = new(mockDep);` not `var sut = ...`\n- [ ] `await using` for any disposable test fixtures\n- [ ] Assert **both** `data` and `error` fields for every `{ data, error }` result — never assert only one side\n- [ ] Each `[Fact]` tests exactly one behavior from the TC specification\n- [ ] Use `[Theory]` with `[InlineData]` or `[MemberData]` for parameterized edge cases listed in the plan\n- [ ] No `Thread.Sleep` or arbitrary delays — use `CancellationToken` properly\n- [ ] Mock only the dependencies the TC exercises — minimal mock configuration\n- [ ] Never mock the system under test itself\n- [ ] No shared mutable state between test cases\n\n#### Integration tests\n\nFor TCs marked as integration type in the plan:\n\n- Use `WebApplicationFactory\u003CT>` or an in-memory `IHost`\n- Register test doubles in the test host's DI — do not modify production registrations\n- Each test must leave shared infrastructure in a clean state\n\nMark each `TodoWrite` TC item complete immediately after its test is written and compiling.\n\n---\n\n### Phase 2 — Run and Verify\n\n```shell\ndotnet test\n```\n\n- All new tests must pass\n- No previously passing test may fail — a test that breaks existing tests is itself a defect; report it to the software-engineer rather than modifying production code\n- If a test fails because the implementation has a bug: stop, report the bug to the software-engineer, do not modify production code yourself\n- If a test fails because the test setup is wrong: fix the test setup only\n\n---\n\n### Phase 3 — Mutation Testing\n\n```shell\ndotnet stryker\n```\n\nFor each surviving mutant in code covered by the new tests:\n\n1. Map the mutant back to the TC that should have caught it\n2. Strengthen or add a test case that produces observably different output when the mutation is present\n3. Re-run `dotnet stryker` to confirm the mutant is killed\n\nAcceptable reasons to leave a mutant alive (add a comment in the test file):\n\n- The mutant is in logging-only code with no observable output difference\n- The code path is architecturally unreachable without breaking DI or middleware contracts\n\nDo not mark work complete with unresolved surviving mutants unless each one is explicitly justified.\n\n---\n\n## Quality Gate\n\nDo not mark the test suite complete until:\n\n- [ ] Every TC from the confirmed plan has a corresponding test method\n- [ ] Every AC listed in the plan maps to at least one passing test\n- [ ] `dotnet test` exits with 0 failures\n- [ ] `dotnet stryker` produces no surviving mutants on new code paths (or each survivor is commented and justified)\n- [ ] Both `data` and `error` are asserted in every `{ data, error }` result test\n- [ ] No previously passing test was broken\n- [ ] No production code was modified\n\n## Output\n\nReport completion with:\n\n> **Tests implemented for**: [component name] — [N tests written, dotnet test: pass, dotnet stryker: N survivors \u002F all killed]\n","You are executing the `write-tests` skill on behalf of the sqa-engineer agent. Your job is to implement the confirmed test plan as working, convention-compliant xUnit test code. This skill expects a confirmed test plan as input — test case design is handled by the `design-test-cases` skill. Do not redesign test strategy here; implement what the plan specifies.\n\n## Input\n\nThe calling agent will pass:\n- A confirmed test plan produced by the `design-test-cases` skill\n- The component under test (file path and class name)\n\n## Process\n\n### Phase 0 — Context Load (silent, no user interaction)\n\nBefore writing any code:\n\n1. Read `CLAUDE.md` to internalize conventions.\n2. Invoke `Skill(\"manage-memory\", args: \"sqa-engineer\")` to load prior knowledge about test fixtures and patterns.\n3. Read the confirmed test plan in full — every TC specification is a work item.\n4. Locate the test project using Glob. Read several existing test files to internalize:\n   - Test framework (xUnit)\n   - Assertion library in use\n   - Test double approach (NSubstitute, hand-rolled, etc.)\n   - Naming convention\n   - Fixture and setup patterns (`IClassFixture`, constructors, `[ClassFixture]`)\n5. Add every TC from the plan as a `TodoWrite` item before writing a single line of code.\n\n---\n\n### Phase 1 — Test Implementation\n\nImplement each TC from the confirmed plan in order. For every test file written:\n\n#### Structure\n\nUse Arrange \u002F Act \u002F Assert in every test method:\n\n```csharp\n[Fact]\npublic async Task MethodName_StateUnderTest_ExpectedBehavior()\n{\n    \u002F\u002F Arrange\n    ...\n\n    \u002F\u002F Act\n    ResultType result = await sut.MethodNameAsync(input, ct);\n\n    \u002F\u002F Assert\n    ...\n}\n```\n\n#### Naming\n\nThree-part names that read as a specification: `MethodName_StateUnderTest_ExpectedBehavior`\n\n- `Validate_WhenAuthHeaderIsMissing_ReturnsErrorResult`\n- `Dispatch_WhenHandlerSucceeds_ReturnsPopulatedData`\n- `Process_WhenTokenIsCancelled_ThrowsOperationCanceledException`\n\n#### Convention checklist (apply to every test file)\n\n- [ ] Explicit type declarations: `MyService sut = new(mockDep);` not `var sut = ...`\n- [ ] `await using` for any disposable test fixtures\n- [ ] Assert **both** `data` and `error` fields for every `{ data, error }` result — never assert only one side\n- [ ] Each `[Fact]` tests exactly one behavior from the TC specification\n- [ ] Use `[Theory]` with `[InlineData]` or `[MemberData]` for parameterized edge cases listed in the plan\n- [ ] No `Thread.Sleep` or arbitrary delays — use `CancellationToken` properly\n- [ ] Mock only the dependencies the TC exercises — minimal mock configuration\n- [ ] Never mock the system under test itself\n- [ ] No shared mutable state between test cases\n\n#### Integration tests\n\nFor TCs marked as integration type in the plan:\n\n- Use `WebApplicationFactory\u003CT>` or an in-memory `IHost`\n- Register test doubles in the test host's DI — do not modify production registrations\n- Each test must leave shared infrastructure in a clean state\n\nMark each `TodoWrite` TC item complete immediately after its test is written and compiling.\n\n---\n\n### Phase 2 — Run and Verify\n\n```shell\ndotnet test\n```\n\n- All new tests must pass\n- No previously passing test may fail — a test that breaks existing tests is itself a defect; report it to the software-engineer rather than modifying production code\n- If a test fails because the implementation has a bug: stop, report the bug to the software-engineer, do not modify production code yourself\n- If a test fails because the test setup is wrong: fix the test setup only\n\n---\n\n### Phase 3 — Mutation Testing\n\n```shell\ndotnet stryker\n```\n\nFor each surviving mutant in code covered by the new tests:\n\n1. Map the mutant back to the TC that should have caught it\n2. Strengthen or add a test case that produces observably different output when the mutation is present\n3. Re-run `dotnet stryker` to confirm the mutant is killed\n\nAcceptable reasons to leave a mutant alive (add a comment in the test file):\n\n- The mutant is in logging-only code with no observable output difference\n- The code path is architecturally unreachable without breaking DI or middleware contracts\n\nDo not mark work complete with unresolved surviving mutants unless each one is explicitly justified.\n\n---\n\n## Quality Gate\n\nDo not mark the test suite complete until:\n\n- [ ] Every TC from the confirmed plan has a corresponding test method\n- [ ] Every AC listed in the plan maps to at least one passing test\n- [ ] `dotnet test` exits with 0 failures\n- [ ] `dotnet stryker` produces no surviving mutants on new code paths (or each survivor is commented and justified)\n- [ ] Both `data` and `error` are asserted in every `{ data, error }` result test\n- [ ] No previously passing test was broken\n- [ ] No production code was modified\n\n## Output\n\nReport completion with:\n\n> **Tests implemented for**: [component name] — [N tests written, dotnet test: pass, dotnet stryker: N survivors \u002F all killed]\n",{"name":5,"model":49,"tools":50,"description":7},"claude-opus-4-7","Read, Write, Edit, Grep, Glob, Bash, TodoWrite","main","00b2c68281930728ee390bb16cec32b88d2caac7",".github\u002Fskills\u002Fwrite-tests","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine","https:\u002F\u002Fgithub.com\u002Frafsanulhasan","\r\n    MCSD || A-CSD || Software Architect\r\n\r\n","2026-06-06 07:47:06",{"source":8,"skillName":5,"commands":59,"prompt":69,"zipAvailable":70},[60,63,66],{"tool":61,"command":62},"npx","npx skills add rafsanulhasan\u002FHypermediaEngine --skill write-tests",{"tool":64,"command":65},"bunx","bunx skills add rafsanulhasan\u002FHypermediaEngine --skill write-tests",{"tool":67,"command":68},"pnpm","pnpm dlx skills add rafsanulhasan\u002FHypermediaEngine --skill write-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-tests\u002FSKILL.md",true,[],[73,93,112,141,164,190],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":44},"01M6KWEF2XQ00C1Y6QCK7YHZ1H","write-documentation","Structured documentation writing workflow for HypermediaEngine. Writes or updates README.md files at the repo root and in each project directory (src\u002F, tests\u002F, samples\u002F, etc.) based on current implementation, ADRs, and architecture decisions.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-documentation\u002FSKILL.md",[],[80,26,81,82,83,84,85,39,86,87,88,89,27,34,90,30,24,91,92,28],"documentation","write documentation","writing","directory","workflow","architecture","src","repo","decisions","README","files","updates","at",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":44},"01M6KWEBDXTXAVPQ3BHS3YYYNT","write-adr","Writes a numbered Architecture Decision Record (ADR) for a significant architectural choice in the HypermediaEngine project. Invoked by the software-architect agent whenever a consequential design decision is made or ratified. Saves the ADR to docs\u002Farchitecture\u002Fdecisions\u002F.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-adr\u002FSKILL.md",[],[100,26,101,43,102,85,103,104,105,106,88,27,107,108,30,109,110,28,111],"adr","write adr","docs","architect","decision","choice","grep","architecture decision record","record","software","opus","architecture decision",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":124,"publishedAt":44},"01M6KWE76TM3QHGQ08PEB3KY6D","tunit-playwright-ui-testing","Comprehensive guidance for writing coded end-to-end UI tests in C# using TUnit.Playwright. Tests inherit from PageTest — the base class manages all browser lifecycle. Covers NuGet setup, PageTest inheritance, Page Object Model, browser configuration, parallelism limiting, and CI integration. Based on the official TUnit docs at https:\u002F\u002Ftunit.dev\u002Fdocs\u002Fexamples\u002Fplaywright.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftunit-playwright-ui-testing\u002FSKILL.md",[118,119],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[35,125,126,127,128,129,130,82,131,132,133,134,135,136,137,138,24,139,140,28],"playwright","ui","playwright ui testing","ui testing","tunit","tunit playwright ui testing","official","dev","examples","ci","lifecycle","model","page","inheritance","end","object",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":150,"publishedAt":44},"01M6KWE44A738GDK65QS02XJBG","triage","Task classification, decomposition, dependency mapping, and routing skill. Invoked by the triage-agent to break any user request into discrete, independently-routable work items with assigned priorities and agent chains.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftriage\u002FSKILL.md",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[143,151,152,153,154,155,156,157,158,159,160,161,162,163],"routing","classification","work","user","dependency","task","priorities","decomposition","user request","mapping","with","break","request",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":174,"publishedAt":44},"01M6KWDZ3W9ZKPR7FTTTSX8H2K","system-design","Expert system design skill. Use PROACTIVELY to design systems, review architectures, and assist software engineers in learning design principles and implementing them in the code with design patterns.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsystem-design\u002FSKILL.md",[170,173],{"categoryNo":171,"categoryName":172,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[43,175,176,177,178,179,180,106,27,181,182,183,184,185,186,109,187,188,161,189],"system","system design","web","design systems","learning","haiku","use","design patterns","design principles","expert","patterns","systems","architectures","principles","implementing",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":44},"01M6KWDVXNF6T2JTMV23RJGAF6","spec-driven-development","Manages the full lifecycle of a feature specification — from collaborative drafting to enforcement during implementation and testing.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspec-driven-development\u002FSKILL.md",[],[197,198,199,200,201,35,135,39,106,27,26,34,202,203,204,205,206,207,208,209],"spec","spec driven development","development","spec driven","driven","enforcement","implementation","specification","analyst","full","feature","sonnet","feature specification"]