[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HDMDCMMBTXTWKBVGJM0615":3,"skill-same:01M6HDMDCMMBTXTWKBVGJM0615":123},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":51,"linkOnly":52,"markdownContent":53,"markdownBody":54,"frontMatter":55,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":63,"ownerHtmlUrl":64,"ownerBlogUrl":65,"ownerDescription":66,"updatedAt":67,"install":68,"resources":80},"01M6HDMDCMMBTXTWKBVGJM0615","aspireify",null,"**WORKFLOW SKILL** - Wire Aspire AppHosts or repair TypeScript AppHost toolchains. Scans the repo, proposes a resource graph, edits C#, file-based C#, or TypeScript AppHosts, wires ServiceDefaults + OTel, validates with `aspire start`, then stops. USE FOR: wire\u002Fscaffold AppHost, add Postgres\u002FRedis\u002FRabbit\u002FMongo, connect frontend to API, after `aspire init`, AddNextJsApp, AddViteApp, WithBrowserLogs, Interaction Service, command arguments, apphost.cs, apphost.mts, unified withEnvironment, .aspire\u002Fmodules refusal, config\u002Fsecrets, TS dependency restore, pnpm\u002Fyarn\u002Fbun, or Yarn Classic. DO NOT USE FOR: skeleton drop (aspire-init), lifecycle-only start\u002Fstop\u002Fwait\u002Frestart or `aspire update --migrate` (aspire-orchestration), publish\u002Fdeploy\u002Fdestroy (aspire-deployment), logs\u002Ftraces (aspire-monitoring), terminal authoring or automation (aspire-terminals). INVOKES: aspire CLI, AppHost source edits, ServiceDefaults wiring. FOR SINGLE OPERATIONS: Run `aspire add PACKAGE` directly for a one-off integration.","microsoft\u002Faspire-skills","microsoft","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F6154722?v=4","01M698VYDXZ6JW5WH3CRV650R8","Microsoft","01M699Z09A17E8C731AGNTAEVR",94,"MIT","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[5,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50],"monitoring","wait","interaction","authoring","pnpm","stop","modules","command","migrate","start","frontend","logs","yarn","update","run","connect","config","typescript","terminal","2026-11-10 10:12:30",false,"---\nname: aspireify\ndescription: >-\n  **WORKFLOW SKILL** - Wire Aspire AppHosts or repair TypeScript AppHost toolchains.\n  Scans the repo, proposes a resource graph, edits C#, file-based C#, or TypeScript\n  AppHosts, wires ServiceDefaults + OTel, validates with `aspire start`, then stops.\n  USE FOR: wire\u002Fscaffold AppHost, add Postgres\u002FRedis\u002FRabbit\u002FMongo, connect frontend\n  to API, after `aspire init`, AddNextJsApp, AddViteApp, WithBrowserLogs,\n  Interaction Service, command arguments, apphost.cs, apphost.mts, unified\n  withEnvironment, .aspire\u002Fmodules refusal, config\u002Fsecrets,\n  TS dependency restore, pnpm\u002Fyarn\u002Fbun, or Yarn Classic.\n  DO NOT USE FOR: skeleton drop (aspire-init), lifecycle-only start\u002Fstop\u002Fwait\u002Frestart\n  or `aspire update --migrate` (aspire-orchestration), publish\u002Fdeploy\u002Fdestroy\n  (aspire-deployment), logs\u002Ftraces (aspire-monitoring), terminal authoring or\n  automation (aspire-terminals).\n  INVOKES: aspire CLI, AppHost source edits, ServiceDefaults wiring.\n  FOR SINGLE OPERATIONS: Run `aspire add PACKAGE` directly for a one-off integration.\nlicense: MIT\nmetadata:\n  author: Microsoft\n  version: \"0.0.5\"\n---\n\n# Aspireify\n\n> **One-time wiring skill.** `aspire init` drops a skeleton; `aspireify` turns\n> that skeleton into a working AppHost by scanning the repo, proposing a resource\n> graph, editing the AppHost, wiring `Aspire.ServiceDefaults`, and validating end\n> to end. Self-deactivates after a clean `aspire start`.\n\n## ? Hard Refusal: Never Edit `.aspire\u002Fmodules\u002F`\n\n> ⛔ **REFUSE** any request to edit, modify, change, open-for-edit, or \"tweak\" files\n> inside `.aspire\u002Fmodules\u002F` of a TypeScript AppHost. This directory is **generated** from\n> the installed Aspire integration package graph. It is regenerated by `aspire add`,\n> `aspire restore`, and startup when package changes require it.\n>\n> If a user asks to edit something in `.aspire\u002Fmodules\u002F` (e.g., `.aspire\u002Fmodules\u002Fpostgres.module.ts`),\n> the correct response is:\n>\n> 1. **Refuse the edit** with a clear \"I won't edit `.aspire\u002Fmodules\u002F`\" statement.\n> 2. **Explain** that `.aspire\u002Fmodules\u002F` is generated and any changes are clobbered.\n> 3. **Redirect** the requested change to the configured AppHost entry point:\n>    current `apphost.mts`, or legacy `apphost.ts`.\n> 4. If the user wants a new integration, suggest `aspire add \u003Cpackage>`; if they want\n>    to change configuration, show the equivalent edit in the AppHost entry point.\n\n| ❌ Wrong | ✅ Right |\n|----------|---------|\n| Open `.aspire\u002Fmodules\u002Fpostgres.module.ts` and tweak the connection options | Edit `apphost.mts` and change `addPostgres('pg', { ... })` options there |\n| Modify a generated `.aspire\u002Fmodules\u002F*` file directly | Re-run `aspire add \u003Cpackage>` after updating `apphost.mts` |\n| Comment out a line in `.aspire\u002Fmodules\u002F` to disable a resource | Remove or guard the resource declaration in `apphost.mts` |\n\nThis rule applies even if the user insists, even for \"one-line\" changes, even for\n\"just to test something.\" The TS AppHost regenerates `.aspire\u002Fmodules\u002F` deterministically;\nedits are unrecoverable noise.\n\n## Guiding Principles\n\n### Minimize changes to the user's code\n\nAdapt the AppHost to fit the app, not the other way around. Prefer `WithEnvironment()`\nto match existing environment variable names, Aspire-managed ports over fixed ports,\nand 1:1 Docker Compose mapping before optimizing. Do not restructure directories,\nrename files, or change build scripts unless the user explicitly chooses that tradeoff.\n\n### Surface tradeoffs; do not decide silently\n\nWhen a small code change unlocks better Aspire integration, present both options:\nthe zero-code-change mapping and the small-change version that enables `WithReference`,\nhealth checks, service discovery, dynamic ports, or dashboard telemetry. Ask which\napproach the user wants, then implement that choice without complaint.\n\n### Verify APIs before writing AppHost code\n\nUse `aspire docs search \u003Ctopic>` and `aspire docs get \u003Cslug>` for workflow guidance.\nUse `aspire docs api search \u003Cquery> --language csharp|typescript` and\n`aspire docs api get \u003Cid>` for API shape. Use `aspire integration list\u002Fsearch` to\nfind integrations before `aspire add`. Do not invent packages, methods, overloads,\nor command shapes; C# and TypeScript AppHost APIs differ.\n\n### Keep configuration visible in the AppHost\n\nScan `.env`, `.env.local`, `.env.development`, `secrets.json.example`,\n`\u003CUserSecretsId>`, and setup scripts. Propose migrating values into AppHost parameters:\nconnection strings become Aspire resources, API keys\u002Ftokens become secret parameters,\nand non-secret config becomes plain parameters or `WithEnvironment()` values. Never\ndelete `.env` files or remove existing `UserSecretsId` entries without explicit user\napproval because non-Aspire workflows may still depend on them.\n\n### Local development first\n\nThis skill optimizes local development, not production deployment. Prefer persistent\ncontainer lifetimes and data volumes for databases\u002Fcaches, use HTTPS endpoints by\ndefault, pass endpoint references instead of hardcoded URLs, and model external SaaS\nURLs\u002FAPI keys as parameters so they are visible in the dashboard.\n\n### Redis TLS edge case\n\nAspire can automatically provision TLS certificates for container resources. If Redis\nhealth checks fail with SSL\u002FTLS handshake errors, do not fall back to `AddContainer()`.\nUse `WithoutHttpsCertificate()` on the Redis resource when the consuming app expects\nplain Redis.\n\n## Project-Local Override\n\nIf `.agents\u002Fskills\u002Faspireify\u002FSKILL.md` exists (installed by `aspire init` or\n`aspire agent init --skills aspireify`), **warn the user** that a project-local\ncopy is present and **defer to it**. The plugin version is the fallback.\n\n```\n⚠️ Project-local .agents\u002Fskills\u002Faspireify\u002FSKILL.md detected — deferring to it.\n```\n\n## Prerequisites\n\n| Requirement | Install |\n|-------------|---------|\n| .NET 10.0 SDK (C# AppHost) | https:\u002F\u002Fdotnet.microsoft.com\u002Fdownload |\n| Node.js `^20.19.0`, `^22.13.0`, or `>=24` (TS AppHost) | https:\u002F\u002Fnodejs.org |\n| Aspire CLI | `npm install -g @microsoft\u002Faspire-cli`, install script, or `dotnet tool install -g Aspire.Cli` |\n| Skeleton already dropped | `aspire init` produced `aspire.config.json` + AppHost stub |\n\n## Detection — When to Activate\n\nActivate when ANY signal is present **AND** the AppHost is unwired (no resources\ndeclared beyond the stub):\n\n| Signal | How to Detect | Confidence |\n|--------|---------------|------------|\n| Skeleton just dropped | `aspire init` just ran in this session | ✅ Definitive |\n| Empty AppHost stub | `apphost.cs` \u002F `Program.cs` \u002F current `apphost.mts` (or legacy `apphost.ts`) only contains `Build().Run()` | ✅ Definitive |\n| `aspire.config.json` without resources | Config present, AppHost has no `AddProject`\u002F`addProject` | High |\n| User asks to \"wire\" \u002F \"scaffold resource graph\" | Verb match: wire, scaffold, integrate, hook up, add Postgres\u002FRedis\u002Fetc. | High |\n| User asks \"what next after aspire init\" | Direct handoff request | ✅ Definitive |\n| Existing repo with services + new AppHost | Repo has `.csproj`\u002F`package.json` projects but AppHost references none | High |\n\nIf the AppHost already has wired resources and the user wants to **start\u002Fstop**\nthe app → `aspire-orchestration`. If the user wants to **deploy** → `aspire-deployment`.\n\n## Language Support\n\n| AppHost Style | Detection | Edit Target |\n|---------------|-----------|-------------|\n| **C# SDK-style** | `.csproj` containing `\u003CSdk Name=\"Aspire.AppHost.Sdk\" \u002F>` | `Program.cs` (top-level statements) |\n| **File-based C#** | `apphost.cs` with `#:sdk Aspire.AppHost.Sdk` and `#:package` directives | `apphost.cs` itself |\n| **TypeScript** | Current `apphost.mts` or legacy `apphost.ts` with generated `.aspire\u002Fmodules\u002F` | Configured AppHost entry point only — **never edit `.aspire\u002Fmodules\u002F`** |\n\nSee [references\u002Fcsharp-authoring.md](references\u002Fcsharp-authoring.md) and\n[references\u002Ftypescript-authoring.md](references\u002Ftypescript-authoring.md).\n\n`aspire-orchestration` owns the CLI-driven migration from legacy `apphost.ts`. After it\nupdates packages and migration artifacts, return to aspireify only when the user still\nneeds AppHost source wiring or authoring.\n\n### TypeScript AppHost package managers\n\nDependency and toolchain failures belong to this skill. Before recommending a command,\ninspect the AppHost directory and then its immediate eligible parent. Within each directory,\nthe first recognized marker wins in this order:\n\n1. `packageManager` in `package.json` (`npm`, `pnpm`, `yarn`, or `bun`, optionally versioned)\n2. `bun.lock`\n3. `bun.lockb`\n4. `pnpm-lock.yaml`\n5. `yarn.lock`\n6. `.yarnrc.yml`\n7. `package-lock.json`\n\nAn AppHost-local marker takes precedence over every parent marker. If neither directory has\na recognized marker, Aspire defaults to npm. Report the selected manager and marker.\n\nUse the selected manager only to repair dependencies or diagnose the toolchain. The resolver\ncommands are `npm install`, `bun install`, and `yarn install`; a generated brownfield pnpm\nAppHost uses `pnpm install --ignore-workspace`, while other pnpm dependency installs use\n`pnpm install`. Yarn Classic (`yarn@1...` or a v1 lockfile) is unsupported: stop and ask the\nuser to upgrade to Yarn 4+ or explicitly migrate to npm, pnpm, or Bun.\n\nDo not change `packageManager` or create, replace, or regenerate a lockfile merely to\ninfluence detection or switch managers. Preserve existing files until the user explicitly\nchooses an upgrade or migration. Start the AppHost with `aspire start --non-interactive`,\nnot a raw package-manager launcher. See\n[references\u002Ftypescript-authoring.md](references\u002Ftypescript-authoring.md) for the full\ncommand matrix and resolver details.\n\n## Workflow Phases\n\n```\n1. SCAN     → discover projects, services, dependencies, integration candidates\n2. PROPOSE  → resource graph + integration list, confirm with user\n3. EDIT     → wire AppHost, add ServiceDefaults + OTel + health checks\n4. VALIDATE → aspire start --non-interactive → aspire wait \u003Ceach resource>\n5. DEACTIVATE → confirm clean start, hand off to aspire-orchestration\n```\n\nFor the detailed, upstream-parity workflow, load these references before editing:\n\n- [apphost-wiring.md](references\u002Fapphost-wiring.md) — full AppHost wiring workflow, API lookup, endpoint\u002Fparameter patterns, validation, solution updates, and cleanup.\n- [docker-compose.md](references\u002Fdocker-compose.md) — docker-compose migration, profiles, image mapping, ports, volumes, and `depends_on`.\n- [full-solution-apphosts.md](references\u002Ffull-solution-apphosts.md) — large solution triage, mixed SDK boundaries, solution membership, ServiceDefaults placement, and legacy host migration.\n- [javascript-apps.md](references\u002Fjavascript-apps.md) — JavaScript resource selection, workspace\u002Fmonorepo package-manager handling, ports, scripts, and TS AppHost package config.\n- [opentelemetry.md](references\u002Fopentelemetry.md) — optional Node.js, Python, and Go OpenTelemetry wiring for non-.NET services.\n\n### 1. Scan\n\nWalk the repo and inventory:\n\n| What | How |\n|------|-----|\n| .NET projects | `find . -name '*.csproj' -not -path '*\u002Fbin\u002F*' -not -path '*\u002Fobj\u002F*'` |\n| Node services | `find . -name 'package.json' -not -path '*\u002Fnode_modules\u002F*'` |\n| Python services | `find . -name 'pyproject.toml' -o -name 'requirements.txt'` |\n| Container deps in compose | `docker-compose.yml`, `compose.yaml` (Postgres? Redis? Rabbit?) |\n| Connection strings | grep `appsettings*.json`, `.env*`, `config\u002F*` for `Postgres`, `Redis`, `Mongo`, `RabbitMQ`, `Cosmos`, `ServiceBus` |\n| Integration packages | `dotnet list package` per project; package.json `dependencies` |\n| Existing endpoints | hardcoded ports in `launchSettings.json`, `next.config.js`, `vite.config.ts` |\n\nFull heuristics in [references\u002Fscan-and-propose.md](references\u002Fscan-and-propose.md).\n\n### 2. Propose\n\nPresent a resource graph **before editing**. Ask clarifying questions:\n\n- \"I see Postgres in `docker-compose.yml` — should I model it as `AddPostgres('db')` or use Azure Database for PostgreSQL?\"\n- \"Your React app hardcodes `http:\u002F\u002Flocalhost:5000` — replace with Aspire service discovery (`endpoint.url`)?\"\n- \"Your API has an `\u002Fadmin` endpoint — exclude it from `WithReference()` so consumers don't see it?\"\n\n### 3. Edit\n\nApply the proposed graph. Use the right authoring style for the AppHost language.\n\n### 4. Validate\n\n```bash\naspire start --non-interactive --format Json\naspire wait \u003Cresource>          # repeat for each declared resource\naspire describe --format Json   # sanity check graph\n```\n\nFull validation flow + recovery in [references\u002Fvalidation.md](references\u002Fvalidation.md).\n\n### 5. Self-Deactivate\n\nAfter a clean `aspire start`, announce:\n\n```\n✅ AppHost wired and validated. Handing off to aspire-orchestration for\n   day-to-day start\u002Fstop\u002Fwait. Aspireify is done.\n```\n\n## Integration Discovery Catalog\n\nMap detected services → Aspire integrations. See\n[references\u002Fscan-and-propose.md](references\u002Fscan-and-propose.md) for the full\ncatalog.\n\n| Detected | C# | TS |\n|----------|----|----|\n| Postgres in compose \u002F `Npgsql` package | `AddPostgres(\"pg\").AddDatabase(\"db\")` | `addPostgres('pg').addDatabase('db')` |\n| Redis in compose \u002F `StackExchange.Redis` | `AddRedis(\"cache\")` | `addRedis('cache')` |\n| RabbitMQ | `AddRabbitMQ(\"mq\")` (v7 client w\u002F pub-sub tracing) | `addRabbitMQ('mq')` |\n| MongoDB | `AddMongoDB(\"mongo\")` | `addMongoDB('mongo')` |\n| Cosmos DB | `AddAzureCosmosDB(\"cosmos\")` | `addAzureCosmosDB('cosmos')` |\n| Azure Service Bus | `AddAzureServiceBus(\"sb\")` | `addAzureServiceBus('sb')` |\n| Azure Cache for Redis (Entra) | `AddAzureRedis(\"cache\")` (now GA) | `addAzureRedis('cache')` |\n| Next.js frontend | `AddNextJsApp(\"web\", \".\u002Fweb\")` | `addNextJsApp('web', '..\u002Fweb')` |\n| Vite SPA | `AddViteApp(\"web\", \".\u002Fweb\")` | `addViteApp('web', '..\u002Fweb')` |\n| Plain Node app | `AddNodeApp(\"api\", \".\u002Fapi\", \"server.js\")` | `addNodeApp('api', '.\u002Fapi', 'server.js')` |\n\n## Current Authoring Rules\n\n| Rule | Why |\n|------|-----|\n| Use **unified `withEnvironment(name, value)`** in TS — never the deprecated per-kind helpers (`withEnvironmentEndpoint`, `withEnvironmentParameter`, etc.) | Single API handles all value kinds; per-kind helpers are deprecated |\n| Use `AddNextJsApp` \u002F `AddViteApp` over hand-rolled Dockerfiles for JS frontends | First-class lifecycle + `PublishAs*` integration |\n| Use `PublishAsStaticWebsite` \u002F `PublishAsNodeServer` \u002F `PublishAsPackageScript` for JS publish | Replaces hand-rolled Dockerfiles; SPA → static, SSR Node → NodeServer, package-script SSR → PackageScript |\n| Add `WithBrowserLogs()` to frontend resources for browser console + screenshots in dashboard | `Aspire.Hosting.Browsers` surfaces browser telemetry in the dashboard |\n| Bind every resource to a compute environment with `WithComputeEnvironment(env)` when multiple environments exist | Multi-environment deploys require explicit binding |\n| **Never edit `.aspire\u002Fmodules\u002F`** in TS AppHosts | Generated; edits get clobbered. Edit the configured `apphost.mts` (or legacy `apphost.ts`) only |\n| Use `WithEndpoint(\"name\", e => ...)` to update endpoints | Endpoint callbacks update existing endpoints rather than throwing on duplicates |\n| Mark admin endpoints with `ExcludeReferenceEndpoint = true` | Prevents consumers from receiving admin URLs via `WithReference()` |\n| Look up unfamiliar API: `aspire docs api search \u003Cquery> --language csharp\\|typescript` | Don't guess overloads or builder chains |\n| Use context `.Services` \u002F `await ctx.services().getInteractionService()` | `.ServiceProvider` is obsolete, and `ctx.services()` alone returns a services accessor |\n| Use `AddConnectionString` for external connection strings | `PublishAsConnectionString` is obsolete |\n| Check `IInteractionService.IsAvailable` before prompting | CLI-invoked commands may be noninteractive; prefer command arguments for dashboard + CLI input |\n| Route terminal authoring to `aspire-terminals` | Owns `WithTerminal`, `TerminalService`, dock\u002Fdialog\u002Fheadless lifetimes, terminal prompts, REPLs and tapes; nonterminal interactions remain here |\n| Keep all Aspire SDK and `Aspire.Hosting.*` packages on the same release family | Mixed release families can fail at startup |\n| Migrate GitHub Models integrations to Azure AI Foundry | `Aspire.Hosting.GitHub.Models` is deprecated and absent from integration discovery |\n| Use `WithModule(RedisModules.*)` for Redis 8 modules | Prefer typed JSON, Search, Bloom Filter, and TimeSeries constants over raw module paths |\n| Use Foundry `AsHostedAgent(...)` for hosted executable\u002Fcontainer agents | Current Azure AI Foundry path replaces deprecated GitHub Models |\n\n## C# vs TS Quick Reference\n\n| Concept | C# | TypeScript |\n|---------|----|------------|\n| Builder | `var builder = DistributedApplication.CreateBuilder(args);` | `const builder = await createBuilder();` |\n| Add project | `builder.AddProject\u003CProjects.Api>(\"api\")` (SDK) or `AddProject(\"api\", \"..\u002FApi\u002FApi.csproj\")` | `await builder.addProject('api', '..\u002FApi\u002FApi.csproj')` |\n| Wire env var (any value type) | `.WithEnvironment(\"KEY\", value)` | `.withEnvironment('KEY', value)` ← unified API |\n| Wait for dependency | `.WaitFor(db)` | `.waitFor(db)` |\n| Pass connection | `.WithReference(db)` | `.withReference(db)` |\n| External HTTP | `.WithExternalHttpEndpoints()` | `.withExternalHttpEndpoints()` |\n| Endpoint expression | `api.GetEndpoint(\"http\")` | `api.getEndpoint('http').url` \u002F `.host` \u002F `.port` |\n| Build + run | `builder.Build().Run();` | `await builder.build().run();` |\n\n## ServiceDefaults Wiring\n\nEach project should call `builder.AddServiceDefaults();` to opt into OpenTelemetry,\nhealth checks, and service discovery. Add the `Aspire.ServiceDefaults` project\nreference (or NuGet for non-monorepo). See\n[references\u002Fservice-defaults.md](references\u002Fservice-defaults.md).\n\n## Endpoint & Reference Conventions\n\n```csharp\n\u002F\u002F Public-facing API. Mark \"admin\" endpoint as not-for-consumers.\nvar api = builder.AddProject\u003CProjects.Api>(\"api\")\n    .WithExternalHttpEndpoints()\n    .WithEndpoint(\"admin\", e => e.ExcludeReferenceEndpoint = true);\n\n\u002F\u002F Frontend wires the API via service discovery.\nbuilder.AddNextJsApp(\"web\", \".\u002Fweb\")\n    .WithReference(api)        \u002F\u002F injects services__api__http and __https\n    .WaitFor(api)\n    .WithBrowserLogs();        \u002F\u002F browser console + screenshots\n```\n\n## Validation & Recovery\n\n| Symptom | Action |\n|---------|--------|\n| `aspire start` fails with build error | Fix code, re-run `aspire start` |\n| File-lock errors during edit | Hand off to `aspire-orchestration` → `aspire stop` → retry |\n| Resource missing from `aspire describe` | Re-run `aspire describe --include-hidden`; `aspire ps` is AppHost-level |\n| TS AppHost change ignored | Confirm you edited the configured `apphost.mts` (or legacy `apphost.ts`), not `.aspire\u002Fmodules\u002F` |\n| Mixed JSON output from `aspire start` | Strip non-JSON lines before parsing ([#15843](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fissues\u002F15843)) |\n\nFull flow in [references\u002Fvalidation.md](references\u002Fvalidation.md).\n\n## Handoff Rules\n\n| Scenario | Route To |\n|----------|----------|\n| AppHost skeleton not yet dropped | → `aspire-init` skill |\n| Day-to-day start\u002Fstop\u002Fwait\u002Frestart | → `aspire-orchestration` skill |\n| Publish, deploy, destroy, pipeline steps | → `aspire-deployment` skill |\n| Logs, traces, metrics, dashboard, browser log inspection | → `aspire-monitoring` skill |\n| Deployed (Azure\u002FAKS) app diagnostics | → `azure-diagnostics` skill (azure-skills) |\n\n## Key Rules\n\n- **Never overwrite existing files** — always augment or merge.\n- **Ask before modifying service code**, especially OpenTelemetry and ServiceDefaults injection.\n- **Respect existing project structure** — do not reorganize the repo.\n- **If stuck, use `aspire doctor`** to diagnose environment issues.\n- **Never hardcode URLs in `WithEnvironment` \u002F `withEnvironment`** — pass endpoint references such as `api.GetEndpoint(\"http\")` or `api.getEndpoint('http')` instead of string literals.\n- **Never use `WithUrlForEndpoint` \u002F `withUrlForEndpoint` to set `dev.localhost` URLs** — that API is only for dashboard display labels; `dev.localhost` belongs in AppHost launch\u002Fprofile configuration.\n\n## References\n\n- [apphost-wiring.md](references\u002Fapphost-wiring.md) — Detailed AppHost wiring workflow and API lookup patterns\n- [docker-compose.md](references\u002Fdocker-compose.md) — Docker Compose migration patterns\n- [full-solution-apphosts.md](references\u002Ffull-solution-apphosts.md) — Large\u002Ffull-solution AppHost guidance\n- [javascript-apps.md](references\u002Fjavascript-apps.md) — JavaScript\u002FTypeScript app and workspace handling\n- [opentelemetry.md](references\u002Fopentelemetry.md) — Non-.NET OpenTelemetry setup\n- [scan-and-propose.md](references\u002Fscan-and-propose.md) — Repo scan heuristics + integration catalog\n- [csharp-authoring.md](references\u002Fcsharp-authoring.md) — C# AppHost patterns\n- [typescript-authoring.md](references\u002Ftypescript-authoring.md) — TS AppHost patterns + parity APIs\n- [service-defaults.md](references\u002Fservice-defaults.md) — Wire OTel, health checks, service discovery\n- [validation.md](references\u002Fvalidation.md) — End-to-end validation + recovery\n- [aspire-13-5-breaking-changes.md](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire\u002Freferences\u002Faspire-13-5-breaking-changes.md) — Breaking changes introduced in 13.5 and fixes for affected releases\n","# Aspireify\n\n> **One-time wiring skill.** `aspire init` drops a skeleton; `aspireify` turns\n> that skeleton into a working AppHost by scanning the repo, proposing a resource\n> graph, editing the AppHost, wiring `Aspire.ServiceDefaults`, and validating end\n> to end. Self-deactivates after a clean `aspire start`.\n\n## ? Hard Refusal: Never Edit `.aspire\u002Fmodules\u002F`\n\n> ⛔ **REFUSE** any request to edit, modify, change, open-for-edit, or \"tweak\" files\n> inside `.aspire\u002Fmodules\u002F` of a TypeScript AppHost. This directory is **generated** from\n> the installed Aspire integration package graph. It is regenerated by `aspire add`,\n> `aspire restore`, and startup when package changes require it.\n>\n> If a user asks to edit something in `.aspire\u002Fmodules\u002F` (e.g., `.aspire\u002Fmodules\u002Fpostgres.module.ts`),\n> the correct response is:\n>\n> 1. **Refuse the edit** with a clear \"I won't edit `.aspire\u002Fmodules\u002F`\" statement.\n> 2. **Explain** that `.aspire\u002Fmodules\u002F` is generated and any changes are clobbered.\n> 3. **Redirect** the requested change to the configured AppHost entry point:\n>    current `apphost.mts`, or legacy `apphost.ts`.\n> 4. If the user wants a new integration, suggest `aspire add \u003Cpackage>`; if they want\n>    to change configuration, show the equivalent edit in the AppHost entry point.\n\n| ❌ Wrong | ✅ Right |\n|----------|---------|\n| Open `.aspire\u002Fmodules\u002Fpostgres.module.ts` and tweak the connection options | Edit `apphost.mts` and change `addPostgres('pg', { ... })` options there |\n| Modify a generated `.aspire\u002Fmodules\u002F*` file directly | Re-run `aspire add \u003Cpackage>` after updating `apphost.mts` |\n| Comment out a line in `.aspire\u002Fmodules\u002F` to disable a resource | Remove or guard the resource declaration in `apphost.mts` |\n\nThis rule applies even if the user insists, even for \"one-line\" changes, even for\n\"just to test something.\" The TS AppHost regenerates `.aspire\u002Fmodules\u002F` deterministically;\nedits are unrecoverable noise.\n\n## Guiding Principles\n\n### Minimize changes to the user's code\n\nAdapt the AppHost to fit the app, not the other way around. Prefer `WithEnvironment()`\nto match existing environment variable names, Aspire-managed ports over fixed ports,\nand 1:1 Docker Compose mapping before optimizing. Do not restructure directories,\nrename files, or change build scripts unless the user explicitly chooses that tradeoff.\n\n### Surface tradeoffs; do not decide silently\n\nWhen a small code change unlocks better Aspire integration, present both options:\nthe zero-code-change mapping and the small-change version that enables `WithReference`,\nhealth checks, service discovery, dynamic ports, or dashboard telemetry. Ask which\napproach the user wants, then implement that choice without complaint.\n\n### Verify APIs before writing AppHost code\n\nUse `aspire docs search \u003Ctopic>` and `aspire docs get \u003Cslug>` for workflow guidance.\nUse `aspire docs api search \u003Cquery> --language csharp|typescript` and\n`aspire docs api get \u003Cid>` for API shape. Use `aspire integration list\u002Fsearch` to\nfind integrations before `aspire add`. Do not invent packages, methods, overloads,\nor command shapes; C# and TypeScript AppHost APIs differ.\n\n### Keep configuration visible in the AppHost\n\nScan `.env`, `.env.local`, `.env.development`, `secrets.json.example`,\n`\u003CUserSecretsId>`, and setup scripts. Propose migrating values into AppHost parameters:\nconnection strings become Aspire resources, API keys\u002Ftokens become secret parameters,\nand non-secret config becomes plain parameters or `WithEnvironment()` values. Never\ndelete `.env` files or remove existing `UserSecretsId` entries without explicit user\napproval because non-Aspire workflows may still depend on them.\n\n### Local development first\n\nThis skill optimizes local development, not production deployment. Prefer persistent\ncontainer lifetimes and data volumes for databases\u002Fcaches, use HTTPS endpoints by\ndefault, pass endpoint references instead of hardcoded URLs, and model external SaaS\nURLs\u002FAPI keys as parameters so they are visible in the dashboard.\n\n### Redis TLS edge case\n\nAspire can automatically provision TLS certificates for container resources. If Redis\nhealth checks fail with SSL\u002FTLS handshake errors, do not fall back to `AddContainer()`.\nUse `WithoutHttpsCertificate()` on the Redis resource when the consuming app expects\nplain Redis.\n\n## Project-Local Override\n\nIf `.agents\u002Fskills\u002Faspireify\u002FSKILL.md` exists (installed by `aspire init` or\n`aspire agent init --skills aspireify`), **warn the user** that a project-local\ncopy is present and **defer to it**. The plugin version is the fallback.\n\n```\n⚠️ Project-local .agents\u002Fskills\u002Faspireify\u002FSKILL.md detected — deferring to it.\n```\n\n## Prerequisites\n\n| Requirement | Install |\n|-------------|---------|\n| .NET 10.0 SDK (C# AppHost) | https:\u002F\u002Fdotnet.microsoft.com\u002Fdownload |\n| Node.js `^20.19.0`, `^22.13.0`, or `>=24` (TS AppHost) | https:\u002F\u002Fnodejs.org |\n| Aspire CLI | `npm install -g @microsoft\u002Faspire-cli`, install script, or `dotnet tool install -g Aspire.Cli` |\n| Skeleton already dropped | `aspire init` produced `aspire.config.json` + AppHost stub |\n\n## Detection — When to Activate\n\nActivate when ANY signal is present **AND** the AppHost is unwired (no resources\ndeclared beyond the stub):\n\n| Signal | How to Detect | Confidence |\n|--------|---------------|------------|\n| Skeleton just dropped | `aspire init` just ran in this session | ✅ Definitive |\n| Empty AppHost stub | `apphost.cs` \u002F `Program.cs` \u002F current `apphost.mts` (or legacy `apphost.ts`) only contains `Build().Run()` | ✅ Definitive |\n| `aspire.config.json` without resources | Config present, AppHost has no `AddProject`\u002F`addProject` | High |\n| User asks to \"wire\" \u002F \"scaffold resource graph\" | Verb match: wire, scaffold, integrate, hook up, add Postgres\u002FRedis\u002Fetc. | High |\n| User asks \"what next after aspire init\" | Direct handoff request | ✅ Definitive |\n| Existing repo with services + new AppHost | Repo has `.csproj`\u002F`package.json` projects but AppHost references none | High |\n\nIf the AppHost already has wired resources and the user wants to **start\u002Fstop**\nthe app → `aspire-orchestration`. If the user wants to **deploy** → `aspire-deployment`.\n\n## Language Support\n\n| AppHost Style | Detection | Edit Target |\n|---------------|-----------|-------------|\n| **C# SDK-style** | `.csproj` containing `\u003CSdk Name=\"Aspire.AppHost.Sdk\" \u002F>` | `Program.cs` (top-level statements) |\n| **File-based C#** | `apphost.cs` with `#:sdk Aspire.AppHost.Sdk` and `#:package` directives | `apphost.cs` itself |\n| **TypeScript** | Current `apphost.mts` or legacy `apphost.ts` with generated `.aspire\u002Fmodules\u002F` | Configured AppHost entry point only — **never edit `.aspire\u002Fmodules\u002F`** |\n\nSee [references\u002Fcsharp-authoring.md](references\u002Fcsharp-authoring.md) and\n[references\u002Ftypescript-authoring.md](references\u002Ftypescript-authoring.md).\n\n`aspire-orchestration` owns the CLI-driven migration from legacy `apphost.ts`. After it\nupdates packages and migration artifacts, return to aspireify only when the user still\nneeds AppHost source wiring or authoring.\n\n### TypeScript AppHost package managers\n\nDependency and toolchain failures belong to this skill. Before recommending a command,\ninspect the AppHost directory and then its immediate eligible parent. Within each directory,\nthe first recognized marker wins in this order:\n\n1. `packageManager` in `package.json` (`npm`, `pnpm`, `yarn`, or `bun`, optionally versioned)\n2. `bun.lock`\n3. `bun.lockb`\n4. `pnpm-lock.yaml`\n5. `yarn.lock`\n6. `.yarnrc.yml`\n7. `package-lock.json`\n\nAn AppHost-local marker takes precedence over every parent marker. If neither directory has\na recognized marker, Aspire defaults to npm. Report the selected manager and marker.\n\nUse the selected manager only to repair dependencies or diagnose the toolchain. The resolver\ncommands are `npm install`, `bun install`, and `yarn install`; a generated brownfield pnpm\nAppHost uses `pnpm install --ignore-workspace`, while other pnpm dependency installs use\n`pnpm install`. Yarn Classic (`yarn@1...` or a v1 lockfile) is unsupported: stop and ask the\nuser to upgrade to Yarn 4+ or explicitly migrate to npm, pnpm, or Bun.\n\nDo not change `packageManager` or create, replace, or regenerate a lockfile merely to\ninfluence detection or switch managers. Preserve existing files until the user explicitly\nchooses an upgrade or migration. Start the AppHost with `aspire start --non-interactive`,\nnot a raw package-manager launcher. See\n[references\u002Ftypescript-authoring.md](references\u002Ftypescript-authoring.md) for the full\ncommand matrix and resolver details.\n\n## Workflow Phases\n\n```\n1. SCAN     → discover projects, services, dependencies, integration candidates\n2. PROPOSE  → resource graph + integration list, confirm with user\n3. EDIT     → wire AppHost, add ServiceDefaults + OTel + health checks\n4. VALIDATE → aspire start --non-interactive → aspire wait \u003Ceach resource>\n5. DEACTIVATE → confirm clean start, hand off to aspire-orchestration\n```\n\nFor the detailed, upstream-parity workflow, load these references before editing:\n\n- [apphost-wiring.md](references\u002Fapphost-wiring.md) — full AppHost wiring workflow, API lookup, endpoint\u002Fparameter patterns, validation, solution updates, and cleanup.\n- [docker-compose.md](references\u002Fdocker-compose.md) — docker-compose migration, profiles, image mapping, ports, volumes, and `depends_on`.\n- [full-solution-apphosts.md](references\u002Ffull-solution-apphosts.md) — large solution triage, mixed SDK boundaries, solution membership, ServiceDefaults placement, and legacy host migration.\n- [javascript-apps.md](references\u002Fjavascript-apps.md) — JavaScript resource selection, workspace\u002Fmonorepo package-manager handling, ports, scripts, and TS AppHost package config.\n- [opentelemetry.md](references\u002Fopentelemetry.md) — optional Node.js, Python, and Go OpenTelemetry wiring for non-.NET services.\n\n### 1. Scan\n\nWalk the repo and inventory:\n\n| What | How |\n|------|-----|\n| .NET projects | `find . -name '*.csproj' -not -path '*\u002Fbin\u002F*' -not -path '*\u002Fobj\u002F*'` |\n| Node services | `find . -name 'package.json' -not -path '*\u002Fnode_modules\u002F*'` |\n| Python services | `find . -name 'pyproject.toml' -o -name 'requirements.txt'` |\n| Container deps in compose | `docker-compose.yml`, `compose.yaml` (Postgres? Redis? Rabbit?) |\n| Connection strings | grep `appsettings*.json`, `.env*`, `config\u002F*` for `Postgres`, `Redis`, `Mongo`, `RabbitMQ`, `Cosmos`, `ServiceBus` |\n| Integration packages | `dotnet list package` per project; package.json `dependencies` |\n| Existing endpoints | hardcoded ports in `launchSettings.json`, `next.config.js`, `vite.config.ts` |\n\nFull heuristics in [references\u002Fscan-and-propose.md](references\u002Fscan-and-propose.md).\n\n### 2. Propose\n\nPresent a resource graph **before editing**. Ask clarifying questions:\n\n- \"I see Postgres in `docker-compose.yml` — should I model it as `AddPostgres('db')` or use Azure Database for PostgreSQL?\"\n- \"Your React app hardcodes `http:\u002F\u002Flocalhost:5000` — replace with Aspire service discovery (`endpoint.url`)?\"\n- \"Your API has an `\u002Fadmin` endpoint — exclude it from `WithReference()` so consumers don't see it?\"\n\n### 3. Edit\n\nApply the proposed graph. Use the right authoring style for the AppHost language.\n\n### 4. Validate\n\n```bash\naspire start --non-interactive --format Json\naspire wait \u003Cresource>          # repeat for each declared resource\naspire describe --format Json   # sanity check graph\n```\n\nFull validation flow + recovery in [references\u002Fvalidation.md](references\u002Fvalidation.md).\n\n### 5. Self-Deactivate\n\nAfter a clean `aspire start`, announce:\n\n```\n✅ AppHost wired and validated. Handing off to aspire-orchestration for\n   day-to-day start\u002Fstop\u002Fwait. Aspireify is done.\n```\n\n## Integration Discovery Catalog\n\nMap detected services → Aspire integrations. See\n[references\u002Fscan-and-propose.md](references\u002Fscan-and-propose.md) for the full\ncatalog.\n\n| Detected | C# | TS |\n|----------|----|----|\n| Postgres in compose \u002F `Npgsql` package | `AddPostgres(\"pg\").AddDatabase(\"db\")` | `addPostgres('pg').addDatabase('db')` |\n| Redis in compose \u002F `StackExchange.Redis` | `AddRedis(\"cache\")` | `addRedis('cache')` |\n| RabbitMQ | `AddRabbitMQ(\"mq\")` (v7 client w\u002F pub-sub tracing) | `addRabbitMQ('mq')` |\n| MongoDB | `AddMongoDB(\"mongo\")` | `addMongoDB('mongo')` |\n| Cosmos DB | `AddAzureCosmosDB(\"cosmos\")` | `addAzureCosmosDB('cosmos')` |\n| Azure Service Bus | `AddAzureServiceBus(\"sb\")` | `addAzureServiceBus('sb')` |\n| Azure Cache for Redis (Entra) | `AddAzureRedis(\"cache\")` (now GA) | `addAzureRedis('cache')` |\n| Next.js frontend | `AddNextJsApp(\"web\", \".\u002Fweb\")` | `addNextJsApp('web', '..\u002Fweb')` |\n| Vite SPA | `AddViteApp(\"web\", \".\u002Fweb\")` | `addViteApp('web', '..\u002Fweb')` |\n| Plain Node app | `AddNodeApp(\"api\", \".\u002Fapi\", \"server.js\")` | `addNodeApp('api', '.\u002Fapi', 'server.js')` |\n\n## Current Authoring Rules\n\n| Rule | Why |\n|------|-----|\n| Use **unified `withEnvironment(name, value)`** in TS — never the deprecated per-kind helpers (`withEnvironmentEndpoint`, `withEnvironmentParameter`, etc.) | Single API handles all value kinds; per-kind helpers are deprecated |\n| Use `AddNextJsApp` \u002F `AddViteApp` over hand-rolled Dockerfiles for JS frontends | First-class lifecycle + `PublishAs*` integration |\n| Use `PublishAsStaticWebsite` \u002F `PublishAsNodeServer` \u002F `PublishAsPackageScript` for JS publish | Replaces hand-rolled Dockerfiles; SPA → static, SSR Node → NodeServer, package-script SSR → PackageScript |\n| Add `WithBrowserLogs()` to frontend resources for browser console + screenshots in dashboard | `Aspire.Hosting.Browsers` surfaces browser telemetry in the dashboard |\n| Bind every resource to a compute environment with `WithComputeEnvironment(env)` when multiple environments exist | Multi-environment deploys require explicit binding |\n| **Never edit `.aspire\u002Fmodules\u002F`** in TS AppHosts | Generated; edits get clobbered. Edit the configured `apphost.mts` (or legacy `apphost.ts`) only |\n| Use `WithEndpoint(\"name\", e => ...)` to update endpoints | Endpoint callbacks update existing endpoints rather than throwing on duplicates |\n| Mark admin endpoints with `ExcludeReferenceEndpoint = true` | Prevents consumers from receiving admin URLs via `WithReference()` |\n| Look up unfamiliar API: `aspire docs api search \u003Cquery> --language csharp\\|typescript` | Don't guess overloads or builder chains |\n| Use context `.Services` \u002F `await ctx.services().getInteractionService()` | `.ServiceProvider` is obsolete, and `ctx.services()` alone returns a services accessor |\n| Use `AddConnectionString` for external connection strings | `PublishAsConnectionString` is obsolete |\n| Check `IInteractionService.IsAvailable` before prompting | CLI-invoked commands may be noninteractive; prefer command arguments for dashboard + CLI input |\n| Route terminal authoring to `aspire-terminals` | Owns `WithTerminal`, `TerminalService`, dock\u002Fdialog\u002Fheadless lifetimes, terminal prompts, REPLs and tapes; nonterminal interactions remain here |\n| Keep all Aspire SDK and `Aspire.Hosting.*` packages on the same release family | Mixed release families can fail at startup |\n| Migrate GitHub Models integrations to Azure AI Foundry | `Aspire.Hosting.GitHub.Models` is deprecated and absent from integration discovery |\n| Use `WithModule(RedisModules.*)` for Redis 8 modules | Prefer typed JSON, Search, Bloom Filter, and TimeSeries constants over raw module paths |\n| Use Foundry `AsHostedAgent(...)` for hosted executable\u002Fcontainer agents | Current Azure AI Foundry path replaces deprecated GitHub Models |\n\n## C# vs TS Quick Reference\n\n| Concept | C# | TypeScript |\n|---------|----|------------|\n| Builder | `var builder = DistributedApplication.CreateBuilder(args);` | `const builder = await createBuilder();` |\n| Add project | `builder.AddProject\u003CProjects.Api>(\"api\")` (SDK) or `AddProject(\"api\", \"..\u002FApi\u002FApi.csproj\")` | `await builder.addProject('api', '..\u002FApi\u002FApi.csproj')` |\n| Wire env var (any value type) | `.WithEnvironment(\"KEY\", value)` | `.withEnvironment('KEY', value)` ← unified API |\n| Wait for dependency | `.WaitFor(db)` | `.waitFor(db)` |\n| Pass connection | `.WithReference(db)` | `.withReference(db)` |\n| External HTTP | `.WithExternalHttpEndpoints()` | `.withExternalHttpEndpoints()` |\n| Endpoint expression | `api.GetEndpoint(\"http\")` | `api.getEndpoint('http').url` \u002F `.host` \u002F `.port` |\n| Build + run | `builder.Build().Run();` | `await builder.build().run();` |\n\n## ServiceDefaults Wiring\n\nEach project should call `builder.AddServiceDefaults();` to opt into OpenTelemetry,\nhealth checks, and service discovery. Add the `Aspire.ServiceDefaults` project\nreference (or NuGet for non-monorepo). See\n[references\u002Fservice-defaults.md](references\u002Fservice-defaults.md).\n\n## Endpoint & Reference Conventions\n\n```csharp\n\u002F\u002F Public-facing API. Mark \"admin\" endpoint as not-for-consumers.\nvar api = builder.AddProject\u003CProjects.Api>(\"api\")\n    .WithExternalHttpEndpoints()\n    .WithEndpoint(\"admin\", e => e.ExcludeReferenceEndpoint = true);\n\n\u002F\u002F Frontend wires the API via service discovery.\nbuilder.AddNextJsApp(\"web\", \".\u002Fweb\")\n    .WithReference(api)        \u002F\u002F injects services__api__http and __https\n    .WaitFor(api)\n    .WithBrowserLogs();        \u002F\u002F browser console + screenshots\n```\n\n## Validation & Recovery\n\n| Symptom | Action |\n|---------|--------|\n| `aspire start` fails with build error | Fix code, re-run `aspire start` |\n| File-lock errors during edit | Hand off to `aspire-orchestration` → `aspire stop` → retry |\n| Resource missing from `aspire describe` | Re-run `aspire describe --include-hidden`; `aspire ps` is AppHost-level |\n| TS AppHost change ignored | Confirm you edited the configured `apphost.mts` (or legacy `apphost.ts`), not `.aspire\u002Fmodules\u002F` |\n| Mixed JSON output from `aspire start` | Strip non-JSON lines before parsing ([#15843](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire\u002Fissues\u002F15843)) |\n\nFull flow in [references\u002Fvalidation.md](references\u002Fvalidation.md).\n\n## Handoff Rules\n\n| Scenario | Route To |\n|----------|----------|\n| AppHost skeleton not yet dropped | → `aspire-init` skill |\n| Day-to-day start\u002Fstop\u002Fwait\u002Frestart | → `aspire-orchestration` skill |\n| Publish, deploy, destroy, pipeline steps | → `aspire-deployment` skill |\n| Logs, traces, metrics, dashboard, browser log inspection | → `aspire-monitoring` skill |\n| Deployed (Azure\u002FAKS) app diagnostics | → `azure-diagnostics` skill (azure-skills) |\n\n## Key Rules\n\n- **Never overwrite existing files** — always augment or merge.\n- **Ask before modifying service code**, especially OpenTelemetry and ServiceDefaults injection.\n- **Respect existing project structure** — do not reorganize the repo.\n- **If stuck, use `aspire doctor`** to diagnose environment issues.\n- **Never hardcode URLs in `WithEnvironment` \u002F `withEnvironment`** — pass endpoint references such as `api.GetEndpoint(\"http\")` or `api.getEndpoint('http')` instead of string literals.\n- **Never use `WithUrlForEndpoint` \u002F `withUrlForEndpoint` to set `dev.localhost` URLs** — that API is only for dashboard display labels; `dev.localhost` belongs in AppHost launch\u002Fprofile configuration.\n\n## References\n\n- [apphost-wiring.md](references\u002Fapphost-wiring.md) — Detailed AppHost wiring workflow and API lookup patterns\n- [docker-compose.md](references\u002Fdocker-compose.md) — Docker Compose migration patterns\n- [full-solution-apphosts.md](references\u002Ffull-solution-apphosts.md) — Large\u002Ffull-solution AppHost guidance\n- [javascript-apps.md](references\u002Fjavascript-apps.md) — JavaScript\u002FTypeScript app and workspace handling\n- [opentelemetry.md](references\u002Fopentelemetry.md) — Non-.NET OpenTelemetry setup\n- [scan-and-propose.md](references\u002Fscan-and-propose.md) — Repo scan heuristics + integration catalog\n- [csharp-authoring.md](references\u002Fcsharp-authoring.md) — C# AppHost patterns\n- [typescript-authoring.md](references\u002Ftypescript-authoring.md) — TS AppHost patterns + parity APIs\n- [service-defaults.md](references\u002Fservice-defaults.md) — Wire OTel, health checks, service discovery\n- [validation.md](references\u002Fvalidation.md) — End-to-end validation + recovery\n- [aspire-13-5-breaking-changes.md](https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire\u002Freferences\u002Faspire-13-5-breaking-changes.md) — Breaking changes introduced in 13.5 and fixes for affected releases\n",{"name":5,"license":15,"metadata":56,"description":7},{"author":12,"version":57},"0.0.5","main","1117facb04b403dd2fc15f048bc0e63fc67c502f","opencode\u002Fv1\u002Faspireify",12,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills","https:\u002F\u002Faspire.dev\u002Fget-started\u002Faspire-skills\u002F","https:\u002F\u002Fgithub.com\u002Fmicrosoft","https:\u002F\u002Fopensource.microsoft.com","Open source projects and samples from Microsoft","2026-11-11 08:52:06",{"source":8,"skillName":5,"commands":69,"prompt":78,"zipAvailable":79},[70,73,76],{"tool":71,"command":72},"npx","npx skills add microsoft\u002Faspire-skills --skill aspireify",{"tool":74,"command":75},"bunx","bunx skills add microsoft\u002Faspire-skills --skill aspireify",{"tool":36,"command":77},"pnpm dlx skills add microsoft\u002Faspire-skills --skill aspireify","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002FSKILL.md",true,[81,87,91,95,99,103,107,111,115,119],{"path":82,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":85,"sourceHtmlUrl":86},"references\u002Fapphost-wiring.md","REFERENCE","参考文档",21962,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fapphost-wiring.md",{"path":88,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fcsharp-authoring.md",8330,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fcsharp-authoring.md",{"path":92,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":93,"sourceHtmlUrl":94},"references\u002Fdocker-compose.md",9835,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fdocker-compose.md",{"path":96,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Ffull-solution-apphosts.md",16094,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Ffull-solution-apphosts.md",{"path":100,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fjavascript-apps.md",7609,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fjavascript-apps.md",{"path":104,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fopentelemetry.md",3873,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fopentelemetry.md",{"path":108,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Fscan-and-propose.md",6578,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fscan-and-propose.md",{"path":112,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fservice-defaults.md",4035,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fservice-defaults.md",{"path":116,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Ftypescript-authoring.md",15439,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Ftypescript-authoring.md",{"path":120,"resourceType":83,"resourceTypeDesc":84,"sizeBytes":121,"sourceHtmlUrl":122},"references\u002Fvalidation.md",3291,"https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspireify\u002Freferences\u002Fvalidation.md",[124,147,168,175,194,212],{"skillNo":125,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":132,"publishedAt":51},"01M6HDNG43XGF64N14PV9VGGKB","aspire-terminals","**WORKFLOW SKILL** - Author and automate Aspire terminals. USE FOR: WithTerminal, withTerminal, TerminalService, TerminalLaunchOptions, docked terminals, terminal prompts, PromptTerminalAsync, TerminalPlacement, AspireTerminalKey, WithRepl, withRepl, aspire terminal ps\u002Fattach\u002Ftape play, VHS tapes for Aspire, or terminal screen\u002Finput automation. DO NOT USE FOR: generic shell commands, ordinary AppHost resource wiring (aspireify), start\u002Fstop\u002Fwait (aspire-orchestration), logs\u002Ftraces or browser telemetry (aspire-monitoring), deployment (aspire-deployment), or nonterminal Interaction Service prompts (aspireify). INVOKES: Aspire docs\u002FAPI lookup, AppHost edits, Aspire terminal CLI; aspire-orchestration for lifecycle validation. FOR SINGLE OPERATIONS: Choose the terminal owner and lifetime first, then read the matching reference.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fskills\u002Faspire-terminals\u002FSKILL.md",[130,131],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[133,134,135,50,136,137,5,138,43,32,41,139,140,141,142,143,34,144,145,146],"aspire","aspire terminals","cli","orchestration","workflow","browser","api","choose","read","attach","commands","screen","input","workflow skill",{"skillNo":148,"name":133,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":156,"publishedAt":51},"01M6HDM7MR6SFZHAM32RNM2MKB","**WORKFLOW SKILL** - Aspire router. Detects AppHosts, enforces guardrails, and selects the right sub-skill. USE FOR: Aspire AppHost, Aspire CLI, distributed app, cloud-native .NET, aspire start\u002Fstop\u002Fresource\u002Fdeploy\u002Fdestroy\u002Fpublish\u002Finit\u002Fnew\u002Fadd\u002Fwait\u002Fdescribe\u002Fps\u002Flogs\u002Fotel, aspire agent init, WithBrowserLogs, WithTerminal, TerminalService, terminal prompts, WithRepl, tapes, Interaction Service, apphost.mts, TS package managers, Yarn Classic, custom resource commands, .aspire\u002Fmodules recovery, ProjectResource to DotnetProjectResource migration, or Playwright URL discovery. DO NOT USE FOR: non-Aspire projects or ordinary build\u002Ftest tasks. INVOKES: aspire-init, aspireify, aspire-project-v2-migration, aspire-orchestration, aspire-deployment, aspire-monitoring, aspire-terminals. FOR SINGLE OPERATIONS: Route directly to the matching sub-skill.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire\u002FSKILL.md",[152,155],{"categoryNo":153,"categoryName":154,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[133,136,137,157,5,158,43,32,159,160,161,162,38,163,164,165,34,146,166,167],"init","tasks","publish","Guardrails","projects","router","route","project","app","URL","managers",{"skillNo":169,"name":126,"nameZh":6,"description":127,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":174,"publishedAt":51},"01M6HDM2RMF6Q15YHYTS7G9SWZ","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-terminals\u002FSKILL.md",[172,173],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[133,134,135,50,136,137,5,138,43,32,41,139,140,141,142,143,34,144,145,146],{"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":182,"publishedAt":51},"01M6HDKY1PNCDYBC317440ZHZ0","aspire-project-v2-migration","**WORKFLOW SKILL** - Safely migrates eligible Aspire 13.6+ AppHosts from legacy ProjectResource APIs to experimental DotnetProjectResource APIs after a per-resource assessment and explicit approval of exact edits. USE FOR: assess or migrate existing AddProject, addProject, AddCSharpApp, addCSharpApp, or AddBlazorGateway resources to Project v2; migrate ProjectResource to DotnetProjectResource; clean up the resulting obsolete AppHost ProjectReference edges. DO NOT USE FOR: upgrading Aspire versions, creating\u002Fwiring a new AppHost, Azure Functions migration, generic source modernization, ordinary C# resource wiring or adding a new AddProject resource (use aspireify), publishing, or build\u002Flifecycle diagnostics. INVOKES: Aspire docs\u002FAPI lookup, aspire add\u002Frestore\u002Fstart\u002Fwait, AppHost and package edits. FOR SINGLE OPERATIONS: Assess first; never edit from a generic migration request alone.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-project-v2-migration\u002FSKILL.md",[181],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[133,183,184,164,137,5,185,186,187,41,139,40,188,189,190,191,33,146,192,193],"aspire project v2 migration","migration","diagnostics","modernization","assessment","edit","never","up","clean","resources","source",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":202,"publishedAt":51},"01M6HDKQX187B70G2MK589KWC7","aspire-orchestration","**WORKFLOW SKILL** — Manage Aspire lifecycle in VS Code or the CLI. WHEN: \"start or stop my Aspire app\", \"aspire_apphost_start\", \"aspire_apphost_stop\", \"notEditorOwned\", \"ambiguousSession\", \"aspire start\", \"aspire stop\", \"aspire wait\", resource restart, file-lock errors (MSB3491 or CS2012), port conflicts, git worktrees, \"--isolated\", \"aspire update --self\", \"aspire update --migrate\", \"aspire describe --include-hidden\", \"aspire stop --force\", \"aspire stop --force --volumes\", integration discovery, default watch, or hot reload. INVOKES: VS Code lifecycle tools first when exposed; Aspire CLI for readiness, inspection, resource operations, isolated worktree starts, and allowed fallbacks. DO NOT USE FOR: deploy\u002Fpublish\u002Fdestroy (aspire-deployment), logs\u002Ftraces\u002Fmetrics (aspire-monitoring), terminal authoring\u002Fattach\u002Ftapes (aspire-terminals), or AppHost code and resource wiring (aspireify). FOR SINGLE OPERATIONS: Load the matching editor tool first; follow exact-target, worktree-isolation, and stop-result rules.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-orchestration\u002FSKILL.md",[200,201],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},[136,133,203,137,5,204,43,32,159,40,205,206,207,142,208,165,146,209,210,211],"aspire orchestration","code","git worktrees","default","conflicts","self","port","errors","lock",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":219,"publishedAt":51},"01M6HDKJBBZFF7EWMF0CK0Y2BD","aspire-monitoring","**ANALYSIS SKILL** - Observe Aspire apps: logs, traces, metrics, resource state, telemetry export, browser telemetry, and the standalone dashboard. Routes between local Aspire CLI, AKS workload diagnostics, and deployed Azure resource health. USE FOR: aspire logs, aspire otel logs, aspire otel traces, aspire otel spans, aspire describe, aspire ps, aspire export, aspire dashboard run, describe --include-hidden, browser logs in dashboard, DevTunnel URLs, WithBrowserLogs, App Insights query, AKS pod logs, container app logs. DO NOT USE FOR: start\u002Fstop\u002Fwait (use aspire-orchestration), deploy\u002Fpublish\u002Fdestroy (use aspire-deployment), AppHost code edits like WithBrowserLogs() (use aspireify), Azure provisioning (use azure-prepare), terminal authoring\u002Finput\u002Ftapes (use aspire-terminals). INVOKES: aspire CLI, azure-diagnostics (deployed Azure), kubectl + Container Insights. FOR SINGLE OPERATIONS: Run the aspire CLI command directly for quick log or describe lookups.","https:\u002F\u002Fgithub.com\u002Fmicrosoft\u002Faspire-skills\u002Fblob\u002Fmain\u002Fopencode\u002Fv1\u002Faspire-monitoring\u002FSKILL.md",[218],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[133,220,32,136,5,204,138,43,159,221,222,223,224,225,226,165,227,228,229,230],"aspire monitoring","analysis","log","observe","workload diagnostics","query","local","apps","quick","insights","standalone"]