[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M69B71B6TMKPV5CNB8972SPT":3,"skill-same:01M69B71B6TMKPV5CNB8972SPT":67},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M69B71B6TMKPV5CNB8972SPT","csharp-spector-coverage-gaps",null,"Discovers and implements gaps in Spector test coverage for the C# HTTP client emitter. Use when asked to find missing Spector scenarios, add Spector test coverage, or implement a specific Spector spec for the C# emitter.","microsoft\u002Ftypespec","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M69B6S8HEDME7WWCNE7RGPJF",5946,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcsharp-spector-coverage-gaps\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"gaps","coverage gaps","csharp spector coverage gaps","csharp","coverage","use","when","for","http client","C#","add","client","missing","test coverage","spec","find","http","test","implement","2026-11-10 10:12:30",false,"---\nname: csharp-spector-coverage-gaps\ndescription: Discovers and implements gaps in Spector test coverage for the C# HTTP client emitter. Use when asked to find missing Spector scenarios, add Spector test coverage, or implement a specific Spector spec for the C# emitter.\n---\n\n# Discovering and implementing Spector coverage gaps for http-client-csharp\n\n## Overview\n\nThis skill discovers which Spector scenarios the C# emitter (`@typespec\u002Fhttp-client-csharp`) does **not** yet cover, then implements the missing test(s). Spector scenarios are defined in `@typespec\u002Fhttp-specs` and `@azure-tools\u002Fazure-http-specs`. The coverage dashboard is at \u003Chttps:\u002F\u002Ftypespec.io\u002Fcan-i-use\u002Fhttp\u002F>.\n\n> **Note:** `{PKG}` refers to `\u003Crepo-root>\u002Fpackages\u002Fhttp-client-csharp` throughout this document.\n\n## Inputs\n\nYou may receive one of:\n\n- **\"Find coverage gaps\"** — discover all missing scenarios and present them.\n- **Spector spec link** — a link to a specific spec under `packages\u002Fhttp-specs\u002Fspecs\u002F...` or `packages\u002Fazure-http-specs\u002Fspecs\u002F...`.\n- **Spec name** — e.g., `http\u002Fencode\u002Fduration`, `http\u002Ftype\u002Fmodel\u002Fflatten`, `http\u002Ftype\u002Funion\u002Fdiscriminated`.\n\n## Output\n\n- A report of coverage gaps (when discovering).\n- New or updated C# NUnit test file(s) under `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\u002F`.\n- Updated `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FTestProjects.Spector.Tests.csproj` if a new project reference is needed.\n- Regenerated client code (via `Generate.ps1`).\n\n## Workflow\n\n- [ ] Ensure prerequisites are met (npm ci, npm run build)\n- [ ] Discover coverage gaps or identify the target spec\n- [ ] Verify the spec is not in the failing specs list\n- [ ] Generate the C# client for the target spec (unstubbed with `-Stubbed $false`, or use Test-Spector.ps1)\n- [ ] Read the generated client to understand the API surface\n- [ ] Read the TypeSpec scenario file to understand expected behavior\n- [ ] Find or create the test file\n- [ ] Implement the test(s) following existing conventions\n- [ ] Run the tests using `Test-Spector.ps1 -filter \"\u003Cspec-path>\"`\n- [ ] Validate all tests pass\n\n---\n\n## Prerequisites — Environment setup\n\nBefore starting, ensure the build environment is ready. These instructions **supersede** the repo-root `pnpm` instructions.\n\n1. **Install dependencies** (from `{PKG}`):\n   ```powershell\n   cd {PKG}\n   npm ci\n   ```\n2. **Build the package**:\n   ```powershell\n   npm run build\n   ```\n\n> ⚠️ Do NOT run `pnpm install` or `pnpm build` at the repo root — only the http-client-csharp package build is needed.\n\n---\n\n## Step 1 — Discover coverage gaps\n\n### How specs are filtered\n\nThe file `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1` defines which specs are included\u002Fexcluded:\n\n**Failing specs** are defined in `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1` in the `$failingSpecs` array. Always check that file for the current list — do not hardcode specs here.\n\n**Azure allow-list** (only these Azure specs are tested):\n\n- `http\u002Fclient\u002Fstructure\u002Fclient-operation-group`\n- `http\u002Fclient\u002Fstructure\u002Fdefault`\n- `http\u002Fclient\u002Fstructure\u002Fmulti-client`\n- `http\u002Fclient\u002Fstructure\u002Frenamed-operation`\n- `http\u002Fclient\u002Fstructure\u002Ftwo-operation-group`\n- `http\u002Fresiliency\u002Fsrv-driven`\n\nAll other specs from `@typespec\u002Fhttp-specs` are included by default.\n\n### Discovering gaps programmatically\n\nCompare available specs against existing tests. Run this from `{PKG}`:\n\n```powershell\nImport-Module \"{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1\" -DisableNameChecking -Force\n\n# Get all valid specs\n$specs = Get-Sorted-Specs | ForEach-Object { Get-SubPath $_ }\n\n# Get all test files\n$testFiles = Get-ChildItem -Path \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\" -Recurse -Filter \"*Tests.cs\" |\n    ForEach-Object { $_.FullName }\n\n# For each spec, check if a corresponding test directory\u002Ffile exists\nforeach ($spec in $specs) {\n    $specParts = $spec -replace '\u002F', '\\' -split '\\\\'\n    # Convert to expected test path segments\n    $testPath = \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\"\n    # ... check if test exists\n}\n```\n\nAlternatively, **manually compare** the list of specs against existing test files:\n\n**Existing test coverage** (test directories under `Spector.Tests\u002FHttp\u002F`):\n\n```\nAuthentication\u002FApiKey, Authentication\u002FHttp\u002FCustom, Authentication\u002FOAuth2, Authentication\u002FUnion\nClient\u002FNaming, Client\u002FStructure\u002F{ClientOperationGroup,Default,MultiClient,RenamedOperation,TwoOperationGroup}\nDocumentation\nEncode\u002F{Array,Bytes,DateTime,Numeric}\nParameters\u002F{Basic,BodyOptionality,CollectionFormat,Path,Query,Spread}\nPayload\u002F{ContentNegotiation,JsonMergePatch,MediaType,Multipart,Pageable,Xml}\nResiliency\u002FSrvDriven\u002F{V1,V2}\nResponse\u002FStatusCodeRange\nRoutes\nSerialization\u002FEncodedName\u002FJson\nServer\u002F{Endpoint\u002FNotDefined,Path\u002FMultiple,Path\u002FSingle,Versions\u002FNotVersioned,Versions\u002FVersioned}\nSpecialHeaders\u002F{ConditionalRequest,Repeatability}\nVersioning\u002F{Added,MadeOptional,Removed,RenamedFrom,ReturnTypeChangedFrom,TypeChangedFrom}\n_Type\u002F{Dictionary,Model\u002FEmpty,Model\u002FInheritance\u002F*,Model\u002FUsage,Model\u002FVisibility,Property\u002F*,Scalar,Union,_Array,_Enum\u002F*}\n```\n\n### Accurate gap detection\n\nThe naive approach of matching spec paths to test directory names can produce false positives because:\n\n- C# reserved words get underscore-prefixed in test dirs (e.g., `type\u002F` → `_Type\u002F`, `array` → `_Array`, `enum` → `_Enum`)\n- kebab-case gets converted to PascalCase (e.g., `content-negotiation` → `ContentNegotiation`)\n- Some test files cover a parent spec but not sub-specs (e.g., `UnionTests.cs` covers `type\u002Funion` but NOT `type\u002Funion\u002Fdiscriminated`)\n\n**To find real gaps**, verify each candidate by checking whether a test _directory_ exists for the spec's exact path, including sub-paths. A test file at a parent level does NOT cover child specs.\n\n**Known failing specs** are tracked in `$failingSpecs` in `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1`. Always read that file for the current list.\n\n> **Important:** The gap list evolves over time. Always re-run the comparison to get current gaps. All committed Spector libraries are stubbed — `[SpectorTest]` will auto-skip tests unless you regenerate with `-Stubbed $false` or use `Test-Spector.ps1`.\n\n### Understanding stubbed vs unstubbed generation\n\nAll Spector libraries **committed to the repository are stubbed**. `Generate.ps1` defaults to `$Stubbed = $true`, which passes `--option @typespec\u002Fhttp-client-csharp.generator-name=StubLibraryGenerator` to the emitter. Stubbed clients use expression-bodied constructors (`=>`) instead of block bodies (`{ }`), and the `[SpectorTest]` attribute automatically skips tests for stubbed clients.\n\nTo generate **unstubbed** code (for local testing), pass `-Stubbed $false`:\n\n```powershell\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n```\n\nHowever, the recommended way to test is via `Test-Spector.ps1` (see Step 7), which handles the unstubbed regeneration, test execution, and directory restoration automatically.\n\n---\n\n## Step 2 — Read the spec to understand expected behavior\n\nSpec files live in `{PKG}\u002Fnode_modules\u002F@typespec\u002Fhttp-specs\u002Fspecs\u002F` (or `@azure-tools\u002Fazure-http-specs\u002Fspecs\u002F` for Azure specs).\n\nIf node_modules is not installed, read from the source at `\u003Crepo-root>\u002Fpackages\u002Fhttp-specs\u002Fspecs\u002F`.\n\nEach spec contains:\n\n- **`main.tsp`** — the TypeSpec definition with `@scenario` and `@scenarioDoc` decorators\n- **`client.tsp`** (optional) — client-level customizations; takes priority over `main.tsp` during generation\n- **`tspconfig.yaml`** (optional in the Spector test project) — C#-specific generation options\n\nRead the `@scenarioDoc` decorators to understand:\n\n- The HTTP method, path, and expected parameters\n- The expected request body shape\n- The expected response status code and body\n- Any special behavior (e.g., \"should return 204\", \"should send header X\")\n\n---\n\n## Step 3 — Generate the C# client for the target spec\n\nUse `Generate.ps1` with a filter to generate only the specific spec. By default, `Generate.ps1` generates **stubbed** code (same as what is committed to the repo). To generate **unstubbed** code for local testing, pass `-Stubbed $false`:\n\n```powershell\ncd {PKG}\n# Generate unstubbed (for local testing\u002Fdevelopment)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n\n# Generate stubbed (default, matches what is committed to repo)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\"\n```\n\nExamples:\n\n```powershell\n# Single spec (unstubbed for testing)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"http\u002Fencode\u002Fduration\" -Stubbed $false\n\n# Versioning spec (generates v1 + v2 automatically)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"http\u002Fversioning\u002Fadded\" -Stubbed $false\n```\n\nThe generated code lands in `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Fsrc\u002FGenerated\u002F`.\n\n### Verify generation succeeded\n\n```powershell\n# Check that client code was generated\nGet-ChildItem \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Fsrc\u002FGenerated\u002F\" -Filter \"*Client.cs\"\n```\n\n> **Note:** All committed Spector libraries are stubbed. The `[SpectorTest]` attribute automatically skips tests for stubbed clients. Use `Test-Spector.ps1` (Step 7) to regenerate unstubbed, run tests, and restore automatically.\n\n---\n\n## Step 4 — Read the generated client API surface\n\nBrowse the generated code to understand:\n\n1. **Client class(es)**: `*Client.cs` — the entry point(s)\n2. **Sub-clients**: accessed via `Get*Client()` methods\n3. **Operations**: async methods like `GetAsync()`, `PutAsync(body)`, `SendAsync()`\n4. **Models**: under `Models\u002F` — request\u002Fresponse shapes\n5. **Constructor signature**: `new XClient(Uri endpoint, XClientOptions options)` or `new XClient(Uri endpoint, KeyCredential credential, XClientOptions options)`\n\nPay attention to:\n\n- Method names (they map to TypeSpec operation names)\n- Parameter types (models, primitives, BinaryData)\n- Return types (`ClientResult`, `ClientResult\u003CT>`, `AsyncPageable\u003CT>`)\n\n---\n\n## Step 5 — Create or extend the test file\n\n### Directory and namespace conventions\n\nThe test directory structure mirrors the spec path with these transformations:\n\n- `http\u002F` → `Http\u002F`\n- kebab-case → PascalCase (e.g., `content-negotiation` → `ContentNegotiation`)\n- `type\u002F` → `_Type\u002F` (leading underscore because `Type` is a C# keyword)\n- `array` → `_Array` (same reason)\n- `enum` → `_Enum` (same reason)\n\n**Namespace pattern**: `TestProjects.Spector.Tests.Http.\u003CPascalCasePath>`\n\nExample mappings:\n\n| Spec path                       | Test directory                    | Namespace                                                   |\n| ------------------------------- | --------------------------------- | ----------------------------------------------------------- |\n| `http\u002Fencode\u002Fduration`          | `Http\u002FEncode\u002FDuration\u002F`           | `TestProjects.Spector.Tests.Http.Encode.Duration`           |\n| `http\u002Ftype\u002Funion\u002Fdiscriminated` | `Http\u002F_Type\u002FUnion\u002FDiscriminated\u002F` | `TestProjects.Spector.Tests.Http._Type.Union.Discriminated` |\n| `http\u002Fspecial-words`            | `Http\u002FSpecialWords\u002F`              | `TestProjects.Spector.Tests.Http.SpecialWords`              |\n\n### Test file template\n\n```csharp\n\u002F\u002F Copyright (c) Microsoft Corporation. All rights reserved.\n\u002F\u002F Licensed under the MIT License.\n\nusing System.Threading.Tasks;\nusing \u003CGeneratedNamespace>;\nusing NUnit.Framework;\n\nnamespace TestProjects.Spector.Tests.Http.\u003CCategory>.\u003CSubCategory>\n{\n    public class \u003CName>Tests : SpectorTestBase\n    {\n        [SpectorTest]\n        public Task \u003CScenarioName>() => Test(async (host) =>\n        {\n            var response = await new \u003CClient>(host, null).\u003CMethod>Async(\u003Cargs>);\n            Assert.AreEqual(\u003CexpectedStatusCode>, response.GetRawResponse().Status);\n        });\n    }\n}\n```\n\n### Common test patterns\n\n**Simple void operation (204 response):**\n\n```csharp\n[SpectorTest]\npublic Task SimpleOp() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).DoThingAsync();\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**GET with typed response:**\n\n```csharp\n[SpectorTest]\npublic Task GetValue() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).GetValueAsync();\n    Assert.AreEqual(\"expected\", response.Value);\n});\n```\n\n**GET with model response:**\n\n```csharp\n[SpectorTest]\npublic Task GetModel() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).GetModelAsync();\n    Assert.AreEqual(\"name\", response.Value.Name);\n    Assert.AreEqual(42, response.Value.Age);\n});\n```\n\n**PUT\u002FPOST with body:**\n\n```csharp\n[SpectorTest]\npublic Task SendModel() => Test(async (host) =>\n{\n    var body = new MyModel(\"name\", 42);\n    var response = await new MyClient(host, null).SendAsync(body);\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Round-trip (GET then PUT):**\n\n```csharp\n[SpectorTest]\npublic Task RoundTrip() => Test(async (host) =>\n{\n    var client = new MyClient(host, null);\n    var getResult = await client.GetAsync();\n    var response = await client.PutAsync(getResult.Value);\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Error assertion:**\n\n```csharp\n[SpectorTest]\npublic Task InvalidKey() => Test((host) =>\n{\n    var exception = Assert.ThrowsAsync\u003CClientResultException>(\n        () => new MyClient(host, new ApiKeyCredential(\"invalid\"), null).CallAsync());\n    Assert.AreEqual(403, exception!.Status);\n    return Task.CompletedTask;\n});\n```\n\n**Sub-client access:**\n\n```csharp\n[SpectorTest]\npublic Task SubClientOp() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null)\n        .GetSubClient()\n        .DoThingAsync();\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Pagination:**\n\n```csharp\n[SpectorTest]\npublic Task ListItems() => Test(async (host) =>\n{\n    var items = new MyClient(host, null).GetItemsAsync();\n    int count = 0;\n    await foreach (var item in items)\n    {\n        count++;\n    }\n    Assert.Greater(count, 0);\n});\n```\n\n### Additional imports commonly needed\n\n```csharp\nusing System;\nusing System.ClientModel;           \u002F\u002F ClientResult, ClientResultException, ApiKeyCredential\nusing System.IO;                     \u002F\u002F For file\u002Fstream scenarios\nusing NUnit.Framework;               \u002F\u002F Test framework\n```\n\n---\n\n## Step 6 — Update the .csproj if needed\n\nIf a new Spector test project directory was created (new spec), a project reference may be needed in `TestProjects.Spector.Tests.csproj`:\n\n```xml\n\u003CProjectReference Include=\"..\\Spector\\http\\\u003Cspec-path>\\src\\\u003CProjectName>.csproj\" \u002F>\n```\n\nCheck existing references to match the pattern. The project name typically matches the `package-name` from `tspconfig.yaml` or is derived from the namespace.\n\n> Only add a project reference if one doesn't already exist for the spec.\n\n---\n\n## Step 7 — Build and run the tests\n\n### Recommended: Use Test-Spector.ps1\n\nThe `Test-Spector.ps1` script is the recommended way to test Spector specs. It automatically:\n\n1. Regenerates the spec as **unstubbed** (so tests are not auto-skipped)\n2. Runs the tests for that spec\n3. Restores the directory to its original stubbed state\n\n```powershell\ncd {PKG}\n# Test a specific spec\npwsh eng\u002Fscripts\u002FTest-Spector.ps1 -filter \"\u003Cspec-path>\"\n```\n\nExample:\n\n```powershell\npwsh eng\u002Fscripts\u002FTest-Spector.ps1 -filter \"http\u002Fencode\u002Fduration\"\n```\n\n### Run full Spector test suite\n\n```powershell\npwsh eng\u002Fscripts\u002FGet-Spector-Coverage.ps1\n```\n\n### Manual approach (if needed)\n\nIf you need more control, you can manually generate unstubbed, build, and run tests:\n\n```powershell\ncd {PKG}\n\n# Generate unstubbed\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n\n# Build\ndotnet build generator\n\n# Run only your new tests\ndotnet test generator\u002FTestProjects\u002FSpector.Tests\u002FTestProjects.Spector.Tests.csproj `\n    --filter \"FullyQualifiedName~TestProjects.Spector.Tests.Http.\u003CYourNamespace>\"\n\n# Restore the directory to stubbed state when done\ngit clean -xfd generator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\ngit restore generator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\n```\n\n---\n\n## Step 8 — Handle special cases\n\n### Versioning specs\n\nVersioning specs generate **two clients** (v1 and v2). Tests go in separate subdirectories:\n\n```\nHttp\u002FVersioning\u002F\u003CName>\u002FV1\u002F\u003CName>V1Tests.cs\nHttp\u002FVersioning\u002F\u003CName>\u002FV2\u002F\u003CName>V2Tests.cs\n```\n\nGeneration is handled automatically by `Generate.ps1` when the path contains `versioning`.\n\n### Srv-driven (resiliency) specs\n\nSimilar to versioning — generates v1 and v2 clients from `old.tsp` and `main.tsp`.\n\n### Specs with tspconfig.yaml\n\nSome specs have a `tspconfig.yaml` in the Spector test project that overrides the `package-name`. Check `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Ftspconfig.yaml` before importing the generated namespace.\n\n---\n\n## Notes\n\n- **Do not modify `Spector-Helper.psm1`** to remove items from the failing list unless you're sure the generator now supports them.\n- **All committed Spector libraries are stubbed** — `Generate.ps1` defaults to `$Stubbed = $true`. Use `Test-Spector.ps1` to temporarily regenerate unstubbed and run tests.\n- **Tests auto-skip** when the generated client is stubbed — it's safe to write tests for stubbed specs. They'll activate when `Test-Spector.ps1` regenerates them unstubbed.\n- Only commit: test files (`.cs`), `.csproj` changes, and `tspconfig.yaml` if needed.\n- Follow existing test naming conventions: `\u003CFeature>Tests.cs` in the matching directory.\n- Use `[SpectorTest]` attribute (not `[Test]`) for all Spector tests — it enables auto-skip for stubbed implementations.\n- All test classes must inherit from `SpectorTestBase`.\n- Do not add change logs — the http-client-csharp instructions say they are not needed.\n- Do not comment out or delete existing tests.\n","# Discovering and implementing Spector coverage gaps for http-client-csharp\n\n## Overview\n\nThis skill discovers which Spector scenarios the C# emitter (`@typespec\u002Fhttp-client-csharp`) does **not** yet cover, then implements the missing test(s). Spector scenarios are defined in `@typespec\u002Fhttp-specs` and `@azure-tools\u002Fazure-http-specs`. The coverage dashboard is at \u003Chttps:\u002F\u002Ftypespec.io\u002Fcan-i-use\u002Fhttp\u002F>.\n\n> **Note:** `{PKG}` refers to `\u003Crepo-root>\u002Fpackages\u002Fhttp-client-csharp` throughout this document.\n\n## Inputs\n\nYou may receive one of:\n\n- **\"Find coverage gaps\"** — discover all missing scenarios and present them.\n- **Spector spec link** — a link to a specific spec under `packages\u002Fhttp-specs\u002Fspecs\u002F...` or `packages\u002Fazure-http-specs\u002Fspecs\u002F...`.\n- **Spec name** — e.g., `http\u002Fencode\u002Fduration`, `http\u002Ftype\u002Fmodel\u002Fflatten`, `http\u002Ftype\u002Funion\u002Fdiscriminated`.\n\n## Output\n\n- A report of coverage gaps (when discovering).\n- New or updated C# NUnit test file(s) under `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\u002F`.\n- Updated `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FTestProjects.Spector.Tests.csproj` if a new project reference is needed.\n- Regenerated client code (via `Generate.ps1`).\n\n## Workflow\n\n- [ ] Ensure prerequisites are met (npm ci, npm run build)\n- [ ] Discover coverage gaps or identify the target spec\n- [ ] Verify the spec is not in the failing specs list\n- [ ] Generate the C# client for the target spec (unstubbed with `-Stubbed $false`, or use Test-Spector.ps1)\n- [ ] Read the generated client to understand the API surface\n- [ ] Read the TypeSpec scenario file to understand expected behavior\n- [ ] Find or create the test file\n- [ ] Implement the test(s) following existing conventions\n- [ ] Run the tests using `Test-Spector.ps1 -filter \"\u003Cspec-path>\"`\n- [ ] Validate all tests pass\n\n---\n\n## Prerequisites — Environment setup\n\nBefore starting, ensure the build environment is ready. These instructions **supersede** the repo-root `pnpm` instructions.\n\n1. **Install dependencies** (from `{PKG}`):\n   ```powershell\n   cd {PKG}\n   npm ci\n   ```\n2. **Build the package**:\n   ```powershell\n   npm run build\n   ```\n\n> ⚠️ Do NOT run `pnpm install` or `pnpm build` at the repo root — only the http-client-csharp package build is needed.\n\n---\n\n## Step 1 — Discover coverage gaps\n\n### How specs are filtered\n\nThe file `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1` defines which specs are included\u002Fexcluded:\n\n**Failing specs** are defined in `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1` in the `$failingSpecs` array. Always check that file for the current list — do not hardcode specs here.\n\n**Azure allow-list** (only these Azure specs are tested):\n\n- `http\u002Fclient\u002Fstructure\u002Fclient-operation-group`\n- `http\u002Fclient\u002Fstructure\u002Fdefault`\n- `http\u002Fclient\u002Fstructure\u002Fmulti-client`\n- `http\u002Fclient\u002Fstructure\u002Frenamed-operation`\n- `http\u002Fclient\u002Fstructure\u002Ftwo-operation-group`\n- `http\u002Fresiliency\u002Fsrv-driven`\n\nAll other specs from `@typespec\u002Fhttp-specs` are included by default.\n\n### Discovering gaps programmatically\n\nCompare available specs against existing tests. Run this from `{PKG}`:\n\n```powershell\nImport-Module \"{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1\" -DisableNameChecking -Force\n\n# Get all valid specs\n$specs = Get-Sorted-Specs | ForEach-Object { Get-SubPath $_ }\n\n# Get all test files\n$testFiles = Get-ChildItem -Path \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\" -Recurse -Filter \"*Tests.cs\" |\n    ForEach-Object { $_.FullName }\n\n# For each spec, check if a corresponding test directory\u002Ffile exists\nforeach ($spec in $specs) {\n    $specParts = $spec -replace '\u002F', '\\' -split '\\\\'\n    # Convert to expected test path segments\n    $testPath = \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector.Tests\u002FHttp\"\n    # ... check if test exists\n}\n```\n\nAlternatively, **manually compare** the list of specs against existing test files:\n\n**Existing test coverage** (test directories under `Spector.Tests\u002FHttp\u002F`):\n\n```\nAuthentication\u002FApiKey, Authentication\u002FHttp\u002FCustom, Authentication\u002FOAuth2, Authentication\u002FUnion\nClient\u002FNaming, Client\u002FStructure\u002F{ClientOperationGroup,Default,MultiClient,RenamedOperation,TwoOperationGroup}\nDocumentation\nEncode\u002F{Array,Bytes,DateTime,Numeric}\nParameters\u002F{Basic,BodyOptionality,CollectionFormat,Path,Query,Spread}\nPayload\u002F{ContentNegotiation,JsonMergePatch,MediaType,Multipart,Pageable,Xml}\nResiliency\u002FSrvDriven\u002F{V1,V2}\nResponse\u002FStatusCodeRange\nRoutes\nSerialization\u002FEncodedName\u002FJson\nServer\u002F{Endpoint\u002FNotDefined,Path\u002FMultiple,Path\u002FSingle,Versions\u002FNotVersioned,Versions\u002FVersioned}\nSpecialHeaders\u002F{ConditionalRequest,Repeatability}\nVersioning\u002F{Added,MadeOptional,Removed,RenamedFrom,ReturnTypeChangedFrom,TypeChangedFrom}\n_Type\u002F{Dictionary,Model\u002FEmpty,Model\u002FInheritance\u002F*,Model\u002FUsage,Model\u002FVisibility,Property\u002F*,Scalar,Union,_Array,_Enum\u002F*}\n```\n\n### Accurate gap detection\n\nThe naive approach of matching spec paths to test directory names can produce false positives because:\n\n- C# reserved words get underscore-prefixed in test dirs (e.g., `type\u002F` → `_Type\u002F`, `array` → `_Array`, `enum` → `_Enum`)\n- kebab-case gets converted to PascalCase (e.g., `content-negotiation` → `ContentNegotiation`)\n- Some test files cover a parent spec but not sub-specs (e.g., `UnionTests.cs` covers `type\u002Funion` but NOT `type\u002Funion\u002Fdiscriminated`)\n\n**To find real gaps**, verify each candidate by checking whether a test _directory_ exists for the spec's exact path, including sub-paths. A test file at a parent level does NOT cover child specs.\n\n**Known failing specs** are tracked in `$failingSpecs` in `{PKG}\u002Feng\u002Fscripts\u002FSpector-Helper.psm1`. Always read that file for the current list.\n\n> **Important:** The gap list evolves over time. Always re-run the comparison to get current gaps. All committed Spector libraries are stubbed — `[SpectorTest]` will auto-skip tests unless you regenerate with `-Stubbed $false` or use `Test-Spector.ps1`.\n\n### Understanding stubbed vs unstubbed generation\n\nAll Spector libraries **committed to the repository are stubbed**. `Generate.ps1` defaults to `$Stubbed = $true`, which passes `--option @typespec\u002Fhttp-client-csharp.generator-name=StubLibraryGenerator` to the emitter. Stubbed clients use expression-bodied constructors (`=>`) instead of block bodies (`{ }`), and the `[SpectorTest]` attribute automatically skips tests for stubbed clients.\n\nTo generate **unstubbed** code (for local testing), pass `-Stubbed $false`:\n\n```powershell\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n```\n\nHowever, the recommended way to test is via `Test-Spector.ps1` (see Step 7), which handles the unstubbed regeneration, test execution, and directory restoration automatically.\n\n---\n\n## Step 2 — Read the spec to understand expected behavior\n\nSpec files live in `{PKG}\u002Fnode_modules\u002F@typespec\u002Fhttp-specs\u002Fspecs\u002F` (or `@azure-tools\u002Fazure-http-specs\u002Fspecs\u002F` for Azure specs).\n\nIf node_modules is not installed, read from the source at `\u003Crepo-root>\u002Fpackages\u002Fhttp-specs\u002Fspecs\u002F`.\n\nEach spec contains:\n\n- **`main.tsp`** — the TypeSpec definition with `@scenario` and `@scenarioDoc` decorators\n- **`client.tsp`** (optional) — client-level customizations; takes priority over `main.tsp` during generation\n- **`tspconfig.yaml`** (optional in the Spector test project) — C#-specific generation options\n\nRead the `@scenarioDoc` decorators to understand:\n\n- The HTTP method, path, and expected parameters\n- The expected request body shape\n- The expected response status code and body\n- Any special behavior (e.g., \"should return 204\", \"should send header X\")\n\n---\n\n## Step 3 — Generate the C# client for the target spec\n\nUse `Generate.ps1` with a filter to generate only the specific spec. By default, `Generate.ps1` generates **stubbed** code (same as what is committed to the repo). To generate **unstubbed** code for local testing, pass `-Stubbed $false`:\n\n```powershell\ncd {PKG}\n# Generate unstubbed (for local testing\u002Fdevelopment)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n\n# Generate stubbed (default, matches what is committed to repo)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\"\n```\n\nExamples:\n\n```powershell\n# Single spec (unstubbed for testing)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"http\u002Fencode\u002Fduration\" -Stubbed $false\n\n# Versioning spec (generates v1 + v2 automatically)\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"http\u002Fversioning\u002Fadded\" -Stubbed $false\n```\n\nThe generated code lands in `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Fsrc\u002FGenerated\u002F`.\n\n### Verify generation succeeded\n\n```powershell\n# Check that client code was generated\nGet-ChildItem \"{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Fsrc\u002FGenerated\u002F\" -Filter \"*Client.cs\"\n```\n\n> **Note:** All committed Spector libraries are stubbed. The `[SpectorTest]` attribute automatically skips tests for stubbed clients. Use `Test-Spector.ps1` (Step 7) to regenerate unstubbed, run tests, and restore automatically.\n\n---\n\n## Step 4 — Read the generated client API surface\n\nBrowse the generated code to understand:\n\n1. **Client class(es)**: `*Client.cs` — the entry point(s)\n2. **Sub-clients**: accessed via `Get*Client()` methods\n3. **Operations**: async methods like `GetAsync()`, `PutAsync(body)`, `SendAsync()`\n4. **Models**: under `Models\u002F` — request\u002Fresponse shapes\n5. **Constructor signature**: `new XClient(Uri endpoint, XClientOptions options)` or `new XClient(Uri endpoint, KeyCredential credential, XClientOptions options)`\n\nPay attention to:\n\n- Method names (they map to TypeSpec operation names)\n- Parameter types (models, primitives, BinaryData)\n- Return types (`ClientResult`, `ClientResult\u003CT>`, `AsyncPageable\u003CT>`)\n\n---\n\n## Step 5 — Create or extend the test file\n\n### Directory and namespace conventions\n\nThe test directory structure mirrors the spec path with these transformations:\n\n- `http\u002F` → `Http\u002F`\n- kebab-case → PascalCase (e.g., `content-negotiation` → `ContentNegotiation`)\n- `type\u002F` → `_Type\u002F` (leading underscore because `Type` is a C# keyword)\n- `array` → `_Array` (same reason)\n- `enum` → `_Enum` (same reason)\n\n**Namespace pattern**: `TestProjects.Spector.Tests.Http.\u003CPascalCasePath>`\n\nExample mappings:\n\n| Spec path                       | Test directory                    | Namespace                                                   |\n| ------------------------------- | --------------------------------- | ----------------------------------------------------------- |\n| `http\u002Fencode\u002Fduration`          | `Http\u002FEncode\u002FDuration\u002F`           | `TestProjects.Spector.Tests.Http.Encode.Duration`           |\n| `http\u002Ftype\u002Funion\u002Fdiscriminated` | `Http\u002F_Type\u002FUnion\u002FDiscriminated\u002F` | `TestProjects.Spector.Tests.Http._Type.Union.Discriminated` |\n| `http\u002Fspecial-words`            | `Http\u002FSpecialWords\u002F`              | `TestProjects.Spector.Tests.Http.SpecialWords`              |\n\n### Test file template\n\n```csharp\n\u002F\u002F Copyright (c) Microsoft Corporation. All rights reserved.\n\u002F\u002F Licensed under the MIT License.\n\nusing System.Threading.Tasks;\nusing \u003CGeneratedNamespace>;\nusing NUnit.Framework;\n\nnamespace TestProjects.Spector.Tests.Http.\u003CCategory>.\u003CSubCategory>\n{\n    public class \u003CName>Tests : SpectorTestBase\n    {\n        [SpectorTest]\n        public Task \u003CScenarioName>() => Test(async (host) =>\n        {\n            var response = await new \u003CClient>(host, null).\u003CMethod>Async(\u003Cargs>);\n            Assert.AreEqual(\u003CexpectedStatusCode>, response.GetRawResponse().Status);\n        });\n    }\n}\n```\n\n### Common test patterns\n\n**Simple void operation (204 response):**\n\n```csharp\n[SpectorTest]\npublic Task SimpleOp() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).DoThingAsync();\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**GET with typed response:**\n\n```csharp\n[SpectorTest]\npublic Task GetValue() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).GetValueAsync();\n    Assert.AreEqual(\"expected\", response.Value);\n});\n```\n\n**GET with model response:**\n\n```csharp\n[SpectorTest]\npublic Task GetModel() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null).GetModelAsync();\n    Assert.AreEqual(\"name\", response.Value.Name);\n    Assert.AreEqual(42, response.Value.Age);\n});\n```\n\n**PUT\u002FPOST with body:**\n\n```csharp\n[SpectorTest]\npublic Task SendModel() => Test(async (host) =>\n{\n    var body = new MyModel(\"name\", 42);\n    var response = await new MyClient(host, null).SendAsync(body);\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Round-trip (GET then PUT):**\n\n```csharp\n[SpectorTest]\npublic Task RoundTrip() => Test(async (host) =>\n{\n    var client = new MyClient(host, null);\n    var getResult = await client.GetAsync();\n    var response = await client.PutAsync(getResult.Value);\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Error assertion:**\n\n```csharp\n[SpectorTest]\npublic Task InvalidKey() => Test((host) =>\n{\n    var exception = Assert.ThrowsAsync\u003CClientResultException>(\n        () => new MyClient(host, new ApiKeyCredential(\"invalid\"), null).CallAsync());\n    Assert.AreEqual(403, exception!.Status);\n    return Task.CompletedTask;\n});\n```\n\n**Sub-client access:**\n\n```csharp\n[SpectorTest]\npublic Task SubClientOp() => Test(async (host) =>\n{\n    var response = await new MyClient(host, null)\n        .GetSubClient()\n        .DoThingAsync();\n    Assert.AreEqual(204, response.GetRawResponse().Status);\n});\n```\n\n**Pagination:**\n\n```csharp\n[SpectorTest]\npublic Task ListItems() => Test(async (host) =>\n{\n    var items = new MyClient(host, null).GetItemsAsync();\n    int count = 0;\n    await foreach (var item in items)\n    {\n        count++;\n    }\n    Assert.Greater(count, 0);\n});\n```\n\n### Additional imports commonly needed\n\n```csharp\nusing System;\nusing System.ClientModel;           \u002F\u002F ClientResult, ClientResultException, ApiKeyCredential\nusing System.IO;                     \u002F\u002F For file\u002Fstream scenarios\nusing NUnit.Framework;               \u002F\u002F Test framework\n```\n\n---\n\n## Step 6 — Update the .csproj if needed\n\nIf a new Spector test project directory was created (new spec), a project reference may be needed in `TestProjects.Spector.Tests.csproj`:\n\n```xml\n\u003CProjectReference Include=\"..\\Spector\\http\\\u003Cspec-path>\\src\\\u003CProjectName>.csproj\" \u002F>\n```\n\nCheck existing references to match the pattern. The project name typically matches the `package-name` from `tspconfig.yaml` or is derived from the namespace.\n\n> Only add a project reference if one doesn't already exist for the spec.\n\n---\n\n## Step 7 — Build and run the tests\n\n### Recommended: Use Test-Spector.ps1\n\nThe `Test-Spector.ps1` script is the recommended way to test Spector specs. It automatically:\n\n1. Regenerates the spec as **unstubbed** (so tests are not auto-skipped)\n2. Runs the tests for that spec\n3. Restores the directory to its original stubbed state\n\n```powershell\ncd {PKG}\n# Test a specific spec\npwsh eng\u002Fscripts\u002FTest-Spector.ps1 -filter \"\u003Cspec-path>\"\n```\n\nExample:\n\n```powershell\npwsh eng\u002Fscripts\u002FTest-Spector.ps1 -filter \"http\u002Fencode\u002Fduration\"\n```\n\n### Run full Spector test suite\n\n```powershell\npwsh eng\u002Fscripts\u002FGet-Spector-Coverage.ps1\n```\n\n### Manual approach (if needed)\n\nIf you need more control, you can manually generate unstubbed, build, and run tests:\n\n```powershell\ncd {PKG}\n\n# Generate unstubbed\npwsh eng\u002Fscripts\u002FGenerate.ps1 -filter \"\u003Cspec-path>\" -Stubbed $false\n\n# Build\ndotnet build generator\n\n# Run only your new tests\ndotnet test generator\u002FTestProjects\u002FSpector.Tests\u002FTestProjects.Spector.Tests.csproj `\n    --filter \"FullyQualifiedName~TestProjects.Spector.Tests.Http.\u003CYourNamespace>\"\n\n# Restore the directory to stubbed state when done\ngit clean -xfd generator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\ngit restore generator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\n```\n\n---\n\n## Step 8 — Handle special cases\n\n### Versioning specs\n\nVersioning specs generate **two clients** (v1 and v2). Tests go in separate subdirectories:\n\n```\nHttp\u002FVersioning\u002F\u003CName>\u002FV1\u002F\u003CName>V1Tests.cs\nHttp\u002FVersioning\u002F\u003CName>\u002FV2\u002F\u003CName>V2Tests.cs\n```\n\nGeneration is handled automatically by `Generate.ps1` when the path contains `versioning`.\n\n### Srv-driven (resiliency) specs\n\nSimilar to versioning — generates v1 and v2 clients from `old.tsp` and `main.tsp`.\n\n### Specs with tspconfig.yaml\n\nSome specs have a `tspconfig.yaml` in the Spector test project that overrides the `package-name`. Check `{PKG}\u002Fgenerator\u002FTestProjects\u002FSpector\u002F\u003Cspec-path>\u002Ftspconfig.yaml` before importing the generated namespace.\n\n---\n\n## Notes\n\n- **Do not modify `Spector-Helper.psm1`** to remove items from the failing list unless you're sure the generator now supports them.\n- **All committed Spector libraries are stubbed** — `Generate.ps1` defaults to `$Stubbed = $true`. Use `Test-Spector.ps1` to temporarily regenerate unstubbed and run tests.\n- **Tests auto-skip** when the generated client is stubbed — it's safe to write tests for stubbed specs. They'll activate when `Test-Spector.ps1` regenerates them unstubbed.\n- Only commit: test files (`.cs`), `.csproj` changes, and `tspconfig.yaml` if needed.\n- Follow existing test naming conventions: `\u003CFeature>Tests.cs` in the matching directory.\n- Use `[SpectorTest]` attribute (not `[Test]`) for all Spector tests — it enables auto-skip for stubbed implementations.\n- All test classes must inherit from `SpectorTestBase`.\n- Do not add change logs — the http-client-csharp instructions say they are not needed.\n- Do not comment out or delete existing tests.\n",{"name":5,"description":7},"main","05b9bad7c57b9b58e8fb5390f9bab081a1a9ac31",".github\u002Fskills\u002Fcsharp-spector-coverage-gaps",421,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec","https:\u002F\u002Ftypespec.io\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-13 02:40:31",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add microsoft\u002Ftypespec --skill csharp-spector-coverage-gaps",{"tool":59,"command":60},"bunx","bunx skills add microsoft\u002Ftypespec --skill csharp-spector-coverage-gaps",{"tool":62,"command":63},"pnpm","pnpm dlx skills add microsoft\u002Ftypespec --skill csharp-spector-coverage-gaps","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fcsharp-spector-coverage-gaps\u002FSKILL.md",true,[],[68,102,122,143,175,188],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":82,"publishedAt":38},"01M69B7KKBZE845SFNJQ5H992V","test-unbranded-emitter","Build and test the @typespec\u002Fhttp-client-python emitter. Use this skill whenever the user wants to test their local changes to the emitter, run the generator test suite, check if their http-client-python changes are passing, or validate a fix. Triggers on phrases like \"test the emitter\", \"run tests\", \"check if my changes pass\", \"run test:generator\", \"run CI\", or any mention of testing\u002Fvalidating changes in the emitter package.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002Fpackages\u002Fhttp-client-python\u002F.github\u002Fskills\u002Ftest-unbranded-emitter\u002FSKILL.md",[74,79],{"categoryNo":75,"categoryName":76,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000023","Skill与智能体开发",[36,83,84,85,86,87,88,35,89,90,91,92,93,94,24,95,96,97,98,99,100,101],"test unbranded emitter","testing","python","build and test","validate","run tests","typespec","run","package","ci","check","fix","test suite","build","local","tests","triggers","generator","changes",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":38},"01M69B7H23BJ7ART6SA67EFJ5W","generate-from-typespec","Generate Python SDK code from a TypeSpec specification using the local emitter. Use this skill when the user wants to generate\u002Fregenerate a Python client from a TypeSpec spec, provides a GitHub URL or local path to a TypeSpec project, or says things like \"generate from this spec\", \"emit Python from this tsp\", \"regenerate the SDK\", or \"compile this TypeSpec for Python\".","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002Fpackages\u002Fhttp-client-python\u002F.github\u002Fskills\u002Fgenerate-from-typespec\u002FSKILL.md",[108],{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},[89,110,111,33,85,112,113,114,115,116,117,24,118,97,119,30,120,26,121,25],"generate from typespec","generate","github","sdk","code","compile","python sdk","user","specification","project","URL","things",{"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":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":129,"publishedAt":38},"01M69B7EJ0F9HGY2Y8RMX9C4E6","diff-upstream","Regenerate the local emitter and diff the generated code against the upstream baseline checked into autorest.python. Use this skill when the user wants to see how their emitter changes affect generated code compared to what's currently in production, says things like \"diff upstream\", \"compare to baseline\", \"what changed vs production\", \"show me the diff\", \"how does this affect generated code\", or wants to validate their changes produce the expected output differences.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002Fpackages\u002Fhttp-client-python\u002F.github\u002Fskills\u002Fdiff-upstream\u002FSKILL.md",[128],{"categoryNo":80,"categoryName":81,"taxonomyType":77,"taxonomyTypeDesc":78},[130,131,132,85,87,114,133,134,135,136,137,24,138,139,97,140,141,121,101,142,25],"diff upstream","diff","upstream","produce","baseline","show me","how","generated","show","me","compare","output","expected",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":163,"publishedAt":38},"01M69B7BHV2RTK64BZ8NQGFPNE","writing-python-sdk-spector-mock-api-tests","Writes TypeSpec http-client-python generator mock API tests (azure\u002Funbranded\u002Fshared) from a Spector case. Use when given a Spector case link or a PR link that modifies Spector cases under http-specs\u002Fazure-http-specs.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpython-sdk-spector-mock-api-tests\u002FSKILL.md",[149,152,155,160],{"categoryNo":150,"categoryName":151,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":153,"categoryName":154,"taxonomyType":77,"taxonomyTypeDesc":78},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":156,"categoryName":157,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",{"categoryNo":161,"categoryName":162,"taxonomyType":158,"taxonomyTypeDesc":159},"01JBSEEDCAT000000000000036","内容创作者",[164,85,113,165,166,116,167,98,168,169,170,35,171,89,24,172,173,174,100,25],"writing","writing python sdk spector mock api tests","api","writing python","mock","mock api","azure","pr","shared","link","case",{"skillNo":176,"name":177,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":38},"01M69B79NV57JMNA7RS13MAE5P","pnpm-format","Format the codebase with pnpm and recover from common formatting failures.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fpnpm-format\u002FSKILL.md",[],[182,183,62,184,185,186,187],"pnpm format","format","common","formatting","with","codebase",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":38},"01M69B784PEAQ45ZKNZAX9NCA9","minimal-repro","Help create a minimal reproduction for a TypeSpec compiler or emitter bug. Use when a user provides TypeSpec source (pasted code or a GitHub URL) and describes an issue. Reproduces locally and reduces to a single-file repro.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Ftypespec\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fminimal-repro\u002FSKILL.md",[],[195,196,197,112,89,198,114,199,200,201,117,24,202,203,204,120,26,205,206,25],"minimal repro","repro","minimal","create","help","compiler","file","single-file","bug","issue","source","single"]