GitWorktrees.seedSkills copies memberSkills:-seeded skill folders into every
provisioned worktree's .claude/skills/ and logged "skill seeding: N of M" as
if that were success — but .claude/skills/ is a Claude Code CLI convention.
opencode has no such discovery, so a kind: opencode member never actually
read a seeded skill even though the log said N of M succeeded.
Two changes, both required:
1. Deliver it. OpenCodeLauncher.skillInstructionFiles scans
<cwd>/.claude/skills/*/SKILL.md at spawn time (the one point the launcher
knows both the kind and the cwd) and appends each to the generated
opencode.json's instructions[] array, the same channel already used for
the member charter and IDE rules. A skill folder with no SKILL.md is
named and skipped rather than silently dropped.
2. Stop claiming it where the claim can't be verified. GitWorktrees.seedSkills'
log now says explicitly that consumption depends on the member's kind and
points at the launcher's own log; OpenCodeLauncher logs its own kind-aware
"skill delivery: M of N ..." line once the kind is actually known, naming
any folder it could not turn into an instructions[] entry.
fleetd.example.yaml's memberSkills: doc previously claimed "Claude Code
members only; an opencode member reads a different path (.opencode/agent)
this key does not touch" — false as of this fix, corrected to name both
kinds and how each consumes it.
Tests: OpenCodeLauncherTest gains two cases driving the real
GitWorktrees#add seeding path (not a hand-built fixture) into an
opencode-kind spawn — one asserting a seeded skill's SKILL.md lands in
instructions[] plus the honest log line, one covering a skill folder
without SKILL.md (delivered skills still flow, the malformed one is named
in the log and excluded from instructions[]). ClaudeCodeLauncher is
untouched — its native .claude/skills/ discovery already worked and is out
of scope.
mvn -B clean test: Tests run: 1603, Failures: 0, Errors: 0, Skipped: 0 — BUILD SUCCESS
Dai Ha
d4a2cd720c