tooling-ward-agent

name	tooling-ward-agent
description	Normalize a dictated ward agent phrase to owner/repo#N and dispatch the detached engineer. Triggers - ward agent, dispatch, fire an agent, spawn an agent, fan out.

tooling-ward-agent

ward agent <role> <ref> is a privileged op: it spins an ephemeral container that fresh-clones the repo and carries the repo's authoritative issue thread to merge under bypassPermissions. Mis-parsing a dictated ref silently sends an agent at the wrong issue. This skill normalizes a dictated reference into a canonical owner/repo#N and dispatches the engineer (successor to ward dispatch/ward drive; ward#174, ward#282; roster rename ward#347). Canonical in coilyco-flight-deck/ward (ward#286).

Assumptions

Fan-out happens before this skill (writing-to-issues/tooling-sidequest sliced the work and filed the issues). This skill takes one dictated reference to one already-open issue, resolves it, dispatches the engineer, hands off - it does not slice work or create issues.

When to fire

Any user phrase containing "dispatch", "agent", or "spawn" plus a numeric tail. Also "fan out" and "run claude on" paired with an issue. Interactive-intent phrasing ("open one for me", "let me iterate on this", "HITL this") no longer maps to engineer - it is detached-only (ward#356); route that to the director, out of this skill's scope.

Do NOT fire when the user already typed a clean owner/repo#N or an issue URL - pass straight through to ward agent. A bare #N from inside a repo checkout also passes straight through: ward agent infers owner/repo from the cwd's git origin (ward#282).

Step 1: refresh the registry

data/repo-registry.md in coilyco-bridge/agentic-os-kai carries each active repo's canonical owner/repo, regenerated daily (sync-repo-registry.yml), so the local checkout lags. Read the live copy before resolving:

gh api repos/coilyco-bridge/agentic-os-kai/contents/data/repo-registry.md --jq '.content' | base64 -d

If gh is unreachable, fall back to local with a one-line caveat to Kai.

Step 2: resolve the ref

Lowercase the repo tokens, strip hyphens/spaces, fuzzy-match the registry's repo column, and take the owner from the matched row - repos span four orgs, so the owner is per-repo, not a fixed default. The full filler list and the baked-in voice-collision table (e.g. "coily" alone -> coilyco-bridge/coily, "coily co ai" -> coilyco-bridge/agentic-os-kai) live in references/normalization.md. Use it, do not guess.

Step 3: confirm, or refuse and explain

Confirm one line with the issue title from the relevant tracker API (ward ops forgejo issue view <owner> <repo> <N>, or gh issue view <ref> for a GitHub ref):

Resolved: coilyco-bridge/coily#125 - "". Send an agent?

Skip confirmation only on a unique, unambiguous match; ALWAYS confirm when two repos fuzzy-match. Refuse (naming the failing condition) if the issue is closed, the owner is outside the four-fleet-org trust set (see references/normalization.md), the repo did not resolve, or the lookup errors.

Step 4: dispatch the engineer

ward agent <role> <ref> takes a role (engineer|director|advisor; ward#347, ward#353) and --harness picks the harness (default claude; --agent is an equal spelling, ward#660). This skill dispatches engineer, which is detached / autonomous only (ward#356): a bare ref runs it fire-and-forget; the PR is the review gate. No attach surface - hands-on work is the director, not this skill. Heuristics + examples: references/surfaces.md.

ward agent engineer coilyco-flight-deck/<repo>#<N>           # detached, fire-and-forget

Out of scope

• Container model, clone, seeding, reservation, reaper, audit (owned by ward agent).
• Authoring the issue body (Kai's job); slicing work into issues (writing-to-issues, tooling-sidequest).