aspireify
**WORKFLOW SKILL** - Wire an Aspire AppHost after `aspire init` drops a skeleton. Scans the repo, proposes a resource graph, edits the AppHost (C#, file-based C#, or TypeScript), wires `Aspire.ServiceDefaults` + OTel, validates with `aspire start`, then self-deactivates. USE FOR: wire AppHost, scaffold resource graph, add Postgres/Redis/Rabbit/Mongo to Aspire, connect frontend to API, after `aspire init` what next, AddNextJsApp, AddViteApp, WithBrowserLogs, file-based apphost.cs, apphost.ts, unified withEnvironment, refuse .aspire/modules edit, migrate .env files, migrate user secrets. DO NOT
Profile →npx skills add microsoft/aspire-skills --skill aspireify --agent copilot
Same command for any agent — swap --agent for claude-code, codex, cursor.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# 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
- 🚫 Hard Refusal: Never Edit .aspire/modules/
- Guiding Principles From Aspire 13.4
- Minimize changes to the user's code
- Surface tradeoffs; do not decide silently
- Verify APIs before writing AppHost code
- Keep configuration visible in the AppHost
- Local development first
- Redis TLS edge case
- Project-Local Override
- Prerequisites
- Detection — When to Activate
- Language Support
- Workflow Phases
- 1. Scan
aspire start --non-interactive --format Json aspire wait <resource> # repeat for each declared resource aspire describe --format Json # sanity check graph
What does the aspireify skill do?
**WORKFLOW SKILL** - Wire an Aspire AppHost after `aspire init` drops a skeleton. Scans the repo, proposes a resource graph, edits the AppHost (C#, file-based C#, or TypeScript), wires `Aspire.ServiceDefaults` + OTel, validates with `aspire start`, then self-deactivates. USE FOR: wire AppHost, scaffold resource graph, add Postgres/Redis/Rabbit/Mongo to Aspire, connect frontend to API, after `aspire init` what next, AddNextJsApp, AddViteApp, WithBrowserLogs, file-based apphost.cs, apphost.ts, unified withEnvironment, refuse .aspire/modules edit, migrate .env files, migrate user secrets. DO NOT
How do I install it?
Run `npx skills add microsoft/aspire-skills --skill aspireify --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From microsoft/aspire-skills, a repository with 76 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.