aspireify

Name: aspireify
Author: microsoft

105installs7forks

How to install aspireify?

microsoft/aspire-skills/aspireify

$npx -y skills add microsoft/aspire-skills --skill aspireify

Installs into the current project.

Summary

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:

Files · 1

View on GitHub

SKILL.md

1	# Aspireify
2
3	> One-time wiring skill. `aspire init` drops a skeleton; `aspireify` turns
4	> that skeleton into a working AppHost by scanning the repo, proposing a resource
5	> graph, editing the AppHost, wiring `Aspire.ServiceDefaults`, and validating end
6	> to end. Self-deactivates after a clean `aspire start`. Aligned with Aspire 13.4
7	> guidance from the current Aspire development branch.
8
9	## 🚫 Hard Refusal: Never Edit `.aspire/modules/`
10
11	> ⛔ REFUSE any request to edit, modify, change, open-for-edit, or "tweak" files
12	> inside `.aspire/modules/` of a TypeScript AppHost. This directory is generated by Aspire
13	> from `apphost.ts` and the integration packages — every file in it gets **clobbered
14	> on the next build, `aspire add`, or `aspire start`**.
15	>
16	> If a user asks to edit something in `.aspire/modules/` (e.g., `.aspire/modules/postgres.module.ts`),
17	> the correct response is:
18	>
19	> 1. Refuse the edit with a clear "I won't edit `.aspire/modules/`" statement.
20	> 2. Explain that `.aspire/modules/` is generated and any changes are clobbered.
21	> 3. Redirect the requested change to `apphost.ts` — the only file the user
22	> should hand-edit in a TS AppHost.
23	> 4. If the user wants a new integration, suggest `aspire add <package>`; if they want
24	> to change configuration, show the equivalent edit in `apphost.ts`.
25
26	\| ❌ Wrong \| ✅ Right \|
27	\|----------\|---------\|
28	\| Open `.aspire/modules/postgres.module.ts` and tweak the connection options \| Edit `apphost.ts` and change `addPostgres('pg', { ... })` options there \|
29	\| Modify a generated `.aspire/modules/*.ts` file directly \| Re-run `aspire add <package>` after updating `apphost.ts` \|
30	\| Comment out a line in `.aspire/modules/` to disable a resource \| Remove or guard the resource declaration in `apphost.ts` \|
31
32	This rule applies even if the user insists, even for "one-line" changes, even for
33	"just to test something." The TS AppHost regenerates `.aspire/modules/` deterministically;
34	edits are unrecoverable noise.
35
36	## Guiding Principles From Aspire 13.4
37
38	### Minimize changes to the user's code
39
40	Adapt the AppHost to fit the app, not the other way around. Prefer `WithEnvironment()`
41	to match existing environment variable names, Aspire-managed ports over fixed ports,
42	and 1:1 Docker Compose mapping before optimizing. Do not restructure directories,
43	rename files, or change build scripts unless the user explicitly chooses that tradeoff.
44
45	### Surface tradeoffs; do not decide silently
46
47	When a small code change unlocks better Aspire integration, present both options:
48	the zero-code-change mapping and the small-change version that enables `WithReference`,
49	health checks, service discovery, dynamic ports, or dashboard telemetry. Ask which
50	approach the user wants, then implement that choice without complaint.
51
52	### Verify APIs before writing AppHost code
53
54	Use `aspire docs search <topic>` and `aspire docs get <slug>` for workflow guidance.
55	Use `aspire docs api search <query> --language csharp\|typescript` and
56	`aspire docs api get <id>` for API shape. Use `aspire integration list/search` to
57	find integrations before `aspire add`. Do not invent packages, methods, overloads,
58	or command shapes; C# and TypeScript AppHost APIs differ.
59
60	### Keep configuration visible in the AppHost
61
62	Scan `.env`, `.env.local`, `.env.development`, `secrets.json.example`,
63	`<UserSecretsId>`, and setup scripts. Propose migrating values into AppHost parameters:
64	connection strings become Aspire resources, API keys/tokens become secret parameters,
65	and non-secret config becomes plain parameters or `WithEnvironment()` values. Never
66	delete `.env` files or remove existing `UserSecretsId` entries without explicit user
67	approval because non-Aspire workflows may still depend on them.
68
69	### Local development first
70
71	This skill optimizes local development, not production deployment. Prefer persistent
72	container lifetimes and dat

People who liked this also viewed

6 picks

Type

aspireify

105installs7forks

View on GitHub

How to install aspireify?

microsoft/aspire-skills/aspireify

$npx -y skills add microsoft/aspire-skills --skill aspireify

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Aspireify
2
3	> One-time wiring skill. `aspire init` drops a skeleton; `aspireify` turns
4	> that skeleton into a working AppHost by scanning the repo, proposing a resource
5	> graph, editing the AppHost, wiring `Aspire.ServiceDefaults`, and validating end
6	> to end. Self-deactivates after a clean `aspire start`. Aligned with Aspire 13.4
7	> guidance from the current Aspire development branch.
8
9	## 🚫 Hard Refusal: Never Edit `.aspire/modules/`
10
11	> ⛔ REFUSE any request to edit, modify, change, open-for-edit, or "tweak" files
12	> inside `.aspire/modules/` of a TypeScript AppHost. This directory is generated by Aspire
13	> from `apphost.ts` and the integration packages — every file in it gets **clobbered
14	> on the next build, `aspire add`, or `aspire start`**.
15	>
16	> If a user asks to edit something in `.aspire/modules/` (e.g., `.aspire/modules/postgres.module.ts`),
17	> the correct response is:
18	>
19	> 1. Refuse the edit with a clear "I won't edit `.aspire/modules/`" statement.
20	> 2. Explain that `.aspire/modules/` is generated and any changes are clobbered.
21	> 3. Redirect the requested change to `apphost.ts` — the only file the user
22	> should hand-edit in a TS AppHost.
23	> 4. If the user wants a new integration, suggest `aspire add <package>`; if they want
24	> to change configuration, show the equivalent edit in `apphost.ts`.
25
26	\| ❌ Wrong \| ✅ Right \|
27	\|----------\|---------\|
28	\| Open `.aspire/modules/postgres.module.ts` and tweak the connection options \| Edit `apphost.ts` and change `addPostgres('pg', { ... })` options there \|
29	\| Modify a generated `.aspire/modules/*.ts` file directly \| Re-run `aspire add <package>` after updating `apphost.ts` \|
30	\| Comment out a line in `.aspire/modules/` to disable a resource \| Remove or guard the resource declaration in `apphost.ts` \|
31
32	This rule applies even if the user insists, even for "one-line" changes, even for
33	"just to test something." The TS AppHost regenerates `.aspire/modules/` deterministically;
34	edits are unrecoverable noise.
35
36	## Guiding Principles From Aspire 13.4
37
38	### Minimize changes to the user's code
39
40	Adapt the AppHost to fit the app, not the other way around. Prefer `WithEnvironment()`
41	to match existing environment variable names, Aspire-managed ports over fixed ports,
42	and 1:1 Docker Compose mapping before optimizing. Do not restructure directories,
43	rename files, or change build scripts unless the user explicitly chooses that tradeoff.
44
45	### Surface tradeoffs; do not decide silently
46
47	When a small code change unlocks better Aspire integration, present both options:
48	the zero-code-change mapping and the small-change version that enables `WithReference`,
49	health checks, service discovery, dynamic ports, or dashboard telemetry. Ask which
50	approach the user wants, then implement that choice without complaint.
51
52	### Verify APIs before writing AppHost code
53
54	Use `aspire docs search <topic>` and `aspire docs get <slug>` for workflow guidance.
55	Use `aspire docs api search <query> --language csharp\|typescript` and
56	`aspire docs api get <id>` for API shape. Use `aspire integration list/search` to
57	find integrations before `aspire add`. Do not invent packages, methods, overloads,
58	or command shapes; C# and TypeScript AppHost APIs differ.
59
60	### Keep configuration visible in the AppHost
61
62	Scan `.env`, `.env.local`, `.env.development`, `secrets.json.example`,
63	`<UserSecretsId>`, and setup scripts. Propose migrating values into AppHost parameters:
64	connection strings become Aspire resources, API keys/tokens become secret parameters,
65	and non-secret config becomes plain parameters or `WithEnvironment()` values. Never
66	delete `.env` files or remove existing `UserSecretsId` entries without explicit user
67	approval because non-Aspire workflows may still depend on them.
68
69	### Local development first
70
71	This skill optimizes local development, not production deployment. Prefer persistent
72	container lifetimes and dat

People who liked this also viewed

6 picks

Type