[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MAMHQNHS1GRE057RJK4CS":3,"skill-same:01M71MAMHQNHS1GRE057RJK4CS":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":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},"01M71MAMHQNHS1GRE057RJK4CS","ai-test-generation",null,"Use AI to write NEW test code from specs, PRDs, user stories, code diffs, bug reports, or OpenAPI specs. Staged pipeline: requirements extraction → risk analysis → coverage matrix → scenario generation → oracle design → test code → human review, with guardrails against hallucinated APIs and weak assertions. Use when: \"generate tests from spec,\" \"tests from PRD,\" \"tests from user story,\" \"auto-generate test cases,\" \"AI write tests for me.\" Not for: testing AI\u002FLLM features in your product — use ai-system-testing. Not for: auditing a pre-existing test suite you did not just generate — use ai-qa-review (Step 7 here only reviews tests THIS pipeline produced). Related: playwright-automation, unit-testing, api-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\u002Fai-test-generation\u002FSKILL.md",[18,23,26,31],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":32,"categoryName":33,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000031","产品经理",[35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54],"test generation","test","generation","ai test generation","oracle","auto","qa","new","only","design","diffs","write tests","Guardrails","testing","pipeline","project","reviews","user story","unit","coverage","2026-11-10 10:56:23",false,"---\nname: ai-test-generation\ndescription: >-\n  Use AI to write NEW test code from specs, PRDs, user stories, code diffs, bug\n  reports, or OpenAPI specs. Staged pipeline: requirements extraction → risk\n  analysis → coverage matrix → scenario generation → oracle design → test code →\n  human review, with guardrails against hallucinated APIs and weak assertions.\n  Use when: \"generate tests from spec,\" \"tests from PRD,\" \"tests from user story,\"\n  \"auto-generate test cases,\" \"AI write tests for me.\"\n  Not for: testing AI\u002FLLM features in your product — use ai-system-testing.\n  Not for: auditing a pre-existing test suite you did not just generate — use\n  ai-qa-review (Step 7 here only reviews tests THIS pipeline produced).\n  Related: playwright-automation, unit-testing, api-testing, qa-project-context.\nlicense: MIT\nmetadata:\n  author: kindlmann\n  version: \"2.0\"\n  category: ai-qa\n---\n\n\u003Cobjective>\nLLMs will happily emit fifty plausible-looking tests that assert nothing, target endpoints that do not exist, and duplicate each other. This skill is a staged pipeline that forces structured intermediates — assumptions, coverage matrix, oracle definitions — out of the model BEFORE any test code, so what you get is traceable, reviewable, and grounded in the real codebase instead of ad-hoc generated noise.\n\n**Before starting:** Check for `.agents\u002Fqa-project-context.md` in the project root. It carries tech stack, test frameworks, naming conventions, selector strategy, and known risk areas that dramatically improve generated test quality.\n\u003C\u002Fobjective>\n\n## Quick Route\n\nThe pipeline is the same for every input; only the Step 1 extraction emphasis changes. Jump to the matching row, then run Steps 2-7 unchanged.\n\n| Input type | Step 1 extracts | Watch for |\n|------------|-----------------|-----------|\n| PRD \u002F feature spec | Entities, business rules, acceptance criteria, NFRs, stated assumptions | Implicit requirements inferred from \"seamless\"\u002F\"fast\" language |\n| User story + AC | Each AC → ≥1 happy + ≥1 negative scenario | ACs that hide multiple behaviors in one line |\n| Code diff (`git diff main...HEAD`) | New\u002Fchanged code paths, modified conditionals, removed behavior | Regression scope: test the changed paths, not the whole module |\n| Bug report | Repro steps, expected vs actual, environment | Write a test asserting *expected* — fails now, passes after fix |\n| OpenAPI \u002F GraphQL SDL | Endpoints, schemas, required fields, enums, auth | Validation, auth-failure, and edge cases per endpoint, not just 200s |\n\nPlaywright projects also pick an agent integration mode — see Discovery Q2.\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then clarify:\n\n1. **What is the input source?** PRD \u002F spec, user story + AC, code diff, bug report, or API schema. Determines Step 1 extraction emphasis (see Quick Route). For an LLM\u002FAI feature spec, stop — generate eval datasets in `ai-system-testing`, not Playwright specs.\n\n2. **What is the target test framework, and (for Playwright) which agent integration mode?**\n   - **E2E:** Playwright (preferred), Cypress. **Unit:** Jest, Vitest, pytest. **API:** Playwright `APIRequestContext`, Supertest, requests.\n   - **Playwright CLI + agents** (recommended for Claude Code \u002F Codex \u002F Cursor): `npx playwright init-agents --loop=claude` scaffolds planner\u002Fgenerator\u002Fhealer agents into `.claude\u002Fagents\u002F` as markdown. They are interactive dev tools that produce standard Playwright tests which run unchanged in CI. Token-efficient; runs inside the agent's loop.\n   - **Playwright MCP** (`npx @playwright\u002Fmcp@latest`): higher overhead, right when the agent must *drive* a live browser interactively over a long session.\n   - **Neither** — hand-write tests using AI as a scratch-pad helper.\n\n3. **What project context is available?** Existing test patterns, Page Objects \u002F helpers, data factories \u002F fixtures, CI constraints (timeout, parallelism). More context = less cleanup.\n\n4. **What is the review workflow?** Full pipeline → human review → merge (default); scenarios only → human writes code; or code → human refines iteratively.\n\n5. **What domain knowledge is needed?** Regulated industry (healthcare, finance) compliance, domain invariants (money never negative, appointments cannot overlap), known risk areas from past incidents.\n\n## Core Principles\n\n1. **Pipeline before code.** Never generate test code before establishing what to test, why, and how to verify it. The seven-step pipeline exists to prevent premature code generation that targets the wrong things.\n\n2. **Structured intermediates are the product.** The assumptions document, coverage matrix, and oracle definitions are more valuable than the test code itself. They are reviewable, traceable, and reusable.\n\n3. **Separate what from how.** Scenario generation (what to test) and oracle design (how to verify) are distinct cognitive tasks. Mixing them produces scenarios biased toward what is easy to assert, with assertions tacked on as afterthoughts.\n\n4. **AI generates the first draft; a human reviews and refines.** Never ship AI-generated tests without human review. The AI accelerates — it does not replace judgment.\n\n5. **Context is everything.** Feed the LLM your conventions, existing patterns, selector strategy, and data setup. The more context, the less cleanup.\n\n6. **Quality over quantity.** Each test has a maintenance cost. Focus on critical paths, complex logic, and known risk areas — not test count.\n\n## The Pipeline\n\n**Mandatory workflow — agents MUST follow this order:**\n\n```\nStep 1: Extract   → Requirements, entities, business rules from input\nStep 2: Analyze   → Risks, invariants, edge cases, ambiguities\nStep 3: Map       → Coverage matrix (requirement → scenario → priority)\nStep 4: Generate  → Candidate scenarios (happy + boundary + negative + security + a11y)\nStep 5: Design    → Assertions and oracles SEPARATELY from scenarios\nStep 6: Code      → Test code (only after all above exist)\nStep 7: Review    → Human review with traceability back to source\n```\n\nFull prompt templates for every step (extraction, risk analysis, scenario, oracle, code) live in `references\u002Fprompt-patterns.md`. Below is the shape of each step's output.\n\n### Step 1: Extract Requirements and Entities\n\nParse the input into structured elements: **Entities** (with roles\u002Fstates\u002Fattributes), **Business Rules** (numbered), **Explicit Requirements** (`[REQ-N]`, stated in source), and **Implicit Requirements** (`[IMP-N]`, inferred — flag every one for human confirmation). Separating explicit from inferred is the rule that prevents testing assumptions as if they were specifications.\n\n### Step 2: Risk Analysis and Invariants\n\nDerive what can go wrong, what must always be true, and where the source is silent.\n\n- **Risks** — table of `Risk | Likelihood | Impact | Source Requirement` (e.g. race condition on stock decrement, email delay > 30s).\n- **Invariants** (must ALWAYS hold) — `stock >= 0`, `order total = sum(items) + tax + shipping`, `user sees only their own orders`.\n- **Ambiguities** (need human answers) — \"Does free shipping apply before or after discount codes?\" Capture these explicitly; do not silently pick one.\n- **Edge cases derived from risks** — two users buy the last item, payment succeeds but email service is down.\n\n### Step 3: Coverage Matrix\n\nThe single most important artifact — it prevents both gaps and duplicates. Map every requirement to scenarios with category, priority, and oracle type:\n\n| Requirement | Scenario | Category | Priority | Oracle Type |\n|-------------|----------|----------|----------|-------------|\n| REQ-1 | Add single item to empty cart | Happy path | P0 | State: cart count = 1 |\n| REQ-1 | Add out-of-stock item | Negative | P0 | UI: error message, cart unchanged |\n| REQ-2 | Complete checkout with valid card | Happy path | P0 | State: order created, stock decremented |\n| REQ-2 | Two users checkout last item | Race condition | P1 | One succeeds, one gets stock error |\n| INV-1 | Stock never goes negative | Invariant | P0 | Data: stock >= 0 after any operation |\n\nAfter building it, verify: every requirement has ≥1 happy and ≥1 negative scenario; every invariant has a direct test; every Step-2 risk has a scenario; no two rows test the same thing.\n\n### Step 4: Generate Candidate Scenarios\n\nFor each matrix row, write the full scenario in Given\u002FWhen\u002FThen with explicit test-data requirements (`Given: user with 99 items in cart (max 100); When: adds one more; Then: count = 100`). Cover these categories systematically:\n\n| Category | Description |\n|----------|-------------|\n| Happy path | The user does exactly what the feature is designed for |\n| Boundary | Edge of valid input ranges — use the BOUNDARIES framework (`references\u002Fprompt-patterns.md`) |\n| Negative | Invalid inputs, unauthorized actions |\n| Security | Auth bypass, injection, privilege escalation |\n| Accessibility | Screen reader, keyboard-only, contrast |\n| State transition | Valid and invalid moves between states |\n| Concurrency | Two users acting simultaneously |\n\n### Step 5: Design Assertions and Oracles\n\n**Deliberately separate from Step 4.** Scenarios describe behavior; oracles describe how to verify it. For each scenario, define oracles across categories — a single assertion is rarely enough to prove a behavior:\n\n| Oracle category | Asserts | Example |\n|-----------------|---------|---------|\n| UI state | Visible text \u002F element state | `cart badge toHaveText('1')` |\n| Data | Persisted state via API\u002FDB | `GET \u002Fapi\u002Fcart` returns 1 item, correct total |\n| Negative | What should NOT happen | no error toast; no navigation away |\n| Side effect | Async\u002Fexternal outcomes | analytics `add_to_cart` fired; email in inbox \u003C 30s |\n\n**Oracle quality rules:** assert business outcomes not implementation details; use the most specific assertion available (`toHaveText('$29.99')`, not `toBeTruthy()`); include negative assertions; verify data integrity, not just UI; assert accessibility (focus management, live-region announcements).\n\n### Step 6: Generate Test Code\n\n**Only after Steps 1-5 produce reviewed artifacts.** Code is a mechanical translation of scenarios + oracles into framework syntax, with traceability comments linking back to the requirement and scenario:\n\n```typescript\n\u002F**\n * Scenario: SC-001 — Add single item to empty cart\n * Requirement: REQ-1 (User can add items to cart)\n * Priority: P0\n *\u002F\ntest('add single item to empty cart', async ({ page, testProduct }) => {\n  await page.goto(`\u002Fproducts\u002F${testProduct.id}`);                       \u002F\u002F Given\n  await page.getByRole('button', { name: 'Add to cart' }).click();      \u002F\u002F When\n  await expect(page.getByTestId('cart-badge')).toHaveText('1');         \u002F\u002F Then\n  await expect(page.getByTestId('error-toast')).not.toBeVisible();      \u002F\u002F Negative oracle\n});\n```\n\n**Code generation rules:** match project conventions (from `qa-project-context.md`); reuse existing Page Objects, fixtures, and data factories; include traceability comments (`Scenario: SC-XXX`, `Requirement: REQ-XX`); follow the project's selector strategy; put setup\u002Fteardown in fixtures, not inline.\n\n### Step 7: Human Review\n\nNot optional — a mandatory pipeline step. This reviews **the tests this pipeline just generated**, before they merge. (To audit a pre-existing suite you did not just generate, use `ai-qa-review` instead.) Run every generated test against this checklist:\n\n- [ ] **Traces to requirement:** test → scenario → coverage row → requirement is followable.\n- [ ] **Tests behavior, not implementation:** survives a harmless refactor.\n- [ ] **Correct abstraction level:** right test type (unit vs integration vs E2E).\n- [ ] **Test naming and readability:** the test name states the behavior; a reader sees intent without decoding the body.\n- [ ] **Test isolation \u002F no shared state:** the test creates and cleans up its own data, holds no order dependency on sibling tests, and passes when run alone or in any order.\n- [ ] **Realistic test data:** plausible, diverse, using `example.com`.\n- [ ] **Meaningful assertions:** matches the oracle definition; specific, not `toBeTruthy()`.\n- [ ] **Matches project conventions:** naming, structure, selector strategy.\n- [ ] **No flakiness risks:** no hardcoded timeouts, race conditions, or order dependence.\n- [ ] **Edge cases included:** goes beyond the happy path.\n- [ ] **Assumptions validated:** Step-2 ambiguities were resolved before coding.\n\n**Review outcome per test:** **KEEP** (merge as-is) · **MODIFY** (fix listed issues, then merge) · **REJECT** (wrong requirement, wrong abstraction, hallucinated API) · **DEFER** (blocked on ambiguity).\n\n## Guardrails\n\nHard rules. Agents MUST follow them.\n\n- **Code before coverage is forbidden.** Never emit test code before Steps 1-3 (requirements, risk analysis with documented assumptions, coverage matrix) exist. If an agent skips to code: STOP, go back.\n- **Assert outcomes, not implementation.** `expect(screen.getByRole('progressbar')).toBeVisible()`, not `expect(component.state.isLoading).toBe(true)`. `expect(page.getByTestId('cart-badge')).toHaveText('1')`, not `expect(store.dispatch).toHaveBeenCalledWith(...)`.\n- **Scenarios (Step 4) before oracles (Step 5), always.** Scenario = WHAT happens; oracle = HOW to verify. Mixing them biases scenarios toward easy assertions.\n- **Always produce the intermediates** — assumptions document, uncovered ambiguities, oracle candidates, and the traceability chain — even in abbreviated form.\n\n**Flag these when detected:**\n- **Hallucinated APIs** — endpoints, selectors, methods, or imports that do not exist in the codebase. Verify mechanically (see Verification) before human review.\n- **Duplicate scenarios** — same behavior, trivially different data. Consolidate or parametrize.\n- **Low-value assertions** — `expect(response).toBeTruthy()`, `expect(page).toHaveURL(\u002F.*\u002F)`.\n- **Missing negative cases** — if every scenario is a happy path, the coverage matrix is incomplete.\n- **Unrealistic test data** — `test@test.com`, `John Doe`, `password123`. Use diverse, plausible data on `example.com`.\n\n## Model selection per step\n\nRoute by difficulty, not habit. Use a cheap model for mechanical extraction (Step 1) and the coverage-matrix bookkeeping (Step 3) — **Haiku 4.5** or **Sonnet 4.6** are plenty. Escalate to **Opus 4.8** for oracle design (Step 5) and hallucination-sensitive code generation (Step 6), where a wrong inference is expensive; reach for **Fable 5** only on genuinely hard reasoning (subtle invariants, regulated-domain logic). Running the strongest model on every step is wasteful; running the cheapest on Step 6 produces fabricated APIs.\n\n## Verification\n\nConvert the \"hallucinated APIs\" warning into a mechanical gate. After Step 6, before human review:\n\n1. **Resolve imports \u002F types.** TypeScript: `npx tsc --noEmit` — fabricated imports and wrong signatures fail here. Python: `python -m pyflakes \u003Cfiles>` or `ruff check`.\n2. **Grep generated selectors\u002Fendpoints against the codebase.** Confirm every `getByTestId('...')` id and every API path the test calls actually exists in source:\n   ```bash\n   grep -roE \"getByTestId\\('([^']+)'\\)\" generated\u002F | sed -E \"s\u002F.*'([^']+)'.*\u002F\\1\u002F\" | sort -u \\\n     | while read id; do grep -rq \"$id\" src\u002F || echo \"MISSING testid: $id\"; done\n   ```\n3. **Run the suite once.** Tests that reference nonexistent routes\u002Fselectors fail fast; quarantine those before review rather than reviewing dead code.\n\nAny `MISSING` line or `tsc` error is a hallucination to fix before a human spends review time.\n\n## Anti-Patterns\n\n1. **Skipping to code.** The most common failure: an agent gets a PRD and immediately writes tests. Without the coverage matrix it misses scenarios and duplicates others. The pipeline exists to prevent this.\n2. **Asserting implementation instead of behavior.** `expect(component.state.isLoading).toBe(true)` breaks on any refactor. Assert `expect(screen.getByRole('progressbar')).toBeVisible()` — what the user observes.\n3. **Mixing scenarios and assertions.** Writing \"test this thing and check this value\" as one step. Separate *what to test* from *how to verify it*.\n4. **No project context in the prompt.** Without conventions and existing patterns, you get generic tests. `qa-project-context.md` exists for exactly this.\n5. **Over-generating.** AI will write 50 tests for a simple function. Each carries maintenance cost. Use the coverage matrix to bound generation to meaningful scenarios.\n6. **Copy-paste without understanding.** If you cannot explain what a generated test does and why, do not merge it. Tests you do not understand become tests you cannot debug.\n7. **Shipping without review.** Step 7 is not optional. AI tests routinely contain hallucinated APIs, wrong selectors, incorrect business logic, and flakiness only human review catches.\n8. **Ignoring the feedback loop.** When AI tests catch real bugs, note the prompt patterns that worked; when they false-positive, note what went wrong. Build a project-specific library of what works.\n\n## Done When\n\n- All seven artifacts exist: requirements document, risk & invariants, coverage matrix, scenario set, oracle definitions, test code, and review notes with a KEEP\u002FMODIFY\u002FREJECT\u002FDEFER decision per test.\n- The coverage matrix was produced and reviewed before any test code file was written.\n- Verification passed: `tsc --noEmit` (or language equivalent) exits 0 and the selector\u002Fendpoint grep reports zero `MISSING` lines.\n- Each generated test has a recorded human review decision; no test is marked KEEP without one.\n- The suite's CI job exits 0 (green).\n- Reproducibility metadata recorded: the exact model ID (e.g. `claude-opus-4-8`, `claude-sonnet-4-6`, `claude-haiku-4-5-20251001`), input source hash, and the version of any skill \u002F CLI \u002F MCP server invoked.\n\n## Related Skills\n\n- **qa-project-context** — Set up the context file that makes AI test generation dramatically better. Configure this first.\n- **playwright-automation** — Deep Playwright patterns (POM, fixtures, CI), plus the Test Agents (`init-agents --loop=claude`, scaffolded into `.claude\u002Fagents\u002F`) and `@playwright\u002Fmcp` modes chosen in Discovery Q2. Generated tests live inside this framework.\n- **unit-testing** — Jest, Vitest, pytest patterns for unit-level generated tests.\n- **api-testing** — Endpoint test patterns for tests generated from OpenAPI specs.\n- **test-strategy** — Decide *what* to test and at which level before generating.\n- **test-reliability** — Make generated tests reliable: flake classification, healing, video receipts.\n- **ai-system-testing** — When the input is an LLM feature spec, generate eval datasets here (Promptfoo, DeepEval, Ragas, Braintrust) instead of Playwright specs.\n- **ai-qa-review** — Audit a *pre-existing* suite you did not just generate (test smells, testability). Step 7 here only reviews this pipeline's own output.\n- **ai-bug-triage** — When generated tests find bugs, classify and report them through the triage pipeline.\n\n## Reference Files (in `references\u002F`)\n\n- **prompt-patterns.md** — Full prompt library aligned to the seven steps: extraction, risk analysis, scenario generation, oracle design, and code generation prompts, plus the BOUNDARIES edge-case framework used in Step 4.\n","\u003Cobjective>\nLLMs will happily emit fifty plausible-looking tests that assert nothing, target endpoints that do not exist, and duplicate each other. This skill is a staged pipeline that forces structured intermediates — assumptions, coverage matrix, oracle definitions — out of the model BEFORE any test code, so what you get is traceable, reviewable, and grounded in the real codebase instead of ad-hoc generated noise.\n\n**Before starting:** Check for `.agents\u002Fqa-project-context.md` in the project root. It carries tech stack, test frameworks, naming conventions, selector strategy, and known risk areas that dramatically improve generated test quality.\n\u003C\u002Fobjective>\n\n## Quick Route\n\nThe pipeline is the same for every input; only the Step 1 extraction emphasis changes. Jump to the matching row, then run Steps 2-7 unchanged.\n\n| Input type | Step 1 extracts | Watch for |\n|------------|-----------------|-----------|\n| PRD \u002F feature spec | Entities, business rules, acceptance criteria, NFRs, stated assumptions | Implicit requirements inferred from \"seamless\"\u002F\"fast\" language |\n| User story + AC | Each AC → ≥1 happy + ≥1 negative scenario | ACs that hide multiple behaviors in one line |\n| Code diff (`git diff main...HEAD`) | New\u002Fchanged code paths, modified conditionals, removed behavior | Regression scope: test the changed paths, not the whole module |\n| Bug report | Repro steps, expected vs actual, environment | Write a test asserting *expected* — fails now, passes after fix |\n| OpenAPI \u002F GraphQL SDL | Endpoints, schemas, required fields, enums, auth | Validation, auth-failure, and edge cases per endpoint, not just 200s |\n\nPlaywright projects also pick an agent integration mode — see Discovery Q2.\n\n## Discovery Questions\n\nCheck `.agents\u002Fqa-project-context.md` first — if it exists, use it and skip anything already answered there. Then clarify:\n\n1. **What is the input source?** PRD \u002F spec, user story + AC, code diff, bug report, or API schema. Determines Step 1 extraction emphasis (see Quick Route). For an LLM\u002FAI feature spec, stop — generate eval datasets in `ai-system-testing`, not Playwright specs.\n\n2. **What is the target test framework, and (for Playwright) which agent integration mode?**\n   - **E2E:** Playwright (preferred), Cypress. **Unit:** Jest, Vitest, pytest. **API:** Playwright `APIRequestContext`, Supertest, requests.\n   - **Playwright CLI + agents** (recommended for Claude Code \u002F Codex \u002F Cursor): `npx playwright init-agents --loop=claude` scaffolds planner\u002Fgenerator\u002Fhealer agents into `.claude\u002Fagents\u002F` as markdown. They are interactive dev tools that produce standard Playwright tests which run unchanged in CI. Token-efficient; runs inside the agent's loop.\n   - **Playwright MCP** (`npx @playwright\u002Fmcp@latest`): higher overhead, right when the agent must *drive* a live browser interactively over a long session.\n   - **Neither** — hand-write tests using AI as a scratch-pad helper.\n\n3. **What project context is available?** Existing test patterns, Page Objects \u002F helpers, data factories \u002F fixtures, CI constraints (timeout, parallelism). More context = less cleanup.\n\n4. **What is the review workflow?** Full pipeline → human review → merge (default); scenarios only → human writes code; or code → human refines iteratively.\n\n5. **What domain knowledge is needed?** Regulated industry (healthcare, finance) compliance, domain invariants (money never negative, appointments cannot overlap), known risk areas from past incidents.\n\n## Core Principles\n\n1. **Pipeline before code.** Never generate test code before establishing what to test, why, and how to verify it. The seven-step pipeline exists to prevent premature code generation that targets the wrong things.\n\n2. **Structured intermediates are the product.** The assumptions document, coverage matrix, and oracle definitions are more valuable than the test code itself. They are reviewable, traceable, and reusable.\n\n3. **Separate what from how.** Scenario generation (what to test) and oracle design (how to verify) are distinct cognitive tasks. Mixing them produces scenarios biased toward what is easy to assert, with assertions tacked on as afterthoughts.\n\n4. **AI generates the first draft; a human reviews and refines.** Never ship AI-generated tests without human review. The AI accelerates — it does not replace judgment.\n\n5. **Context is everything.** Feed the LLM your conventions, existing patterns, selector strategy, and data setup. The more context, the less cleanup.\n\n6. **Quality over quantity.** Each test has a maintenance cost. Focus on critical paths, complex logic, and known risk areas — not test count.\n\n## The Pipeline\n\n**Mandatory workflow — agents MUST follow this order:**\n\n```\nStep 1: Extract   → Requirements, entities, business rules from input\nStep 2: Analyze   → Risks, invariants, edge cases, ambiguities\nStep 3: Map       → Coverage matrix (requirement → scenario → priority)\nStep 4: Generate  → Candidate scenarios (happy + boundary + negative + security + a11y)\nStep 5: Design    → Assertions and oracles SEPARATELY from scenarios\nStep 6: Code      → Test code (only after all above exist)\nStep 7: Review    → Human review with traceability back to source\n```\n\nFull prompt templates for every step (extraction, risk analysis, scenario, oracle, code) live in `references\u002Fprompt-patterns.md`. Below is the shape of each step's output.\n\n### Step 1: Extract Requirements and Entities\n\nParse the input into structured elements: **Entities** (with roles\u002Fstates\u002Fattributes), **Business Rules** (numbered), **Explicit Requirements** (`[REQ-N]`, stated in source), and **Implicit Requirements** (`[IMP-N]`, inferred — flag every one for human confirmation). Separating explicit from inferred is the rule that prevents testing assumptions as if they were specifications.\n\n### Step 2: Risk Analysis and Invariants\n\nDerive what can go wrong, what must always be true, and where the source is silent.\n\n- **Risks** — table of `Risk | Likelihood | Impact | Source Requirement` (e.g. race condition on stock decrement, email delay > 30s).\n- **Invariants** (must ALWAYS hold) — `stock >= 0`, `order total = sum(items) + tax + shipping`, `user sees only their own orders`.\n- **Ambiguities** (need human answers) — \"Does free shipping apply before or after discount codes?\" Capture these explicitly; do not silently pick one.\n- **Edge cases derived from risks** — two users buy the last item, payment succeeds but email service is down.\n\n### Step 3: Coverage Matrix\n\nThe single most important artifact — it prevents both gaps and duplicates. Map every requirement to scenarios with category, priority, and oracle type:\n\n| Requirement | Scenario | Category | Priority | Oracle Type |\n|-------------|----------|----------|----------|-------------|\n| REQ-1 | Add single item to empty cart | Happy path | P0 | State: cart count = 1 |\n| REQ-1 | Add out-of-stock item | Negative | P0 | UI: error message, cart unchanged |\n| REQ-2 | Complete checkout with valid card | Happy path | P0 | State: order created, stock decremented |\n| REQ-2 | Two users checkout last item | Race condition | P1 | One succeeds, one gets stock error |\n| INV-1 | Stock never goes negative | Invariant | P0 | Data: stock >= 0 after any operation |\n\nAfter building it, verify: every requirement has ≥1 happy and ≥1 negative scenario; every invariant has a direct test; every Step-2 risk has a scenario; no two rows test the same thing.\n\n### Step 4: Generate Candidate Scenarios\n\nFor each matrix row, write the full scenario in Given\u002FWhen\u002FThen with explicit test-data requirements (`Given: user with 99 items in cart (max 100); When: adds one more; Then: count = 100`). Cover these categories systematically:\n\n| Category | Description |\n|----------|-------------|\n| Happy path | The user does exactly what the feature is designed for |\n| Boundary | Edge of valid input ranges — use the BOUNDARIES framework (`references\u002Fprompt-patterns.md`) |\n| Negative | Invalid inputs, unauthorized actions |\n| Security | Auth bypass, injection, privilege escalation |\n| Accessibility | Screen reader, keyboard-only, contrast |\n| State transition | Valid and invalid moves between states |\n| Concurrency | Two users acting simultaneously |\n\n### Step 5: Design Assertions and Oracles\n\n**Deliberately separate from Step 4.** Scenarios describe behavior; oracles describe how to verify it. For each scenario, define oracles across categories — a single assertion is rarely enough to prove a behavior:\n\n| Oracle category | Asserts | Example |\n|-----------------|---------|---------|\n| UI state | Visible text \u002F element state | `cart badge toHaveText('1')` |\n| Data | Persisted state via API\u002FDB | `GET \u002Fapi\u002Fcart` returns 1 item, correct total |\n| Negative | What should NOT happen | no error toast; no navigation away |\n| Side effect | Async\u002Fexternal outcomes | analytics `add_to_cart` fired; email in inbox \u003C 30s |\n\n**Oracle quality rules:** assert business outcomes not implementation details; use the most specific assertion available (`toHaveText('$29.99')`, not `toBeTruthy()`); include negative assertions; verify data integrity, not just UI; assert accessibility (focus management, live-region announcements).\n\n### Step 6: Generate Test Code\n\n**Only after Steps 1-5 produce reviewed artifacts.** Code is a mechanical translation of scenarios + oracles into framework syntax, with traceability comments linking back to the requirement and scenario:\n\n```typescript\n\u002F**\n * Scenario: SC-001 — Add single item to empty cart\n * Requirement: REQ-1 (User can add items to cart)\n * Priority: P0\n *\u002F\ntest('add single item to empty cart', async ({ page, testProduct }) => {\n  await page.goto(`\u002Fproducts\u002F${testProduct.id}`);                       \u002F\u002F Given\n  await page.getByRole('button', { name: 'Add to cart' }).click();      \u002F\u002F When\n  await expect(page.getByTestId('cart-badge')).toHaveText('1');         \u002F\u002F Then\n  await expect(page.getByTestId('error-toast')).not.toBeVisible();      \u002F\u002F Negative oracle\n});\n```\n\n**Code generation rules:** match project conventions (from `qa-project-context.md`); reuse existing Page Objects, fixtures, and data factories; include traceability comments (`Scenario: SC-XXX`, `Requirement: REQ-XX`); follow the project's selector strategy; put setup\u002Fteardown in fixtures, not inline.\n\n### Step 7: Human Review\n\nNot optional — a mandatory pipeline step. This reviews **the tests this pipeline just generated**, before they merge. (To audit a pre-existing suite you did not just generate, use `ai-qa-review` instead.) Run every generated test against this checklist:\n\n- [ ] **Traces to requirement:** test → scenario → coverage row → requirement is followable.\n- [ ] **Tests behavior, not implementation:** survives a harmless refactor.\n- [ ] **Correct abstraction level:** right test type (unit vs integration vs E2E).\n- [ ] **Test naming and readability:** the test name states the behavior; a reader sees intent without decoding the body.\n- [ ] **Test isolation \u002F no shared state:** the test creates and cleans up its own data, holds no order dependency on sibling tests, and passes when run alone or in any order.\n- [ ] **Realistic test data:** plausible, diverse, using `example.com`.\n- [ ] **Meaningful assertions:** matches the oracle definition; specific, not `toBeTruthy()`.\n- [ ] **Matches project conventions:** naming, structure, selector strategy.\n- [ ] **No flakiness risks:** no hardcoded timeouts, race conditions, or order dependence.\n- [ ] **Edge cases included:** goes beyond the happy path.\n- [ ] **Assumptions validated:** Step-2 ambiguities were resolved before coding.\n\n**Review outcome per test:** **KEEP** (merge as-is) · **MODIFY** (fix listed issues, then merge) · **REJECT** (wrong requirement, wrong abstraction, hallucinated API) · **DEFER** (blocked on ambiguity).\n\n## Guardrails\n\nHard rules. Agents MUST follow them.\n\n- **Code before coverage is forbidden.** Never emit test code before Steps 1-3 (requirements, risk analysis with documented assumptions, coverage matrix) exist. If an agent skips to code: STOP, go back.\n- **Assert outcomes, not implementation.** `expect(screen.getByRole('progressbar')).toBeVisible()`, not `expect(component.state.isLoading).toBe(true)`. `expect(page.getByTestId('cart-badge')).toHaveText('1')`, not `expect(store.dispatch).toHaveBeenCalledWith(...)`.\n- **Scenarios (Step 4) before oracles (Step 5), always.** Scenario = WHAT happens; oracle = HOW to verify. Mixing them biases scenarios toward easy assertions.\n- **Always produce the intermediates** — assumptions document, uncovered ambiguities, oracle candidates, and the traceability chain — even in abbreviated form.\n\n**Flag these when detected:**\n- **Hallucinated APIs** — endpoints, selectors, methods, or imports that do not exist in the codebase. Verify mechanically (see Verification) before human review.\n- **Duplicate scenarios** — same behavior, trivially different data. Consolidate or parametrize.\n- **Low-value assertions** — `expect(response).toBeTruthy()`, `expect(page).toHaveURL(\u002F.*\u002F)`.\n- **Missing negative cases** — if every scenario is a happy path, the coverage matrix is incomplete.\n- **Unrealistic test data** — `test@test.com`, `John Doe`, `password123`. Use diverse, plausible data on `example.com`.\n\n## Model selection per step\n\nRoute by difficulty, not habit. Use a cheap model for mechanical extraction (Step 1) and the coverage-matrix bookkeeping (Step 3) — **Haiku 4.5** or **Sonnet 4.6** are plenty. Escalate to **Opus 4.8** for oracle design (Step 5) and hallucination-sensitive code generation (Step 6), where a wrong inference is expensive; reach for **Fable 5** only on genuinely hard reasoning (subtle invariants, regulated-domain logic). Running the strongest model on every step is wasteful; running the cheapest on Step 6 produces fabricated APIs.\n\n## Verification\n\nConvert the \"hallucinated APIs\" warning into a mechanical gate. After Step 6, before human review:\n\n1. **Resolve imports \u002F types.** TypeScript: `npx tsc --noEmit` — fabricated imports and wrong signatures fail here. Python: `python -m pyflakes \u003Cfiles>` or `ruff check`.\n2. **Grep generated selectors\u002Fendpoints against the codebase.** Confirm every `getByTestId('...')` id and every API path the test calls actually exists in source:\n   ```bash\n   grep -roE \"getByTestId\\('([^']+)'\\)\" generated\u002F | sed -E \"s\u002F.*'([^']+)'.*\u002F\\1\u002F\" | sort -u \\\n     | while read id; do grep -rq \"$id\" src\u002F || echo \"MISSING testid: $id\"; done\n   ```\n3. **Run the suite once.** Tests that reference nonexistent routes\u002Fselectors fail fast; quarantine those before review rather than reviewing dead code.\n\nAny `MISSING` line or `tsc` error is a hallucination to fix before a human spends review time.\n\n## Anti-Patterns\n\n1. **Skipping to code.** The most common failure: an agent gets a PRD and immediately writes tests. Without the coverage matrix it misses scenarios and duplicates others. The pipeline exists to prevent this.\n2. **Asserting implementation instead of behavior.** `expect(component.state.isLoading).toBe(true)` breaks on any refactor. Assert `expect(screen.getByRole('progressbar')).toBeVisible()` — what the user observes.\n3. **Mixing scenarios and assertions.** Writing \"test this thing and check this value\" as one step. Separate *what to test* from *how to verify it*.\n4. **No project context in the prompt.** Without conventions and existing patterns, you get generic tests. `qa-project-context.md` exists for exactly this.\n5. **Over-generating.** AI will write 50 tests for a simple function. Each carries maintenance cost. Use the coverage matrix to bound generation to meaningful scenarios.\n6. **Copy-paste without understanding.** If you cannot explain what a generated test does and why, do not merge it. Tests you do not understand become tests you cannot debug.\n7. **Shipping without review.** Step 7 is not optional. AI tests routinely contain hallucinated APIs, wrong selectors, incorrect business logic, and flakiness only human review catches.\n8. **Ignoring the feedback loop.** When AI tests catch real bugs, note the prompt patterns that worked; when they false-positive, note what went wrong. Build a project-specific library of what works.\n\n## Done When\n\n- All seven artifacts exist: requirements document, risk & invariants, coverage matrix, scenario set, oracle definitions, test code, and review notes with a KEEP\u002FMODIFY\u002FREJECT\u002FDEFER decision per test.\n- The coverage matrix was produced and reviewed before any test code file was written.\n- Verification passed: `tsc --noEmit` (or language equivalent) exits 0 and the selector\u002Fendpoint grep reports zero `MISSING` lines.\n- Each generated test has a recorded human review decision; no test is marked KEEP without one.\n- The suite's CI job exits 0 (green).\n- Reproducibility metadata recorded: the exact model ID (e.g. `claude-opus-4-8`, `claude-sonnet-4-6`, `claude-haiku-4-5-20251001`), input source hash, and the version of any skill \u002F CLI \u002F MCP server invoked.\n\n## Related Skills\n\n- **qa-project-context** — Set up the context file that makes AI test generation dramatically better. Configure this first.\n- **playwright-automation** — Deep Playwright patterns (POM, fixtures, CI), plus the Test Agents (`init-agents --loop=claude`, scaffolded into `.claude\u002Fagents\u002F`) and `@playwright\u002Fmcp` modes chosen in Discovery Q2. Generated tests live inside this framework.\n- **unit-testing** — Jest, Vitest, pytest patterns for unit-level generated tests.\n- **api-testing** — Endpoint test patterns for tests generated from OpenAPI specs.\n- **test-strategy** — Decide *what* to test and at which level before generating.\n- **test-reliability** — Make generated tests reliable: flake classification, healing, video receipts.\n- **ai-system-testing** — When the input is an LLM feature spec, generate eval datasets here (Promptfoo, DeepEval, Ragas, Braintrust) instead of Playwright specs.\n- **ai-qa-review** — Audit a *pre-existing* suite you did not just generate (test smells, testability). Step 7 here only reviews this pipeline's own output.\n- **ai-bug-triage** — When generated tests find bugs, classify and report them through the triage pipeline.\n\n## Reference Files (in `references\u002F`)\n\n- **prompt-patterns.md** — Full prompt library aligned to the seven steps: extraction, risk analysis, scenario generation, oracle design, and code generation prompts, plus the BOUNDARIES edge-case framework used in Step 4.\n",{"name":5,"license":15,"metadata":60,"description":7},{"author":61,"version":62,"category":63},"kindlmann","2.0","ai-qa","claude\u002Finstall-gsd-build-foQdV","d86cd127f527124b5fd0fd0bc679a4d79b7d01d7",".agents\u002Fskills\u002Fai-test-generation","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 ai-test-generation",{"tool":77,"command":78},"bunx","bunx skills add pattanation\u002FNorvik --skill ai-test-generation",{"tool":80,"command":81},"pnpm","pnpm dlx skills add pattanation\u002FNorvik --skill ai-test-generation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fai-test-generation\u002FSKILL.md",true,[85],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fprompt-patterns.md","REFERENCE","参考文档",16088,"https:\u002F\u002Fgithub.com\u002Fpattanation\u002FNorvik\u002Fblob\u002Fclaude\u002Finstall-gsd-build-foQdV\u002F.agents\u002Fskills\u002Fai-test-generation\u002Freferences\u002Fprompt-patterns.md",[92,122,148,170,191,206],{"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":121},"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":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发",[105,48,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120],"webapp","webapp testing","for","applications","local","frontend","debugging","toolkit","logs","browser","with","playwright","web","behavior","ui","screenshots","2026-11-10 13:02:02",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":96,"licenseFileUrl":126,"sourceHtmlUrl":127,"categories":128,"keywords":130,"publishedAt":121},"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",[129],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[131,132,133,117,134,135,136,107,137,138,110,139,140,141,142,143,144,145,146,147],"builder","artifacts builder","artifacts","web artifacts builder","single-file","css","Tailwind","ui components","single","use","file","components","react","multi","state","routing","state management",{"skillNo":149,"name":150,"nameZh":6,"description":151,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":152,"sourceHtmlUrl":153,"categories":154,"keywords":156,"publishedAt":121},"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",[155],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[157,158,159,50,160,161,162,163,164,165,166,167,168,169],"functions","vueuse","vueuse functions","nuxt","apply","github","concise","build","https","features","vue","js","composables",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":174,"sourceHtmlUrl":175,"categories":176,"keywords":179,"publishedAt":121},"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",[177,178],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[180,48,181,167,182,116,36,183,184,162,185,107,186,187,188,140,189,168,190],"vue testing best practices","testing best practices","best practices","testing patterns","component","vitest","mocking","e2e","utils","patterns","e2e testing",{"skillNo":192,"name":193,"nameZh":6,"description":194,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":195,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":121},"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",[198],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[200,167,201,182,202,184,203,162,189,204,205],"router","vue router best practices","route","guards","navigation","lifecycle",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":210,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":121},"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",[213],{"categoryNo":102,"categoryName":103,"taxonomyType":21,"taxonomyTypeDesc":22},[215,167,182,216,50,217,218,219,200,220,221,222,223,224,225,107,226,140,227,228],"vue best practices","Composition","files","tasks","api","pinia","work","options","ssr","typescript","as","vite","load","standard"]