Document available Radius AI tooling and define its productization path

Start with the existing GitHub Copilot app integration guide and the public source repositories for Radius skills, plugins, and integrations. Verify each host’s capabilities, installation, release status, prerequisites, and limitations before writing the inventory and workflow guidance. Done means the docs include validated setup and application-modeling steps, clearly label preview and proposed work, and link a productization proposal and implementation issues owned by the tooling repositories.

What content needs to be created or modified?

Developers need a clear account of the AI tooling available for adopting Radius: what it does, where to obtain it, how to install and use it, and which capabilities are supported in each host. The existing GitHub Copilot app integration documentation provides one entry point, but it should not be treated as evidence that the same capabilities are available in every AI tool.

This work includes both documentation of available capabilities and a scoped productization proposal for gaps in packaging, distribution, and reuse. Documentation must distinguish released functionality, preview features, and proposed work.

Describe the solution you'd like

Document what exists

• Inventory available Radius skills, plugins, and integrations from their source repositories. Record their capabilities, installation source, host requirements, release status, limitations, and maintenance owner.
• Explain the distinction between reusable skills and host-specific UI or orchestration, including Radius Canvas in the GitHub Copilot app.
• Provide reproducible installation and first-use instructions for each validated host. Evaluate GitHub Copilot CLI and other AI tools as potential consumers of reusable skills, but list them as supported only after validation.
• Walk through using available tooling to inspect an application repository, generate or update an application definition such as app.bicep, review the result, and validate it. Document later deployment steps only where the chosen integration actually supports them.
• Explain credential handling, permissions, repository changes, review of generated infrastructure, cloud costs, and the points where users approve consequential operations.

Define the productization work

Write a short proposal and implementation backlog covering the source of truth for shared skills, host-specific adapters, packaging, versioning, installation, upgrades, testing, and support ownership. Compare reuse options before choosing a repository or dependency model; avoid maintaining duplicate skill instructions across hosts.

Track implementation gaps in the repositories that own the tooling and link them from this documentation issue. Do not present an unimplemented distribution or cross-host design as available functionality.

Acceptance criteria

• A verified inventory distinguishes available, preview, and proposed capabilities, with links to their public source and installation instructions.
• Host compatibility and prerequisites are explicit, including any cloud or application-structure limitations of each integration.
• A reader can install an available tool and complete a documented application-modeling workflow, with expected artifacts and validation steps.
• Generated files, human-review checkpoints, credential requirements, and troubleshooting are explained.
• A short productization proposal records the shared-skill/host-specific boundary, distribution and versioning approach, ownership, and unresolved decisions.
• Implementation work needed to close identified gaps is captured in linked issues in the owning repositories.
• The user-facing documentation is linked from Integrations and relevant application-authoring guidance; no unsupported cross-host or cloud parity is implied.

Where should the new material be placed?

Add a general AI tooling entry point under Integrations, linking to host-specific setup guides and the existing GitHub Copilot app integration. Keep productization decisions and implementation tracking with the tooling's owning repositories, and link their user-facing outcomes back to the docs.

The associated pull request from the Radius code repo, if applicable

N/A at issue creation. Identify and link the appropriate implementation PRs after the inventory and productization proposal establish ownership and scope.

Additional context

Related documentation work:

• #2078: dedicated AWS and Azure setup and module guidance.
• #2079: a canonical end-to-end application tutorial that can provide a consistent example for AI-assisted workflows.

The manual deployment tutorial should remain usable without AI tooling. This issue is not a request to promise a new agent platform or to declare every existing integration generally available; it is a request to document what works today and define a maintainable path for making the remaining tooling usable.