coilyco-flight-deck/ward

Fork 0

skills: ward owns its own `ward agent` dispatch skill (move tooling-ward-agent out of agentic-os-kai) #286

New issue

Closed

opened 2026-06-24 16:50:57 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-06-24 16:50:57 +00:00

Member

Principle

An exclusively ward-focused skill must not live outside the ward repo. tooling-ward-agent - normalize a dictated ward agent phrase to a canonical ref and pick a surface - is ward-only, but its canonical copy lives in coilyco-bridge/agentic-os-kai/.agents/skills/tooling-ward-agent/ (SKILL.md + references/normalization.md + references/surfaces.md). It should ship from ward, next to the code it documents, so a surface change (e.g. the build/pair rename in #283) updates the skill in the same PR instead of drifting behind a cross-repo follow-up nobody runs.

Why this is more than a `git mv`

The skill reaches Kai's Claude harness today because agentic-os-kai's .agents/skills/ is mounted directly by scripts/mount-skills.sh. The existing "capability pull" (scripts/pull-capabilities.py, driven by categories.yaml) that could source a skill from another repo is scoped to the qwen-opencode thin slice, not the Claude surface. So the real work is teaching the mount/pull path to surface a skill authored in ward into Kai's harness, then removing the agentic-os-kai canonical copy. That wiring lives in agentic-os-kai.

Changes

ward (this repo)

Add .agents/skills/tooling-ward-agent/ (SKILL.md + references/normalization.md + references/surfaces.md), moved from agentic-os-kai and retargeted to ward's current surface (drop the stale work/headless framing once #283 lands).
This makes ward the canonical source; the skill now versions with the code.

agentic-os-kai (grant via --repo coilyco-bridge/agentic-os-kai)

Extend scripts/mount-skills.sh (and/or generalize the capability pull beyond the qwen slice) so a skill authored in coilyco-flight-deck/ward/.agents/skills/ is sourced into Kai's Claude/Codex skill surface - the same way agentic-os repo-pointer skills are aggregated today.
Remove the canonical .agents/skills/tooling-ward-agent/; update MEMORY.md/index and refresh-symlinks orphan sweep so the rename leaves no dangling symlink.
Run make refresh-symlinks / make validate-skills to confirm the ward-sourced skill mounts and validates.

Generalization (note, not scope)

The underlying rule - "a skill that references exactly one repo belongs in that repo" - could become a catalog lint in agentic-os (a check_* validator flagging a single-repo skill hosted elsewhere). Out of scope here; file separately if wanted.

Sequencing

Land before #283 so the verb rename edits the in-repo skill. This supersedes that issue's "separate-repo follow-up" note for the skill.

Done condition

tooling-ward-agent is canonical in ward, sourced into Kai's harness via the mount path, removed from agentic-os-kai with no dangling symlink, make validate-skills green in agentic-os-kai, both sides merged to main.

## Principle An exclusively ward-focused skill must not live outside the ward repo. `tooling-ward-agent` - normalize a dictated `ward agent` phrase to a canonical ref and pick a surface - is ward-only, but its canonical copy lives in `coilyco-bridge/agentic-os-kai/.agents/skills/tooling-ward-agent/` (SKILL.md + `references/normalization.md` + `references/surfaces.md`). It should ship from ward, next to the code it documents, so a surface change (e.g. the `build`/`pair` rename in https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/283) updates the skill in the same PR instead of drifting behind a cross-repo follow-up nobody runs. ## Why this is more than a `git mv` The skill reaches Kai's Claude harness today because `agentic-os-kai`'s `.agents/skills/` is mounted directly by `scripts/mount-skills.sh`. The existing "capability pull" (`scripts/pull-capabilities.py`, driven by `categories.yaml`) that *could* source a skill from another repo is scoped to the qwen-opencode thin slice, not the Claude surface. So the real work is teaching the mount/pull path to surface a skill **authored in ward** into Kai's harness, then removing the agentic-os-kai canonical copy. That wiring lives in agentic-os-kai. ## Changes **ward (this repo)** - Add `.agents/skills/tooling-ward-agent/` (SKILL.md + `references/normalization.md` + `references/surfaces.md`), moved from agentic-os-kai and retargeted to ward's current surface (drop the stale `work/headless` framing once https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/283 lands). - This makes ward the canonical source; the skill now versions with the code. **agentic-os-kai (grant via `--repo coilyco-bridge/agentic-os-kai`)** - Extend `scripts/mount-skills.sh` (and/or generalize the capability pull beyond the qwen slice) so a skill authored in `coilyco-flight-deck/ward/.agents/skills/` is sourced into Kai's Claude/Codex skill surface - the same way agentic-os repo-pointer skills are aggregated today. - Remove the canonical `.agents/skills/tooling-ward-agent/`; update `MEMORY.md`/index and `refresh-symlinks` orphan sweep so the rename leaves no dangling symlink. - Run `make refresh-symlinks` / `make validate-skills` to confirm the ward-sourced skill mounts and validates. ## Generalization (note, not scope) The underlying rule - "a skill that references exactly one repo belongs in that repo" - could become a catalog lint in agentic-os (a `check_*` validator flagging a single-repo skill hosted elsewhere). Out of scope here; file separately if wanted. ## Sequencing Land before https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/283 so the verb rename edits the in-repo skill. This supersedes that issue's "separate-repo follow-up" note for the skill. ## Done condition `tooling-ward-agent` is canonical in ward, sourced into Kai's harness via the mount path, removed from agentic-os-kai with no dangling symlink, `make validate-skills` green in agentic-os-kai, both sides merged to main.

coilyco-ops referenced this issue

2026-06-24 16:51:40 +00:00

warded: rename the carry verbs - build (carry), pair (interactive), fold in task #283

coilyco-ops added the

interactive

labels

2026-06-24 17:20:18 +00:00

coilyco-ops commented

2026-06-24 17:25:11 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container ward-ward-issue-286-claude-dcc064c8 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-06-24T17:25:10Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `ward-ward-issue-286-claude-dcc064c8` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-06-24T17:25:10Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-06-24 17:30:39 +00:00

Author

Member

Re-triage (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24)

P2 - Cross-repo skill move with real mount/pull wiring (more than a git mv), committed-direction next-tier work.
interactive - Touches the skill mount path into Kai's harness and removes a canonical copy, so a human verifies the surface still resolves.

**Re-triage** (goose-triage method, claude-macos-kais-macbook-pro-2 as the judgment engine, 2026-06-24) - **P2** - Cross-repo skill move with real mount/pull wiring (more than a git mv), committed-direction next-tier work. - **interactive** - Touches the skill mount path into Kai's harness and removes a canonical copy, so a human verifies the surface still resolves.

coilysiren referenced this issue from a commit

2026-06-24 17:51:17 +00:00

feat(skills): ward owns its own `ward agent` dispatch skill (ward#286)

coilysiren closed this issue

2026-06-24 17:51:17 +00:00

coilysiren referenced this issue from a commit

2026-06-24 17:51:43 +00:00

feat(skills): source ward-authored tooling-ward-agent from ward (ward#286)

coilysiren commented

2026-06-24 17:53:41 +00:00

Owner

Honest retro: the title says "move a skill," but it was really a retarget. The old copy still documented the "ward agent work " form and defaulted every ref to a coilysiren owner, which would now refuse to dispatch ward itself and the other repos that have since spread across four orgs. Most of the work was making the normalization correct again, not the git mv. The mount side was the easy half: the new aggregate_authored_skills mirrors the repo-pointer and hardware aggregations already in mount-skills.sh, and because .claude/skills is fully rebuilt each run, the old canonical symlink drops out with nothing dangling. I also added a small categories.yaml so the check-skills gate actually validates the skill ward now owns, since it was a silent no-op before.

Two rough edges. The 4000-char SKILL.md cap is tight, and the retarget blew past it, so the prose is trimmed close to the bone (3994 of 4000). And this container hit the ward#288 credential clobber: /etc/ward-git-credentials came up 0600 root:root, unreadable by the non-root agent, so I pushed both repos through a GIT_ASKPASS shim reading FORGEJO_TOKEN. Worth a look, since the bootstrap is meant to re-assert those perms before the drop. Confidence is high on the ward side (build and CI both green), a little lower on the mount, which I could only check against a simulated tree here rather than the real projects layout. A refresh-symlinks run on the host is the true confirmation.

— Claude (she/her), via ward agent

Honest retro: the title says "move a skill," but it was really a retarget. The old copy still documented the "ward agent <mode> work <ref>" form and defaulted every ref to a coilysiren owner, which would now refuse to dispatch ward itself and the other repos that have since spread across four orgs. Most of the work was making the normalization correct again, not the git mv. The mount side was the easy half: the new aggregate_authored_skills mirrors the repo-pointer and hardware aggregations already in mount-skills.sh, and because .claude/skills is fully rebuilt each run, the old canonical symlink drops out with nothing dangling. I also added a small categories.yaml so the check-skills gate actually validates the skill ward now owns, since it was a silent no-op before. Two rough edges. The 4000-char SKILL.md cap is tight, and the retarget blew past it, so the prose is trimmed close to the bone (3994 of 4000). And this container hit the ward#288 credential clobber: /etc/ward-git-credentials came up 0600 root:root, unreadable by the non-root agent, so I pushed both repos through a GIT_ASKPASS shim reading FORGEJO_TOKEN. Worth a look, since the bootstrap is meant to re-assert those perms before the drop. Confidence is high on the ward side (build and CI both green), a little lower on the mount, which I could only check against a simulated tree here rather than the real projects layout. A refresh-symlinks run on the host is the true confirmation. — Claude (she/her), via ward agent

coilyco-ops referenced this issue

2026-06-24 17:58:59 +00:00

headless --repo: a secondary-repo push can silently fail while the run closes the issue as done #291