The kit's pitch is "install this harness and trust it to run your project" — 12 agents, 32 skills, self-improving memory. This is a suggestion (plus reusable prior art) for making that trust verifiable rather than implied.
When a user installs the kit, they grant it whatever its skills can do — and that surface is implicit in the markdown. Parsing this repo's .claude/skills with a capability scanner: 17 of the 31 parseable skills contain shell commands (git, gh, node, npm/npx/pnpm, …), 18 reference external URLs, and none declare allowed-tools — which is normal, the format barely carries that information. For ecosystem context: across ~17,000 public Claude Code skills we scanned, 38.8% contain shell commands and only 4% declare them (data + methodology).
For a kit that updates itself (vc:update) and ships frequently, two concrete uses:
- A committed capability manifest (
skills.lock): a machine-readable statement of exactly what each of the 32 skills can execute, fetch, read, and write. Users can audit it in one file instead of 32.
- A CI gate on your own releases: a PR that changes any skill's behavior surface (new shell verb, new endpoint, new path) gets blocked until the delta is approved — so every release can honestly say "capability surface reviewed". A reworded paragraph and a new
curl | bash look identical in git diff; this catches the difference.
Prior art: skil-lock (Apache-2.0 CLI + GitHub Action) does the parse → lock → diff cycle for .claude/skills and .codex/skills. Spec: SPEC.md. Happy to help wire it up if useful; if it doesn't fit the kit's direction, feel free to close.
The kit's pitch is "install this harness and trust it to run your project" — 12 agents, 32 skills, self-improving memory. This is a suggestion (plus reusable prior art) for making that trust verifiable rather than implied.
When a user installs the kit, they grant it whatever its skills can do — and that surface is implicit in the markdown. Parsing this repo's
.claude/skillswith a capability scanner: 17 of the 31 parseable skills contain shell commands (git,gh,node,npm/npx/pnpm, …), 18 reference external URLs, and none declareallowed-tools— which is normal, the format barely carries that information. For ecosystem context: across ~17,000 public Claude Code skills we scanned, 38.8% contain shell commands and only 4% declare them (data + methodology).For a kit that updates itself (
vc:update) and ships frequently, two concrete uses:skills.lock): a machine-readable statement of exactly what each of the 32 skills can execute, fetch, read, and write. Users can audit it in one file instead of 32.curl | bashlook identical ingit diff; this catches the difference.Prior art: skil-lock (Apache-2.0 CLI + GitHub Action) does the parse → lock → diff cycle for
.claude/skillsand.codex/skills. Spec: SPEC.md. Happy to help wire it up if useful; if it doesn't fit the kit's direction, feel free to close.