[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71Q3A4RF400N6X5M1ADHACK":3,"skill-same:01M71Q3A4RF400N6X5M1ADHACK":91},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":14,"repositoryHtmlUrl":59,"repositoryHomepageUrl":60,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M71Q3A4RF400N6X5M1ADHACK","test-case-management",null,"Author and maintain MANUAL and hybrid test cases and suites in TestRail, Xray (Jira), Zephyr Scale, and Qase. Covers test-case anatomy (title, preconditions, steps, expected results, test data), suite\u002Fsection organization, bulk authoring from user stories and acceptance criteria, ambiguous-step linting, CSV\u002FAPI import-export payloads per tool, requirement traceability and coverage gaps, review hygiene, and when a manual case should graduate to automation. Use when: \"write a test case,\" \"manual test case,\" \"TestRail case,\" \"Xray test,\" \"Zephyr Scale case,\" \"Qase case,\" \"import CSV into TestRail,\" \"lint these steps,\" \"traceability report,\" \"should this be automated.\" Not for: Generating automated TEST CODE — that is ai-test-generation. Sprint-level WHAT-to-test selection — that is test-planning. Related: ai-test-generation, test-planning, exploratory-testing, qa-project-context.","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\u002Ftest-case-management\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000004","电子表格","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"test case management","management","test","case","tool","section","traceability","for","hybrid","import","zephyr","context","test cases","steps","authoring","jira","write","selection","testing","project","2026-11-10 13:02:02",false,"---\nname: test-case-management\ndescription: >-\n  Author and maintain MANUAL and hybrid test cases and suites in TestRail, Xray (Jira),\n  Zephyr Scale, and Qase. Covers test-case anatomy (title, preconditions, steps, expected\n  results, test data), suite\u002Fsection organization, bulk authoring from user stories and\n  acceptance criteria, ambiguous-step linting, CSV\u002FAPI import-export payloads per tool,\n  requirement traceability and coverage gaps, review hygiene, and when a manual case should\n  graduate to automation.\n  Use when: \"write a test case,\" \"manual test case,\" \"TestRail case,\" \"Xray test,\" \"Zephyr\n  Scale case,\" \"Qase case,\" \"import CSV into TestRail,\" \"lint these steps,\" \"traceability\n  report,\" \"should this be automated.\"\n  Not for: Generating automated TEST CODE — that is ai-test-generation. Sprint-level\n  WHAT-to-test selection — that is test-planning.\n  Related: ai-test-generation, test-planning, exploratory-testing, qa-project-context.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"1.0\"\n  category: process\n---\n\n\u003Cobjective>\nA manual test case that says \"test the login\" with expected result \"verify it works\" passes\nevery review and catches nothing — two testers run it differently and neither can say whether\nit failed. This skill produces deterministic cases (discrete steps, one observable expected\nresult each, concrete test data), organizes them into navigable suites, and emits the\ntool-correct API\u002FCSV payloads for TestRail, Xray Cloud, Zephyr Scale, and Qase — whose\nlook-alike APIs use different auth schemes, endpoints, and step-field names that agents\nroutinely cross-wire.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Request | Go to |\n|---------|-------|\n| Write one well-formed case from an AC | [Test-Case Anatomy](#test-case-anatomy) |\n| Bulk-generate cases from a story | [Bulk Authoring](#bulk-authoring-from-stories) + tool section |\n| \"Lint these steps \u002F are these verifiable?\" | [Ambiguous-Step Linting](#ambiguous-step-linting) + `references\u002Flinting.md` |\n| TestRail \u002F Xray \u002F Zephyr \u002F Qase API payload | [Tool Payloads](#tool-payloads) + `references\u002Ftool-apis.md` |\n| CSV to import into TestRail | `references\u002Fimport-and-traceability.md` (CSV section) |\n| Organize suites\u002Fsections | `references\u002Fimport-and-traceability.md` (organization) |\n| Requirements ↔ tests, coverage gaps | [Traceability](#traceability) + `references\u002Fimport-and-traceability.md` |\n| Manual → automation decision | [Automation Graduation](#automation-graduation) |\n\n## Discovery Questions\n\nFirst, check `.agents\u002Fqa-project-context.md` in the project root for the tool, project keys,\nand conventions; skip anything answered there. If it's missing, suggest creating one with the\n`qa-project-context` skill. Then clarify:\n\n- **Which tool — TestRail, Xray, Zephyr Scale, or Qase?** Each has a different API auth scheme,\n  endpoint shape, and step-field name. Getting this wrong produces payloads that 401 or 400.\n- **TestRail only: single-repository mode or multiple suites?** Changes whether cases live under\n  sections in one suite or in separate suites — affects every `section_id` and the org plan.\n- **Xray\u002FZephyr only: Jira Cloud or Server\u002FDC?** Cloud and Server use different base paths and\n  auth. This skill targets Cloud; Server uses different endpoints.\n- **Source of the cases — acceptance criteria, a user story, a free-form feature?** Drives how\n  many cases to generate and how to split rules.\n- **Do you need requirement traceability?** If yes, capture the Jira\u002Frequirement issue keys now\n  so cases link on creation rather than being back-filled.\n\n---\n\n## Core Principles\n\n1. **An expected result must be deterministically checkable.** A second human (or a machine)\n   must be able to agree on pass\u002Ffail without guessing. \"Works\", \"looks right\", \"is fine\",\n   \"wait a bit\" fail this test. Name an exact value, a named element and its state, a specific\n   message, a status code, a count, or a time-bounded condition.\n\n2. **One assertion per step.** Each step has a single expected result. Cramming three checks\n   into one step makes a failure ambiguous about which check broke and which to re-run.\n\n3. **One case per business rule, not one giant case.** \"Valid code reduces total \u002F expired code\n   errors \u002F used code rejected\" is three cases with three independent pass\u002Ffail verdicts — not\n   one case with a paragraph of expecteds.\n\n4. **The tool's API is the spec — don't cross-wire the four tools.** TestRail's\n   `custom_steps_separated`, Qase's `Token` header, Xray's two-step GraphQL auth, and Zephyr's\n   separate `teststeps` call are NOT interchangeable. Copy from the right tool's section.\n\n5. **Traceability exists to surface what is NOT covered.** The deliverable is the list of\n   requirements with zero linked tests, from a native coverage report — not a spreadsheet that\n   rots and not \"every test links to something.\"\n\n6. **Automate by ROI, not by volume.** Limited capacity means stable, high-frequency,\n   regression\u002Fsmoke cases graduate first; exploratory, one-off, and high-churn\u002Fflaky cases stay\n   manual. \"Automate everything\" wastes capacity on the worst candidates.\n\n---\n\n## Test-Case Anatomy\n\nA well-formed manual case has five parts. Every part is mandatory; a case missing preconditions\nor test data is not reproducible.\n\n| Part | What it holds | Failure if omitted |\n|------|---------------|--------------------|\n| **Title** | Feature — scenario — expected outcome, one line | Unsearchable, duplicated |\n| **Preconditions** | State the test assumes (account exists, on page X, flag on) | Tester guesses setup; flaky |\n| **Steps** | Discrete actions, one action per step | Non-reproducible |\n| **Expected Results** | One observable post-condition per step | Not verifiable |\n| **Test Data** | Concrete values used (codes, emails, counts, timings) | Not repeatable |\n\n**BAD** (single vague step, non-verifiable expected, no preconditions, no data):\n\n```\nTitle: Login test\nSteps: Test the login.\nExpected: Verify it works.\n```\n\n**GOOD** — from the AC \"after 5 wrong-password attempts, the account locks for 15 minutes\":\n\n```\nTitle: Login — account locks for 15 minutes after 5 failed attempts\nPreconditions: A registered account exists for user@example.com. The user is logged out\n               on the \u002Flogin page. Lockout policy: 5 attempts, 15-minute lockout.\nTest Data: email user@example.com, wrong password \"WrongPass!\", correct password \"Passw0rd!\"\nSteps (one assertion per step \u002F single expected result each):\n  1. Action:   Submit the login form with user@example.com and \"WrongPass!\".\n     Expected: Error \"Invalid email or password.\" shows; the failed-attempt count is now 1.\n  2. Action:   Repeat the wrong-password submit until 5 failed attempts total.\n     Expected: On the 5th failure the account is locked; message reads\n               \"Account locked. Try again in 15 minutes.\"\n  3. Action:   Immediately submit with the CORRECT password \"Passw0rd!\".\n     Expected: Login is still blocked; the same lockout message is shown (lockout overrides\n               valid credentials).\n  4. Action:   Wait 15 minutes, then submit with the correct password.\n     Expected: Login succeeds and the dashboard loads.\n```\n\nNote: explicit preconditions, concrete test data (5 attempts, 15-minute lockout), discrete\nsteps, and a single deterministic expected result per step.\n\n---\n\n## Bulk Authoring from Stories\n\nGiven a story or set of acceptance criteria, split into cases by rule, then generate the\ntool-specific payload. Worked example for the discount-code story (valid reduces total \u002F expired\nerrors \u002F already-used rejected) → **three** cases:\n\n1. Apply a valid code → total reduces (happy path).\n2. Apply an expired (invalid) code → inline error, total unchanged.\n3. Apply an already-used \u002F already-redeemed code → rejected, total unchanged.\n\nAdd the obvious negatives the story implies but doesn't state (empty code, malformed code) when\nthe team wants edge coverage. Each case gets discrete steps and one expected per step — never one\ngiant case covering all three rules. For the WHAT-to-test scope decision across a sprint, that's\n`test-planning`, not this skill.\n\n---\n\n## Ambiguous-Step Linting\n\nWhen asked to \"lint\" a suite, your job is to FLAG non-deterministic steps and rewrite them — NOT\nto agree that they \"look fine.\" The agreeable failure mode (rubber-stamping \"everything works\")\nis the exact thing this section prevents.\n\nA step is bad when its expected result is not deterministically verifiable. Flag any of:\n\n- **Vague action** — \"click around\", \"test the X\", \"play with it\" → name the exact element + action.\n- **Vague data** — \"some data\", \"a value\", \"stuff\" → give concrete test data.\n- **Non-observable expected** — \"everything works\", \"it looks right\", \"is fine\", \"no problems\"\n  → name the exact observable result.\n- **Unbounded wait** — \"wait a bit\", \"after a while\" → bound it (\"within 10 s\" \u002F \"until the\n  spinner disappears and a row appears\").\n- **Multiple assertions in one step** → split to one assertion per step.\n\nFor the classic four-step bad suite (\"app opens \u002F everything works \u002F it looks right \u002F the report\nis ready\"), all four are ambiguous and must be flagged and rewritten with explicit selectors,\nexact values, and bounded conditions — never returned as \"no issues found\". The full lint\nchecklist, the worked rewrite of those four steps, and the lint-output table format are in\n`references\u002Flinting.md`.\n\n---\n\n## Tool Payloads\n\nThe four tools are easy to cross-wire. Summary — full curl\u002FGraphQL bodies in\n`references\u002Ftool-apis.md`:\n\n| Tool | Auth | Create endpoint | Steps field |\n|------|------|-----------------|-------------|\n| **TestRail** | Basic `email:api_key` | `POST add_case\u002F{section_id}` | `custom_steps_separated` array of `{content, expected}` |\n| **Xray Cloud** | `POST \u002Fapi\u002Fv2\u002Fauthenticate` → Bearer token | GraphQL `createTest` at `\u002Fapi\u002Fv2\u002Fgraphql` | `steps[] {action, result}`; Gherkin → `testType: Cucumber` + `gherkin` |\n| **Zephyr Scale Cloud** | `Authorization: Bearer \u003CJWT>` | `POST \u002Fv2\u002Ftestcases` then `POST \u002Fv2\u002Ftestcases\u002F{key}\u002Fteststeps` | separate `teststeps` call, `inline {description, expectedResult, testData}` |\n| **Qase** | header `Token: \u003Ckey>` | `POST \u002Fv1\u002Fcase\u002F{CODE}\u002Fbulk` | `steps[] {action, expected_result, data}` |\n\nTool-specific traps that the reference spells out and you must respect:\n\n- **TestRail** — separated steps need `custom_steps_separated` (NOT the plain `custom_steps` text\n  blob); the endpoint is `add_case\u002F{section_id}` (NOT `add_test`, which is a run instance). Base\n  is `{instance}\u002Findex.php?\u002Fapi\u002Fv2`. Don't use a Qase-style `POST \u002Fcase`.\n- **Xray Cloud** — authenticate first (`\u002Fapi\u002Fv2\u002Fauthenticate` with client_id\u002Fclient_secret →\n  bearer, 24h), then prefer **GraphQL** `createTest`. Import Gherkin as a **Cucumber** test, not\n  a Generic one. Avoid the deprecated Cloud path `\u002Frest\u002Fraven\u002F1.0\u002F...` and Server-style REST and\n  Jira username\u002Fpassword basic auth.\n- **Zephyr Scale Cloud** — base is `api.zephyrscale.smartbear.com\u002Fv2` with JWT Bearer. Steps are a\n  SEPARATE `\u002Ftestcases\u002F{key}\u002Fteststeps` call, not a text blob in the create body. Don't emit `\u002Fv1\u002F`,\n  the wrong host, or Qase's `Token` header.\n- **Qase** — auth is `Token: \u003Ckey>`, NOT `Authorization: Bearer`. Use `POST \u002Fcase\u002F{CODE}\u002Fbulk`\n  with a `cases` array instead of N single POSTs. Don't use TestRail's `add_case` \u002F\n  `custom_steps_separated`.\n\nCSV import for TestRail (header row mapped to importer fields: `Title`, `Section Hierarchy`,\n`Steps (Separated)`, `Expected Result`, `Priority`, `Type`, `Preconditions`) is in\n`references\u002Fimport-and-traceability.md` — use a real CSV with a header row, never free-form prose\nor a single Description column, and never JSON when CSV was requested.\n\n---\n\n## Organization\n\nUse **sections and subsections** for hierarchy, kept **shallow** (3–4 levels). For a web + mobile\nproduct the default is **single-repository mode** with top-level sections per platform\n(`Web`, `Mobile (iOS)`, `Mobile (Android)`, `Shared \u002F API`), feature sections beneath. Split into\n**multiple suites** only when platforms are owned by separate teams with separate cadences.\n\nAvoid: one folder per test case, deep nesting 7+ levels deep, dumping every case in the root\nsection, and duplicating the same case across suites (keep one source of truth). The\nsingle-repository vs multiple-suites trade-off and the full org rules are in\n`references\u002Fimport-and-traceability.md`.\n\n---\n\n## Traceability\n\nGoal: a coverage report that shows which **stories have no tests** — the uncovered requirements.\n\nFor **Xray on Jira**: from each Test, add the native **\"tests\" issue link** to the requirement's\nJira issue key (NOT to a Test Execution — that records runs, not coverage). Read per-story\ncoverage from the Story's Test Coverage panel, and project-wide from the **Traceability Report \u002F\nRequirement Coverage report**. Then filter for requirements with **0 linked tests** — those are\nthe gaps to close. Do not propose a manual spreadsheet as the only traceability mechanism, and do\nnot ignore uncovered requirements. Zephyr Scale, Qase, and TestRail equivalents (issue links +\ntheir coverage\u002Ftraceability views) are in `references\u002Fimport-and-traceability.md`.\n\n---\n\n## Automation Graduation\n\nScore each manual case by ROI: `value ≈ run_frequency × regression_importance ÷ (automation_cost\n× expected_maintenance)`. With limited capacity (e.g. a 400-case Zephyr Scale backlog):\n\n- **Automate first:** high-frequency cases (run every release \u002F regression \u002F smoke), on stable \u002F\n  low-churn \u002F deterministic features, that guard critical regression or smoke paths.\n- **Stay manual:** exploratory or one-off cases, rarely-run cases, high-churn UI still in flux,\n  flaky \u002F non-deterministic behavior, and cases needing human judgment.\n\nReject \"automate everything\" and \"automate the flaky, frequently changing UI first\" — both spend\nscarce capacity on the worst-ROI candidates. Full decision rule in\n`references\u002Fimport-and-traceability.md`. Once a case graduates, the actual test code is written\nwith `ai-test-generation` or a framework skill (`playwright-automation`, `api-testing`) — not\nhere.\n\n---\n\n## Review Hygiene\n\n- Every case is reviewable in one screen: title states the outcome, preconditions present, steps\n  discrete, each expected observable, test data concrete.\n- Run the lint checklist on a new case before it merges; reject non-deterministic expecteds.\n- Link to the requirement at creation time, not as a back-fill.\n- Tag the suite (smoke \u002F regression \u002F platform) so runs can filter; an untagged 400-case repo is\n  unusable for release selection.\n\n---\n\n## Anti-Patterns\n\n### 1. One vague step with a \"verify it works\" expected\n\"Test the login → verify it works\" is unrunnable. Write discrete steps, one observable expected\neach, explicit preconditions, concrete test data.\n\n### 2. Rubber-stamping a suite when asked to lint it\nSaying steps \"look fine\" or lightly rewording while leaving \"everything works\" and \"wait a bit\"\nin place is the failure linting exists to catch. Flag every non-verifiable expected and rewrite it.\n\n### 3. Cross-wiring the four tools' APIs\nBearer on Qase (it uses `Token`), `add_case`\u002F`custom_steps_separated` on Qase or Zephyr,\n`\u002Frest\u002Fraven\u002F1.0\u002F` on Xray Cloud, `\u002Fv1\u002F` on Zephyr Scale Cloud, steps as a text blob in Zephyr's\ncreate body. Each is a 4xx or a silent wrong-field. Copy from the correct tool section.\n\n### 4. One giant case for a multi-rule story\nFolding \"valid \u002F expired \u002F already-used\" into one case yields a single pass\u002Ffail that hides which\nrule broke. One case per rule.\n\n### 5. CSV as free-form prose or a single Description column\nA TestRail import without a header row mapped to importer fields needs manual remapping. Provide\n`Title`, `Section Hierarchy`, `Steps (Separated)`, `Expected Result`, etc.\n\n### 6. Deep nesting and per-case folders\n7+ level trees and one-folder-per-case make the repository unnavigable. Keep 3–4 shallow levels of\nsections; platform at the top for web+mobile.\n\n### 7. Traceability as a manual spreadsheet\nA hand-kept sheet can't reliably answer \"which stories have no tests.\" Use the tool's native\nrequirement→test link and coverage\u002FTraceability report, and surface the uncovered requirements.\n\n### 8. Automate-everything \u002F automate-the-flaky-first\nAutomating one-off exploratory cases or high-churn\u002Fflaky UI first burns capacity for negative ROI.\nSequence stable high-frequency regression\u002Fsmoke first.\n\n---\n\n## Verification\n\nProve the produced artifact actually works before handing it off, smallest check first:\n\n- **Lint your own output:** grep the generated cases for the banned expecteds —\n  `grep -niE \"verify it works|looks right|is fine|wait a bit|no problems|everything works\" cases.*`\n  must return nothing. Any hit is a non-deterministic expected to rewrite.\n- **TestRail CSV:** open it and confirm a header row exists with `Title`, `Section Hierarchy`,\n  `Steps (Separated)`, `Expected Result` — `head -1 cases.csv` should show those columns, not a\n  single `Description`. Dry-run the import wizard; the wizard auto-matches columns with no manual\n  remapping when the headers are right.\n- **API payload, before the real POST:** validate the JSON (`jq . payload.json` exits 0) and\n  confirm the auth header and endpoint match the target tool's row in\n  [Tool Payloads](#tool-payloads) — Qase `Token:` not `Authorization: Bearer`, TestRail\n  `add_case\u002F{section_id}` not `add_test`. A `201`\u002Ftest-id in the response (or a `200` with the new\n  case `key` for Zephyr) confirms the create; a `401` means the auth scheme is cross-wired, a\n  `400` means the step field is.\n- **Traceability:** run the tool's coverage\u002FTraceability report and confirm it lists requirements\n  with 0 linked tests — an empty \"uncovered\" column means the links landed; a populated one is the\n  gap list to close.\n\n---\n\n## Done When\n\n- Each generated case has a title, preconditions, discrete steps, one observable expected result\n  per step, and concrete test data — no \"verify it works\" \u002F \"looks right\" \u002F \"wait a bit\" expecteds.\n- A multi-rule story produced one case per rule, not one combined case.\n- Any emitted API payload uses the correct tool's auth scheme, endpoint, and step-field name\n  (TestRail `custom_steps_separated`+`add_case\u002F{section_id}`; Xray two-step auth + GraphQL\n  `createTest`, Cucumber for Gherkin; Zephyr `\u002Fv2` Bearer + separate `\u002Fteststeps`; Qase `Token`\n  header + `\u002Fcase\u002F{CODE}\u002Fbulk`).\n- Any TestRail CSV has a header row mapping columns to importer fields (`Title`,\n  `Section Hierarchy`, `Steps (Separated)`, `Expected Result`).\n- A linted suite returns every ambiguous step flagged and rewritten — never \"no issues found\"\n  when smells are present.\n- Traceability uses the tool's native requirement→test link and a coverage report that lists the\n  uncovered requirements.\n- Automation graduation produces an ROI-ordered list (stable + high-frequency + regression\u002Fsmoke\n  first) and names what stays manual.\n\n---\n\n## Related Skills\n\n- **ai-test-generation** — go there to turn a graduated manual case into automated TEST CODE; this\n  skill stops at the manual\u002Fhybrid case and its import payload.\n- **test-planning** — go there for sprint\u002Frelease WHAT-to-test selection; this skill authors the\n  cases once the scope is decided.\n- **exploratory-testing** — the source of one-off\u002Fcharter-based cases that should stay manual;\n  pairs with the automation-graduation decision here.\n- **qa-project-context** — the universal dependency: the tool, project keys, and conventions this\n  skill reads before generating any payload.\n\n---\n\n## Reference Files (in `references\u002F`)\n\n- **tool-apis.md** — full TestRail \u002F Xray Cloud \u002F Zephyr Scale \u002F Qase create-case payloads\n  (curl + GraphQL), auth flows, and the per-tool cross-wiring traps.\n- **linting.md** — the ambiguous-step lint checklist, the worked rewrite of the four classic bad\n  steps, and the lint-output table format.\n- **import-and-traceability.md** — TestRail CSV column→field mapping with a 3-case example,\n  suite\u002Fsection organization rules, requirement traceability + coverage-gap reports, and the\n  automation-graduation decision rule.\n","\u003Cobjective>\nA manual test case that says \"test the login\" with expected result \"verify it works\" passes\nevery review and catches nothing — two testers run it differently and neither can say whether\nit failed. This skill produces deterministic cases (discrete steps, one observable expected\nresult each, concrete test data), organizes them into navigable suites, and emits the\ntool-correct API\u002FCSV payloads for TestRail, Xray Cloud, Zephyr Scale, and Qase — whose\nlook-alike APIs use different auth schemes, endpoints, and step-field names that agents\nroutinely cross-wire.\n\u003C\u002Fobjective>\n\n## Quick Route\n\n| Request | Go to |\n|---------|-------|\n| Write one well-formed case from an AC | [Test-Case Anatomy](#test-case-anatomy) |\n| Bulk-generate cases from a story | [Bulk Authoring](#bulk-authoring-from-stories) + tool section |\n| \"Lint these steps \u002F are these verifiable?\" | [Ambiguous-Step Linting](#ambiguous-step-linting) + `references\u002Flinting.md` |\n| TestRail \u002F Xray \u002F Zephyr \u002F Qase API payload | [Tool Payloads](#tool-payloads) + `references\u002Ftool-apis.md` |\n| CSV to import into TestRail | `references\u002Fimport-and-traceability.md` (CSV section) |\n| Organize suites\u002Fsections | `references\u002Fimport-and-traceability.md` (organization) |\n| Requirements ↔ tests, coverage gaps | [Traceability](#traceability) + `references\u002Fimport-and-traceability.md` |\n| Manual → automation decision | [Automation Graduation](#automation-graduation) |\n\n## Discovery Questions\n\nFirst, check `.agents\u002Fqa-project-context.md` in the project root for the tool, project keys,\nand conventions; skip anything answered there. If it's missing, suggest creating one with the\n`qa-project-context` skill. Then clarify:\n\n- **Which tool — TestRail, Xray, Zephyr Scale, or Qase?** Each has a different API auth scheme,\n  endpoint shape, and step-field name. Getting this wrong produces payloads that 401 or 400.\n- **TestRail only: single-repository mode or multiple suites?** Changes whether cases live under\n  sections in one suite or in separate suites — affects every `section_id` and the org plan.\n- **Xray\u002FZephyr only: Jira Cloud or Server\u002FDC?** Cloud and Server use different base paths and\n  auth. This skill targets Cloud; Server uses different endpoints.\n- **Source of the cases — acceptance criteria, a user story, a free-form feature?** Drives how\n  many cases to generate and how to split rules.\n- **Do you need requirement traceability?** If yes, capture the Jira\u002Frequirement issue keys now\n  so cases link on creation rather than being back-filled.\n\n---\n\n## Core Principles\n\n1. **An expected result must be deterministically checkable.** A second human (or a machine)\n   must be able to agree on pass\u002Ffail without guessing. \"Works\", \"looks right\", \"is fine\",\n   \"wait a bit\" fail this test. Name an exact value, a named element and its state, a specific\n   message, a status code, a count, or a time-bounded condition.\n\n2. **One assertion per step.** Each step has a single expected result. Cramming three checks\n   into one step makes a failure ambiguous about which check broke and which to re-run.\n\n3. **One case per business rule, not one giant case.** \"Valid code reduces total \u002F expired code\n   errors \u002F used code rejected\" is three cases with three independent pass\u002Ffail verdicts — not\n   one case with a paragraph of expecteds.\n\n4. **The tool's API is the spec — don't cross-wire the four tools.** TestRail's\n   `custom_steps_separated`, Qase's `Token` header, Xray's two-step GraphQL auth, and Zephyr's\n   separate `teststeps` call are NOT interchangeable. Copy from the right tool's section.\n\n5. **Traceability exists to surface what is NOT covered.** The deliverable is the list of\n   requirements with zero linked tests, from a native coverage report — not a spreadsheet that\n   rots and not \"every test links to something.\"\n\n6. **Automate by ROI, not by volume.** Limited capacity means stable, high-frequency,\n   regression\u002Fsmoke cases graduate first; exploratory, one-off, and high-churn\u002Fflaky cases stay\n   manual. \"Automate everything\" wastes capacity on the worst candidates.\n\n---\n\n## Test-Case Anatomy\n\nA well-formed manual case has five parts. Every part is mandatory; a case missing preconditions\nor test data is not reproducible.\n\n| Part | What it holds | Failure if omitted |\n|------|---------------|--------------------|\n| **Title** | Feature — scenario — expected outcome, one line | Unsearchable, duplicated |\n| **Preconditions** | State the test assumes (account exists, on page X, flag on) | Tester guesses setup; flaky |\n| **Steps** | Discrete actions, one action per step | Non-reproducible |\n| **Expected Results** | One observable post-condition per step | Not verifiable |\n| **Test Data** | Concrete values used (codes, emails, counts, timings) | Not repeatable |\n\n**BAD** (single vague step, non-verifiable expected, no preconditions, no data):\n\n```\nTitle: Login test\nSteps: Test the login.\nExpected: Verify it works.\n```\n\n**GOOD** — from the AC \"after 5 wrong-password attempts, the account locks for 15 minutes\":\n\n```\nTitle: Login — account locks for 15 minutes after 5 failed attempts\nPreconditions: A registered account exists for user@example.com. The user is logged out\n               on the \u002Flogin page. Lockout policy: 5 attempts, 15-minute lockout.\nTest Data: email user@example.com, wrong password \"WrongPass!\", correct password \"Passw0rd!\"\nSteps (one assertion per step \u002F single expected result each):\n  1. Action:   Submit the login form with user@example.com and \"WrongPass!\".\n     Expected: Error \"Invalid email or password.\" shows; the failed-attempt count is now 1.\n  2. Action:   Repeat the wrong-password submit until 5 failed attempts total.\n     Expected: On the 5th failure the account is locked; message reads\n               \"Account locked. Try again in 15 minutes.\"\n  3. Action:   Immediately submit with the CORRECT password \"Passw0rd!\".\n     Expected: Login is still blocked; the same lockout message is shown (lockout overrides\n               valid credentials).\n  4. Action:   Wait 15 minutes, then submit with the correct password.\n     Expected: Login succeeds and the dashboard loads.\n```\n\nNote: explicit preconditions, concrete test data (5 attempts, 15-minute lockout), discrete\nsteps, and a single deterministic expected result per step.\n\n---\n\n## Bulk Authoring from Stories\n\nGiven a story or set of acceptance criteria, split into cases by rule, then generate the\ntool-specific payload. Worked example for the discount-code story (valid reduces total \u002F expired\nerrors \u002F already-used rejected) → **three** cases:\n\n1. Apply a valid code → total reduces (happy path).\n2. Apply an expired (invalid) code → inline error, total unchanged.\n3. Apply an already-used \u002F already-redeemed code → rejected, total unchanged.\n\nAdd the obvious negatives the story implies but doesn't state (empty code, malformed code) when\nthe team wants edge coverage. Each case gets discrete steps and one expected per step — never one\ngiant case covering all three rules. For the WHAT-to-test scope decision across a sprint, that's\n`test-planning`, not this skill.\n\n---\n\n## Ambiguous-Step Linting\n\nWhen asked to \"lint\" a suite, your job is to FLAG non-deterministic steps and rewrite them — NOT\nto agree that they \"look fine.\" The agreeable failure mode (rubber-stamping \"everything works\")\nis the exact thing this section prevents.\n\nA step is bad when its expected result is not deterministically verifiable. Flag any of:\n\n- **Vague action** — \"click around\", \"test the X\", \"play with it\" → name the exact element + action.\n- **Vague data** — \"some data\", \"a value\", \"stuff\" → give concrete test data.\n- **Non-observable expected** — \"everything works\", \"it looks right\", \"is fine\", \"no problems\"\n  → name the exact observable result.\n- **Unbounded wait** — \"wait a bit\", \"after a while\" → bound it (\"within 10 s\" \u002F \"until the\n  spinner disappears and a row appears\").\n- **Multiple assertions in one step** → split to one assertion per step.\n\nFor the classic four-step bad suite (\"app opens \u002F everything works \u002F it looks right \u002F the report\nis ready\"), all four are ambiguous and must be flagged and rewritten with explicit selectors,\nexact values, and bounded conditions — never returned as \"no issues found\". The full lint\nchecklist, the worked rewrite of those four steps, and the lint-output table format are in\n`references\u002Flinting.md`.\n\n---\n\n## Tool Payloads\n\nThe four tools are easy to cross-wire. Summary — full curl\u002FGraphQL bodies in\n`references\u002Ftool-apis.md`:\n\n| Tool | Auth | Create endpoint | Steps field |\n|------|------|-----------------|-------------|\n| **TestRail** | Basic `email:api_key` | `POST add_case\u002F{section_id}` | `custom_steps_separated` array of `{content, expected}` |\n| **Xray Cloud** | `POST \u002Fapi\u002Fv2\u002Fauthenticate` → Bearer token | GraphQL `createTest` at `\u002Fapi\u002Fv2\u002Fgraphql` | `steps[] {action, result}`; Gherkin → `testType: Cucumber` + `gherkin` |\n| **Zephyr Scale Cloud** | `Authorization: Bearer \u003CJWT>` | `POST \u002Fv2\u002Ftestcases` then `POST \u002Fv2\u002Ftestcases\u002F{key}\u002Fteststeps` | separate `teststeps` call, `inline {description, expectedResult, testData}` |\n| **Qase** | header `Token: \u003Ckey>` | `POST \u002Fv1\u002Fcase\u002F{CODE}\u002Fbulk` | `steps[] {action, expected_result, data}` |\n\nTool-specific traps that the reference spells out and you must respect:\n\n- **TestRail** — separated steps need `custom_steps_separated` (NOT the plain `custom_steps` text\n  blob); the endpoint is `add_case\u002F{section_id}` (NOT `add_test`, which is a run instance). Base\n  is `{instance}\u002Findex.php?\u002Fapi\u002Fv2`. Don't use a Qase-style `POST \u002Fcase`.\n- **Xray Cloud** — authenticate first (`\u002Fapi\u002Fv2\u002Fauthenticate` with client_id\u002Fclient_secret →\n  bearer, 24h), then prefer **GraphQL** `createTest`. Import Gherkin as a **Cucumber** test, not\n  a Generic one. Avoid the deprecated Cloud path `\u002Frest\u002Fraven\u002F1.0\u002F...` and Server-style REST and\n  Jira username\u002Fpassword basic auth.\n- **Zephyr Scale Cloud** — base is `api.zephyrscale.smartbear.com\u002Fv2` with JWT Bearer. Steps are a\n  SEPARATE `\u002Ftestcases\u002F{key}\u002Fteststeps` call, not a text blob in the create body. Don't emit `\u002Fv1\u002F`,\n  the wrong host, or Qase's `Token` header.\n- **Qase** — auth is `Token: \u003Ckey>`, NOT `Authorization: Bearer`. Use `POST \u002Fcase\u002F{CODE}\u002Fbulk`\n  with a `cases` array instead of N single POSTs. Don't use TestRail's `add_case` \u002F\n  `custom_steps_separated`.\n\nCSV import for TestRail (header row mapped to importer fields: `Title`, `Section Hierarchy`,\n`Steps (Separated)`, `Expected Result`, `Priority`, `Type`, `Preconditions`) is in\n`references\u002Fimport-and-traceability.md` — use a real CSV with a header row, never free-form prose\nor a single Description column, and never JSON when CSV was requested.\n\n---\n\n## Organization\n\nUse **sections and subsections** for hierarchy, kept **shallow** (3–4 levels). For a web + mobile\nproduct the default is **single-repository mode** with top-level sections per platform\n(`Web`, `Mobile (iOS)`, `Mobile (Android)`, `Shared \u002F API`), feature sections beneath. Split into\n**multiple suites** only when platforms are owned by separate teams with separate cadences.\n\nAvoid: one folder per test case, deep nesting 7+ levels deep, dumping every case in the root\nsection, and duplicating the same case across suites (keep one source of truth). The\nsingle-repository vs multiple-suites trade-off and the full org rules are in\n`references\u002Fimport-and-traceability.md`.\n\n---\n\n## Traceability\n\nGoal: a coverage report that shows which **stories have no tests** — the uncovered requirements.\n\nFor **Xray on Jira**: from each Test, add the native **\"tests\" issue link** to the requirement's\nJira issue key (NOT to a Test Execution — that records runs, not coverage). Read per-story\ncoverage from the Story's Test Coverage panel, and project-wide from the **Traceability Report \u002F\nRequirement Coverage report**. Then filter for requirements with **0 linked tests** — those are\nthe gaps to close. Do not propose a manual spreadsheet as the only traceability mechanism, and do\nnot ignore uncovered requirements. Zephyr Scale, Qase, and TestRail equivalents (issue links +\ntheir coverage\u002Ftraceability views) are in `references\u002Fimport-and-traceability.md`.\n\n---\n\n## Automation Graduation\n\nScore each manual case by ROI: `value ≈ run_frequency × regression_importance ÷ (automation_cost\n× expected_maintenance)`. With limited capacity (e.g. a 400-case Zephyr Scale backlog):\n\n- **Automate first:** high-frequency cases (run every release \u002F regression \u002F smoke), on stable \u002F\n  low-churn \u002F deterministic features, that guard critical regression or smoke paths.\n- **Stay manual:** exploratory or one-off cases, rarely-run cases, high-churn UI still in flux,\n  flaky \u002F non-deterministic behavior, and cases needing human judgment.\n\nReject \"automate everything\" and \"automate the flaky, frequently changing UI first\" — both spend\nscarce capacity on the worst-ROI candidates. Full decision rule in\n`references\u002Fimport-and-traceability.md`. Once a case graduates, the actual test code is written\nwith `ai-test-generation` or a framework skill (`playwright-automation`, `api-testing`) — not\nhere.\n\n---\n\n## Review Hygiene\n\n- Every case is reviewable in one screen: title states the outcome, preconditions present, steps\n  discrete, each expected observable, test data concrete.\n- Run the lint checklist on a new case before it merges; reject non-deterministic expecteds.\n- Link to the requirement at creation time, not as a back-fill.\n- Tag the suite (smoke \u002F regression \u002F platform) so runs can filter; an untagged 400-case repo is\n  unusable for release selection.\n\n---\n\n## Anti-Patterns\n\n### 1. One vague step with a \"verify it works\" expected\n\"Test the login → verify it works\" is unrunnable. Write discrete steps, one observable expected\neach, explicit preconditions, concrete test data.\n\n### 2. Rubber-stamping a suite when asked to lint it\nSaying steps \"look fine\" or lightly rewording while leaving \"everything works\" and \"wait a bit\"\nin place is the failure linting exists to catch. Flag every non-verifiable expected and rewrite it.\n\n### 3. Cross-wiring the four tools' APIs\nBearer on Qase (it uses `Token`), `add_case`\u002F`custom_steps_separated` on Qase or Zephyr,\n`\u002Frest\u002Fraven\u002F1.0\u002F` on Xray Cloud, `\u002Fv1\u002F` on Zephyr Scale Cloud, steps as a text blob in Zephyr's\ncreate body. Each is a 4xx or a silent wrong-field. Copy from the correct tool section.\n\n### 4. One giant case for a multi-rule story\nFolding \"valid \u002F expired \u002F already-used\" into one case yields a single pass\u002Ffail that hides which\nrule broke. One case per rule.\n\n### 5. CSV as free-form prose or a single Description column\nA TestRail import without a header row mapped to importer fields needs manual remapping. Provide\n`Title`, `Section Hierarchy`, `Steps (Separated)`, `Expected Result`, etc.\n\n### 6. Deep nesting and per-case folders\n7+ level trees and one-folder-per-case make the repository unnavigable. Keep 3–4 shallow levels of\nsections; platform at the top for web+mobile.\n\n### 7. Traceability as a manual spreadsheet\nA hand-kept sheet can't reliably answer \"which stories have no tests.\" Use the tool's native\nrequirement→test link and coverage\u002FTraceability report, and surface the uncovered requirements.\n\n### 8. Automate-everything \u002F automate-the-flaky-first\nAutomating one-off exploratory cases or high-churn\u002Fflaky UI first burns capacity for negative ROI.\nSequence stable high-frequency regression\u002Fsmoke first.\n\n---\n\n## Verification\n\nProve the produced artifact actually works before handing it off, smallest check first:\n\n- **Lint your own output:** grep the generated cases for the banned expecteds —\n  `grep -niE \"verify it works|looks right|is fine|wait a bit|no problems|everything works\" cases.*`\n  must return nothing. Any hit is a non-deterministic expected to rewrite.\n- **TestRail CSV:** open it and confirm a header row exists with `Title`, `Section Hierarchy`,\n  `Steps (Separated)`, `Expected Result` — `head -1 cases.csv` should show those columns, not a\n  single `Description`. Dry-run the import wizard; the wizard auto-matches columns with no manual\n  remapping when the headers are right.\n- **API payload, before the real POST:** validate the JSON (`jq . payload.json` exits 0) and\n  confirm the auth header and endpoint match the target tool's row in\n  [Tool Payloads](#tool-payloads) — Qase `Token:` not `Authorization: Bearer`, TestRail\n  `add_case\u002F{section_id}` not `add_test`. A `201`\u002Ftest-id in the response (or a `200` with the new\n  case `key` for Zephyr) confirms the create; a `401` means the auth scheme is cross-wired, a\n  `400` means the step field is.\n- **Traceability:** run the tool's coverage\u002FTraceability report and confirm it lists requirements\n  with 0 linked tests — an empty \"uncovered\" column means the links landed; a populated one is the\n  gap list to close.\n\n---\n\n## Done When\n\n- Each generated case has a title, preconditions, discrete steps, one observable expected result\n  per step, and concrete test data — no \"verify it works\" \u002F \"looks right\" \u002F \"wait a bit\" expecteds.\n- A multi-rule story produced one case per rule, not one combined case.\n- Any emitted API payload uses the correct tool's auth scheme, endpoint, and step-field name\n  (TestRail `custom_steps_separated`+`add_case\u002F{section_id}`; Xray two-step auth + GraphQL\n  `createTest`, Cucumber for Gherkin; Zephyr `\u002Fv2` Bearer + separate `\u002Fteststeps`; Qase `Token`\n  header + `\u002Fcase\u002F{CODE}\u002Fbulk`).\n- Any TestRail CSV has a header row mapping columns to importer fields (`Title`,\n  `Section Hierarchy`, `Steps (Separated)`, `Expected Result`).\n- A linted suite returns every ambiguous step flagged and rewritten — never \"no issues found\"\n  when smells are present.\n- Traceability uses the tool's native requirement→test link and a coverage report that lists the\n  uncovered requirements.\n- Automation graduation produces an ROI-ordered list (stable + high-frequency + regression\u002Fsmoke\n  first) and names what stays manual.\n\n---\n\n## Related Skills\n\n- **ai-test-generation** — go there to turn a graduated manual case into automated TEST CODE; this\n  skill stops at the manual\u002Fhybrid case and its import payload.\n- **test-planning** — go there for sprint\u002Frelease WHAT-to-test selection; this skill authors the\n  cases once the scope is decided.\n- **exploratory-testing** — the source of one-off\u002Fcharter-based cases that should stay manual;\n  pairs with the automation-graduation decision here.\n- **qa-project-context** — the universal dependency: the tool, project keys, and conventions this\n  skill reads before generating any payload.\n\n---\n\n## Reference Files (in `references\u002F`)\n\n- **tool-apis.md** — full TestRail \u002F Xray Cloud \u002F Zephyr Scale \u002F Qase create-case payloads\n  (curl + GraphQL), auth flows, and the per-tool cross-wiring traps.\n- **linting.md** — the ambiguous-step lint checklist, the worked rewrite of the four classic bad\n  steps, and the lint-output table format.\n- **import-and-traceability.md** — TestRail CSV column→field mapping with a 3-case example,\n  suite\u002Fsection organization rules, requirement traceability + coverage-gap reports, and the\n  automation-graduation decision rule.\n",{"name":5,"license":15,"metadata":52,"description":7},{"author":53,"version":54,"category":55},"kindlmann","1.0","process","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Ftest-case-management","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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add pattanation\u002FNorvik --skill test-case-management",{"tool":69,"command":70},"bunx","bunx skills add pattanation\u002FNorvik --skill test-case-management",{"tool":72,"command":73},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill test-case-management","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-case-management\u002FSKILL.md",true,[77,83,87],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"references\u002Fimport-and-traceability.md","REFERENCE","参考文档",7163,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-case-management\u002Freferences\u002Fimport-and-traceability.md",{"path":84,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Flinting.md",3778,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-case-management\u002Freferences\u002Flinting.md",{"path":88,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Ftool-apis.md",8912,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Ftest-case-management\u002Freferences\u002Ftool-apis.md",[92,120,146,168,189,204],{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":97,"sourceHtmlUrl":98,"categories":99,"keywords":104,"publishedAt":47},"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",[100,101],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[105,45,106,34,107,108,109,110,111,112,113,114,115,116,117,118,119],"webapp","webapp testing","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":124,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":47},"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",[127],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[129,130,131,116,132,133,134,34,135,136,109,137,138,139,140,141,142,143,144,145],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":150,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":47},"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",[153],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[155,156,157,46,158,159,160,161,162,163,164,165,166,167],"functions","vueuse","vueuse functions","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":169,"name":170,"nameZh":6,"description":171,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":172,"sourceHtmlUrl":173,"categories":174,"keywords":177,"publishedAt":47},"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",[175,176],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[178,45,179,165,180,115,29,181,182,160,183,34,184,185,186,138,187,166,188],"vue testing best practices","testing best practices","best practices","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":193,"sourceHtmlUrl":194,"categories":195,"keywords":197,"publishedAt":47},"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",[196],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[198,165,199,180,200,182,201,160,187,202,203],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":205,"name":206,"nameZh":6,"description":207,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":208,"sourceHtmlUrl":209,"categories":210,"keywords":212,"publishedAt":47},"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",[211],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[213,165,180,214,46,215,216,217,198,218,219,220,221,222,223,34,224,138,225,226],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]