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. Aligned with Aspire 13.4 guidance from the current Aspire development branch.

🚫 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 by Aspire from apphost.ts and the integration packages — every file in it gets clobbered on the next build, aspire add, or aspire start.

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 apphost.ts — the only file the user should hand-edit in a TS AppHost.
4. If the user wants a new integration, suggest aspire add <package>; if they want to change configuration, show the equivalent edit in apphost.ts.

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 From Aspire 13.4

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.

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.

2. Propose

Present a resource graph before editing. Ask clarifying questions:

• "I see Postgres in docker-compose.yml — should I model it as AddPostgres('db') or use Azure Database for PostgreSQL?"
• "Your React app hardcodes http://localhost:5000 — replace with Aspire service discovery (endpoint.url)?"
• "Your API has an /admin endpoint — exclude it from WithReference() so consumers don't see it?"

3. Edit

Apply the proposed graph. Use the right authoring style for the AppHost language.

4. Validate

aspire start --non-interactive --format Json
aspire wait <resource>          # repeat for each declared resource
aspire describe --format Json   # sanity check graph

Full validation flow + recovery in references/validation.md.

5. Self-Deactivate

After a clean aspire start, announce:

✅ AppHost wired and validated. Handing off to aspire-orchestration for
   day-to-day start/stop/wait. Aspireify is done.

Integration Discovery Catalog

Map detected services → Aspire integrations. See references/scan-and-propose.md for the full catalog.

Current Authoring Rules

C# vs TS Quick Reference

ServiceDefaults Wiring

Each project should call builder.AddServiceDefaults(); to opt into OpenTelemetry, health checks, and service discovery. Add the Aspire.ServiceDefaults project reference (or NuGet for non-monorepo). See references/service-defaults.md.

Endpoint & Reference Conventions

// Public-facing API. Mark "admin" endpoint as not-for-consumers.
var api = builder.AddProject<Projects.Api>("api")
    .WithExternalHttpEndpoints()
    .WithEndpoint("admin", e => e.ExcludeReferenceEndpoint = true);

// Frontend wires the API via service discovery.
builder.AddNextJsApp("web", "./web")
    .WithReference(api)        // injects services__api__http and __https
    .WaitFor(api)
    .WithBrowserLogs();        // browser console + screenshots

Validation & Recovery

Full flow in references/validation.md.

Handoff Rules

Key Rules

• Never overwrite existing files — always augment or merge.
• Ask before modifying service code, especially OpenTelemetry and ServiceDefaults injection.
• Respect existing project structure — do not reorganize the repo.
• If stuck, use aspire doctor to diagnose environment issues.
• Never hardcode URLs in WithEnvironment / withEnvironment — pass endpoint references such as api.GetEndpoint("http") or api.getEndpoint('http') instead of string literals.
• Never use WithUrlForEndpoint / withUrlForEndpoint to set dev.localhost URLs — that API is only for dashboard display labels; dev.localhost belongs in AppHost launch/profile configuration.

References

• apphost-wiring.md — Detailed AppHost wiring workflow and API lookup patterns
• docker-compose.md — Docker Compose migration patterns
• full-solution-apphosts.md — Large/full-solution AppHost guidance
• javascript-apps.md — JavaScript/TypeScript app and workspace handling
• opentelemetry.md — Non-.NET OpenTelemetry setup
• scan-and-propose.md — Repo scan heuristics + integration catalog
• csharp-authoring.md — C# AppHost patterns
• typescript-authoring.md — TS AppHost patterns + parity APIs
• service-defaults.md — Wire OTel, health checks, service discovery
• validation.md — End-to-end validation + recovery