[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CB1VCPWWWS0AJYY646WRC5":3,"skill-same:01M6CB1VCPWWWS0AJYY646WRC5":101},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":48,"linkOnly":49,"markdownContent":50,"markdownBody":51,"frontMatter":52,"refName":78,"commitSha":79,"skillDirectory":80,"forksCount":81,"repositoryHtmlUrl":82,"repositoryHomepageUrl":83,"ownerHtmlUrl":84,"ownerBlogUrl":85,"ownerDescription":86,"updatedAt":87,"install":88,"resources":100},"01M6CB1VCPWWWS0AJYY646WRC5","steward",null,"Provide provider capability awareness, BYOK harness settings and verification, and route commands for native vs emulated support","jmagly\u002Faiwg","jmagly","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1159087?v=4","01M6C10AK8N2WCSQN11FYGTJWN","Joseph Magly","01M6C10AQ8A2RMED1Y1BSVY7NF",229,"MIT","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Futils\u002Fskills\u002Fsteward\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[5,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47],"clean","path","capability","offload","my","commands","token","me","route","worker","fallback","ask","files","issues","fix","up","choose","broken","SET","2026-11-10 10:12:30",false,"---\nnamespace: aiwg\nname: steward\nplatforms: [all]\nkernel: true\ndescription: Provide provider capability awareness, BYOK harness settings and verification, and route commands for native vs emulated support\ntriggers:\n  - \"bring your own key\"\n  - \"BYOK provider settings\"\n  - \"use my OpenRouter key with Hermes\"\n  - \"use my provider key with a harness\"\n  - \"set up worker onboarding\"\n  - \"worker onboarding readiness\"\n  - \"help me choose what to use\"\n  - \"help me choose the right AIWG framework or skill\"\n  - \"ask for one recommended path and one fallback\"\n  - \"aiwg steward\"\n  - \"steward repair AIWG setup\"\n  - \"repair AIWG setup\"\n  - \"AIWG setup is stale or broken\"\n  - \"refresh provider files\"\n  - \"clean up stale AIWG files\"\n  - \"fix AIWG discovery\"\n  - \"clean up AIWG issues\"\n  - \"help me set up jev\"\n  - \"use my jev token\"\n  - \"offload decisions to jev\"\n---\n\n# steward\n\nYou 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.\n\n## Optional signed local merges\n\nRecommend signed merges when repository policy and key access permit them.\nThis is skippable: some users cannot change key usage or repository policies,\nand unsigned delivery must keep working. Use `aiwg steward signed-merges` for\ninstructions, then preview with `--key \u003Cfingerprint> --name \u003Ccommitter>\n--email \u003Cemail> [--format openpgp|ssh|x509] [--key-file \u003Cpath>]`.\nReview the emitted signing, committer, `require_signed_commits`, and\n`delivery.merge=local-signed` config; add `--apply` to save, or `--skip` to\npreserve current settings. Use existing keys; this step changes no repository\npolicies. SSH uses a fingerprint for verification and a key path for signing.\nSet `remotes.tracker_actor.credential` to a store\u002Fenv reference for API writes;\nnever ask users to put tokens in configuration or command arguments.\n\n## Triggers\n\nAlternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):\n\n- \"what can this provider do\" → capabilities for current provider\n- \"is X supported here\" → feature check for current provider\n- \"how do I do X\" (in provider context) → routing advice\n- \"what command handles Y\" → find subcommand\n- \"which model should this use\" → model policy route\n- \"model catalog or routing\" → `aiwg steward models`\n- \"install or repair AIWG\" → public provider-orchestrated setup manifest\n- \"AIWG setup is stale\u002Fbroken\" → steward repair ladder\n- \"refresh provider files\" → status\u002Fdoctor, dry-run refresh, then provider redeploy\n- \"clean up AIWG issues\" → discover `issue-audit`, `aiwg-issue`, or `address-issues`\n\n## Trigger Patterns Reference\n\n| Pattern | Example | Action |\n|---------|---------|--------|\n| Current provider capabilities | \"what does my provider support\" | `aiwg steward capabilities` |\n| Named provider capabilities | \"what does Cursor support\" | `aiwg steward capabilities --provider cursor` |\n| All providers | \"show the full capability matrix\" | `aiwg steward capabilities --all` |\n| Feature check | \"does my provider support agent teams\" | `aiwg steward capabilities --feature agent_teams` |\n| Routing lookup | \"which providers support cron\" | `aiwg steward find --capability cron` |\n| Model routing | \"which model should this use\" | `aiwg steward models`; then `aiwg models audit` or `aiwg models resolve` |\n| 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 |\n| Stale provider files | \"Codex says skills are missing\" | `aiwg status --probe --json`, `aiwg doctor`, `aiwg refresh --dry-run`, then `aiwg use all --provider \u003Cprovider>` or `aiwg refresh --provider \u003Cprovider>` |\n| Stale bootstrap\u002Fcontext | \"doctor says the precedence is superseded\", \"WORKSPACE.md looks wrong\", `precedence-superseded` \u002F `precedence-missing` \u002F `authority-missing` | `aiwg workspace-context doctor`, then `aiwg regenerate` to rewrite the managed blocks; re-run the doctor to confirm healthy |\n| 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 |\n| Stale discovery | \"discover cannot find a known skill\" | Rebuild and sync the framework index, then re-run discovery |\n| Issue cleanup | \"clean up stale issues\" | Discover first: `issue-audit` for backlog cleanup, `address-issues` for implementation, `aiwg-issue` for AIWG product issues |\n| Jev decision offload | \"help me set up jev\", \"use my jev token\" | Follow the Jev setup routing below, then the `decision-offload` rule |\n\n## AIWG Installation Routing\n\nFor an interactive new, existing, stale, broken, duplicate, or development-mode\nAIWG installation, follow\n`https:\u002F\u002Faiwg.io\u002Fsetup.aiwg.yaml` in the\ncurrent supported provider. It is a `provider-orchestrated` manifest: inspect\nand explain before mutation, preserve existing work, then run one self-verifying\n`aiwg use all` deployment and evaluate its `aiwg.use.result.v1` response. Do not\nmake index, regenerate, status, or doctor commands mandatory follow-up steps;\nretain them for an explicit audit, maintenance, or recovery action. Do not send\nthis manifest to deterministic `aiwg setup-run`.\n\nRoute CI, cloud-init, container image, SSH-only, offline, and other\nnon-interactive cases to `docs\u002Finstall\u002Fnon-interactive.md`. Confirm ambiguous\nproject roots and verify each provider separately when a project uses more than\none provider.\n\n## Setup Troubleshooting and Cleanup Routing\n\nThe steward is the primary route when an AIWG setup looks stale, broken, partly\ndeployed, duplicated, or confused by old provider files. Agents should not start\nby grepping `.claude\u002F`, `.codex\u002F`, `.agents\u002F`, `.cursor\u002F`, `.warp\u002F`, or other\nprovider directories. Start with the steward route, use CLI diagnostics, and let\nAIWG decide what to prune or regenerate.\n\nUse this recovery ladder:\n\n1. Discover and load the route if it is not already loaded:\n\n   ```bash\n   aiwg discover \"steward repair AIWG setup\" --type skill\n   aiwg show skill steward --body\n   ```\n\n2. Establish the actual workspace state:\n\n   ```bash\n   aiwg installation show --json\n   aiwg status --probe --json\n   aiwg doctor\n   aiwg runtime-info\n   ```\n\n   Treat `installation.json` in the resolved global user-config directory as\n   the provider-neutral source of truth for installation method, root, update\n   executable, run mode, and channel. Never infer a replacement from the first\n   `npm` or `aiwg` on `PATH`. If the report shows drift, stop ordinary refresh\n   work and ask the operator to choose `aiwg installation adopt` or the\n   explicit `aiwg installation switch --root ... --method ...` recovery path.\n\n   These read-only commands — `version`, `status`, `doctor`, `runtime-info`,\n   `discover`, `show`, and `index query|deps|stats` — keep running under drift\n   and print the drift warning on stderr first. Mutating commands (`update`,\n   `refresh`, `use`, `regenerate`, `index build`, channel switches) fail closed\n   with `AIWG_INSTALLATION_DRIFT` until the identity is repaired, so do not\n   retry them; repair the identity, then continue the ladder.\n\n3. Preview cleanup before changing files:\n\n   ```bash\n   aiwg refresh --dry-run\n   ```\n\n4. Apply the smallest repair that matches the diagnosis:\n\n   ```bash\n   # Re-deploy and prune stale files for the active provider set.\n   aiwg refresh\n\n   # Re-deploy the complete default surface for one provider.\n   aiwg use all --provider \u003Cprovider>\n\n   # Rebuild generated bootstrap\u002Fcontext files when AGENTS.md, AIWG.md,\n   # CLAUDE.md, WARP.md, or other provider bridges are stale.\n   aiwg regenerate\n   ```\n\n5. If discovery itself is stale after source edits, a failed deploy, or an\n   install-root change (`npm link`), rebuild the index and verify the route.\n   **The framework graph indexes the AIWG corpus and can only be built at the\n   install root** — running the build step in a consumer project fails with\n   \"No scan directories found\". Only the sync step runs in the project:\n\n   ```bash\n   cd \"$(aiwg installation show --json | jq -r .actualRoot)\"   # or the known install root\n   aiwg index build --graph framework --force\n\n   cd \u003Cyour project>\n   aiwg index sync --backend fortemi-core --graph framework\n   aiwg discover \"\u003Coriginal user need>\"\n   ```\n\n   `aiwg discover --backend local` works as an immediate workaround while the\n   framework graph is unavailable.\n\n6. Reload the provider session when `aiwg use`, `aiwg refresh`, or\n   `aiwg regenerate` changes provider-facing files.\n\nFor issue cleanup, route through discovery instead of assuming a command:\n\n- AIWG product bug or feature request: `aiwg discover \"file an AIWG issue\"` →\n  `aiwg-issue`\n- Backlog hygiene, stale issues, duplicates, or close\u002Fupdate recommendations:\n  `aiwg discover \"audit open issues\"` → `issue-audit`\n- Implement or process issue work: `aiwg discover \"address issues\"` →\n  `address-issues`\n\nWhen a broken or stale route is confirmed, file an AIWG correction issue with\nthe requested route, observed route, command output, AIWG version, provider, and\nreproduction command. Use `aiwg-issue` for the product issue and include any\n`status --probe` \u002F `doctor` excerpts needed to reproduce the setup failure.\n\n## Jev Setup Routing\n\nWhen the user says \"help me set up Jev\", \"use my jev token\", or anything\nmatching the Jev triggers, walk them through setup in order, then hand off to\nthe `decision-offload` rule:\n\n1. Install or update the CLI:\n\n   ```bash\n   npm i -g aiwg@latest\n   ```\n\n2. Deploy the decision-engine addon (opt-in, excluded from bulk installs):\n\n   ```bash\n   aiwg use decision-engine\n   ```\n\n3. Store the token (never paste it into chat — read it from stdin) and verify:\n\n   ```bash\n   printf '%s' \"$TOKEN\" | aiwg decision setup jev --token-stdin --verify\n   ```\n\n   `setup` writes the credential file atomically with mode 0600 and counts as\n   the explicit opt-in that enables `aiwg decision ask`. Without it, `ask`\n   returns `fallback` with `reason: \"not-configured\"`.\n\n4. From here on, bounded decisions go through the `decision-offload` rule:\n   `aiwg decision ask ... --json`, use the answer when `status` is\n   `answered`, decide normally on `fallback`. Full user-facing steps are in\n   the Jev quickstart:\n\n   `@$AIWG_ROOT\u002Fdocs\u002Fdecision\u002Fjev-quickstart.md`\n\n## Bring Your Own Key\n\nFor \"use my \u003Cprovider> key with \u003Charness>\" (for example \"use my OpenRouter key with Hermes\"),\nroute to `aiwg steward capabilities --provider \u003Charness>` and the `byok` entry in\n`agentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml`. Map Droid to `factory`, and distinguish\nthe inference provider (OpenRouter) from the harness (Hermes, OpenCode, Factory, Copilot,\nCodex or Muse). Return the harness-specific provider\u002Fbase URL, model selector, credential\nenvironment variable or secret-store command, and verification step from that entry.\nFollow its provider-doc link for model-ID quirks; do not invent flags or key settings\nfor unverified routes. These are harness settings, not a new AIWG command.\n\nRead `aiwg show rule token-security --body` before credential guidance. Keys enter only\nvia environment or a secret-store command at point of use, with shell tracing disabled;\nnever ask for a key in chat or put one on argv, in deployed AIWG files, harness config,\nlogs or receipts. Keep credentials scoped to the child process and discard on exit.\nAIWG does not store or manage keys. Explain that BYOK runs bill the user's key and\npaid runs need explicit operator approval, including a verification run; setup alone\ndoes not authorize spending. After approval, use a one-line \"Reply with exactly: byok-ok\"\nprompt and inspect the harness log\u002Fsession for the resolved model. A reply or accepted\nflag alone is insufficient. Report only model, harness version and result, never keys.\n\n## Behavior\n\nWhen triggered:\n\n1. **Identify the subcommand**:\n   - `capabilities` — show what a provider supports, optionally filtered by feature\n   - `find` — show which providers support a capability and how to invoke it\n\n2. **Detect provider context** (for `capabilities` without `--provider`):\n   - Check `CLAUDE_CODE_VERSION` env → `claude-code`\n   - Check `CODEX_API_KEY` env → `codex`\n   - Check `.cursor\u002F` project directory → `cursor`\n   - Fall back to `aiwg runtime-info` for authoritative detection\n\n3. **Run the appropriate command**:\n\n   ```bash\n   # Current provider capabilities (auto-detected)\n   aiwg steward capabilities\n\n   # Named provider\n   aiwg steward capabilities --provider copilot\n\n   # Check specific feature on current provider\n   aiwg steward capabilities --feature agent_teams\n\n   # Full matrix — all providers, all features\n   aiwg steward capabilities --all\n\n   # Find providers that support a capability\n   aiwg steward find --capability cron\n\n   # Model policy and dynamic catalog routing\n   aiwg steward models\n   aiwg models sources --json\n   aiwg models audit --provider codex\n   ```\n\n4. **Interpret and surface routing advice**:\n   - Native support: report the native tool or mechanism\n   - Emulated support: show the `aiwg` command that emulates the feature\n   - No support: report clearly and suggest the nearest alternative\n\n## Direct Worker Onboarding and Readiness\n\nWhen the user asks whether a worker profile is ready to dispatch (\"is codex\nready\", \"onboard the workers\", \"doctor says direct worker not installed\"),\nuse the readiness report — never launch a worker to answer it:\n\n```bash\naiwg doctor\n```\n\nBy default, the direct-worker section of `aiwg doctor` reports configuration\nonly and starts no subprocess for this feature (ordinary `aiwg doctor` does\nstart other subprocesses for unrelated checks — this claim is scoped to\ndirect-worker readiness, not to doctor as a whole). For live install\u002Fversion\nevidence, opt into the bounded probes explicitly:\n\n```bash\naiwg doctor --probe-workers\n```\n\nRead the two facts separately; they never merge. `Direct Worker (\u003Ccli>)`\nchecks report installation readiness (installed with an in-range version,\ninstalled but out of range, banner not matching the registered version\npattern, CLI not installed, probe failed, probe not run, or dispatch\ndisabled). `Direct Worker Dispatch (\u003Ccli>)` checks report dispatch\neligibility. When doctor has the offline model\u002Fcatalog snapshot available\n(worker dispatch on, parallelism valid), this is the actual offline dispatch\nresolver's verdict for every group member referencing the cli — including\nmember-specific refusals and missing installation\u002Fmodel evidence, not a\nre-derived approximation. Without that snapshot it falls back to a\nbinding-only check and says so. Either way, an installed, in-range CLI can\nstill be refused, and the finding says why. Each check carries its config\npointer (file + key), member context, and a `next:` action naming the exact\nfix (install, upgrade\u002Fpin, reinstall, retry the probe, enable dispatch,\nrerun with `--probe-workers`).\n\nAccuracy rules (decision 17 dropped provider-qualification runners and\nevidence files, but the resolver's installation\u002Fmodel-evidence gates stand):\n\n- Never call a profile \"qualified\". All direct profiles are unqualified until\n  an authenticated smoke run; the doctor output says this and names the smoke\n  tracker issue #3005.\n- A `WORKER_DIRECT_READY` finding means only: installed, version in range.\n  It says nothing about dispatch — read the dispatch finding, which stays\n  blocked until the resolver's gates (including the smoke run from #3005)\n  are satisfied. Even an `eligible` dispatch finding is not launch\n  authorization; it means the offline resolver placed the route, under the\n  evidence available to it, without denying it.\n- Probes are opt-in and bounded: `\u003Cexecutable> ...versionArgv` with a cleared\n  environment, explicit working directory, time and output bounds, never a\n  worker launch — and each resolved executable is announced immediately,\n  before it is spawned. **Trust boundary**: the probe runs exactly the\n  executable named by project configuration (or the registry default) with\n  only its registered version arguments. That configuration is an execution\n  trust boundary, not an executable allowlist — project configuration can\n  point at an arbitrary binary, and a `versionArgv` label cannot prove that\n  binary has no side effects. Opting into `--probe-workers` trusts that\n  executable to the same extent any other locally invoked tool is trusted.\n  No new top-level command exists for this — do not invent one.\n\n## Project-Local Authoring Routing\n\nSteward 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`.\n\nRoute these intents directly:\n\n| User intent | Primary route | Notes |\n|---|---|---|\n| Create a repo\u002Fproject-level skill | `aiwg new-bundle \u003Cname> --starter skill` or `aiwg new-extension \u003Cname> --starter skill` | Creates content source under `.aiwg\u002F{extensions,addons,frameworks}\u002F\u003Cname>\u002F`; deploy with `aiwg use \u003Cname>`. |\n| Create a project-level agent | `aiwg new-bundle \u003Cname> --starter agent` or SkillSmith\u002FAgentSmith when generating from a prompt | Use project-local bundle layout so the artifact is versioned with the repo. |\n| Create a custom provider selector | `aiwg new-provider \u003Cname>` or `aiwg new-bundle \u003Cname> --type provider` | Creates `.aiwg\u002Fproviders\u002F\u003Cname>\u002F` with `providerConfig.extends`; select it with `aiwg use \u003Cframework> --provider \u003Cname>`. |\n| Choose extension\u002Faddon\u002Fframework\u002Fplugin\u002Fprovider shape | `aiwg discover \"project-local customization\"` and docs\u002Fcustomization quickstart | Extensions are the usual smallest local customization; addons\u002Fframeworks are heavier. Plugins are marketplace delivery wrappers. Providers are metadata selectors. |\n| Make an agent invoke a custom skill | Create the skill in a project-local bundle, run `aiwg use \u003Cname>`, then reload the provider session | Session reload rules still apply. |\n\nCanonical docs: `docs\u002Fcustomization\u002Fproject-local-quickstart.md`, `docs\u002Fcustomization\u002Fproject-local-lifecycle.md`, and `docs\u002Fcustomization\u002Fextensions-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.\n\nModel-policy caveat: generated skills and commands must carry\n`commandHint.modelRole` and `commandHint.modelTier`; generated agents must carry\n`model-role` and `model-tier`. Do not suggest exact model IDs or legacy\n`haiku|sonnet|opus` choices for new provider-neutral source artifacts.\n\nExternalizing the artifact corpus does not externalize the project control\nplane. Diagnose split-root state with `aiwg status --probe --json` or `aiwg\ndoctor`; preview recovery with `aiwg artifacts repair --dry-run`; use `--apply`\nonly after review. Never overwrite divergent control files or delete divergent\nlocal corpus content.\n\n## Feature-Domain Routing (proactive)\n\nThree 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:\n\n| Domain | Canonical discover phrase | Owning capability |\n|---|---|---|\n| **Expansion authoring** (extension\u002Faddon\u002Fframework) | `aiwg discover \"author an expansion\"` | `scaffold-extension` \u002F `-addon` \u002F `-framework` |\n| **Persona \u002F SOUL** (author **and** select) | `aiwg discover \"create a persona\"` · `aiwg discover \"select a persona\"` | `soul-create`, persona agents under `agentic\u002Fcode\u002Fagents\u002Fpersonas\u002F` |\n| **Project creation** | `aiwg discover \"scaffold a project\"` | `new-project`, `new-bundle` |\n\nRouting protocol:\n\n1. **Volunteer the affordance** (Norman signifier). When a user is near one of these domains but hasn't found the entry point, surface it unprompted: \"you can also author expansions, create or select a persona, or scaffold a project — want me to discover one?\"\n2. **Discover, don't dead-end.** Run the domain's `aiwg discover` phrase; the four discover facets fuse the result so the owning capability ranks top-3.\n3. **Re-query on low confidence.** If the first pass is weak, broaden the phrase or try an adjacent domain before concluding \"not found\" — the `skill-discovery` rule forbids decline-without-search.\n4. **Show the selection.** `aiwg show \u003Ctype> \u003Cname> --body` for the chosen capability.\n\nSee `steward-quickref` for the full anchor tables.\n\n\n## Capability Matrix Source\n\nThe authoritative source is `agentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml`. Key features tracked:\n\n| Feature | Description |\n|---------|-------------|\n| `cron` | Scheduled\u002Frecurring task execution |\n| `agent_teams` | Native multi-agent team orchestration |\n| `tasks` | Background task dispatch |\n| `mcp` | Model Context Protocol server support |\n| `behaviors` | Hook-based behavior scripts |\n| `mission_control` | Multi-session orchestration (`aiwg mc`) |\n\n## Examples\n\n### Example 1: Check current provider\n\n**User**: \"What does my provider support?\"\n\n**Extraction**: Capabilities request, no provider specified — auto-detect\n\n**Action**:\n```bash\naiwg steward capabilities\n```\n\n**Response**: \"You are on **claude-code**. Native support: agent_teams, tasks, mcp, cron. Emulated via aiwg: behaviors (via hooks), mission_control (via `aiwg mc`).\"\n\n### Example 2: Feature-specific check\n\n**User**: \"Does my provider support agent teams natively?\"\n\n**Extraction**: Feature check — `agent_teams` on current provider\n\n**Action**:\n```bash\naiwg steward capabilities --feature agent_teams\n```\n\n**Response**: \"agent_teams on **claude-code**: Native (uses Claude Code's built-in Task tool). No emulation needed.\"\n\n### Example 3: Cross-provider lookup\n\n**User**: \"Which providers support cron natively?\"\n\n**Extraction**: `find` subcommand for `cron` capability\n\n**Action**:\n```bash\naiwg steward find --capability cron\n```\n\n**Response**:\n```\ncron support across providers:\n  claude-code:  native\n  codex:        external trigger (system cron\u002Fsystemd\u002FCI)\n  copilot:      unsupported\n  cursor:       unsupported\n  factory:      unsupported\n  opencode:     unsupported\n  warp:         unsupported\n  windsurf:     unsupported\n  openclaw:     unsupported\n```\n\nExternal means the host scheduler owns time and launches a reviewed provider\ncommand. It is not AIWG emulation; no `aiwg schedule` or `aiwg daemon` command\nexists in the production CLI.\n\n### Example 4: Full matrix\n\n**User**: \"Show me the capability matrix for all providers\"\n\n**Extraction**: `capabilities --all`\n\n**Action**:\n```bash\naiwg steward capabilities --all\n```\n\n**Response**: Formatted table of all named providers and requested features, with native\u002Femulated\u002Funsupported indicators from the authoritative capability matrix.\n\n## Clarification Prompts\n\nIf the user's intent is ambiguous:\n\n- \"Are you asking about the provider you're currently using, or a specific provider?\"\n- \"Should I check all features or a specific one?\"\n\n## References\n\n- @$AIWG_ROOT\u002Fsrc\u002Fcli\u002Fhandlers\u002Fsteward.ts — Steward command handler\n- @$AIWG_ROOT\u002Fagentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml — Authoritative capability matrix\n- @$AIWG_ROOT\u002Fdocs\u002Fcli-reference.md — CLI reference\n","# steward\n\nYou 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.\n\n## Optional signed local merges\n\nRecommend signed merges when repository policy and key access permit them.\nThis is skippable: some users cannot change key usage or repository policies,\nand unsigned delivery must keep working. Use `aiwg steward signed-merges` for\ninstructions, then preview with `--key \u003Cfingerprint> --name \u003Ccommitter>\n--email \u003Cemail> [--format openpgp|ssh|x509] [--key-file \u003Cpath>]`.\nReview the emitted signing, committer, `require_signed_commits`, and\n`delivery.merge=local-signed` config; add `--apply` to save, or `--skip` to\npreserve current settings. Use existing keys; this step changes no repository\npolicies. SSH uses a fingerprint for verification and a key path for signing.\nSet `remotes.tracker_actor.credential` to a store\u002Fenv reference for API writes;\nnever ask users to put tokens in configuration or command arguments.\n\n## Triggers\n\nAlternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):\n\n- \"what can this provider do\" → capabilities for current provider\n- \"is X supported here\" → feature check for current provider\n- \"how do I do X\" (in provider context) → routing advice\n- \"what command handles Y\" → find subcommand\n- \"which model should this use\" → model policy route\n- \"model catalog or routing\" → `aiwg steward models`\n- \"install or repair AIWG\" → public provider-orchestrated setup manifest\n- \"AIWG setup is stale\u002Fbroken\" → steward repair ladder\n- \"refresh provider files\" → status\u002Fdoctor, dry-run refresh, then provider redeploy\n- \"clean up AIWG issues\" → discover `issue-audit`, `aiwg-issue`, or `address-issues`\n\n## Trigger Patterns Reference\n\n| Pattern | Example | Action |\n|---------|---------|--------|\n| Current provider capabilities | \"what does my provider support\" | `aiwg steward capabilities` |\n| Named provider capabilities | \"what does Cursor support\" | `aiwg steward capabilities --provider cursor` |\n| All providers | \"show the full capability matrix\" | `aiwg steward capabilities --all` |\n| Feature check | \"does my provider support agent teams\" | `aiwg steward capabilities --feature agent_teams` |\n| Routing lookup | \"which providers support cron\" | `aiwg steward find --capability cron` |\n| Model routing | \"which model should this use\" | `aiwg steward models`; then `aiwg models audit` or `aiwg models resolve` |\n| 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 |\n| Stale provider files | \"Codex says skills are missing\" | `aiwg status --probe --json`, `aiwg doctor`, `aiwg refresh --dry-run`, then `aiwg use all --provider \u003Cprovider>` or `aiwg refresh --provider \u003Cprovider>` |\n| Stale bootstrap\u002Fcontext | \"doctor says the precedence is superseded\", \"WORKSPACE.md looks wrong\", `precedence-superseded` \u002F `precedence-missing` \u002F `authority-missing` | `aiwg workspace-context doctor`, then `aiwg regenerate` to rewrite the managed blocks; re-run the doctor to confirm healthy |\n| 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 |\n| Stale discovery | \"discover cannot find a known skill\" | Rebuild and sync the framework index, then re-run discovery |\n| Issue cleanup | \"clean up stale issues\" | Discover first: `issue-audit` for backlog cleanup, `address-issues` for implementation, `aiwg-issue` for AIWG product issues |\n| Jev decision offload | \"help me set up jev\", \"use my jev token\" | Follow the Jev setup routing below, then the `decision-offload` rule |\n\n## AIWG Installation Routing\n\nFor an interactive new, existing, stale, broken, duplicate, or development-mode\nAIWG installation, follow\n`https:\u002F\u002Faiwg.io\u002Fsetup.aiwg.yaml` in the\ncurrent supported provider. It is a `provider-orchestrated` manifest: inspect\nand explain before mutation, preserve existing work, then run one self-verifying\n`aiwg use all` deployment and evaluate its `aiwg.use.result.v1` response. Do not\nmake index, regenerate, status, or doctor commands mandatory follow-up steps;\nretain them for an explicit audit, maintenance, or recovery action. Do not send\nthis manifest to deterministic `aiwg setup-run`.\n\nRoute CI, cloud-init, container image, SSH-only, offline, and other\nnon-interactive cases to `docs\u002Finstall\u002Fnon-interactive.md`. Confirm ambiguous\nproject roots and verify each provider separately when a project uses more than\none provider.\n\n## Setup Troubleshooting and Cleanup Routing\n\nThe steward is the primary route when an AIWG setup looks stale, broken, partly\ndeployed, duplicated, or confused by old provider files. Agents should not start\nby grepping `.claude\u002F`, `.codex\u002F`, `.agents\u002F`, `.cursor\u002F`, `.warp\u002F`, or other\nprovider directories. Start with the steward route, use CLI diagnostics, and let\nAIWG decide what to prune or regenerate.\n\nUse this recovery ladder:\n\n1. Discover and load the route if it is not already loaded:\n\n   ```bash\n   aiwg discover \"steward repair AIWG setup\" --type skill\n   aiwg show skill steward --body\n   ```\n\n2. Establish the actual workspace state:\n\n   ```bash\n   aiwg installation show --json\n   aiwg status --probe --json\n   aiwg doctor\n   aiwg runtime-info\n   ```\n\n   Treat `installation.json` in the resolved global user-config directory as\n   the provider-neutral source of truth for installation method, root, update\n   executable, run mode, and channel. Never infer a replacement from the first\n   `npm` or `aiwg` on `PATH`. If the report shows drift, stop ordinary refresh\n   work and ask the operator to choose `aiwg installation adopt` or the\n   explicit `aiwg installation switch --root ... --method ...` recovery path.\n\n   These read-only commands — `version`, `status`, `doctor`, `runtime-info`,\n   `discover`, `show`, and `index query|deps|stats` — keep running under drift\n   and print the drift warning on stderr first. Mutating commands (`update`,\n   `refresh`, `use`, `regenerate`, `index build`, channel switches) fail closed\n   with `AIWG_INSTALLATION_DRIFT` until the identity is repaired, so do not\n   retry them; repair the identity, then continue the ladder.\n\n3. Preview cleanup before changing files:\n\n   ```bash\n   aiwg refresh --dry-run\n   ```\n\n4. Apply the smallest repair that matches the diagnosis:\n\n   ```bash\n   # Re-deploy and prune stale files for the active provider set.\n   aiwg refresh\n\n   # Re-deploy the complete default surface for one provider.\n   aiwg use all --provider \u003Cprovider>\n\n   # Rebuild generated bootstrap\u002Fcontext files when AGENTS.md, AIWG.md,\n   # CLAUDE.md, WARP.md, or other provider bridges are stale.\n   aiwg regenerate\n   ```\n\n5. If discovery itself is stale after source edits, a failed deploy, or an\n   install-root change (`npm link`), rebuild the index and verify the route.\n   **The framework graph indexes the AIWG corpus and can only be built at the\n   install root** — running the build step in a consumer project fails with\n   \"No scan directories found\". Only the sync step runs in the project:\n\n   ```bash\n   cd \"$(aiwg installation show --json | jq -r .actualRoot)\"   # or the known install root\n   aiwg index build --graph framework --force\n\n   cd \u003Cyour project>\n   aiwg index sync --backend fortemi-core --graph framework\n   aiwg discover \"\u003Coriginal user need>\"\n   ```\n\n   `aiwg discover --backend local` works as an immediate workaround while the\n   framework graph is unavailable.\n\n6. Reload the provider session when `aiwg use`, `aiwg refresh`, or\n   `aiwg regenerate` changes provider-facing files.\n\nFor issue cleanup, route through discovery instead of assuming a command:\n\n- AIWG product bug or feature request: `aiwg discover \"file an AIWG issue\"` →\n  `aiwg-issue`\n- Backlog hygiene, stale issues, duplicates, or close\u002Fupdate recommendations:\n  `aiwg discover \"audit open issues\"` → `issue-audit`\n- Implement or process issue work: `aiwg discover \"address issues\"` →\n  `address-issues`\n\nWhen a broken or stale route is confirmed, file an AIWG correction issue with\nthe requested route, observed route, command output, AIWG version, provider, and\nreproduction command. Use `aiwg-issue` for the product issue and include any\n`status --probe` \u002F `doctor` excerpts needed to reproduce the setup failure.\n\n## Jev Setup Routing\n\nWhen the user says \"help me set up Jev\", \"use my jev token\", or anything\nmatching the Jev triggers, walk them through setup in order, then hand off to\nthe `decision-offload` rule:\n\n1. Install or update the CLI:\n\n   ```bash\n   npm i -g aiwg@latest\n   ```\n\n2. Deploy the decision-engine addon (opt-in, excluded from bulk installs):\n\n   ```bash\n   aiwg use decision-engine\n   ```\n\n3. Store the token (never paste it into chat — read it from stdin) and verify:\n\n   ```bash\n   printf '%s' \"$TOKEN\" | aiwg decision setup jev --token-stdin --verify\n   ```\n\n   `setup` writes the credential file atomically with mode 0600 and counts as\n   the explicit opt-in that enables `aiwg decision ask`. Without it, `ask`\n   returns `fallback` with `reason: \"not-configured\"`.\n\n4. From here on, bounded decisions go through the `decision-offload` rule:\n   `aiwg decision ask ... --json`, use the answer when `status` is\n   `answered`, decide normally on `fallback`. Full user-facing steps are in\n   the Jev quickstart:\n\n   `@$AIWG_ROOT\u002Fdocs\u002Fdecision\u002Fjev-quickstart.md`\n\n## Bring Your Own Key\n\nFor \"use my \u003Cprovider> key with \u003Charness>\" (for example \"use my OpenRouter key with Hermes\"),\nroute to `aiwg steward capabilities --provider \u003Charness>` and the `byok` entry in\n`agentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml`. Map Droid to `factory`, and distinguish\nthe inference provider (OpenRouter) from the harness (Hermes, OpenCode, Factory, Copilot,\nCodex or Muse). Return the harness-specific provider\u002Fbase URL, model selector, credential\nenvironment variable or secret-store command, and verification step from that entry.\nFollow its provider-doc link for model-ID quirks; do not invent flags or key settings\nfor unverified routes. These are harness settings, not a new AIWG command.\n\nRead `aiwg show rule token-security --body` before credential guidance. Keys enter only\nvia environment or a secret-store command at point of use, with shell tracing disabled;\nnever ask for a key in chat or put one on argv, in deployed AIWG files, harness config,\nlogs or receipts. Keep credentials scoped to the child process and discard on exit.\nAIWG does not store or manage keys. Explain that BYOK runs bill the user's key and\npaid runs need explicit operator approval, including a verification run; setup alone\ndoes not authorize spending. After approval, use a one-line \"Reply with exactly: byok-ok\"\nprompt and inspect the harness log\u002Fsession for the resolved model. A reply or accepted\nflag alone is insufficient. Report only model, harness version and result, never keys.\n\n## Behavior\n\nWhen triggered:\n\n1. **Identify the subcommand**:\n   - `capabilities` — show what a provider supports, optionally filtered by feature\n   - `find` — show which providers support a capability and how to invoke it\n\n2. **Detect provider context** (for `capabilities` without `--provider`):\n   - Check `CLAUDE_CODE_VERSION` env → `claude-code`\n   - Check `CODEX_API_KEY` env → `codex`\n   - Check `.cursor\u002F` project directory → `cursor`\n   - Fall back to `aiwg runtime-info` for authoritative detection\n\n3. **Run the appropriate command**:\n\n   ```bash\n   # Current provider capabilities (auto-detected)\n   aiwg steward capabilities\n\n   # Named provider\n   aiwg steward capabilities --provider copilot\n\n   # Check specific feature on current provider\n   aiwg steward capabilities --feature agent_teams\n\n   # Full matrix — all providers, all features\n   aiwg steward capabilities --all\n\n   # Find providers that support a capability\n   aiwg steward find --capability cron\n\n   # Model policy and dynamic catalog routing\n   aiwg steward models\n   aiwg models sources --json\n   aiwg models audit --provider codex\n   ```\n\n4. **Interpret and surface routing advice**:\n   - Native support: report the native tool or mechanism\n   - Emulated support: show the `aiwg` command that emulates the feature\n   - No support: report clearly and suggest the nearest alternative\n\n## Direct Worker Onboarding and Readiness\n\nWhen the user asks whether a worker profile is ready to dispatch (\"is codex\nready\", \"onboard the workers\", \"doctor says direct worker not installed\"),\nuse the readiness report — never launch a worker to answer it:\n\n```bash\naiwg doctor\n```\n\nBy default, the direct-worker section of `aiwg doctor` reports configuration\nonly and starts no subprocess for this feature (ordinary `aiwg doctor` does\nstart other subprocesses for unrelated checks — this claim is scoped to\ndirect-worker readiness, not to doctor as a whole). For live install\u002Fversion\nevidence, opt into the bounded probes explicitly:\n\n```bash\naiwg doctor --probe-workers\n```\n\nRead the two facts separately; they never merge. `Direct Worker (\u003Ccli>)`\nchecks report installation readiness (installed with an in-range version,\ninstalled but out of range, banner not matching the registered version\npattern, CLI not installed, probe failed, probe not run, or dispatch\ndisabled). `Direct Worker Dispatch (\u003Ccli>)` checks report dispatch\neligibility. When doctor has the offline model\u002Fcatalog snapshot available\n(worker dispatch on, parallelism valid), this is the actual offline dispatch\nresolver's verdict for every group member referencing the cli — including\nmember-specific refusals and missing installation\u002Fmodel evidence, not a\nre-derived approximation. Without that snapshot it falls back to a\nbinding-only check and says so. Either way, an installed, in-range CLI can\nstill be refused, and the finding says why. Each check carries its config\npointer (file + key), member context, and a `next:` action naming the exact\nfix (install, upgrade\u002Fpin, reinstall, retry the probe, enable dispatch,\nrerun with `--probe-workers`).\n\nAccuracy rules (decision 17 dropped provider-qualification runners and\nevidence files, but the resolver's installation\u002Fmodel-evidence gates stand):\n\n- Never call a profile \"qualified\". All direct profiles are unqualified until\n  an authenticated smoke run; the doctor output says this and names the smoke\n  tracker issue #3005.\n- A `WORKER_DIRECT_READY` finding means only: installed, version in range.\n  It says nothing about dispatch — read the dispatch finding, which stays\n  blocked until the resolver's gates (including the smoke run from #3005)\n  are satisfied. Even an `eligible` dispatch finding is not launch\n  authorization; it means the offline resolver placed the route, under the\n  evidence available to it, without denying it.\n- Probes are opt-in and bounded: `\u003Cexecutable> ...versionArgv` with a cleared\n  environment, explicit working directory, time and output bounds, never a\n  worker launch — and each resolved executable is announced immediately,\n  before it is spawned. **Trust boundary**: the probe runs exactly the\n  executable named by project configuration (or the registry default) with\n  only its registered version arguments. That configuration is an execution\n  trust boundary, not an executable allowlist — project configuration can\n  point at an arbitrary binary, and a `versionArgv` label cannot prove that\n  binary has no side effects. Opting into `--probe-workers` trusts that\n  executable to the same extent any other locally invoked tool is trusted.\n  No new top-level command exists for this — do not invent one.\n\n## Project-Local Authoring Routing\n\nSteward 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`.\n\nRoute these intents directly:\n\n| User intent | Primary route | Notes |\n|---|---|---|\n| Create a repo\u002Fproject-level skill | `aiwg new-bundle \u003Cname> --starter skill` or `aiwg new-extension \u003Cname> --starter skill` | Creates content source under `.aiwg\u002F{extensions,addons,frameworks}\u002F\u003Cname>\u002F`; deploy with `aiwg use \u003Cname>`. |\n| Create a project-level agent | `aiwg new-bundle \u003Cname> --starter agent` or SkillSmith\u002FAgentSmith when generating from a prompt | Use project-local bundle layout so the artifact is versioned with the repo. |\n| Create a custom provider selector | `aiwg new-provider \u003Cname>` or `aiwg new-bundle \u003Cname> --type provider` | Creates `.aiwg\u002Fproviders\u002F\u003Cname>\u002F` with `providerConfig.extends`; select it with `aiwg use \u003Cframework> --provider \u003Cname>`. |\n| Choose extension\u002Faddon\u002Fframework\u002Fplugin\u002Fprovider shape | `aiwg discover \"project-local customization\"` and docs\u002Fcustomization quickstart | Extensions are the usual smallest local customization; addons\u002Fframeworks are heavier. Plugins are marketplace delivery wrappers. Providers are metadata selectors. |\n| Make an agent invoke a custom skill | Create the skill in a project-local bundle, run `aiwg use \u003Cname>`, then reload the provider session | Session reload rules still apply. |\n\nCanonical docs: `docs\u002Fcustomization\u002Fproject-local-quickstart.md`, `docs\u002Fcustomization\u002Fproject-local-lifecycle.md`, and `docs\u002Fcustomization\u002Fextensions-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.\n\nModel-policy caveat: generated skills and commands must carry\n`commandHint.modelRole` and `commandHint.modelTier`; generated agents must carry\n`model-role` and `model-tier`. Do not suggest exact model IDs or legacy\n`haiku|sonnet|opus` choices for new provider-neutral source artifacts.\n\nExternalizing the artifact corpus does not externalize the project control\nplane. Diagnose split-root state with `aiwg status --probe --json` or `aiwg\ndoctor`; preview recovery with `aiwg artifacts repair --dry-run`; use `--apply`\nonly after review. Never overwrite divergent control files or delete divergent\nlocal corpus content.\n\n## Feature-Domain Routing (proactive)\n\nThree 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:\n\n| Domain | Canonical discover phrase | Owning capability |\n|---|---|---|\n| **Expansion authoring** (extension\u002Faddon\u002Fframework) | `aiwg discover \"author an expansion\"` | `scaffold-extension` \u002F `-addon` \u002F `-framework` |\n| **Persona \u002F SOUL** (author **and** select) | `aiwg discover \"create a persona\"` · `aiwg discover \"select a persona\"` | `soul-create`, persona agents under `agentic\u002Fcode\u002Fagents\u002Fpersonas\u002F` |\n| **Project creation** | `aiwg discover \"scaffold a project\"` | `new-project`, `new-bundle` |\n\nRouting protocol:\n\n1. **Volunteer the affordance** (Norman signifier). When a user is near one of these domains but hasn't found the entry point, surface it unprompted: \"you can also author expansions, create or select a persona, or scaffold a project — want me to discover one?\"\n2. **Discover, don't dead-end.** Run the domain's `aiwg discover` phrase; the four discover facets fuse the result so the owning capability ranks top-3.\n3. **Re-query on low confidence.** If the first pass is weak, broaden the phrase or try an adjacent domain before concluding \"not found\" — the `skill-discovery` rule forbids decline-without-search.\n4. **Show the selection.** `aiwg show \u003Ctype> \u003Cname> --body` for the chosen capability.\n\nSee `steward-quickref` for the full anchor tables.\n\n\n## Capability Matrix Source\n\nThe authoritative source is `agentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml`. Key features tracked:\n\n| Feature | Description |\n|---------|-------------|\n| `cron` | Scheduled\u002Frecurring task execution |\n| `agent_teams` | Native multi-agent team orchestration |\n| `tasks` | Background task dispatch |\n| `mcp` | Model Context Protocol server support |\n| `behaviors` | Hook-based behavior scripts |\n| `mission_control` | Multi-session orchestration (`aiwg mc`) |\n\n## Examples\n\n### Example 1: Check current provider\n\n**User**: \"What does my provider support?\"\n\n**Extraction**: Capabilities request, no provider specified — auto-detect\n\n**Action**:\n```bash\naiwg steward capabilities\n```\n\n**Response**: \"You are on **claude-code**. Native support: agent_teams, tasks, mcp, cron. Emulated via aiwg: behaviors (via hooks), mission_control (via `aiwg mc`).\"\n\n### Example 2: Feature-specific check\n\n**User**: \"Does my provider support agent teams natively?\"\n\n**Extraction**: Feature check — `agent_teams` on current provider\n\n**Action**:\n```bash\naiwg steward capabilities --feature agent_teams\n```\n\n**Response**: \"agent_teams on **claude-code**: Native (uses Claude Code's built-in Task tool). No emulation needed.\"\n\n### Example 3: Cross-provider lookup\n\n**User**: \"Which providers support cron natively?\"\n\n**Extraction**: `find` subcommand for `cron` capability\n\n**Action**:\n```bash\naiwg steward find --capability cron\n```\n\n**Response**:\n```\ncron support across providers:\n  claude-code:  native\n  codex:        external trigger (system cron\u002Fsystemd\u002FCI)\n  copilot:      unsupported\n  cursor:       unsupported\n  factory:      unsupported\n  opencode:     unsupported\n  warp:         unsupported\n  windsurf:     unsupported\n  openclaw:     unsupported\n```\n\nExternal means the host scheduler owns time and launches a reviewed provider\ncommand. It is not AIWG emulation; no `aiwg schedule` or `aiwg daemon` command\nexists in the production CLI.\n\n### Example 4: Full matrix\n\n**User**: \"Show me the capability matrix for all providers\"\n\n**Extraction**: `capabilities --all`\n\n**Action**:\n```bash\naiwg steward capabilities --all\n```\n\n**Response**: Formatted table of all named providers and requested features, with native\u002Femulated\u002Funsupported indicators from the authoritative capability matrix.\n\n## Clarification Prompts\n\nIf the user's intent is ambiguous:\n\n- \"Are you asking about the provider you're currently using, or a specific provider?\"\n- \"Should I check all features or a specific one?\"\n\n## References\n\n- @$AIWG_ROOT\u002Fsrc\u002Fcli\u002Fhandlers\u002Fsteward.ts — Steward command handler\n- @$AIWG_ROOT\u002Fagentic\u002Fcode\u002Fproviders\u002Fcapability-matrix.yaml — Authoritative capability matrix\n- @$AIWG_ROOT\u002Fdocs\u002Fcli-reference.md — CLI reference\n",{"name":5,"kernel":53,"triggers":54,"namespace":75,"platforms":76,"description":7},true,[55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74],"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","aiwg",[77],"all","main","ac56f6a215342ed836e51f1945653968b95edd64","agentic\u002Fcode\u002Fplugins\u002Futils\u002Fskills\u002Fsteward",36,"https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg","https:\u002F\u002Faiwg.io","https:\u002F\u002Fgithub.com\u002Fjmagly","https:\u002F\u002Fintegrolabs.io","ml\u002Fai, industrial automation, safety\u002Fsecurity, ssi\r\n\r\nmagly.net\r\nintegrolabs.io\r\naiwg.io\r\nfortemi.com\r\npagenary.com\r\nbytecask.com","2026-11-14 02:10:01",{"source":8,"skillName":5,"commands":89,"prompt":99,"zipAvailable":53},[90,93,96],{"tool":91,"command":92},"npx","npx skills add jmagly\u002Faiwg --skill steward",{"tool":94,"command":95},"bunx","bunx skills add jmagly\u002Faiwg --skill steward",{"tool":97,"command":98},"pnpm","pnpm dlx skills add jmagly\u002Faiwg --skill steward","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Futils\u002Fskills\u002Fsteward\u002FSKILL.md",[],[102,130,154,160,167,181],{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"publishedAt":48},"01M70QA0BSYJ49EES9V4RE8QH1","host-hardening","Read-only system hardening baseline and plan-first host hardening recommendations for SSH, Docker bind addresses, firewall persistence, datastores, exporters and audit retention.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[108],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129],"host","host hardening","hardening","read","re","recommendations","remediation","plan","port","verification","Bash","access","only","retention","audit","never","firewall","bind","secrets","request",{"skillNo":131,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":134,"categories":135,"keywords":140,"publishedAt":48},"01M70PNT2Z4HMZPRBTAF6073NN","exposure-analysis","Read-only firewall analysis and effective host exposure reconstruction for Docker published ports, UFW bypass, stale rules, CDN scope, IPv6 asymmetry and external probe allowlists.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fplugins\u002Fforensics\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[136,139],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[141,142,143,113,144,118,145,146,120,147,110,148,122,149,150,125,126,151,152,153],"exposure analysis","analysis","unknown","credentials","collection","ufw","ports","internet","local","scope","reconstruction","operator","write",{"skillNo":155,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":159,"publishedAt":48},"01M70P8QATMPKA78E4FT5D2TNA","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fsecurity-engineering\u002Fskills\u002Fhost-hardening\u002FSKILL.md",[158],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[112,110,111,121,113,129,116,115,124,117,118,119,120,128,122,123,114,125,126,127],{"skillNo":161,"name":132,"nameZh":6,"description":133,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":162,"categories":163,"keywords":166,"publishedAt":48},"01M70NMPVJ5H0JH131P60FW4R8","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Fagentic\u002Fcode\u002Fframeworks\u002Fforensics-complete\u002Fskills\u002Fexposure-analysis\u002FSKILL.md",[164,165],{"categoryNo":137,"categoryName":138,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[142,141,125,144,118,145,120,143,110,148,122,149,150,113,126,147,146,151,152,153],{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":174,"publishedAt":48},"01M6CB4DDR0B4NNCFK7ZK7449H","fixture-skill","Exercise rule delivery.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Frule-delivery\u002Fskills\u002Ffixture-skill\u002FSKILL.md",[173],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[175,176,177,178,179,180],"fixture skill","fixture","rule","delivery","true","exercise",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"publishedAt":48},"01M6CB4AVK1W76MFMPP0JP32CJ","pi-local","Pi-local duplicate-precedence fixture.","https:\u002F\u002Fgithub.com\u002Fjmagly\u002Faiwg\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fproviders\u002Fpi\u002Fproject\u002F.pi\u002Fskills\u002Fpi-local\u002FSKILL.md",[187],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[189,190,149,191,176],"pi","pi local","duplicate"]