**WORKFLOW SKILL** - Orchestrates Aspire applications using the Aspire CLI and MCP tools for running, debugging, and managing distributed apps. USE FOR: aspire run, aspire stop, start aspire app, check aspire resources, list aspire integrations, debug aspire issues, view aspire logs, add aspire resource, aspire dashboard, update aspire apphost. DO NOT USE FOR: non-Aspire .NET apps (use dotnet CLI), container-only deployments (use docker/podman), Azure deployment after local testing (use azure-deploy skill). INVOKES: Aspire MCP tools (list_resources, list_integrations, list_structured_logs, get_doc, search_docs), bash for CLI commands. FOR SINGLE OPERATIONS: Use Aspire MCP tools directly for quick resource status or doc lookups.
56
63%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.github/skills/aspire/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that excels across all dimensions. It provides specific concrete actions, comprehensive natural trigger terms, explicit 'use when' and 'do not use when' guidance, and clear boundaries against related skills. The DO NOT USE FOR section with alternative skill recommendations is a particularly strong feature that minimizes conflict risk.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: running, debugging, managing distributed apps, checking resources, listing integrations, viewing logs, adding resources, accessing dashboard, updating apphost. Also names specific MCP tools like list_resources, list_integrations, list_structured_logs. | 3 / 3 |
Completeness | Clearly answers both 'what' (orchestrates Aspire applications using CLI and MCP tools for running, debugging, managing) and 'when' (explicit USE FOR and DO NOT USE FOR clauses with specific trigger scenarios). The DO NOT USE FOR section with alternatives adds exceptional clarity. | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: 'aspire run', 'aspire stop', 'start aspire app', 'check aspire resources', 'list aspire integrations', 'debug aspire issues', 'view aspire logs', 'aspire dashboard'. These are highly natural phrases a user would type. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with clear niche (Aspire-specific tooling). The DO NOT USE FOR section explicitly delineates boundaries against dotnet CLI, docker/podman, and azure-deploy skill, making conflicts very unlikely. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill covers a broad range of Aspire operations but suffers from verbosity, redundancy (running the app is described twice), and vague tool references. The content would benefit significantly from being trimmed, having exact MCP tool names specified, and being split across multiple files for progressive disclosure. Concrete CLI commands are a strength, but the debugging and integration workflows lack the specificity and validation checkpoints needed for reliable execution.
Suggestions
Consolidate the duplicate 'running the application' sections and remove explanatory text Claude doesn't need (e.g., what Aspire is, what search/get operations do conceptually).
Use exact MCP tool names (e.g., `list_resources`, `list_structured_logs`) consistently instead of informal descriptions like 'the list resources tool', and show example invocations with parameters.
Split the monolithic file: move documentation tools, Playwright MCP, and updating guidance into separate referenced files (e.g., DOCS_TOOLS.md, PLAYWRIGHT.md, UPDATING.md) with clear one-level-deep links.
Add explicit validation checkpoints and error recovery steps to the debugging workflow—e.g., 'If resource shows Unhealthy status: 1. Check structured logs for that resource 2. Look for connection string issues 3. Restart the resource using execute_resource_command'.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Significant verbosity throughout. Explains obvious concepts ('Aspire is an orchestrator for the entire application'), repeats information (running the application is covered twice with overlapping content), and includes unnecessary phrasing like 'use this tool to get details about' repeatedly. The documentation tools section is particularly bloated—Claude doesn't need to be told what 'search' and 'get' do in such detail. | 1 / 3 |
Actionability | Provides concrete CLI commands (aspire run, aspire stop, aspire run --detach --isolated) which is good, but the MCP tool references are vague—they use informal names like 'list resources tool' and 'list structured logs' without specifying exact tool names or parameters. The debugging section tells Claude to use tools but doesn't show concrete invocation patterns or expected outputs. | 2 / 3 |
Workflow Clarity | There are some workflows present (general recommendations list steps, debugging has a sequence, documentation lookup has a 3-step workflow), but validation checkpoints are mostly missing. The 'make changes incrementally and run aspire run to validate' is vague. There's no explicit feedback loop for what to do when resources fail or when debugging reveals specific error patterns. The relaunch rules section is helpful but lacks error recovery guidance. | 2 / 3 |
Progressive Disclosure | Everything is in a single monolithic file with no references to supporting files. The content is long (~120 lines) and mixes quick-start information with advanced topics (updating, persistent containers, Playwright MCP, documentation tools) all inline. Topics like documentation tool usage, Playwright integration, and updating could easily be split into separate referenced files. | 1 / 3 |
Total | 6 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
147d0c4
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.