You’re three files deep in your Aspire AppHost, and you need to remember exactly which parameters the Redis integration expects. You could alt-tab to your browser, hunt through aspire.dev, squint at the API docs, then come back. Or you could just run a command. Or—better yet—let your AI agent look it up for you without you even thinking about it.
Aspire 13.2 ships with aspire docs—a set of CLI commands for browsing, searching, and reading official Aspire documentation without leaving your terminal. And because the CLI is just a thin layer over Aspire’s documentation services, the same source of truth is available to humans, AI skills, and automation. This isn’t a fragmented snapshot or a crudely scraped copy. It’s the real documentation from aspire.dev, exposed in a way both people and tools can use.
🤖 Skill-friendly, human-friendly
Let’s be real about what’s happening here. Modern AI tooling works best when it can stop improvising and start looking things up. That might mean a repo skill, a local agent workflow, a custom automation step, or just you running a CLI command yourself. Different wrappers, same goal: get the model to read the docs instead of guessing.
AI agents were terrible at helping developers build Aspire apps. They’d recommend dotnet run instead of aspire run, reference learn.microsoft.com for docs that live on aspire.dev, suggest outdated NuGet packages, and—my personal favorite—hallucinate APIs that don’t exist. Why? Because Aspire was .NET specific far longer than polyglot and LLMs are working off training data that predates our latest features. The AI was confidently wrong, which is arguably worse than being obviously wrong. (At least when it’s obviously wrong, you know to ignore it.)
The documentation tooling fixes that. When your assistant can call list_docs, search_docs, and get_doc—whether through a skill, a local tool integration, or a simple CLI wrapper—it stops guessing and starts referencing actual, current documentation from aspire.dev. The important part isn’t the transport. It’s that every workflow can reach the same current docs instead of relying on stale training data. It’s like giving every AI in your stack a cheat sheet— except it’s not cheating, it’s just… reading the docs. (Revolutionary concept, I know 🤣.)
For the full backstory on how the docs tooling came together—the conversation with David Fowler, the plan-spec-spike-it branch, the weighted lexical search architecture, and the llms.txt foundation—check out my post on how I taught AI to read Aspire docs. It’s a fun read, I promise.
But the architecture had a happy side effect: because we built reusable services (IDocsIndexService, IDocsSearchService, IDocsFetcher, IDocsCache) rather than a one-off integration, we could expose the same search engine through a CLI and make it easy for skills and automation to build on top of it. And that’s what this post is about.
Tip
If your editor or agent platform supports repo skills or local tool integrations, wrapaspire docs list, aspire docs search, and aspire docs get in a small skill so your assistant can pull official Aspire guidance on demand. The key idea is simple: point your AI tooling at the CLI instead of hoping the model memorized the latest docs. 💻 The aspire docs CLI: because humans deserve nice things too
The aspire docs command gives you—the actual human developer—direct access to the same documentation index that powers your AI agent. No browser, no context-switching, just docs in your terminal. Think of it as the human-friendly interface to the same search engine. Same source, same results, different consumer.
📋 List all documentation pages
aspire docs list
Returns every documentation page available on aspire.dev. Human-readable by default:
✔️ Found 264 documentation pages.
┌──────────────────────────────────┬──────────────────────────────────┬──────────────────────────────────┐
│ Title │ Slug │ Summary │
├──────────────────────────────────┼──────────────────────────────────┼──────────────────────────────────┤
│ Certificate configuration │ certificate-configuration │ Learn how to configure HTTPS │
│ │ │ endpoints and certificate trust │
│ │ │ for resources in Aspire. │
│ AppHost configuration │ apphost-configuration │ Learn about the Aspire AppHost │
│ │ │ configuration options. │
│ Docker Compose to Aspire AppHost │ docker-compose-to-aspire-apphost │ Quick reference for converting │
│ │ │ Docker Compose YAML to Aspire. │
└──────────────────────────────────┴──────────────────────────────────┴──────────────────────────────────┘
... remaining 261 pages omitted for brevity.
Need structured output for scripting? (Or feeding into other tools?)
aspire docs list --format Json
JSON array with slug, title, and summary for each page. Useful if you’re building a local docs indexer or piping results to jq for filtering.
🔍 Search for a topic
aspire docs search "redis"
This searches both page titles and content. Results are ranked by relevance using the same weighted scoring that powers Aspire’s documentation tooling:
✔️ Found 5 results for 'redis'.
┌───────────────────────────────────┬───────────────────────────────────┬─────────────────────────────────────────────┬────────┐
│ Title │ Slug │ Section │ Score │
├───────────────────────────────────┼───────────────────────────────────┼─────────────────────────────────────────────┼────────┤
│ Redis integration │ redis-integration │ Hosting integration │ 351.75 │
│ Azure Cache for Redis integration │ azure-cache-for-redis-integration │ Hosting integration │ 319.25 │
│ Redis Distributed Caching │ redis-distributed-caching │ Hosting integration │ 186.25 │
│ Redis Output Caching │ redis-output-caching │ Hosting integration │ 186.25 │
│ Examples │ examples │ Example: Derived Container Resource (Redis) │ 128.75 │
└───────────────────────────────────┴───────────────────────────────────┴─────────────────────────────────────────────┴────────┘
Control result count with --limit:
aspire docs search "integration" --limit 5
And yes, --format Json gives you structured output with relevance scoring. Perfect for scripting or feeding results into downstream tools.
📖 Read a full page
aspire docs get redis-integration
Streams the full page content to your terminal—markdown-formatted, ready to read. No browser, no rendering overhead. Just text. (Remember text? It’s what we used before everything needed a JavaScript framework to render.)
📑 Read a specific section
Not all documentation pages are short. Sometimes you only need one section:
aspire docs get redis-integration --section "Add Redis resource"
Returns just that section. Invaluable when you’re looking for a quick API example without scrolling through 500 lines of documentation. Surgical precision.
🔧 Real scenarios: when you’d actually use this
Scenario 1: Skill-assisted Aspire development
You’re building an Aspire app in VS Code with a repo skill or local tool integration configured. You ask your AI assistant: “Add a PostgreSQL database to my AppHost.” Instead of hallucinating an API, the assistant runs aspire docs search "postgres", finds the official integration docs, then reads the right page and gives you the documented approach.
No alt-tabbing. No second-guessing. No “wait, is that a real API?” The AI agent does the doc lookup for you, transparently, in real-time. That’s the whole point. You didn’t even have to think about it—the agent just knew where to look. (Because we told it. You’re welcome.)
Scenario 2: Quick terminal lookups (for the humans)
You’re three files deep in your AppHost and need to remember which parameters the Redis integration expects. You could alt-tab to your browser, hunt through aspire.dev, squint at the docs, then come back. Or:
aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"
Ninety seconds, you have the answer. You never left your terminal. Context preserved. Flow maintained. Chef’s kiss 🤌.
Scenario 3: Feeding docs to custom skills and AI pipelines
Building your own AI tooling on top of Aspire? Maybe a repo skill, an Agent Framework agent, or a custom workflow? Pipe the structured output directly:
aspire docs get redis-integration --format Json | jq '.content' | xclip
Full Redis documentation in your clipboard, ready to paste into an AI chat or add to a prompt context. Or build a custom tool that indexes Aspire docs into your own knowledge base:
aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'
Structured, machine-readable doc metadata in seconds. No web scraping, no API keys, no nonsense. The JSON output is the same structured data the docs tooling uses internally—same source, different plumbing.
Scenario 4: CI/CD documentation validation
Your CI pipeline runs checks on your Aspire AppHosts. You could add a step that validates integrations against the official documentation:
#!/bin/bash
REDIS_DOCS=$(aspire docs get redis-integration --format Json)
# Extract configuration requirements from docs
REQUIRED_CONFIG=$(echo "$REDIS_DOCS" | jq -r '.required_fields[]')
# Validate your AppHost defines them
for field in $REQUIRED_CONFIG; do
grep -q "\"$field\"" apphost.csproj || echo "Missing: $field"
done
Trivial example, but the pattern is powerful. Your CI now has access to the source of truth for Aspire integrations, programmatically. No stale documentation snapshots. No “but the wiki said…” excuses.
📊 Output formats: human and machine
Every command supports two output formats, because not all consumers have eyeballs:
Default (human-readable): Clean markdown, formatted for terminal reading. Colors and wrapping controlled by your terminal.
aspire docs get redis-integration
JSON (machine-readable): Structured JSON with metadata—full page content, section structure, and related links.
aspire docs get redis-integration --format Json
The JSON output makes it trivial to build custom documentation tools, indexers, or knowledge bases on top of Aspire’s official docs. Same data, different interface.
Tip
The documentation is always live. The moment aspire.dev updates, the CLI and any skill or automation built on top of it can reflect that. You’re not downloading a snapshot—you’re querying the real documentation source with ETag-based caching for performance.🎉 The bottom line
The documentation tooling in Aspire 13.2 fixes a real, painful problem: humans and AI assistants both need current, official guidance, and browser tabs plus stale model memory are a lousy way to get it. By putting Aspire docs behind a simple CLI and reusable tools, we turned the docs into something you can use directly in your terminal or plug into skills and automation. Same index, same search, same source of truth.
Like I mentioned earlier, if you want the deep dive on the architecture go read how I taught AI to read Aspire docs. It covers the full story.
Get started by trying the CLI directly, then wire it into whatever skill or automation setup you already use:
aspire docs search "your-topic-here"
That’s all it takes. Now go build something cool—and give your tools the docs while you’re at it. 🚀
Get involved
- 📖 Learn more: Read the full documentation on Aspire CLI documentation commands at aspire.dev.
- 💬 Give us feedback: We’d love to hear what you think—file issues or join discussions on the Aspire GitHub repo.
- 🌐 Join the community: Follow us and connect with other Aspire developers at aspire.dev/community.
0 comments
Be the first to start the discussion.