Kevin Veen-BirkenbachandClaude Opus 5.5
624baccfc4
All 38 first-party skills move to kvb-<category>-<name> with the categories think, create, code, ci, git, check, org and skills; kvb-cleanup and kvb-help are the only uncategorized names. tests/test_naming.py pins the schema, the Agent Skills name rules and the README organigram. enable-plugins.js repoints hook commands of renamed skills in settings.local.json so a stale script path cannot block tools. BREAKING CHANGE: the old skill names and slash commands (/commit-next, /dream, /autotune, ...) are gone; use their kvb- successors listed in the README organigram. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
1.2 KiB
1.2 KiB
name, description
| name | description |
|---|---|
| kvb-think-explain | Explain code and its interactions. Trigger when the operator asks what code does, how a mechanism works, why components interact, or invokes /kvb-think-explain on a file, function, role or module. |
Explain the named code so an engineer who has never seen it can follow it:
- Read the code and every collaborator it touches (callers, callees, templates, configs) before explaining; never explain from the name alone.
- Lead with the purpose in one sentence, then walk the flow in execution order: inputs, transformations, side effects, outputs. Name the real files and line references.
- Make the interactions explicit: which component induces, triggers, or consumes which, and where the single source of truth lives. Point out trip-wires (non-obvious ordering, escaping, caching, permission edges) as part of the flow, not as an appendix.
- Afterwards ask whether to persist a Mermaid diagram of the explained
mechanism under a
## Schemaheading in the README.md next to the affected code (create the heading if missing, replace its previous diagram if present). On approval, keep the diagram to the explained scope: components as nodes, induction/data flow as labeled edges.