[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C233K1GYYEXNGC9CKXHM1G":3,"skill-same:01M6C233K1GYYEXNGC9CKXHM1G":63},{"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":22,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6C233K1GYYEXNGC9CKXHM1G","end2end-testing",null,"Use when adding or modifying end-to-end tests, testing provider-backed application flows, choosing realistic fixtures, or debugging integration failures across service boundaries.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fend2end-testing\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36],"testing","end2end testing","debugging","integration","use","provider","application","across","fixtures","service","tests","end","flows","when","2026-11-10 10:12:30",false,"---\nname: end2end-testing\ndescription: Use when adding or modifying end-to-end tests, testing provider-backed application flows, choosing realistic fixtures, or debugging integration failures across service boundaries.\n---\n\n# End-to-End Testing\n\n## Rule\n\nDrive the real in-process application path and fake only external boundaries.\nAn end-to-end test must fail when the user-visible response, persisted state, or\nother observable contract is wrong; importing or calling isolated helpers is not\nend-to-end proof.\n\n## Resolve the active project contract\n\nBefore writing a test:\n\n1. Read the repository instructions and its canonical testing guidance.\n2. Locate related end-to-end tests, shared base classes, SDK-faithful fakes, and\n   the canonical test command.\n3. Trace the application entry point through parsing, domain logic,\n   persistence, and projection.\n4. Identify the true external boundaries: provider transports, databases,\n   queues, clocks, filesystems, or third-party APIs.\n\nProject-local rules override generic names and examples in this skill. Do not\ninvent paths, fake classes, environment variables, or authentication bypasses.\n\n## Test design\n\n1. Write a focused test and watch it fail for the missing or incorrect\n   behavior.\n2. Enter through the real route, command, handler, or public service boundary.\n3. Keep the parser, reducer\u002Fdomain logic, persistence adapter, projection, and\n   response serialization in process.\n4. Fake only external calls and use real serializable values rather than loose\n   `Mock` or `MagicMock` objects as application data.\n5. Assert the request handed to the external provider, parsed response,\n   persisted state or emitted side effect, and user\u002Fclient\u002Fserver-visible\n   result when those checkpoints are in scope.\n6. Cover success, relevant failure, and boundary cases. For multi-phase calls,\n   provide ordered external responses and verify context passed between phases.\n7. Run the focused test, then the project's relevant end-to-end suite.\n\nUse the project's SDK-faithful realistic response fake when provider response\nshape matters. A shallow hand-shaped dictionary can accidentally omit candidate\nnesting, streaming part order, finish reason, usage metadata, or tool-result\nparts and therefore prove the wrong contract.\n\n## Source preference and fallback labels\n\nUse this fixture-source order:\n\n1. A complete PII-scrubbed request\u002Fresponse pair from raw production or staging\n   provider telemetry.\n2. A local raw provider transport capture when the matching telemetry row is\n   unavailable.\n3. A minimal desired-contract payload only when neither real source exists.\n\nLabel case 3 `SYNTHETIC CONTRACT FIXTURE` in the fixture header or test\ndocstring. It proves deterministic application behavior only; it proves nothing\nabout live-model compliance. Never repair a failed real response while turning\nit into a success fixture. Preserve the failure unchanged and source a separate\nsuccessful response for the success case.\n\nFor telemetry fixtures, select the complete row. Adapt these generic fields to\nthe actual telemetry owner: `occurred_at`, `request_id`, `event_type`, `agent`,\n`model`, `finish_reason`, `request_payload`, `response_payload`,\n`response_parts`, `input_tokens`, `output_tokens`, and `deployed_revision`.\nPin one logical request and event type so wrapper or streaming rows are not\nmixed. Do not use substring or preview columns to build a fixture.\n\nPII-scrub while preserving structure, omissions, non-sensitive malformed and\nnumeric values, and content-part order. Replace all PII, including numeric PII,\nwith clearly synthetic same-type placeholders and record the substitutions.\nAlso record:\n\n- source kind and stable request\u002Fcapture identifier;\n- timestamp, event type, agent, model, and finish-reason shape;\n- deployed revision and any separately verified revision-to-source mapping;\n- fields scrubbed and the structurally equivalent placeholders used.\n\nA deployment identifier is not a source commit unless that mapping was\nverified separately.\n\n## Qualify the incident's behavior boundary\n\nFixture provenance is not SDK\u002Ftransport behavior proof. Record the sanitized\nfixture SHA-256, original capture timestamp, source identity\u002Frevision mapping,\nand scrub manifest separately from the test execution receipt. Preserve failed\nresponses and omissions; never relabel a synthetic adapter as a real capture.\n\nFor an SDK or platform regression, trace the actual response ownership boundary:\nbody getter side effects, shared buffer ownership, single-consumption behavior,\nstream chunk ordering, cancellation, and error paths where relevant. Prefer the\npinned SDK implementation. If unavailable, label a behavioral substitute as a\nsynthetic adapter, not a real SDK execution, and cite the inspected SDK version\nand source contract it models. A passive object with matching JSON is insufficient\nwhen the failure depends on reads consuming or changing the response.\n\nUse the same fixture through the real application entry point on the failing\nrevision and candidate; require RED at the failing revision and GREEN at the\ncandidate for the user-visible assertion. Name any changed harness separately.\nRetain a negative control for the precise behavior that escaped, not just schema\npresence. Bind runtime claims to the actual platform, SDK, transport, build\u002Fsource\nand backend target; Release versus Debug and native versus web are separate\ncoverage dimensions. Missing combinations remain unverified, not implied green.\n\nKeep deterministic replay in the project's existing relevant CI test selection.\nNo new live capture or provider call is implied by a missing fixture or platform\nreceipt; use existing authorized evidence or report the exact gap and owner.\n\n## Claim boundaries\n\n| Fixture | What it can prove | What it cannot prove |\n|---|---|---|\n| Telemetry or raw local capture | Deterministic behavior for that preserved response shape | Current model reliability or broad frequency |\n| `SYNTHETIC CONTRACT FIXTURE` | Desired deterministic parser, state, and projection behavior | Any live-provider capability or compliance |\n| Current real-provider run | Capability for the recorded attempts | Backend correctness unless the application path is also exercised |\n\nKeep `BACKEND READY` and `LLM CONTRACT GREEN` as separate claims. One real\nresponse proves capability, not statistical reliability.\n\n## Completion report\n\n```text\nEND-TO-END READY\nTest: \u003Cpath and test name>\nEntry point: \u003Croute\u002Fcommand\u002Fhandler>\nExternal boundaries faked: \u003Cboundaries>\nFixture: \u003Csource, identifier, provenance, and label if synthetic>\nAssertions: \u003Crequest, parsed result, persisted state\u002Fside effect, visible result>\nFocused command: \u003Ccommand and result>\nRelevant suite: \u003Ccommand and result>\nLive provider compliance: NOT TESTED \u002F PROVEN SEPARATELY\n```\n\nDo not report completion by running unchanged tests alone. Name the test and the\nobservable assertion added or changed.\n\n","# End-to-End Testing\n\n## Rule\n\nDrive the real in-process application path and fake only external boundaries.\nAn end-to-end test must fail when the user-visible response, persisted state, or\nother observable contract is wrong; importing or calling isolated helpers is not\nend-to-end proof.\n\n## Resolve the active project contract\n\nBefore writing a test:\n\n1. Read the repository instructions and its canonical testing guidance.\n2. Locate related end-to-end tests, shared base classes, SDK-faithful fakes, and\n   the canonical test command.\n3. Trace the application entry point through parsing, domain logic,\n   persistence, and projection.\n4. Identify the true external boundaries: provider transports, databases,\n   queues, clocks, filesystems, or third-party APIs.\n\nProject-local rules override generic names and examples in this skill. Do not\ninvent paths, fake classes, environment variables, or authentication bypasses.\n\n## Test design\n\n1. Write a focused test and watch it fail for the missing or incorrect\n   behavior.\n2. Enter through the real route, command, handler, or public service boundary.\n3. Keep the parser, reducer\u002Fdomain logic, persistence adapter, projection, and\n   response serialization in process.\n4. Fake only external calls and use real serializable values rather than loose\n   `Mock` or `MagicMock` objects as application data.\n5. Assert the request handed to the external provider, parsed response,\n   persisted state or emitted side effect, and user\u002Fclient\u002Fserver-visible\n   result when those checkpoints are in scope.\n6. Cover success, relevant failure, and boundary cases. For multi-phase calls,\n   provide ordered external responses and verify context passed between phases.\n7. Run the focused test, then the project's relevant end-to-end suite.\n\nUse the project's SDK-faithful realistic response fake when provider response\nshape matters. A shallow hand-shaped dictionary can accidentally omit candidate\nnesting, streaming part order, finish reason, usage metadata, or tool-result\nparts and therefore prove the wrong contract.\n\n## Source preference and fallback labels\n\nUse this fixture-source order:\n\n1. A complete PII-scrubbed request\u002Fresponse pair from raw production or staging\n   provider telemetry.\n2. A local raw provider transport capture when the matching telemetry row is\n   unavailable.\n3. A minimal desired-contract payload only when neither real source exists.\n\nLabel case 3 `SYNTHETIC CONTRACT FIXTURE` in the fixture header or test\ndocstring. It proves deterministic application behavior only; it proves nothing\nabout live-model compliance. Never repair a failed real response while turning\nit into a success fixture. Preserve the failure unchanged and source a separate\nsuccessful response for the success case.\n\nFor telemetry fixtures, select the complete row. Adapt these generic fields to\nthe actual telemetry owner: `occurred_at`, `request_id`, `event_type`, `agent`,\n`model`, `finish_reason`, `request_payload`, `response_payload`,\n`response_parts`, `input_tokens`, `output_tokens`, and `deployed_revision`.\nPin one logical request and event type so wrapper or streaming rows are not\nmixed. Do not use substring or preview columns to build a fixture.\n\nPII-scrub while preserving structure, omissions, non-sensitive malformed and\nnumeric values, and content-part order. Replace all PII, including numeric PII,\nwith clearly synthetic same-type placeholders and record the substitutions.\nAlso record:\n\n- source kind and stable request\u002Fcapture identifier;\n- timestamp, event type, agent, model, and finish-reason shape;\n- deployed revision and any separately verified revision-to-source mapping;\n- fields scrubbed and the structurally equivalent placeholders used.\n\nA deployment identifier is not a source commit unless that mapping was\nverified separately.\n\n## Qualify the incident's behavior boundary\n\nFixture provenance is not SDK\u002Ftransport behavior proof. Record the sanitized\nfixture SHA-256, original capture timestamp, source identity\u002Frevision mapping,\nand scrub manifest separately from the test execution receipt. Preserve failed\nresponses and omissions; never relabel a synthetic adapter as a real capture.\n\nFor an SDK or platform regression, trace the actual response ownership boundary:\nbody getter side effects, shared buffer ownership, single-consumption behavior,\nstream chunk ordering, cancellation, and error paths where relevant. Prefer the\npinned SDK implementation. If unavailable, label a behavioral substitute as a\nsynthetic adapter, not a real SDK execution, and cite the inspected SDK version\nand source contract it models. A passive object with matching JSON is insufficient\nwhen the failure depends on reads consuming or changing the response.\n\nUse the same fixture through the real application entry point on the failing\nrevision and candidate; require RED at the failing revision and GREEN at the\ncandidate for the user-visible assertion. Name any changed harness separately.\nRetain a negative control for the precise behavior that escaped, not just schema\npresence. Bind runtime claims to the actual platform, SDK, transport, build\u002Fsource\nand backend target; Release versus Debug and native versus web are separate\ncoverage dimensions. Missing combinations remain unverified, not implied green.\n\nKeep deterministic replay in the project's existing relevant CI test selection.\nNo new live capture or provider call is implied by a missing fixture or platform\nreceipt; use existing authorized evidence or report the exact gap and owner.\n\n## Claim boundaries\n\n| Fixture | What it can prove | What it cannot prove |\n|---|---|---|\n| Telemetry or raw local capture | Deterministic behavior for that preserved response shape | Current model reliability or broad frequency |\n| `SYNTHETIC CONTRACT FIXTURE` | Desired deterministic parser, state, and projection behavior | Any live-provider capability or compliance |\n| Current real-provider run | Capability for the recorded attempts | Backend correctness unless the application path is also exercised |\n\nKeep `BACKEND READY` and `LLM CONTRACT GREEN` as separate claims. One real\nresponse proves capability, not statistical reliability.\n\n## Completion report\n\n```text\nEND-TO-END READY\nTest: \u003Cpath and test name>\nEntry point: \u003Croute\u002Fcommand\u002Fhandler>\nExternal boundaries faked: \u003Cboundaries>\nFixture: \u003Csource, identifier, provenance, and label if synthetic>\nAssertions: \u003Crequest, parsed result, persisted state\u002Fside effect, visible result>\nFocused command: \u003Ccommand and result>\nRelevant suite: \u003Ccommand and result>\nLive provider compliance: NOT TESTED \u002F PROVEN SEPARATELY\n```\n\nDo not report completion by running unchanged tests alone. Name the test and the\nobservable assertion added or changed.\n\n",{"name":5,"description":7},"main","42ccd02cbf5e8e47839dc3eab6fc754dc6b339cf",".claude\u002Fskills\u002Fend2end-testing",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-14 03:18:13",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill end2end-testing",{"tool":55,"command":56},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill end2end-testing",{"tool":58,"command":59},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill end2end-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fend2end-testing\u002FSKILL.md",true,[],[64,80,102,116,130,146],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":37},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[66,71,36,72,73,27,74,75,76,77,78,79],"user","replies","check","identity","whatsapp","gmail","read","message","ask",{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"publishedAt":37},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[82,92,93,94,95,96,97,98,99,100,101],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":37},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[108],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},[96,92,110,111,71,112,99,113,95,114,115,100,101],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":37},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[118,123,124,125,95,126,98,127,128,129],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":136,"publishedAt":37},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[137,138,139,27,140,95,141,142,143,144,145],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":150,"licenseFileUrl":151,"sourceHtmlUrl":152,"categories":153,"keywords":163,"publishedAt":37},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[154,157,160],{"categoryNo":155,"categoryName":156,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":158,"categoryName":159,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":161,"categoryName":162,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000032","设计师",[164,165,166,27,167,168,169,71,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,36,188],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]