Files

T

nntrivi2001 c781fcdb45 docs(lanes): design F3b — ccam skills install (E)

Found auditing E1-F3a for Shipyard parity: .claude/skills/ship-feature-lane/
only exists inside ccam-lanes' own repo, never installed globally, so
/ship-feature-lane is unreachable from its actual intended invocation
context (a session inside some OTHER lane's repo). Shipyard's own
install-claude-assets.sh solves this for its bundled skills the same way.

2026-08-05 17:12:37 +07:00

3.3 KiB

Raw Blame History

F3b — `ccam skills install`: making `/ship-feature-lane` actually invokable

Status: approved 2026-08-05. Roadmap it belongs to: docs/superpowers/plans/2026-08-03-shipyard-parity-lanes.md (subsystem E, a gap found auditing E1-F3a for Shipyard parity).

Problem

.claude/skills/ship-feature-lane/SKILL.md's own description says "Invoke inside a lane's working directory" — but Claude Code only auto-discovers a .claude/skills/ directory when the session's cwd is inside the repo that OWNS that directory. The skill lives only at ccam-lanes/.claude/skills/ship-feature-lane/SKILL.md; confirmed empty: ~/.claude/skills/ has no ship-feature-lane entry. Every piece built across E1/E2/E3/F1/F3a is unreachable from its actual intended invocation context — a session inside some OTHER lane's repo, not inside ccam-lanes itself.

Shipyard's own install-claude-assets.sh solves exactly this: it copies bundled skills into ~/.claude/skills/ (user-level, global) so every project's session sees them.

Scope

In scope:

ccam skills install — copies <ccam-lanes repo>/.claude/skills/ship-feature-lane/ to ~/.claude/skills/ship-feature-lane/, overwriting on reinstall (same "reinstall, not merge" shape as ccam lanes agents install).
docs/LANES.md note.

Out of scope:

Changing ccam lanes agents install's existing per-lane .claude/agents/ mechanism. That one's already reachable correctly (Claude Code discovers .claude/agents/ from the lane's own cwd, which IS where a driving session runs) — this gap is specific to the SKILL, not the agents. No architecture change needed there.
Auto-running this from npm run setup or any other command. Explicit, like every other install primitive in this codebase (lanes agents install, lanes mcp sync, lanes proof-link) — a human runs it once per machine.
Any other bundled skill Shipyard ships (/review-prs, /harness-adapt) — CCAM has no equivalent of either; out of scope by the same reasoning pr-reviewer was dropped (no driving skill to attach to).

Design

bin/ccam.js already has REPO_ROOT (path.resolve(path.dirname(fs.realpathSync(__filename)), "..")) — the exact self-location primitive Shipyard needed HARNESS_ROOT for, already present because ccam is npm-linked. No new resolution logic needed.

cmdSkillsInstall() in bin/ccam.js (no HTTP round-trip — this has nothing to do with any lane or the dashboard's DB, purely a local file copy from the CLI's own checkout to the user's home directory; matches the existing local-only pattern cmdLanesProfileInit already uses via REPO_ROOT).
Copies path.join(REPO_ROOT, ".claude", "skills", "ship-feature-lane") → path.join(os.homedir(), ".claude", "skills", "ship-feature-lane") via fs.cpSync(..., {recursive: true, force: true}) (force: true = overwrite existing files, matching reinstall semantics).
Command: ccam skills install, no lane argument (nothing lane-specific here).

Verify

A unit test isn't practical for a command that writes into the real $HOME — instead: a manual smoke check (run the command, confirm ~/.claude/skills/ship-feature-lane/SKILL.md exists and matches the repo's own copy byte-for-byte), same verification shape this repo already uses for routes with no HTTP test harness.

3.3 KiB Raw Blame History

F3b — ccam skills install: making /ship-feature-lane actually invokable