refactor(skills): cap every SKILL.md at 600 words and cut agent messages

Every loaded SKILL.md and every listed description is paid on every turn of every session, and every delivered message costs its recipient a full turn. scripts/budget.py gains SKILL_WORDS = 600, enforced by test_lock, and test_naming forbids a skill naming its own slash command; 53 descriptions and 10 body lines drop it. The 18 longest skills move details into 31 side files read only in their situation (organize's capacity, succession, peers, offices, relay and lineage; cleanup's docker, worktrees, execute and ask; code-tune, changelog, triage, dream, split and others), so all SKILL.md files shrink from 33866 to 26291 words without dropping a rule; an independent review of HEAD against the new text found no loss in 60 of 64 skills and three weakenings, now restored (WSJF re-estimates after an objective change, cleanup's volume checklist, essence's absolute dates).

The kvb-org-organize Peer protocol sends status that asks nothing to the news board, answers nothing that asks nothing, keeps messages terse, and lets light runs admit themselves in the operator's wording; the skills follow it (operator reads the register, relax and wakeup reply through the news, evening collects them there, wsjf asks only for missing estimates, cleanup and triage batch their questions). Skills that explore code ask the codebase-memory-mcp graph first, subagent briefs scale with the stakes and cap their answers, and the skills that need the full register or council tables call show --wide or list --long.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

skills/kvb-think-explain/SKILL.md

@@ -2,23 +2,25 @@
 name: kvb-think-explain
 description: >
   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.
+  does, how a mechanism works or why components interact.
 ---
 
 Explain the named code so an engineer who has never seen it can follow it:
 
 1. 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`; the `kvb-agent-optimize` skill sets it
+   up), grep and read after.
 2. 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.
-3. Make the interactions explicit: which component induces, triggers, or
+   order: inputs, transformations, side effects, outputs, with real files
+   and line references.
+3. 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.
+   trip-wires (non-obvious ordering, escaping, caching, permission edges) in
+   the flow, not in an appendix.
 4. Afterwards ask whether to persist a Mermaid diagram of the explained
    mechanism under a `## Schema` heading 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.
+   scope: components as nodes, induction and data flow as labeled edges.