| name | project-capability-adoption |
| description | Guides on-need adoption of an Agency MCP or Microsoft Foundry capability from the starter's capability catalog. Use when a project asks 'can we use X', 'should we adopt X', or needs to pull a specific tool/profile/Foundry capability without loading the whole surface. |
| lastReviewed | "2026-07-08T00:00:00.000Z" |
Project Capability Adoption
Use this skill when a project wants to pull a single capability on need —
an Agency MCP, an Agency profile, a curated plugin, or a Microsoft Foundry
capability — instead of adopting the whole tool surface up front.
The source of truth is the catalog in
agency-mcp-capabilities.md:
- Agency MCP surface — the Profile-to-MCP map and Capability Catalog (MCPs
configured in agency.toml).
- Foundry Capability Catalog (On-Need) — Microsoft Foundry product
capabilities (IQ family, Toolboxes, Tool Search, Routines, autopilot agents,
Agent Optimizer, Memory, Claude, SDKs). These run on a different runtime
than Agency profiles and are awareness/adoption guidance, not wired into any
starter profile.
Route The Request
| Request | Default route |
|---|
| "Which profile/MCP do I use for task X?" | agency-mcp-capabilities.md Profile-to-MCP map; prefer the narrowest matching profile |
| "Can we adopt Fabric work / semantic models / notebooks?" | project-fabric-operations skill + the project-fabric* templates |
| "Can we adopt a Foundry capability (Toolboxes, Tool Search, Routines, autopilot agents, IQ family, Claude)?" | project-foundry-operations skill + the Foundry Capability Catalog |
| "Should we install this curated plugin?" | plugin-adoption-checklist.md |
| "Is this GA or preview?" | Check the status column in the catalog, then re-confirm against Microsoft's current docs — preview labels move fast |
On-Need Adoption Steps
- Name the active problem. Do not adopt a capability speculatively. If no
current task needs it, record it as a candidate and stop.
- Find it in the catalog. Locate the row in
agency-mcp-capabilities.md.
Note its runtime (Agency MCP profile vs. Foundry), status, and the "Pull
when" / "Use when" trigger.
- Confirm status. For anything marked preview, re-check Microsoft's current
docs before relying on it. Preview items ship without an SLA and can change.
- Prefer the narrowest, read-only path first. For Agency work, use
agency copilot --profile-only <profile>. For Foundry work, prefer
observability/read paths before write-capable or identity-bearing ones
(autopilot agents, live ontology writes).
- Run the plugin adoption checklist where a plugin is involved
(plugin-adoption-checklist.md):
inspect the README, list agents/skills, check write/PR/external-call
behavior, install through a profile not globally.
- Record the decision in the project's own docs (and, if this starter is
being evolved, in whats-new.md). The
additive-merge installer cannot distinguish "never adopted" from
"deliberately declined," so a declined capability must be recorded to survive
a future merge.
Safety Rules
- Foundry capabilities are a different runtime than Agency profiles. Do not
imply a Foundry capability is available through
agency.toml — it is not.
- Preview status is not a green light. Confirm current status and data-handling
terms before a project depends on a preview capability.
- Identity-bearing capabilities (Foundry autopilot agents get their own Entra
Agent ID, mailbox, calendar, and Teams presence) are governance-sensitive.
Treat their adoption like provisioning a new user account, not enabling a
tool.
- Live-write capabilities (Fabric IQ ontology authoring, semantic-model fixes,
remediation plugins) require review-before-apply. Prefer their Preview &
Confirm gates.
- Keep sessions narrow. Adopting one capability is not a reason to load an
unrelated profile or toolbox alongside it.
Would Revise If
Revisit by 2026-09-30. Revise or delete this skill if the catalog structure in
agency-mcp-capabilities.md
changes, or if two projects using the starter adopt a capability without going
through the catalog because the routing here was unclear.
