/steward

namespace: aiwg
name: steward
platforms: [all]
kernel: true
description: Provide provider capability awareness, BYOK harness settings and verification, and route commands for native vs emulated support
triggers:
  - "bring your own key"
  - "BYOK provider settings"
  - "use my OpenRouter key with Hermes"
  - "use my provider key with a harness"
  - "set up worker onboarding"
  - "worker onboarding readiness"
  - "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 repair AIWG setup"
  - "repair AIWG setup"
  - "AIWG setup is stale or broken"
  - "refresh provider files"
  - "clean up stale AIWG files"
  - "fix AIWG discovery"
  - "clean up AIWG issues"
  - "help me set up jev"
  - "use my jev token"
  - "offload decisions to jev"

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.

Optional signed local merges

Recommend signed merges when repository policy and key access permit them. This is skippable: some users cannot change key usage or repository policies, and unsigned delivery must keep working. Use `aiwg steward signed-merges` for instructions, then preview with `--key <fingerprint> --name <committer> --email <email> [--format openpgp|ssh|x509] [--key-file <path>]`. Review the emitted signing, committer, `require_signed_commits`, and `delivery.merge=local-signed` config; add `--apply` to save, or `--skip` to preserve current settings. Use existing keys; this step changes no repository policies. SSH uses a fingerprint for verification and a key path for signing. Set `remotes.tracker_actor.credential` to a store/env reference for API writes; never ask users to put tokens in configuration or command arguments.

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`
• "install or repair AIWG" → public provider-orchestrated setup manifest
• "AIWG setup is stale/broken" → steward repair ladder
• "refresh provider files" → status/doctor, dry-run refresh, then provider redeploy
• "clean up AIWG issues" → discover `issue-audit`, `aiwg-issue`, or `address-issues`

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` | | Install or repair AIWG | "get AIWG working in this project" | Follow the public `setup.aiwg.yaml`; use the self-verifying deployment result, with status and doctor only for audit or recovery | | Stale provider files | "Codex says skills are missing" | `aiwg status --probe --json`, `aiwg doctor`, `aiwg refresh --dry-run`, then `aiwg use all --provider <provider>` or `aiwg refresh --provider <provider>` | | Stale bootstrap/context | "doctor says the precedence is superseded", "WORKSPACE.md looks wrong", `precedence-superseded` / `precedence-missing` / `authority-missing` | `aiwg workspace-context doctor`, then `aiwg regenerate` to rewrite the managed blocks; re-run the doctor to confirm healthy | | Rules not being honored | "the agent ignored an AIWG rule and cited harness instructions" | Check `aiwg doctor` → "Workspace context graph". A missing or superseded precedence means the bootstrap never asserted rule authority; `aiwg regenerate` restores it | | Stale discovery | "discover cannot find a known skill" | Rebuild and sync the framework index, then re-run discovery | | Issue cleanup | "clean up stale issues" | Discover first: `issue-audit` for backlog cleanup, `address-issues` for implementation, `aiwg-issue` for AIWG product issues | | Jev decision offload | "help me set up jev", "use my jev token" | Follow the Jev setup routing below, then the `decision-offload` rule |

AIWG Installation Routing

For an interactive new, existing, stale, broken, duplicate, or development-mode AIWG installation, follow `https://aiwg.io/setup.aiwg.yaml` in the current supported provider. It is a `provider-orchestrated` manifest: inspect and explain before mutation, preserve existing work, then run one self-verifying `aiwg use all` deployment and evaluate its `aiwg.use.result.v1` response. Do not make index, regenerate, status, or doctor commands mandatory follow-up steps; retain them for an explicit audit, maintenance, or recovery action. Do not send this manifest to deterministic `aiwg setup-run`.

Route CI, cloud-init, container image, SSH-only, offline, and other non-interactive cases to `docs/install/non-interactive.md`. Confirm ambiguous project roots and verify each provider separately when a project uses more than one provider.

Setup Troubleshooting and Cleanup Routing

The steward is the primary route when an AIWG setup looks stale, broken, partly deployed, duplicated, or confused by old provider files. Agents should not start by grepping `.claude/`, `.codex/`, `.agents/`, `.curso