[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DYRKE4YEG6S604P2AVSVW4":3,"skill-same:01M6DYRKE4YEG6S604P2AVSVW4":114},{"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":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":57,"ownerHtmlUrl":58,"ownerBlogUrl":59,"ownerDescription":60,"updatedAt":61,"install":62,"resources":75},"01M6DYRKE4YEG6S604P2AVSVW4","nuget-trusted-publishing",null,"Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet\u002Flogin, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.","managedcode\u002Fdotnet-skills","managedcode","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F78253589?v=4","01M6DYDJR3EG8KB5G4PC65XCTT","Managed Code","01M6DYDJX0ZT432N04NYJW89DN",515,"MIT","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"nuget","nuget trusted publishing","publishing","repo","api keys","repo setup","azure artifacts","long","tokens","do","up","only","use","short","ask","azure","migrate","Bash","api","SET","feeds","powershell","publish","github actions","actions","artifacts","create","2026-11-10 10:12:30",false,"---\nname: nuget-trusted-publishing\ndescription: >\n  Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys\n  with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish,\n  migrate from NuGet API key, NuGet\u002Flogin, secure NuGet publishing.\n  DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only).\n  INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.\nlicense: MIT\n---\n\n# NuGet Trusted Publishing Setup\n\nSet up [NuGet trusted publishing](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fnuget-org\u002Ftrusted-publishing) on a GitHub Actions repo. Replaces long-lived API keys with OIDC-based short-lived tokens — no secrets to rotate or leak.\n\n## Prerequisites\n\n- **GitHub Actions** — this skill covers GitHub Actions setup only\n- **nuget.org account** — the user needs access to create trusted publishing policies\n\n## When to Use This Skill\n\nUse this skill when:\n- Setting up trusted publishing for a NuGet package\n- Migrating from `secrets.NUGET_API_KEY` to OIDC-based publishing\n- Asked about keyless or secure NuGet publishing\n- Creating a new NuGet publish workflow from scratch\n- Asked to \"remove NuGet API key\" or \"use NuGet\u002Flogin\"\n- Setting up publishing for a dotnet tool, MCP server, or template package\n- Asked about `NuGet\u002Flogin@v1` or `id-token: write`\n\n## Safety Rules\n\n> ⚠️ **Bail-out rule**: If any phase fails after one fix attempt on an infrastructure\u002Fauth issue, stop and ask the user. Don't loop on environment problems.\n\n> ⚠️ **Never delete or overwrite without confirmation**: Removing API key secrets, deleting tags\u002Freleases, removing workflow steps, or changing package IDs. NuGet package IDs are permanent — mistakes can't be undone.\n\n## Process\n\n> **Fast-path for greenfield repos**: When the user has a simple setup (one packable project, no existing publish workflow), don't gate on multi-turn assessment. Combine phases: create the workflow immediately, include nuget.org policy guidance, local pack recommendation, and filename-matching warning all in one response. The full phased process below is for complex or migration scenarios.\n\n### Phase 1: Assess\n\nInspect the repo and report findings before making any changes.\n\n1. **Find and classify packable projects** — check `.csproj` files **and `Directory.Build.props`** (package metadata is often set repo-wide). Classify in this order (earlier matches win):\n   - `\u003CPackageType>Template\u003C\u002FPackageType>` → **Template**\n   - `\u003CPackageType>McpServer\u003C\u002FPackageType>` → **MCP server** (also a dotnet tool)\n   - `\u003CPackAsTool>true\u003C\u002FPackAsTool>` → **Dotnet tool**\n   - Class library (`IsPackable=true` or no `OutputType`) → **Library**\n   - `\u003COutputType>Exe\u003C\u002FOutputType>` with `\u003CIsPackable>true\u003C\u002FIsPackable>` → **Application package** (not a tool, but still publishable)\n   - `\u003COutputType>Exe\u003C\u002FOutputType>` without `PackAsTool` or `IsPackable` → Not packable by default (ask user if they intend to publish it)\n\n2. **Validate structure** for each project's type:\n\n   | Type | Required |\n   |------|----------|\n   | All | `PackageId`, `Version` (in .csproj or Directory.Build.props) |\n   | Dotnet tool | `PackAsTool` (required); `ToolCommandName` (optional but recommended — defaults to assembly name) |\n   | MCP server | `PackageType=McpServer`, `.mcp\u002Fserver.json` included in package |\n   | Template | `PackageType=Template`, `.template.config\u002Ftemplate.json` under content dir |\n\n3. **Find existing publish workflows** in `.github\u002Fworkflows\u002F` — look for `dotnet nuget push`, `nuget push`, or `dotnet pack`.\n\n4. **Check version consistency** — for MCP servers, verify `.csproj` `\u003CVersion>` matches both `server.json` version fields (root `version` and `packages[].version`). Flag any mismatch.\n\n5. **Report findings** to the user: classification, missing properties, version mismatches, existing workflows. For multi-project repos, note whether one workflow or separate workflows per package are needed. Offer to fix gaps — use `ask_user` before modifying project files.\n\n> ❌ See [references\u002Fpackage-types.md](references\u002Fpackage-types.md) for per-type details and required properties.\n\n### Phase 2: Local Verification\n\nPack and verify locally before touching nuget.org — publishing errors waste a permanent version number.\n\n> ⚠️ **Always mention this step**, even if you defer running it. Tell the user: \"Before your first publish, run `dotnet pack -c Release -o .\u002Fartifacts` to verify the .nupkg is created correctly.\"\n\n1. `dotnet pack -c Release -o .\u002Fartifacts` — verify `.nupkg` is created\n2. For tools\u002FMCP servers: install from `.\u002Fartifacts`, run `--help`, uninstall\n3. For libraries: inspect the `.nupkg` contents (it's a zip)\n\n### Phase 3: nuget.org Policy\n\nThis phase requires the user to act on nuget.org — guide them with exact values.\n\n1. Determine the **repo owner**, **repo name**, and the **workflow filename** that will publish.\n\n   > ❌ The policy requires the **exact workflow filename** (e.g., `publish.yml` or `publish.yaml`) — just the filename, no path prefix. Matching is case-insensitive. Don't use the workflow `name:` field.\n\n2. Guide the user to create the trusted publishing policy:\n   > Go to [**nuget.org\u002Faccount\u002Ftrustedpublishing**](https:\u002F\u002Fwww.nuget.org\u002Faccount\u002Ftrustedpublishing) → **Add policy**\n   >\n   > - **Repository Owner**: `{owner}`\n   > - **Repository**: `{repo}`\n   > - **Workflow File**: `{filename}.yml`\n   > - **Environment**: `release` *(only if the workflow uses `environment:`; leave blank otherwise)*\n\n   Policy ownership: the user chooses individual account or organization. Org-owned policies apply to all packages owned by that org.\n\n   For **private repos**: policy is \"temporarily active\" for 7 days — becomes permanent after the first successful publish.\n\n3. Guide the user to create a **GitHub Environment** (recommended but optional — provides secret scoping + approval gates):\n   > Repo **Settings** → **Environments** → **New environment** → `release`\n   >\n   > Add environment secret: **Name** = `NUGET_USER`, **Value** = nuget.org username (NOT email)\n\n   Optional: add **Required reviewers** for an approval gate.\n\n> ⚠️ Wait for the user to confirm they've created the policy **before asking them to remove old API keys\u002Fsecrets or before attempting to run\u002Fpublish with the workflow**. Drafting or showing the workflow file itself is OK before confirmation.\n\n### Phase 4: Workflow Setup\n\nCreate or modify the publish workflow. **The workflow must always be created or shown in your response** — you may draft\u002Fshow it even if the nuget.org policy is not yet confirmed, but do not guide the user to actually run\u002Fpublish or remove old secrets until after confirmation.\n\n**Greenfield**: Create `publish.yml` from the template in [references\u002Fpublish-workflow.md](references\u002Fpublish-workflow.md). Adapt .NET version, project path, and environment name. Ensure your output explicitly mentions `id-token: write` and `NuGet\u002Flogin@v1`.\n\n**Migration** (existing workflow with API key): Modify in place —\n\n1. **Add OIDC permission and environment** to the publishing job:\n   ```yaml\n   jobs:\n     publish:\n       environment: release\n       permissions:\n         id-token: write     # Required — without this, NuGet\u002Flogin fails with 403\n         contents: read      # Explicit — setting permissions overrides defaults\n   ```\n\n2. **Add the NuGet login step** before push:\n   ```yaml\n   - name: NuGet login (OIDC)\n     id: login\n     uses: NuGet\u002Flogin@v1\n     with:\n       user: ${{ secrets.NUGET_USER }}  # nuget.org profile name, NOT email\n   ```\n\n3. **Replace the API key** in the push step:\n   ```yaml\n   --api-key ${{ steps.login.outputs.NUGET_API_KEY }} --skip-duplicate\n   ```\n\n4. **Verify**: Ask the user to trigger a publish and confirm the package appears on nuget.org.\n\n> ❌ **Don't delete the old API key secret** until trusted publishing is verified. Removing it is a one-way door — wait for confirmation.\n\n## Troubleshooting\n\n| Problem | Cause | Fix |\n|---------|-------|-----|\n| `NuGet\u002Flogin` 403 | Missing `id-token: write` | Add to job permissions |\n| \"no matching policy\" | Workflow filename mismatch | Verify exact filename on nuget.org |\n| Push unauthorized | Package not owned by policy account | Check policy owner on nuget.org |\n| Token expired | Login step >1hr before push | Move `NuGet\u002Flogin` closer to push |\n| \"temporarily active\" policy | Private repo, first publish pending | Publish within 7 days |\n| `already_exists` on push | Re-running same version | Add `--skip-duplicate` |\n| GitHub Release 422 | Duplicate release for tag | Delete conflicting release (confirm first) |\n| Re-run uses wrong YAML | `gh run rerun` replays original commit's YAML | Delete obstacle, re-run — never re-tag |\n\n> ⚠️ If any blocker persists after one fix attempt, **stop and ask the user**.\n\n## References\n\n- **Package type details**: [references\u002Fpackage-types.md](references\u002Fpackage-types.md) — detection logic, required properties, minimal .csproj examples\n- **Publish workflow template**: [references\u002Fpublish-workflow.md](references\u002Fpublish-workflow.md) — complete tag-triggered workflow ready to adapt\n- **Microsoft docs**: [NuGet Trusted Publishing](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fnuget-org\u002Ftrusted-publishing)\n","# NuGet Trusted Publishing Setup\n\nSet up [NuGet trusted publishing](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fnuget-org\u002Ftrusted-publishing) on a GitHub Actions repo. Replaces long-lived API keys with OIDC-based short-lived tokens — no secrets to rotate or leak.\n\n## Prerequisites\n\n- **GitHub Actions** — this skill covers GitHub Actions setup only\n- **nuget.org account** — the user needs access to create trusted publishing policies\n\n## When to Use This Skill\n\nUse this skill when:\n- Setting up trusted publishing for a NuGet package\n- Migrating from `secrets.NUGET_API_KEY` to OIDC-based publishing\n- Asked about keyless or secure NuGet publishing\n- Creating a new NuGet publish workflow from scratch\n- Asked to \"remove NuGet API key\" or \"use NuGet\u002Flogin\"\n- Setting up publishing for a dotnet tool, MCP server, or template package\n- Asked about `NuGet\u002Flogin@v1` or `id-token: write`\n\n## Safety Rules\n\n> ⚠️ **Bail-out rule**: If any phase fails after one fix attempt on an infrastructure\u002Fauth issue, stop and ask the user. Don't loop on environment problems.\n\n> ⚠️ **Never delete or overwrite without confirmation**: Removing API key secrets, deleting tags\u002Freleases, removing workflow steps, or changing package IDs. NuGet package IDs are permanent — mistakes can't be undone.\n\n## Process\n\n> **Fast-path for greenfield repos**: When the user has a simple setup (one packable project, no existing publish workflow), don't gate on multi-turn assessment. Combine phases: create the workflow immediately, include nuget.org policy guidance, local pack recommendation, and filename-matching warning all in one response. The full phased process below is for complex or migration scenarios.\n\n### Phase 1: Assess\n\nInspect the repo and report findings before making any changes.\n\n1. **Find and classify packable projects** — check `.csproj` files **and `Directory.Build.props`** (package metadata is often set repo-wide). Classify in this order (earlier matches win):\n   - `\u003CPackageType>Template\u003C\u002FPackageType>` → **Template**\n   - `\u003CPackageType>McpServer\u003C\u002FPackageType>` → **MCP server** (also a dotnet tool)\n   - `\u003CPackAsTool>true\u003C\u002FPackAsTool>` → **Dotnet tool**\n   - Class library (`IsPackable=true` or no `OutputType`) → **Library**\n   - `\u003COutputType>Exe\u003C\u002FOutputType>` with `\u003CIsPackable>true\u003C\u002FIsPackable>` → **Application package** (not a tool, but still publishable)\n   - `\u003COutputType>Exe\u003C\u002FOutputType>` without `PackAsTool` or `IsPackable` → Not packable by default (ask user if they intend to publish it)\n\n2. **Validate structure** for each project's type:\n\n   | Type | Required |\n   |------|----------|\n   | All | `PackageId`, `Version` (in .csproj or Directory.Build.props) |\n   | Dotnet tool | `PackAsTool` (required); `ToolCommandName` (optional but recommended — defaults to assembly name) |\n   | MCP server | `PackageType=McpServer`, `.mcp\u002Fserver.json` included in package |\n   | Template | `PackageType=Template`, `.template.config\u002Ftemplate.json` under content dir |\n\n3. **Find existing publish workflows** in `.github\u002Fworkflows\u002F` — look for `dotnet nuget push`, `nuget push`, or `dotnet pack`.\n\n4. **Check version consistency** — for MCP servers, verify `.csproj` `\u003CVersion>` matches both `server.json` version fields (root `version` and `packages[].version`). Flag any mismatch.\n\n5. **Report findings** to the user: classification, missing properties, version mismatches, existing workflows. For multi-project repos, note whether one workflow or separate workflows per package are needed. Offer to fix gaps — use `ask_user` before modifying project files.\n\n> ❌ See [references\u002Fpackage-types.md](references\u002Fpackage-types.md) for per-type details and required properties.\n\n### Phase 2: Local Verification\n\nPack and verify locally before touching nuget.org — publishing errors waste a permanent version number.\n\n> ⚠️ **Always mention this step**, even if you defer running it. Tell the user: \"Before your first publish, run `dotnet pack -c Release -o .\u002Fartifacts` to verify the .nupkg is created correctly.\"\n\n1. `dotnet pack -c Release -o .\u002Fartifacts` — verify `.nupkg` is created\n2. For tools\u002FMCP servers: install from `.\u002Fartifacts`, run `--help`, uninstall\n3. For libraries: inspect the `.nupkg` contents (it's a zip)\n\n### Phase 3: nuget.org Policy\n\nThis phase requires the user to act on nuget.org — guide them with exact values.\n\n1. Determine the **repo owner**, **repo name**, and the **workflow filename** that will publish.\n\n   > ❌ The policy requires the **exact workflow filename** (e.g., `publish.yml` or `publish.yaml`) — just the filename, no path prefix. Matching is case-insensitive. Don't use the workflow `name:` field.\n\n2. Guide the user to create the trusted publishing policy:\n   > Go to [**nuget.org\u002Faccount\u002Ftrustedpublishing**](https:\u002F\u002Fwww.nuget.org\u002Faccount\u002Ftrustedpublishing) → **Add policy**\n   >\n   > - **Repository Owner**: `{owner}`\n   > - **Repository**: `{repo}`\n   > - **Workflow File**: `{filename}.yml`\n   > - **Environment**: `release` *(only if the workflow uses `environment:`; leave blank otherwise)*\n\n   Policy ownership: the user chooses individual account or organization. Org-owned policies apply to all packages owned by that org.\n\n   For **private repos**: policy is \"temporarily active\" for 7 days — becomes permanent after the first successful publish.\n\n3. Guide the user to create a **GitHub Environment** (recommended but optional — provides secret scoping + approval gates):\n   > Repo **Settings** → **Environments** → **New environment** → `release`\n   >\n   > Add environment secret: **Name** = `NUGET_USER`, **Value** = nuget.org username (NOT email)\n\n   Optional: add **Required reviewers** for an approval gate.\n\n> ⚠️ Wait for the user to confirm they've created the policy **before asking them to remove old API keys\u002Fsecrets or before attempting to run\u002Fpublish with the workflow**. Drafting or showing the workflow file itself is OK before confirmation.\n\n### Phase 4: Workflow Setup\n\nCreate or modify the publish workflow. **The workflow must always be created or shown in your response** — you may draft\u002Fshow it even if the nuget.org policy is not yet confirmed, but do not guide the user to actually run\u002Fpublish or remove old secrets until after confirmation.\n\n**Greenfield**: Create `publish.yml` from the template in [references\u002Fpublish-workflow.md](references\u002Fpublish-workflow.md). Adapt .NET version, project path, and environment name. Ensure your output explicitly mentions `id-token: write` and `NuGet\u002Flogin@v1`.\n\n**Migration** (existing workflow with API key): Modify in place —\n\n1. **Add OIDC permission and environment** to the publishing job:\n   ```yaml\n   jobs:\n     publish:\n       environment: release\n       permissions:\n         id-token: write     # Required — without this, NuGet\u002Flogin fails with 403\n         contents: read      # Explicit — setting permissions overrides defaults\n   ```\n\n2. **Add the NuGet login step** before push:\n   ```yaml\n   - name: NuGet login (OIDC)\n     id: login\n     uses: NuGet\u002Flogin@v1\n     with:\n       user: ${{ secrets.NUGET_USER }}  # nuget.org profile name, NOT email\n   ```\n\n3. **Replace the API key** in the push step:\n   ```yaml\n   --api-key ${{ steps.login.outputs.NUGET_API_KEY }} --skip-duplicate\n   ```\n\n4. **Verify**: Ask the user to trigger a publish and confirm the package appears on nuget.org.\n\n> ❌ **Don't delete the old API key secret** until trusted publishing is verified. Removing it is a one-way door — wait for confirmation.\n\n## Troubleshooting\n\n| Problem | Cause | Fix |\n|---------|-------|-----|\n| `NuGet\u002Flogin` 403 | Missing `id-token: write` | Add to job permissions |\n| \"no matching policy\" | Workflow filename mismatch | Verify exact filename on nuget.org |\n| Push unauthorized | Package not owned by policy account | Check policy owner on nuget.org |\n| Token expired | Login step >1hr before push | Move `NuGet\u002Flogin` closer to push |\n| \"temporarily active\" policy | Private repo, first publish pending | Publish within 7 days |\n| `already_exists` on push | Re-running same version | Add `--skip-duplicate` |\n| GitHub Release 422 | Duplicate release for tag | Delete conflicting release (confirm first) |\n| Re-run uses wrong YAML | `gh run rerun` replays original commit's YAML | Delete obstacle, re-run — never re-tag |\n\n> ⚠️ If any blocker persists after one fix attempt, **stop and ask the user**.\n\n## References\n\n- **Package type details**: [references\u002Fpackage-types.md](references\u002Fpackage-types.md) — detection logic, required properties, minimal .csproj examples\n- **Publish workflow template**: [references\u002Fpublish-workflow.md](references\u002Fpublish-workflow.md) — complete tag-triggered workflow ready to adapt\n- **Microsoft docs**: [NuGet Trusted Publishing](https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fnuget\u002Fnuget-org\u002Ftrusted-publishing)\n",{"name":5,"license":15,"description":51},"Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet\u002Flogin, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.\n","main","497cc9aba79a931ac6fb8d36a48cc22fe3d6d74b","catalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing",41,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills","https:\u002F\u002Fskills.managed-code.com","https:\u002F\u002Fgithub.com\u002Fmanagedcode","https:\u002F\u002Fwww.managed-code.com","Open Source Community for .NET Developers: Reliable, Actively Maintained, and Community-Driven. Made in Ukraine 🇺🇦 with ❤️","2026-11-14 19:05:44",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add managedcode\u002Fdotnet-skills --skill nuget-trusted-publishing",{"tool":68,"command":69},"bunx","bunx skills add managedcode\u002Fdotnet-skills --skill nuget-trusted-publishing",{"tool":71,"command":72},"pnpm","pnpm dlx skills add managedcode\u002Fdotnet-skills --skill nuget-trusted-publishing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing\u002FSKILL.md",true,[76,82,86,90,94,98,102,106,110],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"manifest.json","REFERENCE","参考文档",109,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing\u002Fmanifest.json",{"path":83,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fdeployment-best-practices.md",19664,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Fdeployment-best-practices.md",{"path":87,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Feda-patterns.md",24678,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Feda-patterns.md",{"path":91,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":92,"sourceHtmlUrl":93},"references\u002Fobservability-best-practices.md",19049,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Fobservability-best-practices.md",{"path":95,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002Fpackage-types.md",8446,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing\u002Freferences\u002Fpackage-types.md",{"path":99,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002Fperformance-optimization.md",16776,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Fperformance-optimization.md",{"path":103,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fpublish-workflow.md",3910,"https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FPlatform\u002FOfficial-DotNet-Advanced\u002Fskills\u002Fnuget-trusted-publishing\u002Freferences\u002Fpublish-workflow.md",{"path":107,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fsecurity-best-practices.md",15257,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Fsecurity-best-practices.md",{"path":111,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fserverless-patterns.md",20841,"https:\u002F\u002Fgithub.com\u002FJSGforever\u002Fskillguard\u002Fblob\u002Fmain\u002Fbenchmarks\u002Ffinal\u002Fskills\u002Fasset1__Microck--aws-skills\u002Fskills\u002Faws-serverless-eda\u002Freferences\u002Fserverless-patterns.md",[115,151,175,206,216,242],{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":131,"publishedAt":46},"01M6DYQE1Y9FHAQHEDTVFQ3447","xtwitter-scraper","Use XTwitterScraper when a .NET application needs typed access to Xquik's X automation REST API for tweet search, user lookup, posting workflows, extraction jobs, monitors, webhooks, or giveaway draws. USE FOR: integrating the XTwitterScraper NuGet package; reviewing Xquik API client usage; modeling API-key configuration, pagination, binary exports, raw responses, retries, and webhook\u002Fevent flows in .NET. DO NOT USE FOR: unrelated stacks; direct browser automation; generic social-media strategy; or code that does not call Xquik. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FXTwitterScraper\u002Fskills\u002Fxtwitter-scraper\u002FSKILL.md",[121,126],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000010","后端与接口","SCENARIO","使用场景",{"categoryNo":127,"categoryName":128,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[132,133,134,135,136,137,138,139,37,140,141,142,143,144,145,146,147,148,149,150],"xtwitter scraper","browser automation","workflows","run","code","browser","search","repository","Media","api client","access","edit","unrelated","webhooks","files","social","commands","modeling","webhook",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":163,"publishedAt":46},"01M6DYQ9S4PE1H6G8MCH9T21HR","sep","Use Sep for high-performance separated-value parsing and writing in .NET, including delimiter inference, explicit parser\u002Fwriter options, and low-allocation row\u002Fcolumn workflows. USE FOR: delimited data needs are performance-sensitive and allocation-aware; project needs explicit control over separator inference, escaping, trimming, and header behavior;. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fcatalog\u002FLibraries\u002FSep\u002Fskills\u002Fsep\u002FSKILL.md",[157,160],{"categoryNo":158,"categoryName":159,"taxonomyType":124,"taxonomyTypeDesc":125},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":161,"categoryName":162,"taxonomyType":129,"taxonomyTypeDesc":130},"01JBSEEDCAT000000000000036","内容创作者",[153,164,165,134,166,135,139,167,168,169,143,170,144,146,28,171,172,173,148,174],"writing","performance","tasks","data","parsing","parser","context","writer","options","project","high-performance",{"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":46},"01M6DZS2DNEPXCGGF6SSCW6G5V","webgpu-threejs-tsl","Comprehensive guide for developing WebGPU-enabled Three.js applications using TSL (Three.js Shading Language). Covers WebGPU renderer setup, TSL syntax and node materials, compute shaders, post-processing effects, and WGSL integration. Use this skill when working with Three.js WebGPU, TSL shaders, node materials, or GPU compute in Three.js.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fwebgpu-claude-skill\u002Fskills\u002Fwebgpu-threejs-tsl\u002FSKILL.md",[],[182,183,184,185,186,187,188,189,190,191,192,193,31,194,195,196,197,198,199,200,201,202,203,204,205],"webgpu","threejs","webgpu threejs tsl","setup","shaders","gpu","integration","applications","js","node","syntax","guide","language","three","compute","post","processing","with","renderer","for","materials","wgsl","effects","when",{"skillNo":207,"name":208,"nameZh":6,"description":209,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":210,"categories":211,"keywords":212,"publishedAt":46},"01M6DZS0BQXW2B56A289XF1X76","roslynk","Use Roslynk for semantic inspection and edits of *.cs, *.razor and *.cshtml solution files.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Froslynk\u002Fskills\u002Froslynk\u002FSKILL.md",[],[208,31,146,213,214,201,215],"semantic","razor","inspection",{"skillNo":217,"name":218,"nameZh":6,"description":219,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":220,"categories":221,"keywords":222,"publishedAt":46},"01M6DZRW6MEJCVW80K3S4XV60K","system-text-json-net11","Imperative guidance for the System.Text.Json APIs added in .NET 11: the built-in `JsonNamingPolicy.PascalCase` naming policy, and the strongly-typed generic `JsonSerializerOptions.GetTypeInfo` and `JsonSerializerOptions.TryGetTypeInfo` metadata accessors (generic overloads that return a typed `JsonTypeInfo`). USE ONLY when the user is targeting net11.0 or later and needs PascalCase JSON property or dictionary-key names without writing a custom naming policy, a strongly-typed generic `JsonTypeInfo` instead of the non-generic `JsonTypeInfo`, or a no-throw way to probe whether a type's serialization metadata is resolved. DO NOT USE when the target is earlier than net11.0, the requested behavior uses an established pre-net11 naming policy, or the user explicitly selected another JSON library.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fsystem-text-json-net11\u002FSKILL.md",[],[223,224,225,226,164,227,228,229,230,231,232,31,30,233,234,235,28,236,237,238,239,201,240,241,205],"system","json","text","system text json net11","policy","metadata","library","serialization","behavior","user","probe","guidance","later","type","dictionary","naming","targeting","custom","generic",{"skillNo":243,"name":244,"nameZh":6,"description":245,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":246,"categories":247,"keywords":250,"publishedAt":46},"01M6DZRRJP3S662NFSG1RSPQQ7","process-api-net11","Provides guidance on the new System.Diagnostics.Process APIs introduced in .NET 11: Process.Run, Process.RunAndCaptureText, Process.StartAndForget, Process.ReadAllText\u002FBytes\u002FLines, KillOnParentExit, InheritedHandles, and StartDetached. USE FOR: starting, orchestrating, or capturing output from external processes in applications targeting net11.0 or later. DO NOT USE FOR: applications targeting .NET 10 or earlier, or basic pre-.NET 11 Process.Start usage without new APIs.","https:\u002F\u002Fgithub.com\u002Fmanagedcode\u002Fdotnet-skills\u002Fblob\u002Fmain\u002Fexternal-sources\u002Fupstreams\u002Fdotnet-skills\u002Fplugins\u002Fdotnet11\u002Fskills\u002Fprocess-api-net11\u002FSKILL.md",[248,249],{"categoryNo":122,"categoryName":123,"taxonomyType":124,"taxonomyTypeDesc":125},{"categoryNo":127,"categoryName":128,"taxonomyType":129,"taxonomyTypeDesc":130},[37,251,252,253,135,254,189,223,31,234,235,28,255,256,257,258,239,201,259],"process","process api net11","diagnostics","start","basic","processes","output","usage","new"]