[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M699D366Z5B6RH2W21SKGHF2":3,"skill-same:01M699D366Z5B6RH2W21SKGHF2":92},{"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":31,"publishedAt":54,"linkOnly":55,"markdownContent":56,"markdownBody":57,"frontMatter":58,"refName":59,"commitSha":60,"skillDirectory":61,"forksCount":62,"repositoryHtmlUrl":63,"repositoryHomepageUrl":6,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":81},"01M699D366Z5B6RH2W21SKGHF2","code-testing",null,"ALWAYS USE for test work that requires changes: write, add, generate, repair, or strengthen tests for existing code in xUnit, MSTest, NUnit, pytest, Vitest\u002FJest, Go, or another framework. Includes regression cases, failing or flaky tests, coverage-driven additions, and audit-then-fix requests. Focused work stays direct; broad or multi-stage work invokes test-engineer. DO NOT USE for only running tests, analysis-only audits, framework\u002Fplatform migrations, a test blocked on a missing production seam (testability-obstacle), or MSTest API\u002Fconfiguration corrections that do not design new cases (writing-mstest-tests). Within an active test-engineer pipeline, reuse supplied guidance and do not re-enter this skill.","microsoft\u002Ftestfx","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699C71CJ91B5WZ3AXG3GG2M",1059,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcode-testing\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53],"code testing","code","testing","engineer","failing","strengthen","seam","for","re","reuse","platform","active","jest","do","fix","write","generate","mstest","test","go","writing","design","2026-11-10 10:12:30",false,"---\nname: code-testing\ndescription: >-\n  ALWAYS USE for test work that requires changes: write, add, generate, repair,\n  or strengthen tests for existing code in xUnit, MSTest, NUnit, pytest,\n  Vitest\u002FJest, Go, or another framework. Includes regression cases, failing or\n  flaky tests, coverage-driven additions, and audit-then-fix requests. Focused\n  work stays direct; broad or multi-stage work invokes test-engineer. DO NOT USE\n  for only running tests, analysis-only audits, framework\u002Fplatform migrations,\n  a test blocked on a missing production seam (testability-obstacle), or MSTest\n  API\u002Fconfiguration corrections that do not design new cases\n  (writing-mstest-tests). Within an active test-engineer pipeline, reuse supplied\n  guidance and do not re-enter this skill.\nlicense: MIT\n---\n\n# Code Testing Skill\n\nThe reliable implicit entry point for generating, repairing, and strengthening\ntests. It handles focused work directly and invokes the public `test-engineer`\nagent for broad or multi-stage requests.\n\n## Non-negotiable execution contract\n\n**Check pipeline ownership first.** If the active agent is\n`test-engineer` (including a plugin-qualified name such as\n`dotnet-test:test-engineer`), or the caller assigned you a phase of\nthat pipeline, do not delegate to another generator. Continue the assigned\nwork inline. This guard takes precedence over every broad-scope delegation\ninstruction below, even if this skill was loaded automatically.\n\nClassify scope **before editing**:\n\n- **Broad** (a project\u002Fpackage-wide suite, or multiple production\n  files\u002Fmodules): create `research.md` and `plan.md` in a resolved\n  non-stageable `\u003CTESTAGENT_DIR>` before implementation, then `status.md` there\n  after the final test-quality review. When `test-engineer` is\n  available, invoke that named custom agent before implementing; do not replace\n  it with a generic subagent carrying the same label or implement the broad\n  request inline. If the state files are absent, the broad workflow is\n  incomplete.\n- **Focused** (the user explicitly limits work to one function\u002Fclass\u002Ffile or one\n  missing method): do not create intermediate state files or fan out to multiple\n  agents. A sparse project-wide request remains broad even when only one source\n  module is present.\n\nFor either scope, run the narrowest relevant test command to a clean exit.\nAlways apply [Report-safe test names and result validation](unit-test-generation.prompt.md#report-safe-test-names-and-result-validation),\nincluding when the caller supplies conventions. Pass this contract to delegated\nimplementers\u002Ftesters; preserve edge-case data and validate configured reports,\nnot just console output.\nKeep the handoff proportional: for one to three focused requirements, use a\ncompact bullet list under a **Requirement coverage** label that names the tests\nand successful command; for broader or multi-requirement work, use a\n`Requirement | Evidence` table. Each requested behavior must cite an exact test\nname.\n\nBefore sending a broad-scope final response, check that the response itself\ncontains `| Requirement | Evidence |` and exact test names for every behavioral\nrow. A table in a child report or internal plan is not enough. Do not summarize\naway those names into module-level bullets or an `Area | Tests` table.\n\nIntermediate state files are internal working data, never deliverables. Keep\n`\u003CTESTAGENT_DIR>` non-stageable, never place it or its files in\nversion-controlled workspace content, and never modify `.gitignore` to hide\nthem.\n\nTreat completeness as a requirement matrix, not a test-count target. Give every\nindependently requested state, boundary, error path, or interaction its own\nconcrete assertion. Combine cases only when one execution genuinely proves the\nwhole requested combination; do not let a parameterized happy-path case stand in\nfor an empty state, invalid discriminator, or before\u002Fat\u002Fafter boundary.\nFor broad requests that name several production modules or layers, give each\nnamed module direct tests for its non-trivial public behavior. Cross-module tests\nprove composition, but do not substitute for the requested module-level\ncoverage. Judge breadth by the behavior matrix, never by matching or exceeding a\nraw test count.\n\nAt the public entry point, delegate broad work to `test-engineer`\nonce. Research, plan, implementation, and review remain required, but they\nneed not be separate sub-agent calls.\n\nUse only capabilities available in the current runtime. Do not retry a missing\nskill under aliases or use another agent to retry a policy-denied operation.\nIf scratch storage is denied, keep the research and plan in context, continue\npermitted test edits, and report the missing state artifacts. If execution is\ndenied, continue permitted static review and report tests as unrun, never passed.\nNeither blocker authorizes modifying production code or weakening requirements.\n\nFor a **broad or comprehensive** request, the explicit matrix is the floor, not\nthe ceiling. Treat each requested module or layer as an inventory heading, not\none behavior: expand it into the bounded public operations and their distinct\nvalidation paths, branches, boundaries, interactions, and state transitions.\nAfter satisfying the explicit matrix, inspect each target API for observable\nequivalence partitions and invariants that the prompt did not name: identity,\nempty, singleton and representative interior inputs; exact boundaries plus an\nimmediately adjacent value; invalid partitions; and ordering, monotonicity,\nrollover, capacity, truncation, or state invariants implied by the implementation.\nAdd one mutation-relevant case per distinct partition not already proved, using\nparameterized or table-driven cases only for siblings that prove the same\nbehavior. A passing coverage threshold is validation, not a breadth stop\ncondition. Stop when remaining inputs exercise the same branch and invariant,\nnot merely when the explicit checklist is complete; never add cases only to\nraise the count.\n\n## When to Use This Skill\n\nUse this skill when you need to:\n\n- Generate unit tests for an entire project or specific files\n- Improve test coverage for existing codebases\n- Create test files that follow project conventions\n- Write tests that actually compile and pass\n- Add tests for new features or untested code\n- Generate or extend MSTest suites; load `writing-mstest-tests` as supporting\n  guidance after this entry skill has established scope and project conventions\n\n## When Not to Use\n\n- Running or executing existing tests (use the `run-tests` skill)\n- Migrating between test frameworks or platforms (report that migration\n  workflows are not installed in this repository; do not delegate to removed\n  skills)\n- Answering an MSTest API\u002Fpattern or modernization question that does not ask to\n  generate tests (use `writing-mstest-tests`)\n- Analysis-only diagnosis of failing tests when no code or test changes are\n  requested\n\n## How It Works\n\nThis skill coordinates multiple specialized agents in a **Research → Plan → Implement** pipeline:\n\n### Pipeline Overview\n\n```text\n┌─────────────────────────────────────────────────────────────┐\n│                     TEST GENERATOR                          │\n│  Coordinates the full pipeline and manages state            │\n└─────────────────────┬───────────────────────────────────────┘\n                      │\n        ┌─────────────┼─────────────┐\n        ▼             ▼             ▼\n┌───────────┐  ┌───────────┐  ┌───────────────┐\n│ RESEARCHER│  │  PLANNER  │  │  IMPLEMENTER  │\n│           │  │           │  │               │\n│ Analyzes  │  │ Creates   │  │ Writes tests  │\n│ codebase  │→ │ phased    │→ │ per phase     │\n│           │  │ plan      │  │               │\n└───────────┘  └───────────┘  └───────┬───────┘\n                                      │\n                    ┌─────────┬───────┼───────────┐\n                    ▼         ▼       ▼           ▼\n              ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐\n              │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │\n              │         │ │       │ │       │ │       │\n              │ Compiles│ │ Runs  │ │ Fixes │ │Formats│\n              │ code    │ │ tests │ │ errors│ │ code  │\n              └─────────┘ └───────┘ └───────┘ └───────┘\n```\n\n## Step-by-Step Instructions\n\n### Step 1: Determine the user request\n\nClassify both intent and scope before editing:\n\n- **Generate or extend**: follow the generation workflow below.\n- **Repair**: reproduce the narrow failure, determine whether the defect is in\n  the test or production behavior, make the smallest authorized fix, and rerun\n  the covering command.\n- **Audit then fix**: invoke `test-engineer` so it can coordinate the internal\n  quality specialist and implementation work.\n\nMake sure you understand what user is asking and for what scope.\nWhen the user does not express strong requirements for test style, coverage goals, or conventions, source the guidelines from [unit-test-generation.prompt.md](unit-test-generation.prompt.md). This prompt provides best practices for discovering conventions, parameterization strategies, behavior-focused coverage, and language-specific patterns.\n\n### Step 2: Size the request before invoking anything\n\nMatch the machinery to the scope. Running the full pipeline on a one-file\nrequest costs turns and tool calls without improving the tests.\n\n| Scope | What it looks like | How to run it |\n| --- | --- | --- |\n| **Focused** | One function, class, or file; \"tests for X only\"; extending an existing suite with the missing cases | Skip intermediate state files and the sub-agent fan-out. Keep the requirement checklist in your head (or in the final table), read only the target and one neighbouring test for conventions, write the tests, run the narrowest test command, review your own assertions inline. |\n| **Broad** | A project, package, or module set; \"comprehensive suite\"; a coverage threshold to clear across several files | Run the full Research → Plan → Implement pipeline in Step 3, with intermediate state files under `\u003CTESTAGENT_DIR>` and the completion contract below. |\n\nWhen in doubt, start focused and escalate only if the request turns out to span\nseveral files. Escalating costs one extra pass; running the broad pipeline on a\nfocused request costs several.\n\nBefore ending a focused request, check all three conditions together:\n\n1. every named behavior has a concrete assertion, including each requested\n   boundary or error path;\n2. the narrow test command exited successfully;\n3. the final handoff maps those behaviors to exact test names and cites that\n   successful command.\n\nDo not replace requirement-level evidence with a generic list of covered areas.\n\n### Step 3: Invoke the Test Generator (broad scope)\n\nStart by invoking the named `test-engineer` custom agent with your test\ngeneration request. Do not use a generic\u002Fgeneral-purpose subagent merely named\n`test-engineer`:\n\n```text\nYou are the sole pipeline owner for this request. Do not invoke code-testing or another test-engineer; complete the phases in your current context. Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines. Treat the current workspace as authoritative even when it is sparse, gutted-looking, synthetic, or missing tracked files; never restore or reconstruct it, including with `git checkout`, `git restore`, `git reset`, or `git clean`.\n```\n\nThe Test Generator owns the pipeline. After it returns, consume its recorded\nquality checks, validation results, and requirement matrix instead of repeating\nSteps 4 and 5 as another pipeline. Do not reload review skills or rerun unchanged\npassing commands. Preserve exact test names from its evidence in the final\nhandoff. If evidence is missing, inspect or follow up on that specific gap\nwithout restarting generation. A reported capability-wide denial also applies\nto the caller; do not attempt another command using that capability.\n\nIf `test-engineer` is unavailable, do not skip the workflow. Execute the\nsame Research → Plan → Implement sequence inline, resolve `\u003CTESTAGENT_DIR>` as\ndescribed below, create the intermediate state files there, and apply the same\ncompletion contract.\n\nFor broad scope, resolve one absolute `\u003CTESTAGENT_DIR>` before creating\nintermediate state files:\n\n1. Prefer a host-provided session artifact or scratch directory.\n2. Otherwise, in a Git worktree run\n   `git rev-parse --path-format=absolute --git-path testagent`; this returns a\n   path in worktree-specific Git metadata that cannot be staged.\n3. Outside Git, create a unique directory under the operating system's\n   temporary directory.\n\nPass the absolute directory to every pipeline agent. The path may be inside the\nrepository's `.git` metadata directory, but it must not be version-controlled\nworkspace content, appear in `git status`, or be stageable.\n\n### Step 4: Execute with bounded context\n\nFor multi-file requests:\n\n1. Turn every explicit user requirement into a checklist before implementation. Include requested layers, collaborators to mock, boundary cases, integrations, coverage thresholds, and report artifacts. Copy multi-condition requirements verbatim — they must each map to one test that exercises the whole combination.\n2. Research only the requested module or project and write the checklist plus a compact target inventory to `\u003CTESTAGENT_DIR>\u002Fresearch.md`.\n3. Reuse manifests, symbol references, and deterministic pairing tools instead of reading every source and test file.\n4. When an available `find-untested-sources` skill is useful for a substantial multi-file inventory, run it once and reuse its pairing and suggested-path output. Otherwise pair the bounded targets manually once; do not probe for an unavailable skill.\n5. Plan each target file once, then implement phases sequentially. Map every checklist item to at least one concrete test or explain why it is blocked.\n6. Build and test the narrow target during fix cycles. Run workspace-level\n   validation once at the end only for broad work, when the repository contract\n   requires that entry point, or when the changes can affect other projects.\n7. Before reporting success, re-open the generated tests and verify every checklist item against concrete test names and assertions. Coverage alone is not evidence that a requested mock seam, boundary, state transition, or property combination was tested.\n8. Read a language example from `code-testing-extensions` only when the repository has no representative tests and the base extension is insufficient.\n9. For .NET, classify SDK-style vs. classic non-SDK before choosing commands or creating files. In classic projects, preserve `packages.config`, existing framework\u002Fmock versions and custom base fixtures, add every new test file to the project's explicit `\u003CCompile Include>` items, and use the repository's MSBuild\u002Ftest-runner commands. Never modernize the project or dependency stack merely to generate tests.\n10. For MSTest, inspect the pinned package version before choosing exception\n    assertions. MSTest 3.5.x uses `Assert.ThrowsException\u003CT>`; do not substitute\n    `[ExpectedException]`, `Assert.Throws\u003CT>`, or `Assert.ThrowsExactly\u003CT>`.\n\n### Completion contract\n\nEvery scope must satisfy points 3–5 below. Points 1 and 2 are the **broad-scope**\nartifacts: on a focused request the same reasoning happens inline and no\nintermediate state files are written.\n\nDo not report completion until all of these are true:\n\n1. *(broad scope)* `\u003CTESTAGENT_DIR>\u002Fresearch.md` records the bounded target\n   inventory, existing test conventions, and the acceptance checklist.\n2. *(broad scope)* `\u003CTESTAGENT_DIR>\u002Fplan.md` maps each checklist item to a planned\n   test or an explicit blocker.\n3. Generated tests compile and pass with the narrowest relevant test command,\n   satisfying the shared report-safe naming and result-validation contract.\n4. Every explicit user requirement is backed by a concrete test and assertion.\n   Fix missing mock seams, boundary cases, state transitions, and property\n   combinations even when coverage already passes. In the final summary, cite\n   at least one generated test name for every checklist item so completion is\n   auditable; if an item has no test to cite, keep implementing or report it as\n   blocked. For non-behavioral requirements such as scaffolding, scope limits,\n   commands, or coverage artifacts, cite the relevant file, command, or report\n   instead of forcing a test-name mapping.\n   A passing suite with fewer tests is not automatically weaker: judge\n   completeness by whether every independently requested behavior has direct,\n   nonredundant evidence, not by raw test volume.\n   For broad\u002Fcomprehensive scope, also verify that every observable equivalence\n   partition and invariant discovered in the bounded target APIs has one\n   mutation-relevant case, even when the prompt did not name it.\n   When the request names multiple modules, verify that each module's own\n   non-trivial public behavior has direct test evidence in addition to any\n   end-to-end composition test.\n5. Review the generated tests for behavior gaps and weak assertions. On a broad\n   scope, invoke `test-gap-analysis` and `assertion-quality` when available and\n   record the findings and fixes in `\u003CTESTAGENT_DIR>\u002Fstatus.md`. On a focused scope,\n   do the equivalent review inline — re-read each generated assertion against\n   the source — without spawning extra passes.\n\nThe final response must provide requirement-by-requirement evidence. Use compact\nbullets under a **Requirement coverage** label for one to three focused\nrequirements; use a `Requirement | Evidence` table for broader scopes.\nBehavioral evidence cites exact generated test names. Non-behavioral evidence\ncites the relevant project file, validation command, or coverage report. A\ngeneric list of tested areas is not a substitute.\n\nPreserve the user's exact meaning in each evidence item; quote verbatim only\nwhen wording distinguishes a required combination. A test that merely exercises\nthe same collaborators does not satisfy a requirement about their interaction,\nand per-class requirements need a citation per class.\n\n**Cite a clean run, not an attempt.** The commands behind the final evidence must\nhave finished successfully: quote the final passing test summary and, when\nthresholds were requested, the per-module coverage table from a run that exited\n0. If the last coverage run exited non-zero, fix it and re-run before reporting;\nnever infer threshold clearance from a failed or partial run.\n\nBefore reporting, inspect the final working-tree changes and confirm that\n`research.md`, `plan.md`, `status.md`, and any other intermediate state files are\nnot among the changes intended for commit.\n\n## State Management\n\nBroad-scope runs store intermediate state files in a non-stageable\n`\u003CTESTAGENT_DIR>` backed by host scratch storage, Git metadata, or OS temp. A\nfocused request does not create these files:\n\n| File                     | Purpose                      |\n| ------------------------ | ---------------------------- |\n| `\u003CTESTAGENT_DIR>\u002Fresearch.md` | Codebase analysis results    |\n| `\u003CTESTAGENT_DIR>\u002Fplan.md`     | Phased implementation plan   |\n| `\u003CTESTAGENT_DIR>\u002Fstatus.md`   | Final quality review and fixes |\n\n## Agent Reference\n\n| Agent                      | Purpose              |\n| -------------------------- | -------------------- |\n| `test-engineer`   | Coordinates pipeline |\n| `code-testing-researcher`  | Analyzes codebase    |\n| `code-testing-planner`     | Creates test plan    |\n| `code-testing-implementer` | Writes test files    |\n| `code-testing-builder`     | Compiles code        |\n| `code-testing-tester`      | Runs tests           |\n| `code-testing-fixer`       | Fixes errors         |\n| `code-testing-linter`      | Formats code         |\n\n## Requirements\n\n- Project must have a build\u002Ftest system configured\n- Testing framework should be installed (or installable)\n- VS Code with GitHub Copilot extension\n\nClassic non-SDK .NET projects are supported when their existing build\u002Ftest\ntoolchain is available. When it is not available on the current machine, the\nagent can still add and register version-compatible tests, but must report\nexecution as blocked rather than substituting `dotnet test`.\n\n## Troubleshooting\n\n### Tests don't compile\n\nThe `code-testing-fixer` agent will attempt to resolve compilation errors. Check\n`\u003CTESTAGENT_DIR>\u002Fplan.md` for the expected test structure. Call the\n`code-testing-extensions` skill and read the language-specific extension file\nfor error code references (e.g., `dotnet.md` for .NET).\n\n### Tests fail\n\nMost failures in generated tests are caused by **wrong expected values in assertions**, not production code bugs:\n\n1. Read the actual test output\n2. Read the production code to understand correct behavior\n3. Fix the assertion, not the production code\n4. Never mark tests `[Ignore]` or `[Skip]` just to make them pass\n\n### Wrong testing framework detected\n\nSpecify your preferred framework in the initial request: \"Generate Jest tests for...\"\n\n### Environment-dependent tests fail\n\nTests that depend on external services, network endpoints, specific ports, or precise timing will fail in CI environments. Focus on unit tests with mocked dependencies instead.\n\n### Broader validation fails\n\nDuring implementation, build and test the narrow target. Run a solution or\nworkspace-level command only for broad work, when the repository contract uses\nthat entry point, or when the targeted change can affect other projects. Do not\nturn a focused test request into an unconditional full non-incremental build.\n","# Code Testing Skill\n\nThe reliable implicit entry point for generating, repairing, and strengthening\ntests. It handles focused work directly and invokes the public `test-engineer`\nagent for broad or multi-stage requests.\n\n## Non-negotiable execution contract\n\n**Check pipeline ownership first.** If the active agent is\n`test-engineer` (including a plugin-qualified name such as\n`dotnet-test:test-engineer`), or the caller assigned you a phase of\nthat pipeline, do not delegate to another generator. Continue the assigned\nwork inline. This guard takes precedence over every broad-scope delegation\ninstruction below, even if this skill was loaded automatically.\n\nClassify scope **before editing**:\n\n- **Broad** (a project\u002Fpackage-wide suite, or multiple production\n  files\u002Fmodules): create `research.md` and `plan.md` in a resolved\n  non-stageable `\u003CTESTAGENT_DIR>` before implementation, then `status.md` there\n  after the final test-quality review. When `test-engineer` is\n  available, invoke that named custom agent before implementing; do not replace\n  it with a generic subagent carrying the same label or implement the broad\n  request inline. If the state files are absent, the broad workflow is\n  incomplete.\n- **Focused** (the user explicitly limits work to one function\u002Fclass\u002Ffile or one\n  missing method): do not create intermediate state files or fan out to multiple\n  agents. A sparse project-wide request remains broad even when only one source\n  module is present.\n\nFor either scope, run the narrowest relevant test command to a clean exit.\nAlways apply [Report-safe test names and result validation](unit-test-generation.prompt.md#report-safe-test-names-and-result-validation),\nincluding when the caller supplies conventions. Pass this contract to delegated\nimplementers\u002Ftesters; preserve edge-case data and validate configured reports,\nnot just console output.\nKeep the handoff proportional: for one to three focused requirements, use a\ncompact bullet list under a **Requirement coverage** label that names the tests\nand successful command; for broader or multi-requirement work, use a\n`Requirement | Evidence` table. Each requested behavior must cite an exact test\nname.\n\nBefore sending a broad-scope final response, check that the response itself\ncontains `| Requirement | Evidence |` and exact test names for every behavioral\nrow. A table in a child report or internal plan is not enough. Do not summarize\naway those names into module-level bullets or an `Area | Tests` table.\n\nIntermediate state files are internal working data, never deliverables. Keep\n`\u003CTESTAGENT_DIR>` non-stageable, never place it or its files in\nversion-controlled workspace content, and never modify `.gitignore` to hide\nthem.\n\nTreat completeness as a requirement matrix, not a test-count target. Give every\nindependently requested state, boundary, error path, or interaction its own\nconcrete assertion. Combine cases only when one execution genuinely proves the\nwhole requested combination; do not let a parameterized happy-path case stand in\nfor an empty state, invalid discriminator, or before\u002Fat\u002Fafter boundary.\nFor broad requests that name several production modules or layers, give each\nnamed module direct tests for its non-trivial public behavior. Cross-module tests\nprove composition, but do not substitute for the requested module-level\ncoverage. Judge breadth by the behavior matrix, never by matching or exceeding a\nraw test count.\n\nAt the public entry point, delegate broad work to `test-engineer`\nonce. Research, plan, implementation, and review remain required, but they\nneed not be separate sub-agent calls.\n\nUse only capabilities available in the current runtime. Do not retry a missing\nskill under aliases or use another agent to retry a policy-denied operation.\nIf scratch storage is denied, keep the research and plan in context, continue\npermitted test edits, and report the missing state artifacts. If execution is\ndenied, continue permitted static review and report tests as unrun, never passed.\nNeither blocker authorizes modifying production code or weakening requirements.\n\nFor a **broad or comprehensive** request, the explicit matrix is the floor, not\nthe ceiling. Treat each requested module or layer as an inventory heading, not\none behavior: expand it into the bounded public operations and their distinct\nvalidation paths, branches, boundaries, interactions, and state transitions.\nAfter satisfying the explicit matrix, inspect each target API for observable\nequivalence partitions and invariants that the prompt did not name: identity,\nempty, singleton and representative interior inputs; exact boundaries plus an\nimmediately adjacent value; invalid partitions; and ordering, monotonicity,\nrollover, capacity, truncation, or state invariants implied by the implementation.\nAdd one mutation-relevant case per distinct partition not already proved, using\nparameterized or table-driven cases only for siblings that prove the same\nbehavior. A passing coverage threshold is validation, not a breadth stop\ncondition. Stop when remaining inputs exercise the same branch and invariant,\nnot merely when the explicit checklist is complete; never add cases only to\nraise the count.\n\n## When to Use This Skill\n\nUse this skill when you need to:\n\n- Generate unit tests for an entire project or specific files\n- Improve test coverage for existing codebases\n- Create test files that follow project conventions\n- Write tests that actually compile and pass\n- Add tests for new features or untested code\n- Generate or extend MSTest suites; load `writing-mstest-tests` as supporting\n  guidance after this entry skill has established scope and project conventions\n\n## When Not to Use\n\n- Running or executing existing tests (use the `run-tests` skill)\n- Migrating between test frameworks or platforms (report that migration\n  workflows are not installed in this repository; do not delegate to removed\n  skills)\n- Answering an MSTest API\u002Fpattern or modernization question that does not ask to\n  generate tests (use `writing-mstest-tests`)\n- Analysis-only diagnosis of failing tests when no code or test changes are\n  requested\n\n## How It Works\n\nThis skill coordinates multiple specialized agents in a **Research → Plan → Implement** pipeline:\n\n### Pipeline Overview\n\n```text\n┌─────────────────────────────────────────────────────────────┐\n│                     TEST GENERATOR                          │\n│  Coordinates the full pipeline and manages state            │\n└─────────────────────┬───────────────────────────────────────┘\n                      │\n        ┌─────────────┼─────────────┐\n        ▼             ▼             ▼\n┌───────────┐  ┌───────────┐  ┌───────────────┐\n│ RESEARCHER│  │  PLANNER  │  │  IMPLEMENTER  │\n│           │  │           │  │               │\n│ Analyzes  │  │ Creates   │  │ Writes tests  │\n│ codebase  │→ │ phased    │→ │ per phase     │\n│           │  │ plan      │  │               │\n└───────────┘  └───────────┘  └───────┬───────┘\n                                      │\n                    ┌─────────┬───────┼───────────┐\n                    ▼         ▼       ▼           ▼\n              ┌─────────┐ ┌───────┐ ┌───────┐ ┌───────┐\n              │ BUILDER │ │TESTER │ │ FIXER │ │LINTER │\n              │         │ │       │ │       │ │       │\n              │ Compiles│ │ Runs  │ │ Fixes │ │Formats│\n              │ code    │ │ tests │ │ errors│ │ code  │\n              └─────────┘ └───────┘ └───────┘ └───────┘\n```\n\n## Step-by-Step Instructions\n\n### Step 1: Determine the user request\n\nClassify both intent and scope before editing:\n\n- **Generate or extend**: follow the generation workflow below.\n- **Repair**: reproduce the narrow failure, determine whether the defect is in\n  the test or production behavior, make the smallest authorized fix, and rerun\n  the covering command.\n- **Audit then fix**: invoke `test-engineer` so it can coordinate the internal\n  quality specialist and implementation work.\n\nMake sure you understand what user is asking and for what scope.\nWhen the user does not express strong requirements for test style, coverage goals, or conventions, source the guidelines from [unit-test-generation.prompt.md](unit-test-generation.prompt.md). This prompt provides best practices for discovering conventions, parameterization strategies, behavior-focused coverage, and language-specific patterns.\n\n### Step 2: Size the request before invoking anything\n\nMatch the machinery to the scope. Running the full pipeline on a one-file\nrequest costs turns and tool calls without improving the tests.\n\n| Scope | What it looks like | How to run it |\n| --- | --- | --- |\n| **Focused** | One function, class, or file; \"tests for X only\"; extending an existing suite with the missing cases | Skip intermediate state files and the sub-agent fan-out. Keep the requirement checklist in your head (or in the final table), read only the target and one neighbouring test for conventions, write the tests, run the narrowest test command, review your own assertions inline. |\n| **Broad** | A project, package, or module set; \"comprehensive suite\"; a coverage threshold to clear across several files | Run the full Research → Plan → Implement pipeline in Step 3, with intermediate state files under `\u003CTESTAGENT_DIR>` and the completion contract below. |\n\nWhen in doubt, start focused and escalate only if the request turns out to span\nseveral files. Escalating costs one extra pass; running the broad pipeline on a\nfocused request costs several.\n\nBefore ending a focused request, check all three conditions together:\n\n1. every named behavior has a concrete assertion, including each requested\n   boundary or error path;\n2. the narrow test command exited successfully;\n3. the final handoff maps those behaviors to exact test names and cites that\n   successful command.\n\nDo not replace requirement-level evidence with a generic list of covered areas.\n\n### Step 3: Invoke the Test Generator (broad scope)\n\nStart by invoking the named `test-engineer` custom agent with your test\ngeneration request. Do not use a generic\u002Fgeneral-purpose subagent merely named\n`test-engineer`:\n\n```text\nYou are the sole pipeline owner for this request. Do not invoke code-testing or another test-engineer; complete the phases in your current context. Generate unit tests for [path or description of what to test], following the [unit-test-generation.prompt.md](unit-test-generation.prompt.md) guidelines. Treat the current workspace as authoritative even when it is sparse, gutted-looking, synthetic, or missing tracked files; never restore or reconstruct it, including with `git checkout`, `git restore`, `git reset`, or `git clean`.\n```\n\nThe Test Generator owns the pipeline. After it returns, consume its recorded\nquality checks, validation results, and requirement matrix instead of repeating\nSteps 4 and 5 as another pipeline. Do not reload review skills or rerun unchanged\npassing commands. Preserve exact test names from its evidence in the final\nhandoff. If evidence is missing, inspect or follow up on that specific gap\nwithout restarting generation. A reported capability-wide denial also applies\nto the caller; do not attempt another command using that capability.\n\nIf `test-engineer` is unavailable, do not skip the workflow. Execute the\nsame Research → Plan → Implement sequence inline, resolve `\u003CTESTAGENT_DIR>` as\ndescribed below, create the intermediate state files there, and apply the same\ncompletion contract.\n\nFor broad scope, resolve one absolute `\u003CTESTAGENT_DIR>` before creating\nintermediate state files:\n\n1. Prefer a host-provided session artifact or scratch directory.\n2. Otherwise, in a Git worktree run\n   `git rev-parse --path-format=absolute --git-path testagent`; this returns a\n   path in worktree-specific Git metadata that cannot be staged.\n3. Outside Git, create a unique directory under the operating system's\n   temporary directory.\n\nPass the absolute directory to every pipeline agent. The path may be inside the\nrepository's `.git` metadata directory, but it must not be version-controlled\nworkspace content, appear in `git status`, or be stageable.\n\n### Step 4: Execute with bounded context\n\nFor multi-file requests:\n\n1. Turn every explicit user requirement into a checklist before implementation. Include requested layers, collaborators to mock, boundary cases, integrations, coverage thresholds, and report artifacts. Copy multi-condition requirements verbatim — they must each map to one test that exercises the whole combination.\n2. Research only the requested module or project and write the checklist plus a compact target inventory to `\u003CTESTAGENT_DIR>\u002Fresearch.md`.\n3. Reuse manifests, symbol references, and deterministic pairing tools instead of reading every source and test file.\n4. When an available `find-untested-sources` skill is useful for a substantial multi-file inventory, run it once and reuse its pairing and suggested-path output. Otherwise pair the bounded targets manually once; do not probe for an unavailable skill.\n5. Plan each target file once, then implement phases sequentially. Map every checklist item to at least one concrete test or explain why it is blocked.\n6. Build and test the narrow target during fix cycles. Run workspace-level\n   validation once at the end only for broad work, when the repository contract\n   requires that entry point, or when the changes can affect other projects.\n7. Before reporting success, re-open the generated tests and verify every checklist item against concrete test names and assertions. Coverage alone is not evidence that a requested mock seam, boundary, state transition, or property combination was tested.\n8. Read a language example from `code-testing-extensions` only when the repository has no representative tests and the base extension is insufficient.\n9. For .NET, classify SDK-style vs. classic non-SDK before choosing commands or creating files. In classic projects, preserve `packages.config`, existing framework\u002Fmock versions and custom base fixtures, add every new test file to the project's explicit `\u003CCompile Include>` items, and use the repository's MSBuild\u002Ftest-runner commands. Never modernize the project or dependency stack merely to generate tests.\n10. For MSTest, inspect the pinned package version before choosing exception\n    assertions. MSTest 3.5.x uses `Assert.ThrowsException\u003CT>`; do not substitute\n    `[ExpectedException]`, `Assert.Throws\u003CT>`, or `Assert.ThrowsExactly\u003CT>`.\n\n### Completion contract\n\nEvery scope must satisfy points 3–5 below. Points 1 and 2 are the **broad-scope**\nartifacts: on a focused request the same reasoning happens inline and no\nintermediate state files are written.\n\nDo not report completion until all of these are true:\n\n1. *(broad scope)* `\u003CTESTAGENT_DIR>\u002Fresearch.md` records the bounded target\n   inventory, existing test conventions, and the acceptance checklist.\n2. *(broad scope)* `\u003CTESTAGENT_DIR>\u002Fplan.md` maps each checklist item to a planned\n   test or an explicit blocker.\n3. Generated tests compile and pass with the narrowest relevant test command,\n   satisfying the shared report-safe naming and result-validation contract.\n4. Every explicit user requirement is backed by a concrete test and assertion.\n   Fix missing mock seams, boundary cases, state transitions, and property\n   combinations even when coverage already passes. In the final summary, cite\n   at least one generated test name for every checklist item so completion is\n   auditable; if an item has no test to cite, keep implementing or report it as\n   blocked. For non-behavioral requirements such as scaffolding, scope limits,\n   commands, or coverage artifacts, cite the relevant file, command, or report\n   instead of forcing a test-name mapping.\n   A passing suite with fewer tests is not automatically weaker: judge\n   completeness by whether every independently requested behavior has direct,\n   nonredundant evidence, not by raw test volume.\n   For broad\u002Fcomprehensive scope, also verify that every observable equivalence\n   partition and invariant discovered in the bounded target APIs has one\n   mutation-relevant case, even when the prompt did not name it.\n   When the request names multiple modules, verify that each module's own\n   non-trivial public behavior has direct test evidence in addition to any\n   end-to-end composition test.\n5. Review the generated tests for behavior gaps and weak assertions. On a broad\n   scope, invoke `test-gap-analysis` and `assertion-quality` when available and\n   record the findings and fixes in `\u003CTESTAGENT_DIR>\u002Fstatus.md`. On a focused scope,\n   do the equivalent review inline — re-read each generated assertion against\n   the source — without spawning extra passes.\n\nThe final response must provide requirement-by-requirement evidence. Use compact\nbullets under a **Requirement coverage** label for one to three focused\nrequirements; use a `Requirement | Evidence` table for broader scopes.\nBehavioral evidence cites exact generated test names. Non-behavioral evidence\ncites the relevant project file, validation command, or coverage report. A\ngeneric list of tested areas is not a substitute.\n\nPreserve the user's exact meaning in each evidence item; quote verbatim only\nwhen wording distinguishes a required combination. A test that merely exercises\nthe same collaborators does not satisfy a requirement about their interaction,\nand per-class requirements need a citation per class.\n\n**Cite a clean run, not an attempt.** The commands behind the final evidence must\nhave finished successfully: quote the final passing test summary and, when\nthresholds were requested, the per-module coverage table from a run that exited\n0. If the last coverage run exited non-zero, fix it and re-run before reporting;\nnever infer threshold clearance from a failed or partial run.\n\nBefore reporting, inspect the final working-tree changes and confirm that\n`research.md`, `plan.md`, `status.md`, and any other intermediate state files are\nnot among the changes intended for commit.\n\n## State Management\n\nBroad-scope runs store intermediate state files in a non-stageable\n`\u003CTESTAGENT_DIR>` backed by host scratch storage, Git metadata, or OS temp. A\nfocused request does not create these files:\n\n| File                     | Purpose                      |\n| ------------------------ | ---------------------------- |\n| `\u003CTESTAGENT_DIR>\u002Fresearch.md` | Codebase analysis results    |\n| `\u003CTESTAGENT_DIR>\u002Fplan.md`     | Phased implementation plan   |\n| `\u003CTESTAGENT_DIR>\u002Fstatus.md`   | Final quality review and fixes |\n\n## Agent Reference\n\n| Agent                      | Purpose              |\n| -------------------------- | -------------------- |\n| `test-engineer`   | Coordinates pipeline |\n| `code-testing-researcher`  | Analyzes codebase    |\n| `code-testing-planner`     | Creates test plan    |\n| `code-testing-implementer` | Writes test files    |\n| `code-testing-builder`     | Compiles code        |\n| `code-testing-tester`      | Runs tests           |\n| `code-testing-fixer`       | Fixes errors         |\n| `code-testing-linter`      | Formats code         |\n\n## Requirements\n\n- Project must have a build\u002Ftest system configured\n- Testing framework should be installed (or installable)\n- VS Code with GitHub Copilot extension\n\nClassic non-SDK .NET projects are supported when their existing build\u002Ftest\ntoolchain is available. When it is not available on the current machine, the\nagent can still add and register version-compatible tests, but must report\nexecution as blocked rather than substituting `dotnet test`.\n\n## Troubleshooting\n\n### Tests don't compile\n\nThe `code-testing-fixer` agent will attempt to resolve compilation errors. Check\n`\u003CTESTAGENT_DIR>\u002Fplan.md` for the expected test structure. Call the\n`code-testing-extensions` skill and read the language-specific extension file\nfor error code references (e.g., `dotnet.md` for .NET).\n\n### Tests fail\n\nMost failures in generated tests are caused by **wrong expected values in assertions**, not production code bugs:\n\n1. Read the actual test output\n2. Read the production code to understand correct behavior\n3. Fix the assertion, not the production code\n4. Never mark tests `[Ignore]` or `[Skip]` just to make them pass\n\n### Wrong testing framework detected\n\nSpecify your preferred framework in the initial request: \"Generate Jest tests for...\"\n\n### Environment-dependent tests fail\n\nTests that depend on external services, network endpoints, specific ports, or precise timing will fail in CI environments. Focus on unit tests with mocked dependencies instead.\n\n### Broader validation fails\n\nDuring implementation, build and test the narrow target. Run a solution or\nworkspace-level command only for broad work, when the repository contract uses\nthat entry point, or when the targeted change can affect other projects. Do not\nturn a focused test request into an unconditional full non-incremental build.\n",{"name":5,"license":15,"description":7},"main","f8f2bfd77819bb789d4736ce7db4a567a37fcf7e",".agents\u002Fskills\u002Fcode-testing",315,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-14 02:35:02",{"source":8,"skillName":5,"commands":69,"prompt":79,"zipAvailable":80},[70,73,76],{"tool":71,"command":72},"npx","npx skills add microsoft\u002Ftestfx --skill code-testing",{"tool":74,"command":75},"bunx","bunx skills add microsoft\u002Ftestfx --skill code-testing",{"tool":77,"command":78},"pnpm","pnpm dlx skills add microsoft\u002Ftestfx --skill code-testing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcode-testing\u002FSKILL.md",true,[82,88],{"path":83,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":86,"sourceHtmlUrl":87},"unit-test-generation.prompt.md","REFERENCE","参考文档",14056,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fcode-testing\u002Funit-test-generation.prompt.md",{"path":89,"resourceType":84,"resourceTypeDesc":85,"sizeBytes":90,"sourceHtmlUrl":91},"workflow.md",62463,"https:\u002F\u002Fgithub.com\u002Fsherryswift1019-gif\u002FAI-DZHT\u002Fblob\u002Fmain\u002F_bmad\u002Fbmm\u002F4-implementation\u002Fbmad-retrospective\u002Fworkflow.md",[93,119,145,166,185,210],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":54},"01M70GYY0AV0JGMTHE2CN6TNYK","dotnet-breaking-changes","Use before changing .NET\u002FC# code whose callers you do not control: a NuGet library, or a repo with PublicAPI.Shipped\u002FUnshipped.txt, ApiCompat, multiple TargetFrameworks, InternalsVisibleTo, or generated (.g.cs) partials. Green builds miss silent breaks from optional parameters, parameter names, sealing, const values, nullability, and #if. USE FOR: \"without breaking existing callers\"; adding a public method, overload, optional parameter, or interface member to a shipped library; renaming a public method or an internal helper a friend assembly uses; consolidating duplicated logic; changing a signature, nullability, default, or attribute; adding a target framework; RS0016\u002FRS0017 or ApiCompat errors; \"is this PR breaking?\". For a rename, extract, or merge, also invoke csharp-refactoring. DO NOT USE FOR: an executable whose callers all live in one project; renaming a local variable or private member, even in a shipped library; formatting; framework\u002FSDK\u002FNuGet upgrades (use dotnet-upgrade).","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fdotnet-breaking-changes\u002FSKILL.md",[],[100,101,102,103,104,105,106,107,108,109,110,111,112,33,113,114,115,116,117,118],"dotnet","dotnet breaking changes","changes","green","project","default","local","errors","interface","generated","upgrade","invoke","you","refactoring","merge","rename","library","live","assembly",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":126,"publishedAt":54},"01M699HHE9DTZWAMPB1ZR7ZKSW","testfx-test-value-evidence","Apply the vendored test-value-evidence skill with TestFx toolchain, assertion, parallel-safety, packed-consumer, and review conventions. Use when implementing or reviewing behavior-changing TestFx PRs or commits, including source-only changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-test-value-evidence\u002FSKILL.md",[125],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[50,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,102,142,143,144],"testfx test value evidence","test value evidence","evidence","value","review","parallel","toolchain","commits","implementing","prs","only","use","when","apply","with","behavior","Safety","conventions",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":151,"publishedAt":54},"01M699HEYWH1B9XGNBFY8J2FZS","testfx-parallel-safety-preflight","Check concurrency and isolation before implementing or refactoring TestFx tests, lifecycle code, helpers, shared-state declarations, or production paths those tests exercise. Use before narrowing DoNotParallelize or ResourceLock, changing parallelization settings, or introducing asynchronous workers; repeat against the final diff.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-parallel-safety-preflight\u002FSKILL.md",[],[152,143,153,132,154,155,135,156,33,157,113,158,159,160,161,162,163,164,138,165],"testfx parallel safety preflight","preflight","shared","asynchronous","exercise","concurrency","paths","isolation","helpers","diff","parallelization","lifecycle","tests","workers",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":54},"01M699HC61ZV9GJ2C8JV03951G","testfx-localization-validation","Validate generated TestFx localization catalogs, resource IDs, placeholders and locked tokens. Use for RESX\u002FXLF changes, OneLoc PRs, localization build failures, duplicate targets or units, and orphaned translation entries.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-localization-validation\u002FSKILL.md",[],[173,174,175,176,177,178,39,179,180,136,109,138,181,182,102,183,184],"testfx localization validation","validation","localization","validate","translation","ids","tokens","entries","units","duplicate","targets","build",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":192,"publishedAt":54},"01M699H9J2NWQXE4BDT6R0FH7S","testfx-acceptance-validation","Validate TestFx shipping paths and capable CI execution using packed consumers, package\u002Fcache provenance, exact exits and artifacts, and selected-versus-executed test evidence. Use for acceptance regressions, package\u002FMSBuild\u002Flauncher\u002Fprotocol changes, or skipped-only CI results; not for unrelated unit-only or documentation changes.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftestfx-acceptance-validation\u002FSKILL.md",[191],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[193,194,174,50,195,129,196,197,198,137,199,138,200,201,202,203,204,205,206,207,208,209,158,39],"testfx acceptance validation","acceptance","msbuild","launcher","ci","execution","package","cache","artifacts","provenance","documentation","unrelated","shipping","results","protocol","unit","ci results",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":216,"publishedAt":54},"01M699H70BB999BT4F627T1PHE","session-delivery-hygiene","Gate local-session scope, persistent delivery, live PR state, integration provenance, and owned cleanup. Use before implementing guidance changes, changing or pushing PR work, diagnosing package\u002Foutput mismatches, or handing off implementation.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftestfx\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsession-delivery-hygiene\u002FSKILL.md",[],[217,218,219,220,221,135,106,222,223,117,224,199,138,202,225,226,102,227,228,229],"session delivery hygiene","delivery","session","hygiene","scope","cleanup","work","pr","output","state","integration","guidance","gate"]