Aspireify

Aspireify

One-time wiring skill. aspire init drops a skeleton; aspireify turns that skeleton into a working AppHost by scanning the repo, proposing a resource graph, editing the AppHost, wiring Aspire.ServiceDefaults, and validating end to end. Self-deactivates after a clean aspire start.

🚫 Hard Refusal: Never Edit .aspire/modules/

⛔ REFUSE any request to edit, modify, change, open-for-edit, or "tweak" files inside .aspire/modules/ of a TypeScript AppHost. This directory is generated from the installed Aspire integration package graph. It is regenerated by aspire add, aspire restore, and startup when package changes require it.

If a user asks to edit something in .aspire/modules/ (e.g., .aspire/modules/postgres.module.ts), the correct response is:

1. Refuse the edit with a clear "I won't edit .aspire/modules/" statement.
2. Explain that .aspire/modules/ is generated and any changes are clobbered.
3. Redirect the requested change to the configured AppHost entry point: current apphost.mts, or legacy apphost.ts.
4. If the user wants a new integration, suggest aspire add <package>; if they want to change configuration, show the equivalent edit in the AppHost entry point.

This rule applies even if the user insists, even for "one-line" changes, even for "just to test something." The TS AppHost regenerates .aspire/modules/ deterministically; edits are unrecoverable noise.

Guiding Principles

Minimize changes to the user's code

Adapt the AppHost to fit the app, not the other way around. Prefer WithEnvironment() to match existing environment variable names, Aspire-managed ports over fixed ports, and 1:1 Docker Compose mapping before optimizing. Do not restructure directories, rename files, or change build scripts unless the user explicitly chooses that tradeoff.

Surface tradeoffs; do not decide silently

When a small code change unlocks better Aspire integration, present both options: the zero-code-change mapping and the small-change version that enables WithReference, health checks, service discovery, dynamic ports, or dashboard telemetry. Ask which approach the user wants, then implement that choice without complaint.

Verify APIs before writing AppHost code

Use aspire docs search <topic> and aspire docs get <slug> for workflow guidance. Use aspire docs api search <query> --language csharp|typescript and aspire docs api get <id> for API shape. Use aspire integration list/search to find integrations before aspire add. Do not invent packages, methods, overloads, or command shapes; C# and TypeScript AppHost APIs differ.

Keep configuration visible in the AppHost

Scan .env, .env.local, .env.development, secrets.json.example, <UserSecretsId>, and setup scripts. Propose migrating values into AppHost parameters: connection strings become Aspire resources, API keys/tokens become secret parameters, and non-secret config becomes plain parameters or WithEnvironment() values. Never delete .env files or remove existing UserSecretsId entries without explicit user approval because non-Aspire workflows may still depend on them.

Local development first

This skill optimizes local development, not production deployment. Prefer persistent container lifetimes and data volumes for databases/caches, use HTTPS endpoints by default, pass endpoint references instead of hardcoded URLs, and model external SaaS URLs/API keys as parameters so they are visible in the dashboard.

Redis TLS edge case

Aspire can automatically provision TLS certificates for container resources. If Redis health checks fail with SSL/TLS handshake errors, do not fall back to AddContainer(). Use WithoutHttpsCertificate() on the Redis resource when the consuming app expects plain Redis.

Project-Local Override

If .agents/skills/aspireify/SKILL.md exists (installed by aspire init or aspire agent init --skills aspireify), warn the user that a project-local copy is present and defer to it. The plugin version is the fallback.

⚠️ Project-local .agents/skills/aspireify/SKILL.md detected — deferring to it.

Prerequisites

Detection — When to Activate

Activate when ANY signal is present AND the AppHost is unwired (no resources declared beyond the stub):

If the AppHost already has wired resources and the user wants to start/stop the app → aspire-orchestration. If the user wants to deploy → aspire-deployment.

Language Support

See references/csharp-authoring.md and references/typescript-authoring.md.

aspire-orchestration owns the CLI-driven migration from legacy apphost.ts. After it updates packages and migration artifacts, return to aspireify only when the user still needs AppHost source wiring or authoring.

TypeScript AppHost package managers

Dependency and toolchain failures belong to this skill. Before recommending a command, inspect the AppHost directory and then its immediate eligible parent. Within each directory, the first recognized marker wins in this order:

1. packageManager in package.json (npm, pnpm, yarn, or bun, optionally versioned)
2. bun.lock
3. bun.lockb
4. pnpm-lock.yaml
5. yarn.lock
6. .yarnrc.yml
7. package-lock.json

An AppHost-local marker takes precedence over every parent marker. If neither directory has a recognized marker, Aspire defaults to npm. Report the selected manager and marker.

Use the selected manager only to repair dependencies or diagnose the toolchain. The resolver commands are npm install, bun install, and yarn install; a generated brownfield pnpm AppHost uses pnpm install --ignore-workspace, while other pnpm dependency installs use pnpm install. Yarn Classic (yarn@1... or a v1 lockfile) is unsupported: stop and ask the user to upgrade to Yarn 4+ or explicitly migrate to npm, pnpm, or Bun.

Do not change packageManager or create, replace, or regenerate a lockfile merely to influence detection or switch managers. Preserve existing files until the user explicitly chooses an upgrade or migration. Start the AppHost with aspire start --non-interactive, not a raw package-manager launcher. See references/typescript-authoring.md for the full command matrix and resolver details.

Workflow Phases

1. SCAN     → discover projects, services, dependencies, integration candidates
2. PROPOSE  → resource graph + integration list, confirm with user
3. EDIT     → wire AppHost, add ServiceDefaults + OTel + health checks
4. VALIDATE → aspire start --non-interactive → aspire wait <each resource>
5. DEACTIVATE → confirm clean start, hand off to aspire-orchestration

For the detailed, upstream-parity workflow, load these references before editing:

• apphost-wiring.md — full AppHost wiring workflow, API lookup, endpoint/parameter patterns, validation, solution updates, and cleanup.
• docker-compose.md — docker-compose migration, profiles, image mapping, ports, volumes, and depends_on.
• full-solution-apphosts.md — large solution triage, mixed SDK boundaries, solution membership, ServiceDefaults placement, and legacy host migration.
• javascript-apps.md — JavaScript resource selection, workspace/monorepo package-manager handling, ports, scripts, and TS AppHost package config.
• opentelemetry.md — optional Node.js, Python, and Go OpenTelemetry wiring for non-.NET services.

1. Scan

Walk the repo and inventory:

Full heuristics in references/scan-and-propose.md.