# Skill-cohesion / composition prompt (Opus 4.8)

A prompt to audit every videoclaw skill, command, and script and rewire them so skills
compose — delegating to canonical commands and to each other instead of reimplementing —
so the whole product works hand in hand. Authored with the `prompting-opus-4-8` skill
(enumerated scope, explicit parallel fan-out, verify-against-code, audit -> plan-gate ->
implement).

Run at **xhigh** effort with a large output budget.

```text
You're working on videoclaw-v3 (the `vclaw` CLI). The product has grown organically — many
skills, many commands, many scripts — and they don't all compose cleanly. I want everything
working hand in hand: skills should reuse each other and call the canonical commands rather
than reimplementing logic, every front-door should route to the right lane, and no
capability should be duplicated or orphaned. The goal is one coherent system where the
skills, commands, and code reference each other correctly.

Ground truth is the code, not your memory. The authoritative inventory is: every
skills/<name>/SKILL.md, skills/catalog.json, the COMMANDS array in src/video/cli-schema.ts
(with its count assertion in src/tests/cli-schema.test.ts), `vclaw --help` and per-command
`--help`, the handlers in src/cli/handlers/, the npm scripts in package.json, and the
scripts under scripts/ and references/. Read these to build the real picture before changing
anything.

Scope is the WHOLE system, not a sample. Treat each of these as something to inspect:
- every skill in skills/ and its catalog.json entry
- every CLI command/alias in the COMMANDS array and its handler
- every npm script and every script under scripts/ (guardrail scripts, wrappers, helpers)
- the cross-references between all of the above
Review each one; don't generalize from the first few you look at.

What "works hand in hand" means concretely — find and fix these:
1. DUPLICATION: a skill (or script) that reimplements logic a CLI command or another skill
   already owns. The skill should DRIVE the canonical command, not re-derive it. Collapse the
   duplicate onto the owner.
2. MISSING COMPOSITION: a skill that should delegate to another skill or command but doesn't.
   Wire it using the project's cross-reference convention — an explicit "REQUIRED SUB-SKILL:
   <name>" / "use the <command> command" pointer in the SKILL.md — rather than copying the
   sub-skill's steps inline. Skills within skills, not skills repeating skills.
3. FRONT-DOOR ROUTING: orchestrator/front-door skills (e.g. the concierge/clawbot lane menu,
   brand-agency's phases, character-ad) must route to the correct lane skills and commands
   that actually exist today. Fix any lane that points at a renamed, removed, or wrong target.
4. ORPHANS & GAPS: a command no skill surfaces, or a skill whose underlying command was
   renamed/removed. Reconnect them or flag for removal.
5. STALE/BROKEN REFERENCES: any SKILL.md pointing at a path, command, flag, or skill name
   that no longer matches the code. Correct it to the real one.
6. CONSISTENCY: the same primitive (character sheets, storyboard grid, seedance packets,
   audio, assemble, preview/portal) should be invoked the same canonical way everywhere, so
   lanes share one path instead of diverging.

Spawn parallel subagents — Opus does not fan out on its own. Dispatch subagents to map
independent slices concurrently (skills inventory + their stated dependencies; the command
surface from cli-schema/--help; the scripts; the catalog.json parity), and keep working
while they run. Have them return a single shared artifact: a dependency map of
skill -> {sub-skills it should use, commands it should drive} and a list of every mismatch
(where it is, what's wrong, what the correct target is, with the file/command that proves it).

Work in two passes:
1. MAP & AUDIT (parallel): build the dependency map and the mismatch list across the whole
   system. Then show me the map and a short ranked plan (which rewires matter most), and pause
   once for me there. Where something already composes correctly, say so and leave it alone —
   don't churn working skills.
2. REWIRE (after I approve): make skills compose. Replace inline reimplementations with
   pointers to the owning command/sub-skill; fix front-door routing; reconnect orphans;
   correct stale references; converge divergent paths onto the canonical one. Edit SKILL.md
   files, catalog.json, and thin command glue only — do NOT rewrite or refactor the working
   command implementations themselves. This is wiring and composition, not a rewrite.

Conventions and guardrails:
- Keep each skill's structure and voice; you're adjusting how it composes, not restyling it.
- Don't reintroduce legacy paths — skills/check:skill-frontdoor bans stale ~/.claude/skills
  and legacy-pipeline references; keep it green.
- Run `npm run check:skill-frontdoor`, `npm run check:cleanroom-docs`, and the
  skills/catalog.json parity test, plus `npm run build` and `npm test`, before declaring a
  batch done. If you touch the command set, update the count assertion in cli-schema.test.ts.
  Note: check:release-readiness-lite has historically exited 0 even on a failing test — read
  the actual test output, don't trust the exit code.

Verify before you claim done. Before reporting a rewire as correct, confirm the target it now
points at actually exists in the code/--help you read this session, and that the composed flow
runs end to end (or say which seam you couldn't exercise). Don't claim a guardrail passed
unless you ran it.

When you finish, lead with the outcome — how many skills now compose correctly, which
duplications you collapsed, which front-doors you fixed, and that the guardrails and build
pass — then the per-skill detail. Plain sentences, each skill and command its own clause.
```