[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACKG78GSZJ2EM7Q3H9A3RB":3,"skill-same:01M6ACKG78GSZJ2EM7Q3H9A3RB":70},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6ACKG78GSZJ2EM7Q3H9A3RB","openspec-oneshot",null,"Run a full OpenSpec workflow from one request. Use when the user wants proposal, implementation, commits, spec sync, and archive handled as one resumable flow.","apache\u002Fcauseway","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACK5FDA6VVQG8EXM21X4XJ",909,"MIT","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-oneshot\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"oneshot","openspec oneshot","openspec","use","when","request","true","proposal","spec sync","as","full","local","cli","archive","Bash","commits","flow","run","sync","workflow","spec","2026-11-10 10:12:30",false,"---\nname: update-integrations\ndescription: Update integration documentation links and API reference data by synchronizing NuGet package names with their documentation URLs and generating per-package API schemas. Use when adding new integrations, refreshing package data, ensuring integration-docs.json stays in sync with aspire-integrations.json, or regenerating API reference JSON files.\n---\n\n# Update Integration Documentation Links & API Reference Data\n\nThis skill synchronizes the integration package catalog with documentation URL mappings and generates per-package API reference schemas. It ensures every NuGet package listed in the integrations data file has a corresponding documentation link and an up-to-date API reference JSON file.\n\n> **Automation note:** The scheduled `update-integration-data` workflow (`.github\u002Fworkflows\u002Fupdate-integration-data.yml`) runs this update deterministically — no agent\u002FLLM. It executes `src\u002Ffrontend\u002Fscripts\u002Fupdate-integration-data.ps1`, which runs `bun run update:all`, detects `\"version\":` changes in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`, and — only when a version actually moves — runs the C# and TypeScript API regeneration (and the twoslash bundle) before opening or refreshing a PR via the Aspire bot GitHub App. That PR is approved and squash-merged automatically by `.github\u002Fpolicies\u002Fauto-merge.yml` once the required `ci-gate` check passes; removing its `:octocat: auto-merge` label holds it for manual review. You can reproduce the full flow locally with `pwsh src\u002Ffrontend\u002Fscripts\u002Fupdate-integration-data.ps1` (add `-SkipRegen` for a fast data-only run). Use this skill for **manual or one-off runs that need judgment** — for example: adding a new integration, reconciling `integration-docs.json`, validating release-branch feed resolution, troubleshooting a regen failure flagged by the workflow's PR, or regenerating data outside the scheduled cadence.\n\n## Overview\n\nThe automated flow also reconciles documentation mappings and runs `bun run test:unit:structured-data` before API regeneration or PR creation. This uses a data-only Vitest configuration so validation does not rewrite Astro's generated assets. Mapping changes are included in the generated PR.\n\nThe aspire.dev site maintains three key data locations:\n\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`** — Package metadata fetched from the configured package feeds (titles, descriptions, icons, versions, download counts).\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fintegration-docs.json`** — Mappings from package names to site-relative documentation URLs.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`** — Per-package API reference JSON files (e.g. `Aspire.Hosting.Redis.13.1.2.json`) generated by the `PackageJsonGenerator` tool. These feed the auto-generated API reference pages at `\u002Freference\u002Fapi\u002F`.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F`** — Per-package TypeScript API reference JSON files (e.g. `Aspire.Hosting.Redis.13.2.0.json`) generated by the `AtsJsonGenerator` tool. These feed the auto-generated TypeScript API reference pages at `\u002Freference\u002Fapi\u002Ftypescript\u002F`.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts`** — A single consolidated TypeScript declaration bundle generated from the `ts-modules` JSON by `scripts\u002Fgenerate-twoslash-types.ts`. Consumed by `expressive-code-twoslash` to provide hover tooltips for TypeScript code samples in the docs. **Source-controlled** — commit the diff whenever `ts-modules` changes.\n\nThis skill keeps the documentation mappings in sync with the package catalog and regenerates both the C# and TypeScript API reference data.\n\n## Prerequisites\n\n- Node.js installed and available on `PATH`\n- .NET SDK installed and available on `PATH` (required for the `PackageJsonGenerator` tool)\n- PowerShell (pwsh) available on `PATH` (for running the generation script)\n- Working directory is the repository root\n- The frontend project dependencies are installed (`bun install` in `src\u002Ffrontend\u002F`)\n\n### Release branch package source behavior\n\n- On `main` and all non-`release\u002F*` branches, official Aspire packages resolve from `https:\u002F\u002Fapi.nuget.org\u002Fv3\u002Findex.json`\n- On `release\u002F*` branches, official packages (`Aspire.*`) must resolve from the branch-specific public Azure Artifacts feed instead of nuget.org\n- Community Toolkit packages (`CommunityToolkit.Aspire.*`) always resolve from nuget.org\n- The branch name in this repo is expected to match the corresponding branch in `microsoft\u002Faspire` (for example `release\u002F13.2`)\n- The release feed name follows `darc-pub-microsoft-aspire-{shortSha}` where `{shortSha}` is the first 8 characters of the head commit SHA for the matching Aspire release branch\n- The automation derives the NuGet service index from that feed name as `https:\u002F\u002Fpkgs.dev.azure.com\u002Fdnceng\u002Fpublic\u002F_packaging\u002F{feed-name}\u002Fnuget\u002Fv3\u002Findex.json`\n\n#### Release feed resolution\n\nThe scripts use this precedence on `release\u002F*` branches:\n\n1. `ASPIRE_RELEASE_FEED_URL` — accepts the full NuGet service index URL, the Azure DevOps feed page URL, or the raw feed name\n2. `ASPIRE_RELEASE_FEED_NAME` — explicit feed name such as `darc-pub-microsoft-aspire-aad16017`\n3. `ASPIRE_RELEASE_COMMIT` \u002F `ASPIRE_RELEASE_COMMIT_SHA` — derives the feed name from the commit SHA prefix\n4. Automatic lookup of the matching branch head via `git ls-remote` against `https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire`\n\nIf the Aspire release branch is not publicly reachable yet, set one of the override environment variables above. The scripts intentionally fail on `release\u002F*` if the official release feed cannot be resolved, to avoid accidentally ingesting stale nuget.org packages.\n\nWhen the commit-specific feed is unavailable but a shared feed contains the required\nbuild, set `ASPIRE_RELEASE_FEED_URL` and `ASPIRE_RELEASE_VERSION` together. The\nversion must be an exact package version matching the release branch, not a range.\nOfficial packages select only that version; Toolkit packages keep their normal\nnuget.org selection. Packages absent from that build retain an existing catalog\nentry, if any, rather than importing a different release. An unavailable pin for\nthe entire integration set, an unlisted\u002Fdeprecated pinned version, or a pinned\nregistration lookup failure stops the update before the catalog is written.\nSelected-version registration metadata supplies release descriptions and tags.\nWhere no published nuget.org icon metadata exists, the updater reports use of the\npublic Aspire site icon instead of embedding an unpublished or authenticated-feed\nimage URL.\n\nFor an app-managed worktree whose branch name is not `release\u002F*`, set\n`BUILD_SOURCEBRANCH=refs\u002Fheads\u002Frelease\u002FN.N` in the update process alongside those\noverrides. This supplies the existing branch-resolution context without renaming\nor switching the worktree. Do not set these variables globally. Review the\nresolved source and version before regeneration; C# and TypeScript generators\nconsume the resulting catalog's exact versions.\n\n## Step-by-Step Process\n\n### 1. Run the update script\n\nFetch the latest package data from the configured package feeds:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend update:integrations\n```\n\nThis writes updated package metadata to `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`. The script queries the NuGet v3 API for packages matching `owner:aspire`, `Aspire.Hosting.`, and `CommunityToolkit.Aspire`, then filters out deprecated, unlisted, and excluded packages.\n\nIt also removes documentation mappings for Aspire and Community Toolkit packages absent from the updated catalog. Manually curated third-party mappings are preserved, and new documentation URLs still require manual resolution.\n\nOn `release\u002F*` branches, the script queries the branch-specific official Aspire feed for `Aspire.*` packages and continues to query nuget.org for `CommunityToolkit.Aspire.*` packages.\n\n### 2. Read the updated package data\n\nLoad `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json` and extract all package names from the `title` field of each entry in the JSON array.\n\n### 3. Update integration documentation mappings\n\nLoad `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fintegration-docs.json` and reconcile it with the package list:\n\n- **For each package name** (from `title` field) in `aspire-integrations.json`:\n  - Check if a matching entry exists in `integration-docs.json` (where `match` equals the package name)\n  - If an entry exists, verify the `href` is correct\n  - If no entry exists, determine the appropriate documentation URL\n\n- **Remove stale entries** for catalog-managed Aspire and Community Toolkit packages no longer in `aspire-integrations.json`. Preserve mappings for third-party packages outside the catalog's sources.\n\n- **Preserve existing correct mappings** — do not change entries that are already accurate\n\n### 4. Determining documentation URLs\n\nWhen a package has no existing mapping, determine the URL based on:\n\n#### Package name patterns\n\n| Package prefix | Documentation path pattern |\n|---|---|\n| `Aspire.Hosting.Azure.*` | `\u002Fintegrations\u002Fcloud\u002Fazure\u002F{service-name}\u002F` |\n| `Aspire.Azure.*` | `\u002Fintegrations\u002Fcloud\u002Fazure\u002F{service-name}\u002F` |\n| `Aspire.Hosting.{Tech}` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `Aspire.{Client}.{Driver}` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `CommunityToolkit.Aspire.Hosting.*` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `CommunityToolkit.Aspire.*` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n\n#### Technology categories\n\nThe documentation site organizes integrations into these categories:\n\n| Category path | Technologies |\n|---|---|\n| `\u002Fintegrations\u002Fai\u002F` | OpenAI, Ollama, Milvus, Qdrant |\n| `\u002Fintegrations\u002Fcaching\u002F` | Redis, Valkey, Garnet, Memcached |\n| `\u002Fintegrations\u002Fcloud\u002Fazure\u002F` | All Azure services |\n| `\u002Fintegrations\u002Fcompute\u002F` | Orleans, Dapr |\n| `\u002Fintegrations\u002Fdatabases\u002F` | PostgreSQL, SQL Server, MySQL, MongoDB, Cosmos DB, Oracle, Elasticsearch, Milvus, Qdrant |\n| `\u002Fintegrations\u002Fdatabases\u002Fefcore\u002F` | EF Core variants of database integrations |\n| `\u002Fintegrations\u002Fdevtools\u002F` | Developer tools and utilities |\n| `\u002Fintegrations\u002Fframeworks\u002F` | Framework integrations |\n| `\u002Fintegrations\u002Fmessaging\u002F` | Kafka, RabbitMQ, NATS, Azure Service Bus, Event Hubs |\n| `\u002Fintegrations\u002Fobservability\u002F` | OpenTelemetry, Seq, logging |\n| `\u002Fintegrations\u002Freverse-proxies\u002F` | YARP |\n| `\u002Fintegrations\u002Fsecurity\u002F` | Keycloak, Key Vault |\n\n#### URL resolution strategy\n\n1. Match against existing similar package mappings in `integration-docs.json`\n2. Infer from the package name and technology category\n3. **Verify the page exists** — check the file system under `src\u002Ffrontend\u002Fsrc\u002Fcontent\u002Fdocs\u002F`, then use Playwright CLI to confirm the route renders\n4. If no valid documentation page can be found, flag the package for manual review\n\n### 5. Generate API reference data\n\nAfter updating the integration catalog, regenerate the per-package API reference JSON files. The `generate-package-json.ps1` script automates this:\n\n```bash\ncd src\u002Ftools\u002FPackageJsonGenerator && pwsh .\u002Fgenerate-package-json.ps1\n```\n\nThe script performs the following for every package listed in `aspire-integrations.json`:\n\n1. Resolves the correct package source per package: official Aspire packages use the branch-specific release feed on `release\u002F*`, while Community Toolkit packages continue to use nuget.org.\n2. Queries that package source for the latest stable version (falls back to latest preview if no stable exists).\n3. Downloads the package into the local NuGet cache via `dotnet restore` if not already cached.\n   Provisioning SDK overlays restore with the same-version `Aspire.Hosting`\n   reference to model their AppHost context; other packages retain standalone\n   per-package restore graphs. Dependency errors remain fatal.\n   Restores run in parallel, up to 8 at a time by default (`-Parallelism` changes\n   the limit; `-Sequential` restores one package at a time). A failed `dotnet restore`\n   is attempted up to three times before the package counts as failed.\n4. Selects the best-matching target framework folder (prefers `net10.0`, then `net9.0`, etc.).\n5. Uses Roslyn to analyze the assembly and extract all public types, members, XML docs, and attributes.\n6. Writes a `{Package}.{Version}.json` file to `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`.\n\nAn assembly that opts into an `AspireExportProvider` can expose generated ATS\nAPIs without public C# types. For those assemblies, the generator retains package\nidentity and provenance with `types: []` and `package.hasGeneratedExports: true`.\nThis record feeds TypeScript generation and requires a corresponding TypeScript\nmodule at semantic validation. It does not add an empty C# package to API navigation.\nBuild-only packages without public types or generated-export opt-ins remain explicit skips.\n\nThe generated JSON follows this schema:\n\n```json\n{\n  \"package\": {\n    \"name\": \"Aspire.Hosting.Redis\",\n    \"version\": \"13.1.2\",\n    \"targetFramework\": \"net10.0\"\n  },\n  \"types\": [\n    {\n      \"name\": \"TypeName\",\n      \"fullName\": \"Namespace.TypeName\",\n      \"namespace\": \"Namespace\",\n      \"kind\": \"class\",\n      \"accessibility\": \"public\",\n      \"members\": [ ... ],\n      \"docs\": { ... }\n    }\n  ]\n}\n```\n\nThese files are consumed by the `packages` content collection defined in `src\u002Ffrontend\u002Fsrc\u002Fcontent.config.ts` and used to render API reference pages at `\u002Freference\u002Fapi\u002F{package}\u002F{type}\u002F`.\n\n#### Selective regeneration\n\nTo regenerate API data for specific packages only:\n\n```bash\npwsh .\u002Fgenerate-package-json.ps1 -Packages @(\"Aspire.Hosting.Redis\", \"Aspire.Hosting.PostgreSQL\")\n```\n\n#### Targeting a different framework\n\nTo use a different target framework (e.g. `net10.0`):\n\n```bash\npwsh .\u002Fgenerate-package-json.ps1 -Framework \"net10.0\"\n```\n\n#### Handling failures\n\nThe script reports a summary of successes, failures, and skipped packages. Common reasons for skips or failures:\n\n- Package has no `lib\u002F` folder (meta-packages, build-only packages)\n- No DLLs found for the preferred TFM\n- NuGet API resolution failure\n\nPackages that fail should be investigated individually — they may need a different framework target or may not ship a public API surface.\nBecause restores are retried, a restore failure in the summary usually has a persistent cause, such as a pinned version that's no longer published on the package's feed.\n\nIf an official release feed is required but not yet publicly reachable, rerun with one of the release feed override environment variables set.\n\n### 5a. Generate TypeScript API reference data\n\nAfter updating `aspire-integrations.json`, regenerate the TypeScript API reference JSON files for the hosting packages that expose ATS capabilities:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend update:ts-api\n```\n\nThe companion `generate-ts-api-json.ps1` script reads the generated C# package JSON files in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`, selects `Aspire.Hosting`, `Aspire.Hosting.*`, and `CommunityToolkit.Aspire.Hosting.*` packages, and passes each package\u002Fversion through to `aspire sdk dump`. This keeps `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F` aligned with the same package set and versions that already flowed through C# API generation.\n\nRadius versions exporting the generic `IDotnetProgramResource` overload are\nscanned with `Aspire.Hosting.Dotnet` as supporting context. Its exact version\ncomes from the generated C# metadata, so the scanner can retain the export on\n`DotnetProjectResource` while the concrete overload serves legacy project\nresources. Generate the Dotnet module first when regenerating Radius selectively.\nThe transformer excludes core and supporting APIs using their generated modules;\nit preserves Radius's real capability IDs and expanded receiver targets.\nA scanner collision that removes the generic export must be fixed upstream,\nnot hidden by changing the C# metadata or weakening API-reference validation.\n\nFor generated-export overlays, the script also obtains the matching\n`aspire sdk export --language typescript` document. Referenced SDK enum definitions\nmissing from the raw dump are taken from that canonical export, with package identity\nand unambiguous ownership checks. Union members are preserved during transformation;\nmissing or unsupported enum definitions fail generation rather than becoming empty\ninterface stubs. Semantic validation checks enum members in the final Twoslash bundle.\nThe bundle represents enums as string unions with companion constant objects.\nWhen independent packages export the same enum short name, the shared bundle\ncombines their literals; each package's API JSON retains its exact enum surface.\nUse the package-specific SDK to validate behavior that depends on those differences.\nThe generator rejects nonzero SDK dump exits and error diagnostics even when a JSON\nfile was produced. An incomplete dump isn't a successful API-generation result.\nThe one exception is a known scanner defect: a method inherited by several proxy\ntypes is exported once per derived type under the base type's capability ID, and the\nscanner reports each collision as a `Duplicate capability` error. When a dump exits\nnonzero after writing its JSON, the script passes `--tolerate-known-scanner-diagnostics`\nto the transformer, which accepts only that diagnostic shape, and only when the dump's\n`HandleTypes` show that each defining type is, or derives from, the type that owns the\ncapability ID. Any other error diagnostic, or a nonzero exit without one, still fails the\npackage. The script lists tolerated diagnostics in its summary, and\n`update-integration-data.ps1` raises a CI warning and lists the affected packages in the\npull request body. Remove the tolerance\nonce the shipped Aspire CLI includes [microsoft\u002Faspire#20443](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fpull\u002F20443).\n\nPackages are generated in waves: `Aspire.Hosting` first, then packages that don't need\nsupporting scan context, then packages that do. Packages in a wave run concurrently,\nup to 8 at a time by default; set `ASPIRE_TS_API_PARALLELISM` to change the limit (`1`\nprocesses one package at a time). `-AspireRepoPath` runs always process one package at\na time because they build shared repo projects. Each `aspire` CLI call is limited to 10\nminutes and each helper tool call to 5 minutes. A dump or export that fails without\nproducing a result, for example after a timeout or a transient restore failure, is\nattempted up to three times.\n\nWhen a TypeScript module is regenerated for a new package version, stale `ts-modules` JSON files for older versions of that same package are deleted automatically. Regenerated modules with no functions or types are omitted from `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F`.\n\nAfter the JSON is refreshed, `update-ts-api` automatically chains `generate-twoslash-types.ts` to rebuild `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts`. This bundle is source-controlled and its diff must be committed alongside the `ts-modules` JSON changes — without it, docs hover tooltips fall back to `any`. If you only need to refresh the bundle (e.g. after a generator script change) without running the full SDK dump, use:\n\n```bash\ncd src\u002Ffrontend && bun run twoslash-types\n```\n\n### 6. Verify all links\n\nFor every entry in the updated `integration-docs.json`:\n\n- **Site-relative links** must end with a trailing `\u002F`\n- **External links** (e.g., AWS docs) are allowed and should use full URLs\n- **All site-relative links must point to existing documentation pages** — check by verifying a corresponding `.mdx` file exists under `src\u002Ffrontend\u002Fsrc\u002Fcontent\u002Fdocs\u002F`\n\nDo not assume a page exists without verification.\n\n### 7. Save the result\n\nWrite the updated `integration-docs.json` maintaining consistent formatting (2-space indentation, trailing newline). The API reference JSON files in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F` are written directly by the generation script and require no additional save step.\n\nRun the structured-data tests after changing the catalog or documentation map:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend test:unit:structured-data\n```\n\n## Entry format\n\nEach entry in `integration-docs.json` follows this structure:\n\n```json\n{\n  \"match\": \"Aspire.Hosting.Redis\",\n  \"href\": \"\u002Fintegrations\u002Fcaching\u002Fredis\u002Fredis-get-started\u002F\"\n}\n```\n\n- `match` — The exact NuGet package name (from the `title` field in `aspire-integrations.json`)\n- `href` — A site-relative path (with trailing `\u002F`) or an external URL\n\n## Handling unmapped packages\n\nWhen a package name has no clear documentation mapping:\n\n1. **Do not invent a URL** — only use paths that correspond to real pages\n2. **List the package** for manual review with a note explaining why no mapping was found\n3. These packages likely need new documentation pages written (hand off to the `doc-writer` skill)\n\n## Example output\n\nAfter running this skill, the agent should report:\n\n- Number of packages in `aspire-integrations.json`\n- Number of mapped entries in `integration-docs.json`\n- Any new mappings added\n- Any stale mappings removed\n- Any packages that could not be mapped (flagged for manual review)\n- Number of API reference JSON files generated (success \u002F failed \u002F skipped)\n- Any packages that failed API generation, with reasons\n- Confirmation that `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts` was refreshed (and that the diff will be committed)\n","# Update Integration Documentation Links & API Reference Data\n\nThis skill synchronizes the integration package catalog with documentation URL mappings and generates per-package API reference schemas. It ensures every NuGet package listed in the integrations data file has a corresponding documentation link and an up-to-date API reference JSON file.\n\n> **Automation note:** The scheduled `update-integration-data` workflow (`.github\u002Fworkflows\u002Fupdate-integration-data.yml`) runs this update deterministically — no agent\u002FLLM. It executes `src\u002Ffrontend\u002Fscripts\u002Fupdate-integration-data.ps1`, which runs `bun run update:all`, detects `\"version\":` changes in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`, and — only when a version actually moves — runs the C# and TypeScript API regeneration (and the twoslash bundle) before opening or refreshing a PR via the Aspire bot GitHub App. That PR is approved and squash-merged automatically by `.github\u002Fpolicies\u002Fauto-merge.yml` once the required `ci-gate` check passes; removing its `:octocat: auto-merge` label holds it for manual review. You can reproduce the full flow locally with `pwsh src\u002Ffrontend\u002Fscripts\u002Fupdate-integration-data.ps1` (add `-SkipRegen` for a fast data-only run). Use this skill for **manual or one-off runs that need judgment** — for example: adding a new integration, reconciling `integration-docs.json`, validating release-branch feed resolution, troubleshooting a regen failure flagged by the workflow's PR, or regenerating data outside the scheduled cadence.\n\n## Overview\n\nThe automated flow also reconciles documentation mappings and runs `bun run test:unit:structured-data` before API regeneration or PR creation. This uses a data-only Vitest configuration so validation does not rewrite Astro's generated assets. Mapping changes are included in the generated PR.\n\nThe aspire.dev site maintains three key data locations:\n\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`** — Package metadata fetched from the configured package feeds (titles, descriptions, icons, versions, download counts).\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fintegration-docs.json`** — Mappings from package names to site-relative documentation URLs.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`** — Per-package API reference JSON files (e.g. `Aspire.Hosting.Redis.13.1.2.json`) generated by the `PackageJsonGenerator` tool. These feed the auto-generated API reference pages at `\u002Freference\u002Fapi\u002F`.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F`** — Per-package TypeScript API reference JSON files (e.g. `Aspire.Hosting.Redis.13.2.0.json`) generated by the `AtsJsonGenerator` tool. These feed the auto-generated TypeScript API reference pages at `\u002Freference\u002Fapi\u002Ftypescript\u002F`.\n- **`src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts`** — A single consolidated TypeScript declaration bundle generated from the `ts-modules` JSON by `scripts\u002Fgenerate-twoslash-types.ts`. Consumed by `expressive-code-twoslash` to provide hover tooltips for TypeScript code samples in the docs. **Source-controlled** — commit the diff whenever `ts-modules` changes.\n\nThis skill keeps the documentation mappings in sync with the package catalog and regenerates both the C# and TypeScript API reference data.\n\n## Prerequisites\n\n- Node.js installed and available on `PATH`\n- .NET SDK installed and available on `PATH` (required for the `PackageJsonGenerator` tool)\n- PowerShell (pwsh) available on `PATH` (for running the generation script)\n- Working directory is the repository root\n- The frontend project dependencies are installed (`bun install` in `src\u002Ffrontend\u002F`)\n\n### Release branch package source behavior\n\n- On `main` and all non-`release\u002F*` branches, official Aspire packages resolve from `https:\u002F\u002Fapi.nuget.org\u002Fv3\u002Findex.json`\n- On `release\u002F*` branches, official packages (`Aspire.*`) must resolve from the branch-specific public Azure Artifacts feed instead of nuget.org\n- Community Toolkit packages (`CommunityToolkit.Aspire.*`) always resolve from nuget.org\n- The branch name in this repo is expected to match the corresponding branch in `microsoft\u002Faspire` (for example `release\u002F13.2`)\n- The release feed name follows `darc-pub-microsoft-aspire-{shortSha}` where `{shortSha}` is the first 8 characters of the head commit SHA for the matching Aspire release branch\n- The automation derives the NuGet service index from that feed name as `https:\u002F\u002Fpkgs.dev.azure.com\u002Fdnceng\u002Fpublic\u002F_packaging\u002F{feed-name}\u002Fnuget\u002Fv3\u002Findex.json`\n\n#### Release feed resolution\n\nThe scripts use this precedence on `release\u002F*` branches:\n\n1. `ASPIRE_RELEASE_FEED_URL` — accepts the full NuGet service index URL, the Azure DevOps feed page URL, or the raw feed name\n2. `ASPIRE_RELEASE_FEED_NAME` — explicit feed name such as `darc-pub-microsoft-aspire-aad16017`\n3. `ASPIRE_RELEASE_COMMIT` \u002F `ASPIRE_RELEASE_COMMIT_SHA` — derives the feed name from the commit SHA prefix\n4. Automatic lookup of the matching branch head via `git ls-remote` against `https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire`\n\nIf the Aspire release branch is not publicly reachable yet, set one of the override environment variables above. The scripts intentionally fail on `release\u002F*` if the official release feed cannot be resolved, to avoid accidentally ingesting stale nuget.org packages.\n\nWhen the commit-specific feed is unavailable but a shared feed contains the required\nbuild, set `ASPIRE_RELEASE_FEED_URL` and `ASPIRE_RELEASE_VERSION` together. The\nversion must be an exact package version matching the release branch, not a range.\nOfficial packages select only that version; Toolkit packages keep their normal\nnuget.org selection. Packages absent from that build retain an existing catalog\nentry, if any, rather than importing a different release. An unavailable pin for\nthe entire integration set, an unlisted\u002Fdeprecated pinned version, or a pinned\nregistration lookup failure stops the update before the catalog is written.\nSelected-version registration metadata supplies release descriptions and tags.\nWhere no published nuget.org icon metadata exists, the updater reports use of the\npublic Aspire site icon instead of embedding an unpublished or authenticated-feed\nimage URL.\n\nFor an app-managed worktree whose branch name is not `release\u002F*`, set\n`BUILD_SOURCEBRANCH=refs\u002Fheads\u002Frelease\u002FN.N` in the update process alongside those\noverrides. This supplies the existing branch-resolution context without renaming\nor switching the worktree. Do not set these variables globally. Review the\nresolved source and version before regeneration; C# and TypeScript generators\nconsume the resulting catalog's exact versions.\n\n## Step-by-Step Process\n\n### 1. Run the update script\n\nFetch the latest package data from the configured package feeds:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend update:integrations\n```\n\nThis writes updated package metadata to `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json`. The script queries the NuGet v3 API for packages matching `owner:aspire`, `Aspire.Hosting.`, and `CommunityToolkit.Aspire`, then filters out deprecated, unlisted, and excluded packages.\n\nIt also removes documentation mappings for Aspire and Community Toolkit packages absent from the updated catalog. Manually curated third-party mappings are preserved, and new documentation URLs still require manual resolution.\n\nOn `release\u002F*` branches, the script queries the branch-specific official Aspire feed for `Aspire.*` packages and continues to query nuget.org for `CommunityToolkit.Aspire.*` packages.\n\n### 2. Read the updated package data\n\nLoad `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Faspire-integrations.json` and extract all package names from the `title` field of each entry in the JSON array.\n\n### 3. Update integration documentation mappings\n\nLoad `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fintegration-docs.json` and reconcile it with the package list:\n\n- **For each package name** (from `title` field) in `aspire-integrations.json`:\n  - Check if a matching entry exists in `integration-docs.json` (where `match` equals the package name)\n  - If an entry exists, verify the `href` is correct\n  - If no entry exists, determine the appropriate documentation URL\n\n- **Remove stale entries** for catalog-managed Aspire and Community Toolkit packages no longer in `aspire-integrations.json`. Preserve mappings for third-party packages outside the catalog's sources.\n\n- **Preserve existing correct mappings** — do not change entries that are already accurate\n\n### 4. Determining documentation URLs\n\nWhen a package has no existing mapping, determine the URL based on:\n\n#### Package name patterns\n\n| Package prefix | Documentation path pattern |\n|---|---|\n| `Aspire.Hosting.Azure.*` | `\u002Fintegrations\u002Fcloud\u002Fazure\u002F{service-name}\u002F` |\n| `Aspire.Azure.*` | `\u002Fintegrations\u002Fcloud\u002Fazure\u002F{service-name}\u002F` |\n| `Aspire.Hosting.{Tech}` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `Aspire.{Client}.{Driver}` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `CommunityToolkit.Aspire.Hosting.*` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n| `CommunityToolkit.Aspire.*` | `\u002Fintegrations\u002F{category}\u002F{tech}\u002F` |\n\n#### Technology categories\n\nThe documentation site organizes integrations into these categories:\n\n| Category path | Technologies |\n|---|---|\n| `\u002Fintegrations\u002Fai\u002F` | OpenAI, Ollama, Milvus, Qdrant |\n| `\u002Fintegrations\u002Fcaching\u002F` | Redis, Valkey, Garnet, Memcached |\n| `\u002Fintegrations\u002Fcloud\u002Fazure\u002F` | All Azure services |\n| `\u002Fintegrations\u002Fcompute\u002F` | Orleans, Dapr |\n| `\u002Fintegrations\u002Fdatabases\u002F` | PostgreSQL, SQL Server, MySQL, MongoDB, Cosmos DB, Oracle, Elasticsearch, Milvus, Qdrant |\n| `\u002Fintegrations\u002Fdatabases\u002Fefcore\u002F` | EF Core variants of database integrations |\n| `\u002Fintegrations\u002Fdevtools\u002F` | Developer tools and utilities |\n| `\u002Fintegrations\u002Fframeworks\u002F` | Framework integrations |\n| `\u002Fintegrations\u002Fmessaging\u002F` | Kafka, RabbitMQ, NATS, Azure Service Bus, Event Hubs |\n| `\u002Fintegrations\u002Fobservability\u002F` | OpenTelemetry, Seq, logging |\n| `\u002Fintegrations\u002Freverse-proxies\u002F` | YARP |\n| `\u002Fintegrations\u002Fsecurity\u002F` | Keycloak, Key Vault |\n\n#### URL resolution strategy\n\n1. Match against existing similar package mappings in `integration-docs.json`\n2. Infer from the package name and technology category\n3. **Verify the page exists** — check the file system under `src\u002Ffrontend\u002Fsrc\u002Fcontent\u002Fdocs\u002F`, then use Playwright CLI to confirm the route renders\n4. If no valid documentation page can be found, flag the package for manual review\n\n### 5. Generate API reference data\n\nAfter updating the integration catalog, regenerate the per-package API reference JSON files. The `generate-package-json.ps1` script automates this:\n\n```bash\ncd src\u002Ftools\u002FPackageJsonGenerator && pwsh .\u002Fgenerate-package-json.ps1\n```\n\nThe script performs the following for every package listed in `aspire-integrations.json`:\n\n1. Resolves the correct package source per package: official Aspire packages use the branch-specific release feed on `release\u002F*`, while Community Toolkit packages continue to use nuget.org.\n2. Queries that package source for the latest stable version (falls back to latest preview if no stable exists).\n3. Downloads the package into the local NuGet cache via `dotnet restore` if not already cached.\n   Provisioning SDK overlays restore with the same-version `Aspire.Hosting`\n   reference to model their AppHost context; other packages retain standalone\n   per-package restore graphs. Dependency errors remain fatal.\n   Restores run in parallel, up to 8 at a time by default (`-Parallelism` changes\n   the limit; `-Sequential` restores one package at a time). A failed `dotnet restore`\n   is attempted up to three times before the package counts as failed.\n4. Selects the best-matching target framework folder (prefers `net10.0`, then `net9.0`, etc.).\n5. Uses Roslyn to analyze the assembly and extract all public types, members, XML docs, and attributes.\n6. Writes a `{Package}.{Version}.json` file to `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`.\n\nAn assembly that opts into an `AspireExportProvider` can expose generated ATS\nAPIs without public C# types. For those assemblies, the generator retains package\nidentity and provenance with `types: []` and `package.hasGeneratedExports: true`.\nThis record feeds TypeScript generation and requires a corresponding TypeScript\nmodule at semantic validation. It does not add an empty C# package to API navigation.\nBuild-only packages without public types or generated-export opt-ins remain explicit skips.\n\nThe generated JSON follows this schema:\n\n```json\n{\n  \"package\": {\n    \"name\": \"Aspire.Hosting.Redis\",\n    \"version\": \"13.1.2\",\n    \"targetFramework\": \"net10.0\"\n  },\n  \"types\": [\n    {\n      \"name\": \"TypeName\",\n      \"fullName\": \"Namespace.TypeName\",\n      \"namespace\": \"Namespace\",\n      \"kind\": \"class\",\n      \"accessibility\": \"public\",\n      \"members\": [ ... ],\n      \"docs\": { ... }\n    }\n  ]\n}\n```\n\nThese files are consumed by the `packages` content collection defined in `src\u002Ffrontend\u002Fsrc\u002Fcontent.config.ts` and used to render API reference pages at `\u002Freference\u002Fapi\u002F{package}\u002F{type}\u002F`.\n\n#### Selective regeneration\n\nTo regenerate API data for specific packages only:\n\n```bash\npwsh .\u002Fgenerate-package-json.ps1 -Packages @(\"Aspire.Hosting.Redis\", \"Aspire.Hosting.PostgreSQL\")\n```\n\n#### Targeting a different framework\n\nTo use a different target framework (e.g. `net10.0`):\n\n```bash\npwsh .\u002Fgenerate-package-json.ps1 -Framework \"net10.0\"\n```\n\n#### Handling failures\n\nThe script reports a summary of successes, failures, and skipped packages. Common reasons for skips or failures:\n\n- Package has no `lib\u002F` folder (meta-packages, build-only packages)\n- No DLLs found for the preferred TFM\n- NuGet API resolution failure\n\nPackages that fail should be investigated individually — they may need a different framework target or may not ship a public API surface.\nBecause restores are retried, a restore failure in the summary usually has a persistent cause, such as a pinned version that's no longer published on the package's feed.\n\nIf an official release feed is required but not yet publicly reachable, rerun with one of the release feed override environment variables set.\n\n### 5a. Generate TypeScript API reference data\n\nAfter updating `aspire-integrations.json`, regenerate the TypeScript API reference JSON files for the hosting packages that expose ATS capabilities:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend update:ts-api\n```\n\nThe companion `generate-ts-api-json.ps1` script reads the generated C# package JSON files in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F`, selects `Aspire.Hosting`, `Aspire.Hosting.*`, and `CommunityToolkit.Aspire.Hosting.*` packages, and passes each package\u002Fversion through to `aspire sdk dump`. This keeps `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F` aligned with the same package set and versions that already flowed through C# API generation.\n\nRadius versions exporting the generic `IDotnetProgramResource` overload are\nscanned with `Aspire.Hosting.Dotnet` as supporting context. Its exact version\ncomes from the generated C# metadata, so the scanner can retain the export on\n`DotnetProjectResource` while the concrete overload serves legacy project\nresources. Generate the Dotnet module first when regenerating Radius selectively.\nThe transformer excludes core and supporting APIs using their generated modules;\nit preserves Radius's real capability IDs and expanded receiver targets.\nA scanner collision that removes the generic export must be fixed upstream,\nnot hidden by changing the C# metadata or weakening API-reference validation.\n\nFor generated-export overlays, the script also obtains the matching\n`aspire sdk export --language typescript` document. Referenced SDK enum definitions\nmissing from the raw dump are taken from that canonical export, with package identity\nand unambiguous ownership checks. Union members are preserved during transformation;\nmissing or unsupported enum definitions fail generation rather than becoming empty\ninterface stubs. Semantic validation checks enum members in the final Twoslash bundle.\nThe bundle represents enums as string unions with companion constant objects.\nWhen independent packages export the same enum short name, the shared bundle\ncombines their literals; each package's API JSON retains its exact enum surface.\nUse the package-specific SDK to validate behavior that depends on those differences.\nThe generator rejects nonzero SDK dump exits and error diagnostics even when a JSON\nfile was produced. An incomplete dump isn't a successful API-generation result.\nThe one exception is a known scanner defect: a method inherited by several proxy\ntypes is exported once per derived type under the base type's capability ID, and the\nscanner reports each collision as a `Duplicate capability` error. When a dump exits\nnonzero after writing its JSON, the script passes `--tolerate-known-scanner-diagnostics`\nto the transformer, which accepts only that diagnostic shape, and only when the dump's\n`HandleTypes` show that each defining type is, or derives from, the type that owns the\ncapability ID. Any other error diagnostic, or a nonzero exit without one, still fails the\npackage. The script lists tolerated diagnostics in its summary, and\n`update-integration-data.ps1` raises a CI warning and lists the affected packages in the\npull request body. Remove the tolerance\nonce the shipped Aspire CLI includes [microsoft\u002Faspire#20443](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fpull\u002F20443).\n\nPackages are generated in waves: `Aspire.Hosting` first, then packages that don't need\nsupporting scan context, then packages that do. Packages in a wave run concurrently,\nup to 8 at a time by default; set `ASPIRE_TS_API_PARALLELISM` to change the limit (`1`\nprocesses one package at a time). `-AspireRepoPath` runs always process one package at\na time because they build shared repo projects. Each `aspire` CLI call is limited to 10\nminutes and each helper tool call to 5 minutes. A dump or export that fails without\nproducing a result, for example after a timeout or a transient restore failure, is\nattempted up to three times.\n\nWhen a TypeScript module is regenerated for a new package version, stale `ts-modules` JSON files for older versions of that same package are deleted automatically. Regenerated modules with no functions or types are omitted from `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fts-modules\u002F`.\n\nAfter the JSON is refreshed, `update-ts-api` automatically chains `generate-twoslash-types.ts` to rebuild `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts`. This bundle is source-controlled and its diff must be committed alongside the `ts-modules` JSON changes — without it, docs hover tooltips fall back to `any`. If you only need to refresh the bundle (e.g. after a generator script change) without running the full SDK dump, use:\n\n```bash\ncd src\u002Ffrontend && bun run twoslash-types\n```\n\n### 6. Verify all links\n\nFor every entry in the updated `integration-docs.json`:\n\n- **Site-relative links** must end with a trailing `\u002F`\n- **External links** (e.g., AWS docs) are allowed and should use full URLs\n- **All site-relative links must point to existing documentation pages** — check by verifying a corresponding `.mdx` file exists under `src\u002Ffrontend\u002Fsrc\u002Fcontent\u002Fdocs\u002F`\n\nDo not assume a page exists without verification.\n\n### 7. Save the result\n\nWrite the updated `integration-docs.json` maintaining consistent formatting (2-space indentation, trailing newline). The API reference JSON files in `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Fpkgs\u002F` are written directly by the generation script and require no additional save step.\n\nRun the structured-data tests after changing the catalog or documentation map:\n\n```bash\nbun run --cwd .\u002Fsrc\u002Ffrontend test:unit:structured-data\n```\n\n## Entry format\n\nEach entry in `integration-docs.json` follows this structure:\n\n```json\n{\n  \"match\": \"Aspire.Hosting.Redis\",\n  \"href\": \"\u002Fintegrations\u002Fcaching\u002Fredis\u002Fredis-get-started\u002F\"\n}\n```\n\n- `match` — The exact NuGet package name (from the `title` field in `aspire-integrations.json`)\n- `href` — A site-relative path (with trailing `\u002F`) or an external URL\n\n## Handling unmapped packages\n\nWhen a package name has no clear documentation mapping:\n\n1. **Do not invent a URL** — only use paths that correspond to real pages\n2. **List the package** for manual review with a note explaining why no mapping was found\n3. These packages likely need new documentation pages written (hand off to the `doc-writer` skill)\n\n## Example output\n\nAfter running this skill, the agent should report:\n\n- Number of packages in `aspire-integrations.json`\n- Number of mapped entries in `integration-docs.json`\n- Any new mappings added\n- Any stale mappings removed\n- Any packages that could not be mapped (flagged for manual review)\n- Number of API reference JSON files generated (success \u002F failed \u002F skipped)\n- Any packages that failed API generation, with reasons\n- Confirmation that `src\u002Ffrontend\u002Fsrc\u002Fdata\u002Ftwoslash\u002Faspire.d.ts` was refreshed (and that the diff will be committed)\n",{"name":45,"description":46},"update-integrations","Update integration documentation links and API reference data by synchronizing NuGet package names with their documentation URLs and generating per-package API schemas. Use when adding new integrations, refreshing package data, ensuring integration-docs.json stays in sync with aspire-integrations.json, or regenerating API reference JSON files.","main","f05f5561b1b858344124cd848ff06469627d7e6e",".agents\u002Fskills\u002Fopenspec-oneshot",315,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway","https:\u002F\u002Fcauseway.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-14 03:20:17",{"source":8,"skillName":45,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add apache\u002Fcauseway --skill update-integrations",{"tool":62,"command":63},"bunx","bunx skills add apache\u002Fcauseway --skill update-integrations",{"tool":65,"command":66},"pnpm","pnpm dlx skills add apache\u002Fcauseway --skill update-integrations","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-oneshot\u002FSKILL.md",true,[],[71,93,104,126,142,150],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":40},"01M6ACKQK07AJ62E010HJHGKZK","openspec-update-change","Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-update-change\u002FSKILL.md",[],[78,79,80,21,31,81,82,83,33,84,85,86,22,87,88,89,90,91,23,92],"change","update","openspec update change","code","planning","artifacts","plan","decisions","edit","never","Fold","coherent","with","Existing","new",{"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":40},"01M6ACKND59G6M6XBHZ6KCBDY1","openspec-sync-specs","Sync delta specs from a change to main specs. Use when the user wants to update main specs with changes from a delta spec, without archiving the change.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-sync-specs\u002FSKILL.md",[],[37,100,21,31,39,78,79,33,101,22,102,47,90,103,23],"openspec sync specs","user","delta","changes",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":115,"publishedAt":40},"01M6ACKJMA9K21YE9K5T1P6NRD","openspec-propose","Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-propose\u002FSKILL.md",[110],{"categoryNo":111,"categoryName":112,"taxonomyType":113,"taxonomyTypeDesc":114},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",[116,21,117,31,78,118,83,33,119,22,120,121,122,123,124,26,90,125,23,92],"openspec propose","design","tasks","generated","ready","implementation","build","get","complete","for",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":132,"publishedAt":40},"01M6ACKE3GGEV3TMM2THTQW8EB","openspec-explore","Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-explore\u002FSKILL.md",[],[133,134,21,31,78,33,101,22,135,136,137,138,139,140,141,125,23],"openspec explore","explore","think","thinking partner","thinking","ideas","requirements","partner","mode",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":40},"01M6ACKBVG2GT4C6KEV08TT8FH","openspec-archive-change","Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-archive-change\u002FSKILL.md",[],[78,149,32,21,31,38,33,101,22,121,124,23],"openspec archive change",{"skillNo":151,"name":152,"nameZh":6,"description":153,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":154,"categories":155,"keywords":156,"publishedAt":40},"01M6ACK92XEZ17W30MKC1RPP8T","openspec-apply-change","Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fcauseway\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fopenspec-apply-change\u002FSKILL.md",[],[78,157,21,158,159,31,160,118,161,33,162,163,101,22,121,164,23],"openspec apply change","openspec apply","apply","implement","start","continue","work","implementing"]