[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MD10CYC4831NP6180ZMC1":3,"skill-same:01M71MD10CYC4831NP6180ZMC1":99},{"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":34,"publishedAt":55,"linkOnly":56,"markdownContent":57,"markdownBody":58,"frontMatter":59,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":14,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":70,"install":71,"resources":84},"01M71MD10CYC4831NP6180ZMC1","api-testing",null,"Test REST and GraphQL APIs with Playwright APIRequestContext, Supertest, or standalone HTTP clients. Covers schema validation with Zod 4\u002FAJV, auth flow testing, CRUD lifecycle tests, error and header validation, pagination, and performance assertions. Use when: \"API test,\" \"endpoint test,\" \"REST test,\" \"GraphQL test,\" \"schema validation,\" \"Postman replacement.\" Not for: consumer-driven contract verification (Pact, broker) — use contract-testing; browser UI flows — use playwright-automation. Related: contract-testing, test-data-management, ci-cd-integration, playwright-automation.","pattanation\u002FNorvik","pattanation","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F235419268?v=4","01M71M5THHYYB15ME8R2E4FCZG","Patta","01M71M5TJM1NDM992M8PDKYR2K",0,"MIT","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fapi-testing\u002FSKILL.md",[18,23,26,29],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":30,"categoryName":31,"taxonomyType":32,"taxonomyTypeDesc":33},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"api","api testing","testing","ui","data","flow","verification","browser","crud","when","zod 4","postman","ci","flows","performance","auth","zod","api test","standalone","error","2026-11-10 10:56:23",false,"---\nname: api-testing\ndescription: >-\n  Test REST and GraphQL APIs with Playwright APIRequestContext, Supertest, or standalone\n  HTTP clients. Covers schema validation with Zod 4\u002FAJV, auth flow testing, CRUD lifecycle\n  tests, error and header validation, pagination, and performance assertions. Use when:\n  \"API test,\" \"endpoint test,\" \"REST test,\" \"GraphQL test,\" \"schema validation,\" \"Postman replacement.\"\n  Not for: consumer-driven contract verification (Pact, broker) — use contract-testing; browser UI flows — use playwright-automation.\n  Related: contract-testing, test-data-management, ci-cd-integration, playwright-automation.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: automation\n---\n\n\u003Cobjective>\nA response that adds a nullable field or quietly drops one slips past `toHaveProperty` spot-checks and silently breaks the frontend in production. Schema-as-contract tests catch that drift in CI, not prod. This skill produces REST and GraphQL API tests that assert response shape, status codes, headers, auth boundaries, and timing — against a real test environment, not a mocked stand-in.\n\u003C\u002Fobjective>\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then:\n\n1. **REST, GraphQL, or both?** REST-only suites use standard HTTP assertions. GraphQL needs query\u002Fmutation builders and benefits from an introspection-diff snapshot.\n2. **Auth mechanism?** JWT, API key, OAuth 2.0, or session cookies — each needs a different fixture strategy.\n3. **OpenAPI\u002FSwagger spec available?** If yes, auto-generate Zod schemas as contracts (`orval`, `openapi-zod-client`) and consider spec-driven fuzzing with Schemathesis.\n\n---\n\n## Core Principles\n\n1. **Test contracts, not implementations.** Assert on response shape, status codes, and headers — not on internal logic or database state.\n2. **Schema validation catches drift before it breaks consumers.** A failing schema test means you caught a breaking change before your frontend did.\n3. **Auth flows are tests too — don't just hardcode tokens.** Test login, refresh, expiration, and permission boundaries.\n4. **Response time is a testable assertion.** Performance regressions caught in CI are cheaper than production incidents.\n\n---\n\n## Exploratory vs Automated: Tooling\n\nAPI exploration (debugging, manual probing, OpenAPI playground) and automated API testing are different jobs. Use the right tool for each:\n\n| Tool | Best for | Why |\n|------|----------|-----|\n| **Bruno** (v3.4+) | File-based collections, git-reviewable workflows, FOSS Postman replacement | Filesystem-first, no cloud sync required; gRPC + OAuth + GraphQL query builder |\n| **Hurl** (8.x) | Plain-text HTTP testing, CI smoke checks | One file = many requests + assertions; runs anywhere curl runs; certificate + JSONPath (RFC 9535) queries |\n| **Hoppscotch** | Web-based Postman-style exploration | Open source, runs in browser, good for quick checks |\n| **Playwright `APIRequestContext`** | Automated tests in your test runner | This skill's focus — covered below |\n| **Supertest** (Node) \u002F **httpx** (Python) | In-process API tests against your own app | Fastest feedback when you control both sides |\n\nSkip Postman\u002FInsomnia for new projects unless your team already has investment there — file-based tools (Bruno, Hurl) are easier to review in PRs and survive when collections drift.\n\n## Playwright API Testing\n\n`APIRequestContext` supports standalone API tests without launching a browser and shares cookie\u002Fstorage state with browser contexts. Use it for:\n\n- **Standalone API tests** — `request.get\u002Fpost\u002F...` with status, header, and body assertions.\n- **Combined browser + API tests** — seed data via API, assert it appears in the UI, then clean up via API.\n- **Authenticated fixtures** — log in once in a fixture, hand a pre-authenticated `APIRequestContext` to tests, and dispose it on teardown. Never hardcode tokens.\n\nSee `references\u002Fplaywright-setup.md` for the `playwright.config.ts`, standalone tests, combined browser+API test, and the authenticated API fixture.\n\n---\n\n## Schema Validation\n\nValidate response shape against a schema rather than spot-checking individual fields with `toHaveProperty`. Two common approaches:\n\n- **Zod 4** — define a schema, `safeParse` the response, and assert `result.success`. Log `result.error.issues` on failure for a precise diff. Use the Zod 4 native string formats: `z.email()`, `z.uuid()`, `z.iso.datetime()` — the chained `z.string().email()` forms are deprecated and slated for removal.\n- **AJV with JSON Schema** — when you already have JSON Schema (e.g. from an OpenAPI spec), compile and validate with `ajv` + `ajv-formats`.\n\n**Schema-as-contract:** have both the API and the tests import the same schema file. If the response shape changes, consumer tests fail immediately. With an OpenAPI spec, auto-generate the schema (`orval` or `openapi-zod-client`). For spec-first teams, add **Schemathesis** as a CI job to fuzz the live API against the spec and catch undocumented shapes and edge-case 500s.\n\nSee `references\u002Fschema-validation.md` for the Zod 4, AJV, schema-as-contract, and Schemathesis implementations.\n\n---\n\n## Test Patterns\n\nCover each endpoint with a happy-path test plus at least one error-path test. The common patterns:\n\n- **CRUD lifecycle** — a `describe.serial` block that creates, reads, updates, deletes, then verifies the 404. Carries the resource id across steps.\n- **Auth flows** — login success, invalid credentials (401), expired token (401), token refresh, and permission boundary (403). Treat auth as its own describe block.\n- **Error responses** — 400 (malformed body), 422 (validation with field details), 429 (rate limit + `retry-after`). Don't ship happy-path-only suites.\n- **Response headers** — assert `content-type`, `cache-control`, and rate-limit headers directly (not behind a conditional that may never fire). See the pattern below.\n- **Pagination** — first-page metadata, out-of-bounds empty page, and rejection of invalid page size.\n- **File upload\u002Fdownload** — multipart upload and `content-disposition` header verification.\n- **GraphQL** — a small `gql` helper, then query \u002F mutation \u002F invalid-query (errors array) cases, plus an introspection-diff snapshot to catch silently-removed fields.\n- **Webhooks** — spin up a throwaway HTTP server, register a webhook, trigger the event, and assert delivery.\n\nSee `references\u002Ftest-patterns.md` for the full runnable implementations of every pattern above plus performance assertions.\n\n### Response Headers\n\nHeaders carry the contract: cache directives, rate-limit info, content type, CORS policy. Assert them with `response.headers()` and index by lowercase name; don't gate the assertion behind an `if (rateLimited)` that may not fire.\n\n```typescript\ntest('GET \u002Fapi\u002Fusers sets expected response headers', async ({ request }) => {\n  const response = await request.get('\u002Fapi\u002Fusers');\n  const headers = response.headers();\n\n  expect(headers).toBeDefined();\n  expect(headers['content-type']).toContain('application\u002Fjson');\n  expect(headers['cache-control']).toBeDefined();   \u002F\u002F \"no-store\" | \"max-age=60\" | ...\n});\n```\n\nFor the rate-limit and `retry-after` variants, see `references\u002Ftest-patterns.md` (Response Header Validation).\n\n---\n\n## Performance Assertions\n\nResponse time and payload size are testable assertions — assert that a hot endpoint responds within a budget (e.g. 500ms), that payloads stay under a size ceiling, and that the API survives a burst of concurrent requests without 5xx. See `references\u002Ftest-patterns.md` (Performance Assertions section) for the code.\n\n---\n\n## Anti-Patterns\n\n### 1. Hardcoded auth tokens\nTokens expire, rotate, and differ across environments. Use a login fixture that acquires tokens dynamically.\n\n### 2. Testing against production\nAPI tests create, modify, and delete data. Run against a dedicated test environment or local instance.\n\n### 3. Not validating error responses\nHappy-path-only suites miss the most common production issues. Test 400, 401, 403, 404, and 500 responses for every endpoint.\n\n### 4. Asserting headers only conditionally\nHeaders carry cache directives, rate limit info, content type, and CORS policy. Assert them directly on every relevant response — a check buried inside `if (rateLimited)` may never run and proves nothing.\n\n### 5. No cleanup after test data creation\nTests that create resources without deleting them pollute the database. Use `afterEach`\u002F`afterAll` hooks or fixture teardown.\n\n### 6. Treating API tests as unit tests\nDon't mock the database — API tests verify the contract from the consumer's perspective. Mock only genuine third parties you don't own (payment gateways, external SaaS).\n\n### 7. Ignoring idempotency\nPUT and DELETE should be idempotent. Test that calling them twice produces the same result.\n\n---\n\n## Done When\n\n- Every target endpoint has at least a happy-path test and at least one error-path test (4xx or 5xx response validated).\n- Auth flow tested as its own describe block: successful login, invalid credentials, expired token, and permission boundary (403).\n- Schema validation assertions on response shape using Zod 4 or AJV — not just `toHaveProperty` spot-checks.\n- Header assertions exist for at least `content-type` and any cache\u002Frate-limit headers the API sets, asserted unconditionally.\n- Contract tests in place for any endpoint consumed by a different team or service (shared schema file; for consumer-driven verification use `contract-testing`).\n- Genuine third-party calls (payment gateways, external SaaS) are mocked or virtualized; the API and its database run for real.\n- CI job for the suite exits 0 (green) against the test environment.\n\n## Reference Files (in `references\u002F`)\n\n- **playwright-setup.md** — `playwright.config.ts`, standalone API tests, combined browser+API tests, and the authenticated `APIRequestContext` fixture.\n- **schema-validation.md** — Zod 4 and AJV\u002FJSON-Schema response validation, the schema-as-contract pattern, and Schemathesis spec-driven fuzzing.\n- **test-patterns.md** — Runnable CRUD lifecycle, auth flows, error responses, response headers, pagination, file upload\u002Fdownload, GraphQL (+ introspection diff), webhook, and performance tests.\n\n## Related Skills\n\n- **contract-testing** — Consumer-driven contract verification with Pact\u002Fbroker; go there when a separate team consumes your API and you need guaranteed compatibility, not just a shared schema.\n- **playwright-automation** — Browser-based E2E testing, Page Object Model, and combined browser + API patterns.\n- **ci-cd-integration** — Running API test suites in CI pipelines, parallelization, and environment management.\n- **test-strategy** — Deciding what to test at the API layer vs. unit vs. E2E.\n","\u003Cobjective>\nA response that adds a nullable field or quietly drops one slips past `toHaveProperty` spot-checks and silently breaks the frontend in production. Schema-as-contract tests catch that drift in CI, not prod. This skill produces REST and GraphQL API tests that assert response shape, status codes, headers, auth boundaries, and timing — against a real test environment, not a mocked stand-in.\n\u003C\u002Fobjective>\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then:\n\n1. **REST, GraphQL, or both?** REST-only suites use standard HTTP assertions. GraphQL needs query\u002Fmutation builders and benefits from an introspection-diff snapshot.\n2. **Auth mechanism?** JWT, API key, OAuth 2.0, or session cookies — each needs a different fixture strategy.\n3. **OpenAPI\u002FSwagger spec available?** If yes, auto-generate Zod schemas as contracts (`orval`, `openapi-zod-client`) and consider spec-driven fuzzing with Schemathesis.\n\n---\n\n## Core Principles\n\n1. **Test contracts, not implementations.** Assert on response shape, status codes, and headers — not on internal logic or database state.\n2. **Schema validation catches drift before it breaks consumers.** A failing schema test means you caught a breaking change before your frontend did.\n3. **Auth flows are tests too — don't just hardcode tokens.** Test login, refresh, expiration, and permission boundaries.\n4. **Response time is a testable assertion.** Performance regressions caught in CI are cheaper than production incidents.\n\n---\n\n## Exploratory vs Automated: Tooling\n\nAPI exploration (debugging, manual probing, OpenAPI playground) and automated API testing are different jobs. Use the right tool for each:\n\n| Tool | Best for | Why |\n|------|----------|-----|\n| **Bruno** (v3.4+) | File-based collections, git-reviewable workflows, FOSS Postman replacement | Filesystem-first, no cloud sync required; gRPC + OAuth + GraphQL query builder |\n| **Hurl** (8.x) | Plain-text HTTP testing, CI smoke checks | One file = many requests + assertions; runs anywhere curl runs; certificate + JSONPath (RFC 9535) queries |\n| **Hoppscotch** | Web-based Postman-style exploration | Open source, runs in browser, good for quick checks |\n| **Playwright `APIRequestContext`** | Automated tests in your test runner | This skill's focus — covered below |\n| **Supertest** (Node) \u002F **httpx** (Python) | In-process API tests against your own app | Fastest feedback when you control both sides |\n\nSkip Postman\u002FInsomnia for new projects unless your team already has investment there — file-based tools (Bruno, Hurl) are easier to review in PRs and survive when collections drift.\n\n## Playwright API Testing\n\n`APIRequestContext` supports standalone API tests without launching a browser and shares cookie\u002Fstorage state with browser contexts. Use it for:\n\n- **Standalone API tests** — `request.get\u002Fpost\u002F...` with status, header, and body assertions.\n- **Combined browser + API tests** — seed data via API, assert it appears in the UI, then clean up via API.\n- **Authenticated fixtures** — log in once in a fixture, hand a pre-authenticated `APIRequestContext` to tests, and dispose it on teardown. Never hardcode tokens.\n\nSee `references\u002Fplaywright-setup.md` for the `playwright.config.ts`, standalone tests, combined browser+API test, and the authenticated API fixture.\n\n---\n\n## Schema Validation\n\nValidate response shape against a schema rather than spot-checking individual fields with `toHaveProperty`. Two common approaches:\n\n- **Zod 4** — define a schema, `safeParse` the response, and assert `result.success`. Log `result.error.issues` on failure for a precise diff. Use the Zod 4 native string formats: `z.email()`, `z.uuid()`, `z.iso.datetime()` — the chained `z.string().email()` forms are deprecated and slated for removal.\n- **AJV with JSON Schema** — when you already have JSON Schema (e.g. from an OpenAPI spec), compile and validate with `ajv` + `ajv-formats`.\n\n**Schema-as-contract:** have both the API and the tests import the same schema file. If the response shape changes, consumer tests fail immediately. With an OpenAPI spec, auto-generate the schema (`orval` or `openapi-zod-client`). For spec-first teams, add **Schemathesis** as a CI job to fuzz the live API against the spec and catch undocumented shapes and edge-case 500s.\n\nSee `references\u002Fschema-validation.md` for the Zod 4, AJV, schema-as-contract, and Schemathesis implementations.\n\n---\n\n## Test Patterns\n\nCover each endpoint with a happy-path test plus at least one error-path test. The common patterns:\n\n- **CRUD lifecycle** — a `describe.serial` block that creates, reads, updates, deletes, then verifies the 404. Carries the resource id across steps.\n- **Auth flows** — login success, invalid credentials (401), expired token (401), token refresh, and permission boundary (403). Treat auth as its own describe block.\n- **Error responses** — 400 (malformed body), 422 (validation with field details), 429 (rate limit + `retry-after`). Don't ship happy-path-only suites.\n- **Response headers** — assert `content-type`, `cache-control`, and rate-limit headers directly (not behind a conditional that may never fire). See the pattern below.\n- **Pagination** — first-page metadata, out-of-bounds empty page, and rejection of invalid page size.\n- **File upload\u002Fdownload** — multipart upload and `content-disposition` header verification.\n- **GraphQL** — a small `gql` helper, then query \u002F mutation \u002F invalid-query (errors array) cases, plus an introspection-diff snapshot to catch silently-removed fields.\n- **Webhooks** — spin up a throwaway HTTP server, register a webhook, trigger the event, and assert delivery.\n\nSee `references\u002Ftest-patterns.md` for the full runnable implementations of every pattern above plus performance assertions.\n\n### Response Headers\n\nHeaders carry the contract: cache directives, rate-limit info, content type, CORS policy. Assert them with `response.headers()` and index by lowercase name; don't gate the assertion behind an `if (rateLimited)` that may not fire.\n\n```typescript\ntest('GET \u002Fapi\u002Fusers sets expected response headers', async ({ request }) => {\n  const response = await request.get('\u002Fapi\u002Fusers');\n  const headers = response.headers();\n\n  expect(headers).toBeDefined();\n  expect(headers['content-type']).toContain('application\u002Fjson');\n  expect(headers['cache-control']).toBeDefined();   \u002F\u002F \"no-store\" | \"max-age=60\" | ...\n});\n```\n\nFor the rate-limit and `retry-after` variants, see `references\u002Ftest-patterns.md` (Response Header Validation).\n\n---\n\n## Performance Assertions\n\nResponse time and payload size are testable assertions — assert that a hot endpoint responds within a budget (e.g. 500ms), that payloads stay under a size ceiling, and that the API survives a burst of concurrent requests without 5xx. See `references\u002Ftest-patterns.md` (Performance Assertions section) for the code.\n\n---\n\n## Anti-Patterns\n\n### 1. Hardcoded auth tokens\nTokens expire, rotate, and differ across environments. Use a login fixture that acquires tokens dynamically.\n\n### 2. Testing against production\nAPI tests create, modify, and delete data. Run against a dedicated test environment or local instance.\n\n### 3. Not validating error responses\nHappy-path-only suites miss the most common production issues. Test 400, 401, 403, 404, and 500 responses for every endpoint.\n\n### 4. Asserting headers only conditionally\nHeaders carry cache directives, rate limit info, content type, and CORS policy. Assert them directly on every relevant response — a check buried inside `if (rateLimited)` may never run and proves nothing.\n\n### 5. No cleanup after test data creation\nTests that create resources without deleting them pollute the database. Use `afterEach`\u002F`afterAll` hooks or fixture teardown.\n\n### 6. Treating API tests as unit tests\nDon't mock the database — API tests verify the contract from the consumer's perspective. Mock only genuine third parties you don't own (payment gateways, external SaaS).\n\n### 7. Ignoring idempotency\nPUT and DELETE should be idempotent. Test that calling them twice produces the same result.\n\n---\n\n## Done When\n\n- Every target endpoint has at least a happy-path test and at least one error-path test (4xx or 5xx response validated).\n- Auth flow tested as its own describe block: successful login, invalid credentials, expired token, and permission boundary (403).\n- Schema validation assertions on response shape using Zod 4 or AJV — not just `toHaveProperty` spot-checks.\n- Header assertions exist for at least `content-type` and any cache\u002Frate-limit headers the API sets, asserted unconditionally.\n- Contract tests in place for any endpoint consumed by a different team or service (shared schema file; for consumer-driven verification use `contract-testing`).\n- Genuine third-party calls (payment gateways, external SaaS) are mocked or virtualized; the API and its database run for real.\n- CI job for the suite exits 0 (green) against the test environment.\n\n## Reference Files (in `references\u002F`)\n\n- **playwright-setup.md** — `playwright.config.ts`, standalone API tests, combined browser+API tests, and the authenticated `APIRequestContext` fixture.\n- **schema-validation.md** — Zod 4 and AJV\u002FJSON-Schema response validation, the schema-as-contract pattern, and Schemathesis spec-driven fuzzing.\n- **test-patterns.md** — Runnable CRUD lifecycle, auth flows, error responses, response headers, pagination, file upload\u002Fdownload, GraphQL (+ introspection diff), webhook, and performance tests.\n\n## Related Skills\n\n- **contract-testing** — Consumer-driven contract verification with Pact\u002Fbroker; go there when a separate team consumes your API and you need guaranteed compatibility, not just a shared schema.\n- **playwright-automation** — Browser-based E2E testing, Page Object Model, and combined browser + API patterns.\n- **ci-cd-integration** — Running API test suites in CI pipelines, parallelization, and environment management.\n- **test-strategy** — Deciding what to test at the API layer vs. unit vs. E2E.\n",{"name":5,"license":15,"metadata":60,"description":7},{"author":61,"version":62,"category":63},"kindlmann","2.0","automation","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fapi-testing","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik","https:\u002F\u002Fnorvik-orpin.vercel.app","https:\u002F\u002Fgithub.com\u002Fpattanation","2026-07-17 11:17:04",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add pattanation\u002FNorvik --skill api-testing",{"tool":77,"command":78},"bunx","bunx skills add pattanation\u002FNorvik --skill api-testing",{"tool":80,"command":81},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill api-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fapi-testing\u002FSKILL.md",true,[85,91,95],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fplaywright-setup.md","REFERENCE","参考文档",2707,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fapi-testing\u002Freferences\u002Fplaywright-setup.md",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fschema-validation.md",3747,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fapi-testing\u002Freferences\u002Fschema-validation.md",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Ftest-patterns.md",10872,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fapi-testing\u002Freferences\u002Ftest-patterns.md",[100,128,154,177,199,214],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":104,"licenseFileUrl":105,"sourceHtmlUrl":106,"categories":107,"keywords":112,"publishedAt":127},"01M71QDV4DM8T19HEHWATEF1K4","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fwebapp-testing\u002FSKILL.md",[108,109],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[113,37,114,115,116,117,118,119,120,121,42,122,123,124,125,38,126],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","with","playwright","web","behavior","screenshots","2026-11-10 13:02:02",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":104,"licenseFileUrl":132,"sourceHtmlUrl":133,"categories":134,"keywords":136,"publishedAt":127},"01M71QDH2GGMXGA9105C9W1N7B","web-artifacts-builder","Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn\u002Fui). Use for complex artifacts requiring state management, routing, or shadcn\u002Fui components - not for simple single-file HTML\u002FJSX artifacts.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fweb-artifacts-builder\u002FSKILL.md",[135],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[137,138,139,124,140,141,142,115,143,144,118,145,146,147,148,149,150,151,152,153],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":158,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":127},"01M71QD9T2XC3EWMQNN9ACNWQ1","vueuse-functions","Apply VueUse composables where appropriate to build concise, maintainable Vue.js \u002F Nuxt features.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvueuse-functions\u002FSKILL.md",[161],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[163,164,165,166,167,168,169,170,171,172,173,174,175,176],"functions","vueuse","vueuse functions","project","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":181,"sourceHtmlUrl":182,"categories":183,"keywords":186,"publishedAt":127},"01M71QD51HWSGYMCMB7RW7PGK8","vue-testing-best-practices","Use for Vue.js testing. Covers Vitest, Vue Test Utils, component testing, mocking, testing patterns, and Playwright for E2E testing.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-testing-best-practices\u002FSKILL.md",[184,185],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[187,37,188,174,189,123,190,191,192,169,193,115,194,195,196,146,197,175,198],"vue testing best practices","testing best practices","best practices","test","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":200,"name":201,"nameZh":6,"description":202,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":203,"sourceHtmlUrl":204,"categories":205,"keywords":207,"publishedAt":127},"01M71QD358H2DJ9THJRBP77T3T","vue-router-best-practices","Vue Router 4 patterns, navigation guards, route params, and route-component lifecycle interactions.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-router-best-practices\u002FSKILL.md",[206],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[208,174,209,189,210,192,211,169,197,212,213],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":215,"name":216,"nameZh":6,"description":217,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":218,"sourceHtmlUrl":219,"categories":220,"keywords":222,"publishedAt":127},"01M71QCYPNWDE2MQZ1TF3ED5S4","vue-best-practices","MUST be used for Vue.js tasks. Strongly recommends Composition API with `\u003Cscript setup>` and TypeScript as the standard approach. Covers Vue 3, SSR, Volar, vue-tsc. Load for any Vue, .vue files, Vue Router, Pinia, or Vite with Vue work. ALWAYS use Composition API unless the project explicitly requires Options API.","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FLICENSE.md","https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fvue-best-practices\u002FSKILL.md",[221],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},[223,174,189,224,166,225,226,35,208,227,228,229,230,231,232,115,233,146,234,235],"vue best practices","Composition","files","tasks","pinia","work","options","ssr","typescript","as","vite","load","standard"]