/steward

namespace: aiwg
name: steward
platforms: [all]
kernel: true
description: Provide provider capability awareness and route commands by answering what the current provider supports natively vs must emulate
triggers:
  - "help me choose what to use"
  - "help me choose the right AIWG framework or skill"
  - "ask for one recommended path and one fallback"
  - "aiwg steward"

steward

You provide provider capability awareness and intelligent command routing. You read the canonical capability matrix to answer what the current provider supports natively, what must be emulated, and which command achieves a given goal on the active platform.

Triggers

Alternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):

• "what can this provider do" → capabilities for current provider
• "is X supported here" → feature check for current provider
• "how do I do X" (in provider context) → routing advice
• "what command handles Y" → find subcommand
• "which model should this use" → model policy route
• "model catalog or routing" → `aiwg steward models`

Trigger Patterns Reference

| Pattern | Example | Action | |---------|---------|--------| | Current provider capabilities | "what does my provider support" | `aiwg steward capabilities` | | Named provider capabilities | "what does Cursor support" | `aiwg steward capabilities --provider cursor` | | All providers | "show the full capability matrix" | `aiwg steward capabilities --all` | | Feature check | "does my provider support agent teams" | `aiwg steward capabilities --feature agent_teams` | | Routing lookup | "which providers support cron" | `aiwg steward find --capability cron` | | Model routing | "which model should this use" | `aiwg steward models`; then `aiwg models audit` or `aiwg models resolve` |

Behavior

When triggered:

1. **Identify the subcommand**:

• `capabilities` — show what a provider supports, optionally filtered by feature
• `find` — show which providers support a capability and how to invoke it

2. **Detect provider context** (for `capabilities` without `--provider`):

• Check `CLAUDE_CODE_VERSION` env → `claude-code`
• Check `CODEX_API_KEY` env → `codex`
• Check `.cursor/` project directory → `cursor`
• Fall back to `aiwg runtime-info` for authoritative detection

3. **Run the appropriate command**:

   # Current provider capabilities (auto-detected)
   aiwg steward capabilities

   # Named provider
   aiwg steward capabilities --provider copilot

   # Check specific feature on current provider
   aiwg steward capabilities --feature agent_teams

   # Full matrix — all providers, all features
   aiwg steward capabilities --all

   # Find providers that support a capability
   aiwg steward find --capability cron

   # Model policy and dynamic catalog routing
   aiwg steward models
   aiwg models sources --json
   aiwg models audit --provider codex

4. **Interpret and surface routing advice**:

• Native support: report the native tool or mechanism
• Emulated support: show the `aiwg` command that emulates the feature
• No support: report clearly and suggest the nearest alternative

Project-Local Authoring Routing

Steward capability routing is intentionally broader than the provider matrix when the user asks how to create AIWG artifacts for their own project. For project-local authoring intents, do not answer only with `aiwg steward capabilities`.

Route these intents directly:

| User intent | Primary route | Notes | |---|---|---| | Create a repo/project-level skill | `aiwg new-bundle <name> --starter skill` or `aiwg new-extension <name> --starter skill` | Creates content source under `.aiwg/{extensions,addons,frameworks}/<name>/`; deploy with `aiwg use <name>`. | | Create a project-level agent | `aiwg new-bundle <name> --starter agent` or SkillSmith/AgentSmith when generating from a prompt | Use project-local bundle layout so the artifact is versioned with the repo. | | Create a custom provider selector | `aiwg new-provider <name>` or `aiwg new-bundle <name> --type provider` | Creates `.aiwg/providers/<name>/` with `providerConfig.extends`; select it with `aiwg use <framework> --provider <name>`. | | Choose extension/addon/framework/plugin/provider shape | `aiwg discover "project-local customization"` and docs/customization quickstart | Extensions are the usual smallest local customization; addons/frameworks are heavier. Plugins are marketplace delivery wrappers. Providers are metadata selectors. | | Make an agent invoke a custom skill | Create the skill in a project-local bundle, run `aiwg use <name>`, then reload the provider session | Session reload rules still apply. |

Canonical docs: `docs/customization/project-local-quickstart.md`, `docs/customization/project-local-lifecycle.md`, and `docs/customization/extensions-vs-addons-vs-frameworks-vs-plugins.md`. Mention that project-local artifacts and provider definitions are trusted repo code and should be reviewed before deploy.

Model-policy caveat: generated skills and commands must carry `commandHint.modelRole` and `commandHint.modelTier`; generated agents must carry `model-role` and `model-tier`. Do not suggest exact model IDs or legacy `haiku|sonnet|opus` choices for new provider-neutral source artifacts.

Feature-Domain Routing (proactive)

Three cross-cutting feature domains fall outside the framework quickrefs and were historically undiscoverable (#1623). The steward owns routing for them via the `steward-quickref` kernel skill. Be **proactive** — these are easy to miss:

| Domain | Canonical discover phrase | Owning capability | |---|---|---| | **Expansion authoring** (extension/addon/framework) | `aiwg discover "author an expansion"` | `scaffold-extension` / `-addon` / `-framework` | | **Persona / SOUL** (author **and** select) | `aiwg discover "create a persona"` · `aiwg discover "select a persona"` | `soul-create`, persona agents under `agentic/code