Kevin Veen-BirkenbachandClaude Opus 5.5
8b0c287ada
The skill listing stood at 1498 of 1500 words; the trimmed descriptions bring it to 1420, so the new kvb-check-ansible description fits without pushing others out. 🎯 Fix: 95 % 💥 Break: 1 % 💸 Cost: 99 % ⏱️ Time: 100 % 🛡️ Security: 100 % 🏆 Score: 95 🚦 Gate: ✅ 90/5, cost and time <= 100, security 100 % Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
name, description
| name | description |
|---|---|
| kvb-think-explain | Explain on request what code does, how a mechanism works or why components interact. |
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.
Explore through the codebase-memory-mcp graph first (
search_graph,trace_path,get_architecture; thekvb-agent-optimizeskill sets it up), grep and read after. - Lead with the purpose in one sentence, then walk the flow in execution order: inputs, transformations, side effects, outputs, with 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) in the flow, not in 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 and data flow as labeled edges.