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>

scripts/budget.py

@@ -1,5 +1,5 @@
 #!/usr/bin/env python3
-"""Count every first-party skill description against the listing budget.
+"""Count every first-party skill description against the listing budget, and each SKILL.md against its cap.
 
 Args:
     --repo: skills repository root.
@@ -19,6 +19,14 @@ from pathlib import Path
 
 LISTING_WORDS = 1500
 DESCRIPTION_WORDS = 40
+SKILL_WORDS = 600
+
+
+def skill_sizes(repo: Path) -> dict[str, int]:
+    return {
+        p.parent.name: len(p.read_text(encoding="utf-8").split())
+        for p in sorted((repo / "skills").glob("*/SKILL.md"))
+    }
 
 
 def words(skill_md: str) -> int:
@@ -65,7 +73,10 @@ def main() -> int:
         print(f"{n}\t{name}")
     for name in over:
         print(f"over {DESCRIPTION_WORDS}: {name}")
-    return 1 if total > LISTING_WORDS or over else 0
+    long = sorted(name for name, n in skill_sizes(repo).items() if n > SKILL_WORDS)
+    for name in long:
+        print(f"SKILL.md over {SKILL_WORDS}: {name}")
+    return 1 if total > LISTING_WORDS or over or long else 0
 
 
 if __name__ == "__main__":

skills/kvb-agent-optimize/SKILL.md

@@ -2,8 +2,7 @@
 name: kvb-agent-optimize
 description: >
   Make a repository easy for agents: a code graph index (codebase-memory-mcp)
-  and lean agent instructions. Trigger on /kvb-agent-optimize; kvb-optimize
-  runs it.
+  and lean agent instructions; kvb-optimize runs it.
 ---
 
 An agent that queries a graph reads a fraction of what an agent exploring

skills/kvb-agent-relax/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-agent-relax
 description: >
   Relax this agent on kvb-org-evening: finish its task, end its loops, start
-  nothing new. Trigger on its request or /kvb-agent-relax.
+  nothing new. Trigger on its request.
 ---
 
 Verify first: `${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py status`
@@ -11,6 +11,7 @@ The request asks for less, so it needs no operator approval.
 
 Follow steps 2 to 4 of the `kvb-agent-sleep` skill (start nothing, end your
 loops, write the handover), with two differences: finish the current task
-instead of parking it, and keep answering the operator. Reply to the sender
-in one line, `relaxed: <what still runs>`. Waking up is the
+instead of parking it, and keep answering the operator. Reply through the
+news, not a message: `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py
+post --to <sender> "relaxed: <what still runs>"`. Waking up is the
 `kvb-agent-wakeup` skill.

skills/kvb-agent-sleep/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-agent-sleep
 description: >
   Put this agent to sleep on kvb-org-sunset: park work, end loops, write a
-  morning handover, stay idle. Trigger on its request or /kvb-agent-sleep.
+  morning handover, stay idle. Trigger on its request.
 ---
 
 Verify first: `${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py status`
@@ -26,8 +26,9 @@ The request asks for less, so it needs no operator approval, and it ends a
    - each loop with its exact prompt and interval or cron expression;
    - each running job with its command and log path;
    - each open task of yours in the `kvb-org-rasci` register with its next step.
-5. **Reply** to the sender in one line, `asleep: <handover path>`, and end the
-   turn. Offices stay claimed and register rows unchanged.
+5. **Reply** to the sender in one line, `asleep: <handover path>`, by
+   `SendMessage` (its next wave waits on it), and end the turn. Offices stay
+   claimed and register rows unchanged.
 
 ## While asleep
 

skills/kvb-agent-wakeup/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-agent-wakeup
 description: >
   Wake this agent from kvb-agent-relax or kvb-agent-sleep into its old roles;
-  kvb-org-sunrise sends it to all. Trigger on its request or /kvb-agent-wakeup.
+  kvb-org-sunrise sends it to all. Trigger on its request.
 ---
 
 Verify first with `${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py
@@ -22,8 +22,10 @@ status`:
    expression.
 3. Read the log of every job it lists; a finished job's result goes to its
    task.
-4. Check `council.py list` and the default branch instead of trusting old
-   state: messages held overnight beyond 100 were dropped.
+4. Check `council.py list`, `news.py show` and the default branch instead of
+   trusting old state: messages held overnight beyond 100 were dropped.
 5. Continue with the next step of each task. Your offices are still yours.
 
-Reply to a sunrise message in one line: `awake: <what resumes>`.
+Reply to a sunrise message through the news, not a message:
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post --to <sender>
+"awake: <what resumes>"`.

skills/kvb-check-break-risk/SKILL.md

@@ -7,9 +7,8 @@ description: >
 ---
 
 Break risk is the probability the change breaks something it did not intend to
-touch. It is not the inverse of fix confidence, and it is not a mood. Derive it
-by the steps below; a number produced without them is a guess wearing a
-percent sign.
+touch: not the inverse of fix confidence, not a mood. Derive it by the steps
+below; without them a number is a guess.
 
 ## Fast path
 
@@ -22,7 +21,10 @@ under 1%, and skip the method. Any other file takes the full method.
 
 1. **Consumers**: enumerate every consumer of everything the change alters, in
    the committed state (`git grep <symbol> HEAD`) and of its output; say the
-   count. A caveat never licenses a low number; an enumeration does.
+   count. A caveat never licenses a low number; an enumeration does. Query
+   the codebase-memory-mcp graph first (`detect_changes`, `trace_path`,
+   `search_graph`; the `kvb-agent-optimize` skill sets it up), grep and read
+   after.
 2. **Delta**: run the old and the new code on today's inputs and compare at
    the surface where the difference shows (rendered output, emitted config,
    returned set, wire bytes), not as the source reads.
@@ -45,7 +47,7 @@ its residuals. Anchor roughly:
 
 - **Under 5%**: consumers enumerated, delta measured at the surface, every axis
   of the matrix covered by executed evidence, failure mode closed.
-- **5 to 15%**: measured, but one axis or one layer rests on reasoning — no live
+- **5 to 15%**: measured, but one axis or one layer rests on reasoning: no live
   run, a mode not exercised, a runtime the render cannot prove.
 - **15 to 40%**: a real behaviour change whose consumers are enumerated but
   whose effect is unmeasured, or a latent finding with a plausible trigger.

skills/kvb-check-confidence/SKILL.md

@@ -7,21 +7,19 @@ description: >
 ---
 
 Every stage summary, fix report, or ready-to-commit bundle ends with a
-confidence block.
+confidence block. Invoke the `kvb-check-break-risk` skill every time before
+writing it; this skill reports the number it derives and never estimates one
+itself.
 
-Invoke the `kvb-check-break-risk` skill every time, before writing the block; this skill
-reports the number it derives and never estimates one itself.
-
-1. **Fix confidence** (percent): probability the change does what it
-   claims. **Break risk** (percent): probability it breaks anything else,
-   derived via the `kvb-check-break-risk` skill. Two separate numbers, never one
-   blended figure.
-2. **Evidence**: the strongest proof lines only — what was executed,
-   reproduced, enumerated, or read from authoritative source. Distinguish
-   proven (ran it, saw it) from derived (reasoned statically).
-3. **Residuals**: name exactly what keeps the number below 100 and what
-   would close the gap (live deploy, missing artifact, unexercised path).
-   Never a bare percentage without its residuals.
+1. **Fix confidence** (percent): probability the change does what it claims.
+   **Break risk** (percent): probability it breaks anything else, from the
+   `kvb-check-break-risk` skill. Two numbers, never one blended figure.
+2. **Evidence**: the strongest proof lines only: what was executed,
+   reproduced, enumerated, or read from an authoritative source. Mark proven
+   (ran it, saw it) apart from derived (reasoned statically).
+3. **Residuals**: exactly what keeps the number below 100 and what would
+   close the gap (live deploy, missing artifact, unexercised path). Never a
+   bare percentage without its residuals.
 
 Calibration rules:
 
@@ -39,5 +37,6 @@ needs the project's full quality gate green on the exact head (in
 infinito-nexus `make quality-high`); before that, the numbers are
 provisional and the missing gate is the residual.
 
-Objective: the `kvb-skill-tune` skill's **Objective** section. Two figures with their residuals replace a
-hedging paragraph and save the operator a verification round trip.
+Objective: the `kvb-skill-tune` skill's **Objective** section. Two figures
+with their residuals replace a hedging paragraph and save the operator a
+verification round trip.

skills/kvb-check-legal/SKILL.md

@@ -3,30 +3,30 @@ name: kvb-check-legal
 description: >
   Check a commit's licences, attribution, copied snippets, GDPR and
   trademarks. Run AUTOMATICALLY before every commit the operator requests;
-  also on /kvb-check-legal [ref|range], "rechtlich prüfen", "lizenz prüfen".
+  also on "rechtlich prüfen", "lizenz prüfen".
 ---
 
 The stance is the project's counsel: find what would make the change unlawful
 to distribute before it is distributed. This is not legal advice but a reading
 of the licence texts, with German and EU law where jurisdiction matters; every
-report says so in one line. Leaked secrets belong to `kvb-check-security`, engineering
-principles to `kvb-check-principles`.
+report says so in one line. Leaked secrets belong to `kvb-check-security`,
+engineering principles to `kvb-check-principles`.
 
 ## Target
 
 - Before a commit: the staging index (`git diff --cached`, plus every added or
   changed file in full where origin or licence is in question).
-- `/kvb-check-legal <ref>` or `/kvb-check-legal <a>..<b>`: that commit or range.
-- `/kvb-check-legal` alone: the index if it is non-empty, else `HEAD`.
+- A `<ref>` or `<a>..<b>` after the command: that commit or range.
+- The command alone: the index if it is non-empty, else `HEAD`.
 
 ## Fast exit
 
 The target is in scope only if it adds or changes at least one of: a
-dependency manifest or lockfile; a vendored, generated, or third-party file; a
-LICENSE, NOTICE, or COPYING file or a licence header; code with a foreign
+dependency manifest or lockfile; a vendored, generated or third-party file; a
+LICENSE, NOTICE or COPYING file or a licence header; code with a foreign
 origin (a source URL, a foreign copyright line, a block that reads unlike its
 surroundings); an external request (CDN, web font, analytics, embed, API);
-handling of personal data; a logo, icon, or third-party brand name. Nothing in
+handling of personal data; a logo, icon or third-party brand name. Nothing in
 scope: report `advocate: nothing licence-relevant in <target>` in one line and
 let the commit proceed.
 
@@ -41,29 +41,27 @@ never a blocker of the commit at hand.
 ## The checks
 
 Only for a target in scope: read `checks.md` next to this file and apply its
-seven checks (inbound code, dependency licences, project licence fit,
-attribution, copied snippets, data protection, trademarks).
+seven checks.
 
 ## Severity
 
-- **Blocker** - the commit would distribute what the project may not
-  distribute: an incompatible inbound or dependency licence, or non-trivial
-  code or assets without a licence.
-- **Finding** - fixable while keeping the change: missing attribution, NOTICE,
+- **Blocker**: the commit would distribute what the project may not: an
+  incompatible inbound or dependency licence, or non-trivial code or assets
+  without a licence.
+- **Finding**: fixable while keeping the change: missing attribution, NOTICE
   or header; a data-protection gap; trademark use; a block of unclear origin.
-- **Note** - worth knowing, no action required.
+- **Note**: worth knowing, no action required.
 
 ## Blockers stop the commit
 
-Harden every blocker with the `kvb-think-dialectic` skill before reporting it. The
-antithesis tries: the code is trivial or the operator's own; the dependency is
-build- or test-only and never distributed; an exception applies (linking or
-Classpath exception, dual licensing, a licence grant in the issue or commit
-history). A blocker that survives stops the commit: present it with the
+Harden every blocker with the `kvb-think-dialectic` skill before reporting
+it. The antithesis tries: the code is trivial or the operator's own; the
+dependency is build- or test-only and never distributed; an exception applies
+(linking or Classpath exception, dual licensing, a licence grant in the issue
+or commit history). A surviving blocker stops the commit: present it with the
 options (remove, replace with a compatible alternative, relicense, obtain
 permission) and wait. The operator's explicit acceptance lets this one commit
-proceed and never carries over to the next. Findings and notes never stop a
-commit.
+proceed and never carries over. Findings and notes never stop a commit.
 
 ## Output
 
@@ -72,7 +70,7 @@ the operator's language). Then one table, blockers first:
 
 | Severity | Check | Location | What is wrong | Licence or law | Fix | Evidence |
 
-`Evidence` is `proven` (licence text, metadata, or file read; cite path:line
+`Evidence` is `proven` (licence text, metadata or file read; cite path:line
 or the registry URL) or `derived` (inferred). Close with the verdict (commit
 stops or proceeds) and the `kvb-check-confidence` skill's numbers.
 
@@ -80,8 +78,8 @@ stops or proceeds) and the `kvb-check-confidence` skill's numbers.
 
 - Never infer a licence from a package's name or reputation; read it. An
   unreachable registry makes the row `derived`, never clean.
-- Never invent a licence clause, a statute, or a court ruling; cite only what
+- Never invent a licence clause, a statute or a court ruling; cite only what
   you read.
 - Read-only apart from stopping the commit: never edit licence files, add
-  headers, or remove dependencies on your own. Propose the fix; the operator
+  headers or remove dependencies on your own. Propose the fix; the operator
   decides.

skills/kvb-check-principles/SKILL.md

@@ -2,84 +2,82 @@
 name: kvb-check-principles
 description: >
   Find violated principles (SPOT, DRY, KISS, SRP, trust boundaries) in a
-  repository, path or diff. Trigger on /kvb-check-principles, "sei
-  skeptisch", "kritische analyse", or "review the architecture".
+  repository, path or diff. Trigger on "sei skeptisch", "kritische
+  analyse", or "review the architecture".
 ---
 
 The stance is adversarial: the code is guilty until its structure proves
 otherwise. This skill hunts violated principles, not bugs (`code-review`),
-not bloat (`ponytail-audit`), not leaked secrets (`kvb-check-security`). Read-only —
-report the findings, change nothing unless the operator asks afterwards.
+bloat (`ponytail-audit`) or leaked secrets (`kvb-check-security`). Read-only:
+report, change nothing unless the operator asks afterwards.
 
 ## Scope
 
-The operator names the target: a repository, a directory, a role, or a diff.
-Without a target, take the whole repository and rank by blast radius. State
-the scope in one line before reporting, and name explicitly what you did not
-read — an audit that silently covered half the tree reads as clean.
+The operator names the target: a repository, directory, role or diff.
+Without one, take the whole repository and rank by blast radius. State the
+scope in one line and name what you did not read; a silent half-audit reads
+as clean.
 
 ## The lenses
 
 Apply each independently; a finding belongs to exactly one:
 
-1. **SPOT** — one truth, one place. A value, a version, a hostname, a
-   schema, a list of names that exists twice is a divergence waiting to
-   happen. Name both locations and the drift they will cause.
-2. **DRY** — repeated *knowledge*, not repeated text. Two blocks that look
-   alike but change for different reasons are correctly separate; merging
-   them is the violation. Prove the shared reason to change, or drop the
-   finding.
-3. **SRP** — one reason to change per unit. Look for the module that both
-   parses and persists, the function whose name contains "and", the role
-   that configures and deploys and monitors. The test: name the two
-   stakeholders who would each demand a change here.
-4. **KISS** — mechanism the problem never asked for: an abstraction with one
-   implementation, a config value that never varies, a cache with no
-   measured pressure, a retry loop around a deterministic call.
-5. **Security** — only at trust boundaries: unvalidated input crossing into
-   a query, a shell, a template, or a path; authorization checked in the
-   caller instead of the resource; a secret in a default, a log, or an
-   image layer; a permission wider than the operation needs. Defensive
-   findings only.
-6. **Silent defaults** — a fallback that substitutes a guess for a value the
+1. **SPOT**: one truth, one place. A value, version, hostname, schema or list
+   of names that exists twice will diverge. Name both locations and the
+   drift.
+2. **DRY**: repeated *knowledge*, not text. Look-alike blocks that change for
+   different reasons are correctly separate; merging them is the violation.
+   Prove the shared reason to change, or drop the finding.
+3. **SRP**: one reason to change per unit: the module that parses and
+   persists, the function named "x and y", the role that configures, deploys
+   and monitors. Name the two stakeholders who would each demand a change.
+4. **KISS**: mechanism nobody asked for: an abstraction with one
+   implementation, a config value that never varies, a cache with no measured
+   pressure, a retry loop around a deterministic call.
+5. **Security**, only at trust boundaries: unvalidated input reaching a
+   query, shell, template or path; authorization checked in the caller
+   instead of the resource; a secret in a default, log or image layer; a
+   permission wider than the operation needs. Defensive findings only.
+6. **Silent defaults**: a fallback substituting a guess for a value the
    caller failed to supply, turning a misconfiguration into wrong behaviour
-   instead of a loud failure. See the `kvb-code-no-defaults` skill.
+   instead of a loud failure (the `kvb-code-no-defaults` skill).
 
 ## Method
 
-- **Evidence before verdict.** Every finding carries `file:line` you actually
-  read. Grep for the sibling occurrences before calling something a
-  duplicate — one hit is not a pattern.
-- **Name the failure.** A finding must state what concretely goes wrong:
-  which value drifts, which caller breaks, which input reaches which sink.
-  A finding whose worst case is "feels wrong" gets deleted, not softened.
-- **Attack your own finding.** For anything consequential or expensive to
-  fix, run it through the `kvb-think-dialectic` skill before reporting it — the
-  strongest counter-argument is usually "these two are not the same
-  knowledge" or "this boundary is already checked upstream".
-- **Respect intent.** A deliberate marker (`ponytail:`, a documented
-  exception, a nocheck directive with a reason) is a known ceiling, not a
-  finding. Report it only when the ceiling has since been exceeded.
+- **Graph first**: explore through the codebase-memory-mcp graph
+  (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`; the
+  `kvb-agent-optimize` skill sets it up), grep and read after.
+- **Evidence before verdict**: every finding carries a `file:line` you read.
+  Grep the sibling occurrences before calling something a duplicate; one hit
+  is not a pattern.
+- **Name the failure**: which value drifts, which caller breaks, which input
+  reaches which sink. A finding whose worst case is "feels wrong" is deleted,
+  not softened.
+- **Attack your own finding**: run anything consequential or expensive to fix
+  through the `kvb-think-dialectic` skill before reporting it; the strongest
+  counter is usually "not the same knowledge" or "already checked upstream".
+  Skeptics scale with the stakes; each brief names the `file:line` and the
+  claim and caps the answer at five lines.
+- **Respect intent**: a deliberate marker (`ponytail:`, a documented
+  exception, a nocheck directive with a reason) is a known ceiling, a finding
+  only once exceeded.
 
 ## Output
 
-One ranked table, worst blast radius first:
+One table, worst blast radius first:
 
 | Severity | Principle | Location | What is wrong | Smallest fix |
 
-Then three closing lines at most: what the scope excluded, which findings
-survived `kvb-think-dialectic` versus which are still derived-only, and the single
-finding to fix first. No per-finding paragraphs — the operator asks when a
-row needs unpacking.
+Then at most three lines: what the scope excluded, which findings survived
+`kvb-think-dialectic` and which are still derived-only, and the one to fix
+first. No per-finding paragraphs; the operator asks when a row needs it.
 
 ## Rules
 
-- Never report formatting, naming taste, or missing comments; a linter owns
-  those and the operator did not ask.
-- Distinguish proven (grepped, read, reproduced) from derived (reasoned
-  statically) per finding, and close with the `kvb-check-confidence` skill's numbers
-  for the audit as a whole.
+- Never report formatting, naming taste or missing comments.
+- Mark each finding proven (grepped, read, reproduced) or derived (reasoned
+  statically), and close with the `kvb-check-confidence` skill's numbers for
+  the audit.
 - No silent caps: if you ranked and cut, say how many findings were dropped
   and by what rule.
-- Skepticism ends at the report. Do not fix, stage, or refactor as part of
-  this skill.
+- Skepticism ends at the report: no fix, stage or refactor in this skill.

skills/kvb-check-security/SKILL.md

@@ -2,8 +2,8 @@
 name: kvb-check-security
 description: >
   Run the MEDUSA scanner on a repository, working tree or secret stores:
-  security scans, vetting a repo, leaked secrets in chat or shell history, or
-  /kvb-check-security. Defensive only.
+  security scans, vetting a repo, leaked secrets in chat or shell history.
+  Defensive only.
 ---
 
 MEDUSA is a defensive AI-first security scanner (40,000+ patterns: CVEs, prompt injection, MCP tool poisoning, leaked secrets).

skills/kvb-ci-artifacts/SKILL.md

@@ -54,7 +54,7 @@ tells you whether the proxy or the upstream burned the seconds.
 
 Two failure modes turn a search into a false conclusion:
 
-- **Clustered flags silently change the pattern.** Write them separately —
+- **Clustered flags silently change the pattern.** Write them separately:
   `grep -r -a -i -l -F "needle" dir/`, not `-ariel`. A cluster where one letter
   takes an argument consumes your pattern and searches for something else, and
   the run still exits successfully.

skills/kvb-ci-observe/SKILL.md

@@ -2,59 +2,60 @@
 name: kvb-ci-observe
 description: >
   Watch a CI run, pipeline, build or log on a cadence and triage new failures.
-  Trigger on /kvb-ci-observe <target> or a request to keep monitoring and fix
-  regressions.
+  Trigger on a request to keep monitoring and fix regressions.
 ---
 
-Keep a target under continuous watch and act only when it degrades. The loop is
-the watcher; triage is the response. Do not re-investigate failures already
-resolved this session, and do not idle-poll work the harness will notify you
-about.
+Keep a target under watch and act only when it degrades: the loop watches,
+triage responds. Never re-investigate a failure already resolved this
+session, and never poll work the harness will notify you about.
 
 ## Before you start: fix the target
 
 The operator names one concrete target: a CI run id or url, a pipeline, a
-branch's checks, a build, or a log file. Restate it in one line and record the
-current failure set as the baseline (the failures already known or already
-fixed this session). Everything the watch reports is diffed against that
-baseline, so a stale baseline re-triages solved failures.
+branch's checks, a build, or a log file. Restate it in one line and record
+the current failure set (known or already fixed this session) as the
+baseline. Every observation is diffed against it; a stale baseline
+re-triages solved failures.
 
 ## The loop
 
-Drive this with `/loop` in dynamic mode (no fixed interval unless the operator
-gave one): after each observation, schedule the next wake-up yourself and pass
-the same `/kvb-ci-observe` prompt back so the next firing repeats the watch.
+Drive it with `/loop` in dynamic mode (no fixed interval unless the operator
+gave one): after each observation, schedule the next wake-up and pass this
+skill's prompt back unchanged.
 
-1. **Poll the target.** Pull its current state (job list, check conclusions, the
-   log's tail); for a GitHub Actions run, the kvb-ci-artifacts skill's
-   `ci_failures.py <run>`. Enumerate the failures exactly as the `kvb-ci-triage` skill's step 1
-   does: failure, cancelled, timed-out; a downstream aggregate that fails only
-   because an upstream did is not its own failure.
-2. **Diff against the baseline.** A failure is *new* only if it is not in the
-   baseline and was not already triaged this session. If nothing is new, log one
-   short line ("still green" / "N known failures, no change") and reschedule.
-3. **Triage each new failure.** Invoke the `kvb-ci-triage` skill on the new set only —
-   which applies `kvb-think-dialectic` per failing job to a ~99% root cause and a real
-   fix. Never mask (no retry-until-pass, no disabled check, no soft-skip). Fold
-   each newly fixed failure into the baseline so it is not re-triaged.
-4. **Reschedule.** Pick the next delay from what you are waiting on: an active
-   run that changes every few minutes gets a check matched to its cadence; a
-   quiet or long-running target gets a long fallback (1200s+). Keep watching
-   until the target reaches a terminal state (run completed, pipeline finished)
-   AND every failure it produced has a verified fix, then stop the loop.
+1. **Poll the target**: its job list, check conclusions or log tail; for a
+   GitHub Actions run, the `kvb-ci-artifacts` skill's `ci_failures.py <run>`.
+   Enumerate failures as the `kvb-ci-triage` skill's step 1 does: failure,
+   cancelled, timed-out; a downstream aggregate that fails only because an
+   upstream did is not its own failure.
+2. **Diff against the baseline.** A failure is new only if it is neither in
+   the baseline nor triaged this session. Nothing new: log one short line
+   ("still green" / "N known failures, no change") and reschedule.
+3. **Triage each new failure** with the `kvb-ci-triage` skill on the new set
+   only; it applies `kvb-think-dialectic` per failing job to a ~99% root
+   cause and a real fix. Never mask (no retry-until-pass, disabled check or
+   soft skip). A new failure and its verdict go to peers as news, never as a
+   message: `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post
+   "<target>: <job> <failing line> -> <verdict>"`. Fold each newly fixed
+   failure into the baseline.
+4. **Reschedule** by what you wait on: an active run that changes every few
+   minutes gets a check matched to its cadence, a quiet or long-running
+   target a long fallback (1200s+). Stop once the target reaches a terminal
+   state (run completed, pipeline finished) AND every failure it produced
+   has a verified fix.
 
 ## Rules
 
-- The loop is a fallback timer, not a busy-wait: if the harness will notify you
-  when tracked work finishes (a background task, a spawned agent), wait for that
-  notification instead of polling for it; reserve the timed wake-up for external
-  state the harness cannot see (a remote CI run, a deploy queue).
-- Executed evidence beats reasoning: read the actual failing log line and the
-  artifact, not the job title — kvb-ci-triage and kvb-think-dialectic carry this through.
-- One baseline, updated in place: dedup every observation against all failures
-  seen so far, or a flaky-then-fixed failure reappears every cycle and the watch
-  never converges.
+- The loop is a fallback timer, not a busy-wait: for tracked work the
+  harness reports (a background task, a spawned agent), wait for that
+  notification; reserve the timed wake-up for state the harness cannot see
+  (a remote CI run, a deploy queue).
+- Executed evidence beats reasoning: read the failing log line and the
+  artifact, not the job title.
+- One baseline, updated in place: dedup every observation against all
+  failures seen so far, or a flaky-then-fixed failure reappears every cycle
+  and the watch never converges.
 - Report only on change: a new failure and its triage verdict, or a terminal
   "target is green, watch closed". Silence between changes is correct.
 - Never invent results for a run still in progress; report what the poll
-  actually returned.
+  returned.

skills/kvb-ci-triage/SKILL.md

@@ -6,109 +6,62 @@ description: >
   failed jobs.
 ---
 
-Drive a red pipeline to green by root cause, not by guesswork. Treat every
-failing job as its own investigation, and do not declare a fix until that job's
-root cause is proven.
+Drive a red pipeline green by root cause. Every failing job is its own
+investigation; no fix before its root cause is proven. For GitHub Actions,
+the `kvb-ci-artifacts` skill's `ci_failures.py <run>` does the mechanics of
+steps 0 to 2 in one call; the judgement stays yours.
 
 ## Procedure
 
-For a GitHub Actions run, the kvb-ci-artifacts skill's `ci_failures.py <run>`
-does the mechanics of steps 0 to 2 in one call: distance to HEAD, the failed
-jobs' logs, and a first clustering. The judgement in those steps stays yours.
-
-0. **Check the run against HEAD before anything else.** A CI run is a snapshot
-   of one commit, and the branch has moved since. Run
-   `git log --oneline <run-sha>..HEAD | wc -l` as the first command of the
-   triage. Zero means the run speaks for the current tree and you proceed.
-   Non-zero means it does not, and you scope the job set down **before**
-   enumerating, clustering, or spawning anything — every job you investigate
-   against stale code is work thrown away, and a fix proposed there risks
-   reverting someone else's. Two cheap discriminators do it without opening an
-   artifact: `git diff --name-only <run-sha>..HEAD -- <source dir> | cut -d/ -f2 | sort -u`
-   for which components already moved, and a grep of the saved job logs for the
-   literal error signature of each cause already fixed in that range. What
-   survives both is the job set the rest of this procedure applies to; say how
-   many jobs you dropped and why.
-1. **Enumerate every failing job.** Pull the run's job list and isolate each job
-   whose conclusion is failure, cancelled, or timed-out. A downstream aggregate
-   job that fails only because an upstream job did is not a separate root cause —
-   note it and move on.
-2. **Cluster the failures by error message.** Group the failing jobs by their
-   actual failing line, not by job name. Jobs whose messages differ in anything
-   but the interpolated identifiers (host, app, port, path) belong in separate
-   clusters.
-3. **Coordinate every cluster.** Run the `kvb-org-organize` skill's Lineage and Peer
-   protocol for each cluster before fixing it: claim it, ask the lineage
-   whether someone already fixes it, and take their fix or keep yours. Keep
-   investigating while you wait for answers. In the `kvb-org-rasci` register
-   the cluster's objective is the root cause fixed, its key results are the
-   failing jobs passing again, one per job.
-4. **Download artifacts per cluster.** Use the `kvb-ci-artifacts` skill for the
-   mechanics — it covers per-job logs while a run is still in progress, which
-   bundle to pull, and the grep hygiene that keeps a false positive from
-   becoming a root cause. For each cluster, fetch every artifact of
-   one representative job: reports, rescue diagnostics, inventories, container
-   logs. Pull a second member's artifacts only when the representative's
-   evidence does not explain the whole cluster. The job log usually names an
-   artifact path and nothing more; the assertion text, the server-side
-   exception and the state dumps are inside the artifact. Do this even when the
-   log looks conclusive, because a log that explains the symptom rarely
-   explains the cause.
-5. **One funnel per cluster.** Hand every cluster you claimed in step 3 to the
-   `kvb-org-split` skill: one agent per cluster, working in its own worktree on its own
-   branch created from the exact current HEAD, with that cluster as its only
-   concern, the artifact paths of step 4 in its brief and a time cap for its
-   interim report.
-   Steps 6 to 8 run inside that sidetree, so no cluster's edits land under
-   another cluster's work or under a running gate or deploy. Run clusters in
-   parallel only when their fixes touch different files and the machine has
-   room. A split cluster (step 7) gets a funnel of its own.
-6. **Dialectic per cluster.** For EACH cluster, invoke the `kvb-think-dialectic` skill:
-   form a thesis about the root cause from evidence (the job log, its artifacts,
-   the code at the run's commit, git history), attack it with independent
-   skeptics, and iterate to a ~99% thesis.
-7. **Distinguish shared vs hidden causes.** A cluster is a hypothesis, not a
-   proof: if the dialectic shows one cluster splitting into two causes, split it.
-   When a job hides a second failure behind the first, keep going until the job
-   is actually green, not just past the first error.
-8. **Fix at the root, through the funnel.** Apply the real fix for each proven
-   root cause in the cluster's sidetree, with a test and a negative control as
-   the `kvb-org-split` skill demands. The fix enters the main line only at the funnel's
-   bar (at least 90 % fix confidence, under 5 % break risk) after its
-   independent review; below the bar the cluster ends as a proposal for the
-   operator, never as a merge. Never mask a failure: no retry-until-pass, no
-   disabling the check, no soft-skip. If a failure is genuinely external
-   (upstream outage, flaky infra), confirm that with evidence and surface it
-   honestly instead of fixing around it. Report every fix, every proposal, and
-   every abandoned attempt to the same agents through the `kvb-org-organize` Peer protocol,
-   then remove the sidetree.
-9. **Tune what ran out of time.** Only for a cluster whose jobs died on their
-   time budget (timed out, or cancelled by the runner's limit), or when the
-   operator asks: hand the job log that ran furthest to the `kvb-code-tune` skill. Its
-   candidates run through funnels of their own, separate from the cluster's fix
-   sidetree, and never delay or block the fix.
-10. **Follow the run.** While the run is still in progress, re-check it
-   periodically and triage each newly failed job as it appears. The run is done
-   only when it has finished and every failure has a verified fix.
+0. **Run against HEAD, first**: `git log --oneline <run-sha>..HEAD | wc -l`.
+   Zero: the run speaks for the current tree. Otherwise read `stale-run.md`
+   next to this file before anything else.
+1. **Enumerate** every job that failed, was cancelled or timed out. An
+   aggregate job failing only because an upstream one did is noted, not a
+   root cause.
+2. **Cluster** by the actual failing line, not the job name; messages that
+   differ beyond interpolated identifiers (host, app, port, path) are
+   separate clusters.
+3. **Coordinate** each cluster via the `kvb-org-organize` Peer protocol,
+   lineage included: claim it; read `council.py list`, the register, the news
+   and `find_fix.py`; then ask every live peer for known fixes, one batched
+   `SendMessage` per peer for all clusters nothing there answers. Investigate
+   while waiting; take their fix or keep yours. Register (`kvb-org-rasci`):
+   objective the root cause fixed, one key result per failing job passing.
+4. **Artifacts** per cluster (the `kvb-ci-artifacts` skill: in-progress
+   logs, which bundle, grep hygiene): every artifact of one representative
+   job (reports, rescue diagnostics, inventories, container logs); a second
+   member's only when the first leaves part of the cluster unexplained. Pull
+   them even when the log looks conclusive: it only names the artifact; the
+   assertion, server-side exception and state dumps are inside.
+5. **One funnel per cluster** via the `kvb-org-split` skill: one agent per
+   claimed cluster, its own worktree and branch from the exact current HEAD,
+   that cluster its only concern, worked as `funnel.md` next to this file
+   says (dialectic, shared vs hidden causes, root fix); read it before
+   working one yourself. Spawn only as many as the stakes justify; each
+   brief names that file, the failing line, artifact paths, files and the
+   claim to prove or refute, a time cap for the interim report and an answer
+   cap (verdict table, at most 15 lines). Parallel only when the fixes touch
+   different files and the machine has room.
+6. **Timeouts**: only for a cluster whose jobs died on their time budget, or
+   on operator request, hand the furthest-running job log to `kvb-code-tune`;
+   its candidates get funnels of their own and never delay the fix.
+7. **Follow** a run still in progress and triage each newly failed job; done
+   when the run finished and every failure has a verified fix.
 
 ## Rules
 
-- Executed evidence beats reasoning: read the actual failing log line and the
-  artifact, not the job title.
-- A derived source is not evidence. A conversation summary, your own earlier
-  message, a cluster table you built ten minutes ago, or a subagent's report
-  proves nothing on its own. Only the job log, the artifact, the code at the
-  run's commit, and command output you just ran count. Quote them literally; if
-  you cannot quote it, you do not know it.
-- Re-derive after a context compaction. A summary carried across a compaction
-  boundary preserves your conclusions but not the evidence under them, and a
-  cluster assignment that was wrong stays wrong while reading as settled fact.
-  Before acting on any pre-compaction attribution, rebuild it from the job logs.
-- Classify each failure: a real defect (fix it), a flake or infra hiccup (prove
-  it is transient before dismissing), or already-fixed-by-a-later-commit. For
-  that last class the comparison is `<run-sha>..HEAD`, never the run's commit
-  alone: the run cannot contain a fix that landed after it, so looking there
-  can only ever confirm the failure. Name the commit that carries the fix.
-- Report a per-job verdict: root cause, the artifact path and line that prove
-  it, the fix, the cluster's sidetree branch, and the funnel verdict (merged or
-  proposal). A verdict that cites only the job log has not finished step 4.
+- Explore code through the codebase-memory-mcp graph first (`search_graph`,
+  `trace_path`, `get_architecture`, `detect_changes`; the
+  `kvb-agent-optimize` skill sets it up), grep and read after.
+- Only the job log, the artifact, the code at the run's commit and command
+  output you just ran count as evidence, quoted literally; a summary, your
+  earlier message, an old cluster table or a subagent's report proves
+  nothing. After a context compaction, rebuild every attribution from the job
+  logs before acting on it.
+- Classify each failure: real defect (fix), flake or infra (prove it
+  transient first), or fixed by a later commit (compare `<run-sha>..HEAD`,
+  never the run's commit alone; name the fixing commit).
+- Per job verdict: root cause, the proving artifact path and line, the fix,
+  the sidetree branch, the funnel verdict (merged or proposal). A verdict
+  citing only the job log has not finished step 4.

skills/kvb-ci-triage/funnel.md

@@ -0,0 +1,31 @@
+# Working one cluster in its sidetree
+
+Run inside the cluster's own worktree, so no cluster's edits land under
+another cluster's work or under a running gate or deploy. The `kvb-ci-triage`
+skill's Rules apply here too.
+
+1. **Dialectic**: invoke the `kvb-think-dialectic` skill for the cluster:
+   form a thesis about the root cause from evidence (the job log, its
+   artifacts, the code at the run's commit, git history), attack it with
+   independent skeptics, and iterate to a ~99% thesis.
+2. **Shared vs hidden causes**: a cluster is a hypothesis, not a proof; if
+   the dialectic shows it splitting into two causes, split it, and the new
+   cluster gets a funnel of its own. When a job hides a second failure behind
+   the first, keep going until the job is actually green, not just past the
+   first error.
+3. **Fix at the root**: apply the real fix for each proven root cause in the
+   sidetree, with a test and a negative control as the `kvb-org-split` skill
+   demands. Light runs (no Docker, about a minute: targeted pytest or
+   unittest, ruff, single lint files) self-admit with
+   `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
+   test-nostack`; `make test`, gates, deploys and anything with Docker keep
+   the chair's request, grant and release. The fix enters the main line only
+   at the funnel's bar (at least 90 % fix confidence, under 5 % break risk)
+   after its independent review; below the bar the cluster ends as a
+   proposal for the operator, never as a merge. Never mask a failure: no
+   retry-until-pass, no disabling the check, no soft-skip. If a failure is
+   genuinely external (upstream outage, flaky infra), confirm that with
+   evidence and surface it honestly instead of fixing around it. Report every
+   fix, proposal and abandoned attempt to the peers asked in step 3 of the
+   skill with `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post
+   "<text>"` (`--to <name>` per peer), then remove the sidetree.

skills/kvb-ci-triage/stale-run.md

@@ -0,0 +1,17 @@
+# Run behind HEAD
+
+A CI run is a snapshot of one commit, and the branch has moved since. Scope
+the job set down **before** enumerating, clustering or spawning anything:
+every job investigated against stale code is work thrown away, and a fix
+proposed there risks reverting someone else's.
+
+Two cheap discriminators, without opening an artifact:
+
+- `git diff --name-only <run-sha>..HEAD -- <source dir> | cut -d/ -f2 | sort -u`
+  shows which components already moved.
+- A grep of the saved job logs for the literal error signature of each cause
+  already fixed in that range.
+
+What survives both is the job set the procedure applies to; say how many jobs
+you dropped and why. The run cannot contain a fix that landed after it, so
+looking only at its commit can only ever confirm the failure.

skills/kvb-cleanup/SKILL.md

@@ -2,198 +2,89 @@
 name: kvb-cleanup
 description: >
   Free disk space agents filled in /tmp, Docker and agent dirs; delete only
-  what the operator picks. Trigger on /kvb-cleanup, "aufräumen", "bereinigen",
+  what the operator picks. Trigger on "aufräumen", "bereinigen",
   "platte voll", "no space left on device".
 ---
 
-Nothing is deleted before the operator has picked it. Every candidate carries
-its owner, its size, and its risk.
+Delete only what the operator picked in this run; questions, inventory and
+proposal change nothing. Never invent a size or a peer's answer: unmeasured
+is `unknown`.
 
-## Step 0: the resource chair
+## Step 0: the chair
 
-Shared resources belong to the resource chair of the `kvb-org-organize` skill. If
-another session holds the chair, send it the cleanup request and stop, unless
-the operator ordered the cleanup in this session; then tell the chair before
-step 1, so its grants and queue stay consistent. The `kvb-org-organize` resource
-watch already runs the configured low-risk cleanup at its stop threshold; this
-skill covers everything that needs the operator's pick.
+Shared resources belong to the `kvb-org-organize` chair; its resource watch
+already runs the configured low-risk cleanup. Another session chairs: send it
+the request and stop, or, when the operator ordered the cleanup here, first
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post --to <chair>
+"<plan>"`.
 
-## Step 1: ask the peers
+## Step 1: inventory
 
-List every agent the host can message (in Claude Code: `ListAgents`). Only
-peers sharing this machine's filesystem and Docker daemon count: local
-sessions and your own subagents. Cloud sessions and remote sessions on other
-machines hold nothing here; skip them.
+Read-only, in parallel, with sizes, only in the agent write scope (Claude
+Code: `sandbox.filesystem.allowWrite`) and session scratch dirs, even where
+more is readable; never another user's files. Prefer the project's cleanup
+and teardown targets; obey rules forbidding raw commands.
 
-Send each local peer one message (`SendMessage`) and go on with step 2 while
-they answer:
+- **/tmp**: `du -sh` per own top-level entry; system entries (`.X11-unix`,
+  `.ICE-unix`, `systemd-private-*`, `ssh-*`, `tmux-*`, sockets) are never
+  candidates.
+- **Docker**, **worktrees**: read `docker.md` (its `⚠ Volumes` checklist
+  joins Step 4) and `worktrees.md` next to this file when present.
+- **Agent dirs**: pip, npm, pre-commit, act, gh, buildx caches; Ansible and
+  build temp dirs.
+- **Register**: `council.py list --long`; `rasci.py artifacts` (`kvb-org-artefacts`,
+  `--ended` for candidates): workdir, branch, artifacts, status and worker per
+  `kvb-org-rasci` task.
+- **Live use**: `fuser`, `lsof`, `ps -o pid,etime,comm`, never full command
+  lines or environments (credentials). Sandboxed, an empty result proves
+  nothing.
+- **Archive duties**: memory or project rules requiring a copy before
+  deletion (logs, reports, generated maps).
 
-```text
-Cleanup planned by <own session name>. Reply to me with everything you still
-need, one item per line:
-- paths under /tmp, caches, worktrees
-- containers, compose or stack projects, volumes, images, networks
-- running jobs (deploys, tests, builds) and when they finish
-Reply "nothing" if you need none of it. Items you do not answer for stay.
-Also search your own worktrees and volumes for unused ones (branch merged or
-pushed, no uncommitted changes, stack not needed), list them with their size
-as deletion candidates, delete only your own finished items, and tell me what
-you removed.
-```
+## Step 2: ask the owners
 
-## Step 2: inventory
+Owner: register worker, session id in the path, worktree or compose project,
+container label, open handle, else `unknown`. `SendMessage` the text in
+`ask.md` next to this file once to each local peer owning candidates the
+register does not cover; go on meanwhile.
 
-Read-only, in parallel, sizes included:
+## Step 3: classify
 
-- **Scope**: the directories agents may write to, taken from the host's
-  sandbox or permission config (in Claude Code:
-  `sandbox.filesystem.allowWrite` in `.claude/settings.json`) plus the session
-  scratch dirs. Anything outside is out of scope, even when readable.
-- **/tmp**: `du -sh` per top-level entry the current user owns. System entries
-  (`.X11-unix`, `.ICE-unix`, `systemd-private-*`, `ssh-*`, `tmux-*`, sockets)
-  are never candidates.
-- **Docker**: `docker system df -v`; containers with state and compose project
-  label, volumes with the containers using them
-  (`docker ps -a --filter volume=<name>`), dangling and unused images, build
-  cache, unused networks. For every stopped container (`exited`, `created`)
-  record its volumes (`{{.Mounts}}`); for every volume no running container
-  uses, record size, `CreatedAt` (`docker volume inspect`) and compose project
-  label, anonymous ones included.
-- **Worktrees**: per worktree its size (`du -sh`), its dirty state (`git
-  status --short`), whether its branch is pushed, and whether its HEAD is
-  already contained in an integration line: the default branch and every
-  branch the project merges features into (ask the operator or the project's
-  memory which ones). With `pkgmgr` installed, `pkgmgr branch gc --json
-  --sizes --merged-into <line>` (one per line) measures all of it; its
-  merged-clean items go to the `kvb-git-branch-gc` skill.
-- **Other agent dirs**: package and tool caches (pip, npm, pre-commit, act,
-  gh, buildx), Ansible and build temp dirs.
-- **Register**: `rasci.py artifacts` of the `kvb-org-artefacts` skill:
-  workdir, branch and artifacts of every task in the `kvb-org-rasci` register,
-  with its status and worker; `--ended` narrows it to the candidates.
-- **Live use**: open handles (`fuser`, `lsof`) and running processes by name
-  only (`ps -o pid,etime,comm`). Never print full command lines or
-  environments: process arguments carry credentials. A sandboxed agent often
-  sees only its own processes, so an empty handle list proves nothing there;
-  then only entries untouched for more than 24 hours (`find -mtime +0`) are
-  candidates, and newer ones stay as `keep (recent, possibly in use)`.
-- **Archive duties**: memory and project instructions that require copying
-  something out before deletion (logs, reports, generated maps). Such an item
-  is `archive first`, never a plain delete.
+First match wins: claimed by a peer, `keep`; in a register task not `done`,
+`stopped` or `stale`, `keep (task <task>)` (an ended task's items are its
+worker's candidates); a running deploy, gate, test, swarm run or build, `keep
+(running)`; a silent peer's, `keep (no answer from <peer>)`, silence is not
+consent; sandboxed, anything touched within 24 hours (`find -mtime +0` lists
+the older), `keep (recent, possibly in use)`; archive duty,
+`archive first`, never a plain delete. Else a candidate:
 
-Prefer the project's own cleanup and teardown targets (Makefile, scripts) over
-raw commands where they exist, and obey project rules that forbid raw
-commands.
-
-## Step 3: attribute
-
-Give every candidate an owner: a peer's reply, a session id in the path, a
-worktree or compose project name, a container label, an open handle, or
-`unknown`. Then apply, first match wins:
-
-1. Claimed by a peer: `keep`.
-2. Listed in the register under a task that is not `done`, `stopped` or `stale`:
-   `keep (task <task>)`. Under an ended task it is a candidate whose owner is
-   the task's worker.
-3. A job running on it (deploy, gate, test, swarm run, build): `keep
-   (running)`.
-4. Attributable to a peer that has not answered: `keep (no answer from
-   <peer>)`. Silence is not consent.
-5. Archive duty: `archive first`.
-6. Everything else is a candidate with a risk class:
-
-| Risk | Meaning | Typical items |
-| ---- | ------- | ------------- |
-| low | regenerated automatically, cheap | stopped containers without volumes, dangling images, unused networks, scratch dirs and logs of finished sessions |
-| medium | regenerated, but slow, rate-limited or network-bound | unused tagged images (re-pull, registry limits), build cache (cold rebuilds), package caches, clean worktrees whose HEAD is already in an integration line (ignored files such as `node_modules`, build output or evidence are lost, no commit) |
-| high | data loss or a broken run possible | volumes, stopped containers with volumes, running unclaimed containers or stacks, worktrees with uncommitted or unpushed work, unread reports, anything `unknown` |
+- **low**, regenerated cheaply: stopped containers without volumes, dangling
+  images, unused networks, finished sessions' scratch and logs.
+- **medium**, regenerated slowly, rate-limited or networked: unused tagged
+  images, build cache, package caches, clean worktrees already merged.
+- **high**, data loss or a broken run: volumes, stopped containers with
+  volumes, running unclaimed containers or stacks, dirty or unpushed
+  worktrees, unread reports, anything `unknown`.
 
 ## Step 4: propose
 
-One table, biggest first:
+One table, biggest first: area, item, size, owner, risk, proposal, what
+breaks if wrong. Below it reclaimable size per risk and every `keep` grouped
+by reason. Then `AskUserQuestion`:
 
-| Area | Item | Size | Owner | Risk | Proposal | What breaks if wrong |
-
-Below it: reclaimable size per risk class, and every `keep` row grouped by
-reason, so the operator sees what was protected and why.
-
-Then ask with `AskUserQuestion` in two calls.
-
-**Call 1, the selection** (`multiSelect: true`, checklists, at most four
-questions): `/tmp`, `Docker`, `Other dirs`, and a separate `High risk`
-question that holds every high-risk candidate. Size, risk and worst case go
-into each option's description. An area with more than four options is
-grouped by owner or risk, or split into a further call. Only ticked items are
-selected; nothing is preselected.
-
-**Stopped containers and volumes** always get their own checklist
-(`multiSelect: true`, header `⚠ Volumes`, in a further call when call 1 is
-full). Every stopped container and every volume without a running container
-appears there unless a peer claimed it; none is dropped as "not proposed",
-`unknown` and anonymous ones included. The question text carries the warning:
-`Deleting a volume is irreversible; its data does not come back unless the
-description says how.` One option per stopped container together with its
-volumes (removing the container alone frees nothing of them), one per
-unattached volume, anonymous ones grouped. Each description gives size,
-`CreatedAt`, owner or compose project, and what is lost.
-
-**Call 2, the confirmation** (`multiSelect: false`, radio buttons), computed
-from the ticks: `Execute: <n> items, <size> (Recommended)`, `Revise the
-selection`, `Abort`. The execute description names the worst case of the
-ticked items. Revise repeats call 1; nothing is deleted before `Execute`.
+1. `multiSelect: true`, at most four questions: `/tmp`, `Docker`, `Other
+   dirs`, `High risk` (every high-risk candidate); size, risk and worst case
+   in each option's description. Over four options: group by owner or risk,
+   or call again. Only ticks select; nothing preselected.
+2. `multiSelect: false`: `Execute: <n> items, <size> (Recommended)` naming
+   the ticked items' worst case, `Revise the selection` (repeats 1), `Abort`.
 
 ## Step 5: execute
 
-- Re-check claims, open handles and running state right before each delete: a
-  peer may have started something since the inventory.
-- Delete exactly the selected items, by name or path. No blanket prune
-  (`docker system prune -a --volumes`, `rm -rf /tmp/*`) that sweeps beyond the
-  selection. For more than a handful of paths, write the list to a file under
-  `/tmp`, grep it against every claim once more, then delete with
-  `xargs -d '\n' rm -rf -- < <list>`.
-- Locally built images free little on their own: their layers stay behind as
-  build cache. After removing images, re-measure `docker system df`; the
-  layers show up as reclaimable build cache. Offer
-  `docker builder prune --filter until=24h` as a follow-up candidate, ask the
-  peers that claimed build cache first, and run it outside their running
-  builds.
-- A host permission layer (an auto-mode classifier, a deny rule) may refuse a
-  delete. Never route around it with another command or a peer. Finish the
-  rest, then put the refused item to the operator again as its own option: an
-  explicit renewed selection may pass; if it is refused again, hand over the
-  exact command with its list file for the operator to run.
-- Never stop, take down or kill a running job, and never ask its owner to, to
-  free space: not for a priority slot, not at a disk stop. Free idle items,
-  ask the operator for an exception, or wait; an owner's own disk guard only
-  alerts the chair, and only the operator can order a running job down.
-  A hung job is not freed through cleanup: the `kvb-org-organize` skill's hang rule
-  lets only its owner end it.
-- Idle running stacks go down through the project's teardown target, never by
-  removing their containers or volumes underneath them.
-- Remove a worktree the way it was made: a slot worktree through the
-  project's teardown target (e.g. `make worktree-down`), run outside the
-  sandbox; a plain sidetree through `git worktree remove` without `--force`,
-  which refuses a dirty tree.
-- Archive-first items: copy out, verify the copy, then delete.
-- Drop every deleted item from its task as the `kvb-org-artefacts` skill
-  says (`set <task> --drop-artifact <kind>:<ref>`), so `artifacts` stays true.
-- A delete failing on permissions (files owned by a container UID): use the
-  project's container helper. Never sudo, never bypass the sandbox; without a
-  helper, report the path.
-- Stop on the first unexpected error and report it.
+After `Execute`, read `execute.md` next to this file first.
 
 ## Step 6: report
 
 `df -h` and `docker system df` before and after, freed size per area, every
-skipped or failed item with its reason. Tell each peer that answered which of
-the removed items lay near its own.
-
-## Rules
-
-- Questions, inventory and proposal change nothing. Deletion needs the
-  operator's selection in this run; a selection from an earlier run does not
-  carry over.
-- Never delete outside the agent write scope, another user's files, or system
-  entries in `/tmp`.
-- Never invent a peer's answer or a size. Unmeasured is `unknown`, and
-  `unknown` is high risk.
+skipped or failed item with its reason. `news.py post --to <peer>` tells each
+answering peer which removed items lay near its own.

skills/kvb-cleanup/ask.md

@@ -0,0 +1,10 @@
+# Message to a peer owning unregistered candidates
+
+```text
+Cleanup by <own session name>. These unregistered items look like yours:
+<item, size per line>
+Reply with those you still need and jobs running on them with their end, or
+"none"; unanswered items stay. Delete your own finished worktrees and volumes
+(branch merged or pushed, clean, stack unneeded) and post them via news.py;
+list other unused ones with their size as deletion candidates.
+```

skills/kvb-cleanup/docker.md

@@ -0,0 +1,32 @@
+# Docker items
+
+## Inventory
+
+`docker system df -v`; containers with state and compose project label,
+volumes with the containers using them (`docker ps -a --filter
+volume=<name>`), dangling and unused images, build cache, unused networks.
+For every stopped container (`exited`, `created`) record its volumes
+(`{{.Mounts}}`); for every volume no running container uses, record size,
+`CreatedAt` (`docker volume inspect`) and compose project label, anonymous
+ones included.
+
+## Volumes checklist
+
+Stopped containers and volumes always get their own checklist
+(`multiSelect: true`, header `⚠ Volumes`, in a further call when call 1 is
+full). Every stopped container and every volume without a running container
+appears there unless a peer claimed it; none is dropped as "not proposed",
+`unknown` and anonymous ones included. The question text carries the warning:
+`Deleting a volume is irreversible; its data does not come back unless the
+description says how.` One option per stopped container together with its
+volumes (removing the container alone frees nothing of them), one per
+unattached volume, anonymous ones grouped. Each description gives size,
+`CreatedAt`, owner or compose project, and what is lost.
+
+## After removing images
+
+Locally built images free little on their own: their layers stay behind as
+build cache. Re-measure `docker system df`; the layers show up as reclaimable
+build cache. Offer `docker builder prune --filter until=24h` as a follow-up
+candidate, ask the peers that claimed build cache first, and run it outside
+their running builds.

skills/kvb-cleanup/execute.md

@@ -0,0 +1,31 @@
+# Executing the selection
+
+- Re-check claims, open handles and running state right before each delete:
+  a peer may have started something since the inventory.
+- Delete exactly the selected items, by name or path. No blanket prune
+  (`docker system prune -a --volumes`, `rm -rf /tmp/*`) that sweeps beyond
+  the selection. For more than a handful of paths, write the list to a file
+  under `/tmp`, grep it against every claim once more, then delete with
+  `xargs -d '\n' rm -rf -- < <list>`.
+- Never stop, take down or kill a running job, and never ask its owner to, to
+  free space: not for a priority slot, not at a disk stop. Free idle items,
+  ask the operator for an exception, or wait; an owner's own disk guard only
+  alerts the chair, and only the operator can order a running job down. A
+  hung job is not freed through cleanup: the `kvb-org-organize` hang rule
+  lets only its owner end it.
+- Idle running stacks go down through the project's teardown target, never by
+  removing their containers or volumes underneath them. Worktrees go as
+  `worktrees.md` says.
+- Archive-first items: copy out, verify the copy, then delete.
+- Drop every deleted item from its task as the `kvb-org-artefacts` skill says
+  (`rasci.py set <task> --drop-artifact <kind>:<ref>`), so `artifacts` stays
+  true.
+- A host permission layer (an auto-mode classifier, a deny rule) may refuse a
+  delete. Never route around it with another command or a peer. Finish the
+  rest, then put the refused item to the operator again as its own option: an
+  explicit renewed selection may pass; if it is refused again, hand over the
+  exact command with its list file for the operator to run.
+- A delete failing on permissions (files owned by a container UID): use the
+  project's container helper. Never sudo, never bypass the sandbox; without a
+  helper, report the path.
+- Stop on the first unexpected error and report it.

skills/kvb-cleanup/worktrees.md

@@ -0,0 +1,21 @@
+# Worktrees
+
+## Inventory
+
+Per worktree: size (`du -sh`), dirty state (`git status --short`), whether
+its branch is pushed, and whether its HEAD is already contained in an
+integration line: the default branch and every branch the project merges
+features into (ask the operator or the project's memory which ones). With
+`pkgmgr` installed, `pkgmgr branch gc --json --sizes --merged-into <line>`
+(one per line) measures all of it; its merged-clean items go to the
+`kvb-git-branch-gc` skill.
+
+A clean worktree whose HEAD is in an integration line is medium risk: its
+ignored files (`node_modules`, build output, evidence) are lost, no commit.
+
+## Removal
+
+Remove a worktree the way it was made: a slot worktree through the project's
+teardown target (e.g. `make worktree-down`), run outside the sandbox; a plain
+sidetree through `git worktree remove` without `--force`, which refuses a
+dirty tree.

skills/kvb-coach-meditation/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-coach-meditation
 description: >
   Short meditation with generative alpha-wave music, animated fractals and
-  breathing cues, tuned by feedback. Trigger on /kvb-coach-meditation.
+  breathing cues, tuned by feedback.
 ---
 
 A short session in the browser: `assets/meditation.html` plays generative

skills/kvb-coach/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-coach
 description: >
   Coach the operator's next step: psyche, body, sleep, food, own and
-  delegable tasks. Trigger on /kvb-coach or "was soll ich tun".
+  delegable tasks. Trigger on "was soll ich tun".
 ---
 
 Be the operator's coach: short, warm, concrete, with emojis, in the

skills/kvb-code-no-comments/SKILL.md

@@ -3,41 +3,36 @@ name: kvb-code-no-comments
 description: >
   Purge explanatory comments from staged and unstaged changes. Run
   AUTOMATICALLY before every commit or stage request (commit, commit
-  no-verify, stage next, "commite ..."); also on /kvb-code-no-comments or
-  comment complaints.
+  no-verify, stage next, "commite ..."); also on comment complaints.
 ---
 
-When the operator asks to commit or stage, run this audit first and only
-then perform the requested git action; never ask whether to run it.
+On a commit or stage request, run this audit first, then the requested git
+action; never ask whether to run it.
 
-Audit every staged and unstaged change (`git diff` plus `git diff --cached`,
-added lines only) and delete every explanatory comment:
+Audit the added lines of every staged and unstaged change (`git diff` plus
+`git diff --cached`) and delete every explanatory comment:
 
-1. Delete: restated code, step narration, section banners, "Note that",
+1. Delete restated code, step narration, section banners, "Note that",
    rationale prose, apology comments, and any comment whose information the
-   code, task name, or commit message already carries. When in doubt,
-   delete.
-2. Keep only: parameter/exit-code docs, nocheck/noqa/shellcheck directives,
-   and project-sanctioned exception markers that name a concrete trip-wire.
-   A relabeled narration is not an exception; delete it instead.
-3. Block-comment languages are not line-oriented. In Jinja (`{# … #}`), C-like
-   (`/* … */`), HTML (`<!-- … -->`) and their kin, a closing delimiter alone on
-   its own line looks exactly like a comment line and gets deleted with the
-   rest — after which the opening delimiter swallows every live statement down
-   to the next closer. Never strip these languages with a line filter. Delete
-   the whole block by hand, then count the delimiters (`grep -c '{#'` against
-   `grep -c '#}'`) and re-parse the file.
-4. Re-run the project's comment lint if one exists. A green lint does NOT prove
-   the deletion was safe: a swallowed block is still syntactically valid, so
-   both the lint and the language parser can pass over code that no longer
-   executes. Diff against the pre-edit revision (`git show HEAD:<path>`) and
-   confirm that only comment lines left.
-5. Do not stage in order to run a check (the `kvb-git-commit-next` skill's step 4
-   says why). Re-stage after the audit exactly the files that were staged
-   before it.
-6. Penalty: if this audit finds anything you wrote yourself, admit it in
-   the report (file and count, no excuses), lower your confidence numbers
-   for the affected bundle, and write the incident to persistent agent
-   memory (extend the existing minimal-comments feedback entry with the
-   date and the pattern you slipped on) so the calibration survives the
-   session.
+   code, task name or commit message already carries. When in doubt, delete.
+2. Keep only parameter and exit-code docs, nocheck/noqa/shellcheck
+   directives, and project-sanctioned exception markers naming a concrete
+   trip-wire. A relabeled narration is not an exception; delete it.
+3. Block-comment languages are not line-oriented. In Jinja (`{# … #}`),
+   C-like (`/* … */`), HTML (`<!-- … -->`) and their kin, a closing delimiter
+   alone on its line looks like a comment line; deleted with the rest, it
+   lets the opening delimiter swallow every live statement down to the next
+   closer. Never strip these with a line filter: delete the whole block by
+   hand, count the delimiters (`grep -c '{#'` against `grep -c '#}'`) and
+   re-parse the file.
+4. Re-run the project's comment lint if one exists. Green does NOT prove the
+   deletion safe: a swallowed block stays syntactically valid, so lint and
+   parser pass over code that no longer executes. Diff against the pre-edit
+   revision (`git show HEAD:<path>`) and confirm only comment lines left.
+5. Do not stage to run a check (the `kvb-git-commit-next` skill's step 4 says
+   why). After the audit, re-stage exactly the files staged before it.
+6. Penalty: anything you wrote yourself goes into the report (file and
+   count, no excuses), lowers your confidence numbers for the affected
+   bundle, and is written to persistent agent memory (extend the existing
+   minimal-comments feedback entry with the date and the pattern you slipped
+   on) so the calibration survives the session.

skills/kvb-code-no-defaults/SKILL.md

@@ -6,97 +6,64 @@ description: >
   templates or infrastructure are written, edited or reviewed.
 ---
 
-A default value is a guess, written at the point where the caller's intent is
-least known, and it turns a missing value into a plausible wrong answer instead
-of an error. Two callers then read the same call differently: one means "use the
-default", the other simply forgot. That ambiguity is the defect this rule exists
-to prevent.
-
-Never write a substantive default. Require the value. When it is absent, fail
-immediately, loudly, and with a message that names the missing thing.
+A default is a guess written where the caller's intent is least known: it
+turns a missing value into a plausible wrong answer instead of an error, and
+two callers read the same call differently (one means "use the default", the
+other forgot). Never write a substantive default: require the value, and when
+it is absent fail immediately, loudly, naming the missing thing.
 
 ## The rule
 
-1. Every parameter, option, setting, environment lookup, column, and template
+1. Every parameter, option, setting, environment lookup, column and template
    variable MUST be supplied explicitly by its caller.
-2. A missing value MUST abort at the earliest possible moment — argument
-   parsing, config load, container start — never at the point of use, and never
-   by proceeding with a substitute.
+2. A missing value MUST abort at the earliest moment (argument parsing,
+   config load, container start), never at the point of use and never by
+   proceeding with a substitute.
 3. The error MUST name the missing key and where to set it.
-4. Optionality, when a value genuinely may be absent, MUST be modelled as an
-   explicit named case that the call site handles, never as a silent
-   substitution. `None`/`null` handled in a visible branch is fine; a fallback
-   baked into the accessor is not.
+4. Genuine optionality MUST be an explicit named case the call site handles,
+   never a silent substitution: `None`/`null` in a visible branch is fine, a
+   fallback baked into the accessor is not.
 
-## The empty defaults are free
+## Free and justified defaults
 
-`false`, `null` (`None`, `nil`, `undefined`), and the empty string `""` MAY be
-used as defaults without justification. They are the one class that carries no
-guess: they denote absence itself rather than inventing a value the caller might
-have meant. `${VAR:-}`, `d.get(k)`, `a ?? null`, and `def f(a=None)` are fine.
+`false`, `null` (`None`, `nil`, `undefined`) and `""` MAY be defaults without
+justification: they denote absence itself, not a guessed value. `${VAR:-}`,
+`d.get(k)`, `a ?? null` and `def f(a=None)` are fine.
 
-Every other default value — a number, a non-empty string, a non-empty list or
-map, an enum member, a path, a timeout, a retry count — MUST carry an inline
-comment stating why that specific value is correct for every caller that omits
-it. No comment, no default. Use whatever exception-comment form the project
-sanctions; where none exists, a plain comment on or directly above the default.
+Every other default (a number, a non-empty string, list or map, an enum
+member, a path, a timeout, a retry count) MUST carry an inline comment saying
+why that specific value is right for every caller that omits it; no comment,
+no default. Use the project's sanctioned exception-comment form, else a plain
+comment on or directly above the default. The comment names the assumption
+so a reviewer can disagree with it.
 
-The comment is the point: it forces you to name the assumption, so a reviewer
-can disagree with it. "Sensible", "standard", and "usual" name nothing — if the
-justification does not survive being written down, the default does not survive
-either.
-
-## Banned constructs, by language
-
-Each `Never` below means the default is a substantive value. The same construct
-with `false`, `null`, or `""` is permitted, and with any other value is permitted
-only when justified in a comment.
-
-| Language | Never | Instead |
-| --- | --- | --- |
-| Bash | `${VAR:-x}`, `${VAR:=x}`, `: "${VAR:=x}"` | `: "${VAR:?set VAR in <file>}"` |
-| Python | `def f(a=1)`, `d.get(k, x)`, `getattr(o, n, x)`, `os.environ.get(k, x)`, `argparse(default=)` | required args, `d[k]`, `os.environ[k]`, `add_argument(required=True)` |
-| Jinja / Ansible | `\| default(x)`, `lookup('env', k) \| default('')` | `\| mandatory`, `assert` on the var |
-| JS / TS | `function f(a = 1)`, `const {a = 1} = o`, `a \|\| x`, `a ?? x` | required params, explicit `if (a === undefined) throw` |
-| Go | relying on zero values | constructor that validates every field |
-| Rust | `unwrap_or`, `unwrap_or_default`, `#[serde(default)]` | `ok_or(Error::MissingX)?`, `#[serde(deny_unknown_fields)]` |
-| Java / C# | optional parameters, `??`, `getOrDefault` | required constructor args, explicit null check that throws |
-| SQL | `DEFAULT` on a column | `NOT NULL` and supply it in every insert |
-| Make | `VAR ?= x` | `VAR := $(or $(VAR),$(error VAR is required))` |
-| Docker / Compose | `${VAR:-x}`, `ENV` placeholders standing in for config | `${VAR:?VAR is required}` |
-| Terraform / Helm | `variable { default = }`, `default` in `values.yaml` | no default; fail on the missing input |
+"Sensible", "standard", "usual", "it is conventional", "every other project
+does it", "the value is obvious" and "it keeps the signature short" justify
+nothing: they assert someone else made the choice. A valid justification
+names why this value is right for a caller who says nothing. The operator
+asking for a specific default, in this conversation, for this value, settles
+it without a comment.
 
 ## How to apply
 
-Before writing any parameter, ask: what happens if the caller omits it? If the
-answer is anything other than "it fails and says so", rewrite it.
-
-While editing, treat every `default`, `?:`, `??`, `||`, `:-`, `:=`, `or`,
-`fallback`, and `getOrElse` in a value-resolution position as a finding unless
-its substitute is `false`, `null` or `""`, or a comment already justifies it.
-Grep your own diff for them before presenting it.
-
-Pushing a default one layer up is not a fix: a caller that passes a constant it
-invented has only moved the guess. Follow the value to its true owner —
-the operator, the inventory, the deployment config — and require it there.
-
-Removing an existing default is a behaviour change. Do not do it silently as a
-drive-by: name it, and let the operator decide whether it lands in this change
-or its own.
-
-## What does not count as a justification
-
-"It is conventional", "every other project does it", "the value is obvious",
-and "it keeps the signature short" justify nothing — they assert that someone
-else made the choice, which is the ambiguity this rule exists to remove. A valid
-justification names why this value is right for a caller who says nothing.
-
-An operator asking for a specific default, in this conversation, for this value,
-settles it without a comment.
+- Before writing any parameter, ask what happens if the caller omits it;
+  anything but "it fails and says so" gets rewritten.
+- While editing, treat every `default`, `?:`, `??`, `||`, `:-`, `:=`, `or`,
+  `fallback` and `getOrElse` in a value-resolution position as a finding
+  unless its substitute is `false`, `null` or `""` or a comment justifies it.
+  Grep your own diff for them before presenting it.
+- Read `constructs.md` next to this file for a language's banned forms and
+  their replacements before rewriting a default there.
+- Pushing a default one layer up is no fix: a caller passing a constant it
+  invented only moved the guess. Follow the value to its true owner (the
+  operator, the inventory, the deployment config) and require it there.
+- Removing an existing default is a behaviour change, never a silent
+  drive-by: name it and let the operator decide whether it lands in this
+  change or its own.
 
 ## Penalty
 
-If this audit finds an unjustified default you wrote yourself: say so in the
-report, with file and count and no excuses; lower the confidence numbers for the affected
-bundle; and write the incident to persistent agent memory, recording the date
-and the construct you reached for, so the calibration survives the session.
+An unjustified default you wrote yourself: say so in the report with file and
+count and no excuses, lower the confidence numbers for the affected bundle,
+and write the incident with the date and the construct you reached for to
+persistent agent memory, so the calibration survives the session.

skills/kvb-code-no-defaults/constructs.md

@@ -0,0 +1,19 @@
+# Banned constructs, by language
+
+Each `Never` below means the default is a substantive value. The same
+construct with `false`, `null` or `""` is permitted, and with any other value
+only when justified in a comment.
+
+| Language | Never | Instead |
+| --- | --- | --- |
+| Bash | `${VAR:-x}`, `${VAR:=x}`, `: "${VAR:=x}"` | `: "${VAR:?set VAR in <file>}"` |
+| Python | `def f(a=1)`, `d.get(k, x)`, `getattr(o, n, x)`, `os.environ.get(k, x)`, `argparse(default=)` | required args, `d[k]`, `os.environ[k]`, `add_argument(required=True)` |
+| Jinja / Ansible | `\| default(x)`, `lookup('env', k) \| default('')` | `\| mandatory`, `assert` on the var |
+| JS / TS | `function f(a = 1)`, `const {a = 1} = o`, `a \|\| x`, `a ?? x` | required params, explicit `if (a === undefined) throw` |
+| Go | relying on zero values | constructor that validates every field |
+| Rust | `unwrap_or`, `unwrap_or_default`, `#[serde(default)]` | `ok_or(Error::MissingX)?`, `#[serde(deny_unknown_fields)]` |
+| Java / C# | optional parameters, `??`, `getOrDefault` | required constructor args, explicit null check that throws |
+| SQL | `DEFAULT` on a column | `NOT NULL` and supply it in every insert |
+| Make | `VAR ?= x` | `VAR := $(or $(VAR),$(error VAR is required))` |
+| Docker / Compose | `${VAR:-x}`, `ENV` placeholders standing in for config | `${VAR:?VAR is required}` |
+| Terraform / Helm | `variable { default = }`, `default` in `values.yaml` | no default; fail on the missing input |

skills/kvb-code-refactor/SKILL.md

@@ -2,105 +2,81 @@
 name: kvb-code-refactor
 description: >
   Refactor every uncommitted file up to the project's standards without
-  changing behaviour. Trigger on /kvb-code-refactor or asked to clean up,
-  tidy or polish the current changes.
+  changing behaviour. Trigger when asked to clean up, tidy or polish the
+  current changes.
 ---
 
 The unit of work is the uncommitted change set, not the repository. Behaviour
-stays identical: a refactor that changes what the code does is a bug, not a
-cleanup.
+stays identical: a refactor that changes what the code does is a bug.
 
 ## Step 1: fix the file set
 
-Read the set from git, never from memory of what was edited:
+Read it from `git status --porcelain`, never from memory: modified, added,
+renamed and untracked files, without deleted files, binaries, lockfiles,
+vendored trees and generated output. Restate the list in one line before
+touching anything; if it is empty, say so and stop.
 
-```bash
-git status --porcelain
-```
-
-Take modified, added, renamed and untracked files. Drop deleted files, binaries,
-lockfiles, vendored trees and generated output. Restate the resulting list in
-one line before touching anything; if it is empty, say so and stop.
-
-Never `git stash` and never revert a working-tree file to compare - other agents
-and the operator share this tree. Read the committed version with
-`git show HEAD:<path>` into a temporary file instead.
+Never `git stash` or revert a working-tree file to compare: others share this
+tree. Read the committed version with `git show HEAD:<path>` into a temporary
+file.
 
 ## Step 2: get a safety net first
 
-A refactor is only provably behaviour-preserving if something failed before it
-and passes after it. Before editing, check what covers the change set:
+Behaviour stays provable only through a check before and after: tests that
+cover the change set run now and give the green baseline; a suite already red
+is reported, not refactored around. No coverage: read `net.md` next to this
+file before editing.
 
-- **Coverage exists**: run it now and record the green baseline. A suite that
-  was already red gets reported, not refactored around.
-- **No coverage and the code is testable logic**: write the characterization
-  tests first, against the current behaviour - including the behaviour you
-  consider wrong, so the refactor cannot silently change it. Keep them small
-  and framework-free unless the project already has a framework. Fix the
-  captured wrongness in a separate change, never in this one.
-- **Not sensibly testable**: pure glue, declarative config, a thin wrapper over
-  a service the test would have to mock into meaninglessness, or a project with
-  no test setup at all. Say so in one line and refactor without a net; do not
-  invent a test harness the project never asked for.
-
-The new tests are part of the deliverable and must still pass unchanged after
-the refactor. A test that had to be edited to stay green means the behaviour
-moved: revert the refactor, not the test.
+Light runs (targeted tests, ruff, single lint files) start once `watch.py
+admit --kind test-nostack` of the `kvb-org-organize` skill prints `grant`; no
+chair request.
 
 ## Step 3: refactor each file
 
-Read the whole file first, then apply the standards that the surrounding code
-and the project's own config already establish (formatter config, linter rules,
-existing idioms) over any generic preference of your own.
+Read the whole file first; the project's own standards (formatter config,
+linter rules, existing idioms) outrank generic preference. Find callers,
+duplicates and existing helpers 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.
 
-Four principles govern the result:
+- **SRP**: one file, one responsibility; one function, one reason to change.
+  A unit that needs an "and" to describe it is two.
+- **SPOT**: every fact (constant, path, schema, rule) lives in one place;
+  everything else references it.
+- **KISS**: the simplest construct that works; no abstraction without a
+  second caller today, no configuration for a value that never varies.
+- **DRY**: logic is written once; a literal repeated three times is a missing
+  constant.
+- **File size**: read `size.md` next to this file for a file over 250 lines.
+- **Duplication**: fold repeated logic into the existing helper; a new one
+  only when two or more call sites need it now.
+- **Dead weight**: unused imports, variables and parameters, unreachable
+  branches, single-value flags, one-implementation abstractions.
+- **Naming**: names state what a thing is, in the file's convention.
+- **Shape**: split a function that needs a scroll; return early instead of
+  nesting; magic values become a named constant at the use site.
+- **Errors**: never widen or swallow a caught exception, never remove a
+  validation or security check to shorten code.
+- **Comments**: invoke the `kvb-code-no-comments` skill.
 
-- **SRP**: one file, one responsibility; one function, one reason to change. A
-  unit that needs an "and" to describe it is two units.
-- **SPOT**: every fact - a constant, a path, a schema, a rule - lives in exactly
-  one place and everything else references it.
-- **KISS**: the simplest construct that works. No abstraction without a second
-  caller today, no configuration for a value that never varies.
-- **DRY**: the same logic is written once. A literal repeated three times is a
-  missing constant.
-
-Concretely:
-
-- **File size**: no file containing program code exceeds 250 lines. Split the
-  overflow along the SRP seam - it is the symptom, not the cause. Description
-  and markup languages are exempt (Markdown, YAML, JSON, HTML, translation and
-  data files), as is the rare file the language or framework genuinely forbids
-  splitting: name that reason in the report, "it was easier" does not qualify.
-- **Duplication**: fold repeated logic into the helper that already exists;
-  create a new one only when two or more call sites need it now.
-- **Dead weight**: unused imports, variables, parameters, branches that cannot
-  be reached, flags with a single value, abstractions with one implementation.
-- **Naming**: names that state what a thing is, matching the file's convention.
-- **Shape**: split a function that needs a scroll to read; collapse nesting by
-  returning early; replace magic values with a named constant at its use site.
-- **Errors**: never widen a caught exception, never swallow one, never remove a
-  validation or a security check to make the code shorter.
-- **Comments**: invoke the `kvb-code-no-comments` skill rather than reimplementing its
-  rules here.
-
-Do not reformat regions you have no substantive fix for - cosmetic churn buries
-the real change in the diff. If a file's problem is architectural and cannot be
-fixed inside the change set, report it instead of half-doing it.
+Never reformat a region without a substantive fix: cosmetic churn buries the
+real change. An architectural problem the change set cannot fix is reported,
+not half-done.
 
 ## Step 4: keep behaviour provable
 
-- Re-run the step 2 net and require the same green result as the baseline.
-- Never fold a bug fix, a feature, or a dependency change into a refactor.
-  Found a real bug? Name it in the report and leave it for a separate change.
-- Run the cheap checks the project already has for the touched files (formatter,
-  linter, the module's own unit tests). Do not start a full suite, a build, or a
-  deploy on your own initiative - propose it and let the operator trigger it.
-- State plainly what was verified and what was not. An unverified refactor is
-  reported as unverified.
+- Re-run the step 2 net; require the baseline's green result.
+- Never fold a bug fix, feature or dependency change into a refactor; name a
+  found bug in the report for a separate change.
+- Run the project's cheap checks for the touched files (formatter, linter,
+  the module's unit tests). Never start a full suite, build or deploy on your
+  own: propose it for the operator to trigger.
+- Report what was verified and what was not, an unverified refactor as
+  unverified.
 
 ## Step 5: report
 
-One line per file: what changed and why it is safe. Then one line naming what
-was deliberately left alone (architectural findings, bugs, files skipped) and
-the exact command the operator can run to validate. Do not commit unless the
-operator asked for a commit.
+One line per file: what changed and why it is safe. Then one line on what was
+deliberately left alone (architectural findings, bugs, skipped files) and the
+exact command the operator can run to validate. Commit only when the operator
+asked.

skills/kvb-code-refactor/net.md

@@ -0,0 +1,15 @@
+# Refactor: no test covers the change set
+
+- **Testable logic**: write characterization tests first, against the
+  current behaviour, including the behaviour you consider wrong, so the
+  refactor cannot silently change it. Keep them small and framework-free
+  unless the project already has a framework. Fix the captured wrongness in
+  a separate change, never in this one.
+- **Not sensibly testable**: pure glue, declarative config, a thin wrapper
+  over a service the test would have to mock into meaninglessness, or a
+  project with no test setup at all. Say so in one line and refactor without
+  a net; do not invent a test harness the project never asked for.
+
+The new tests are part of the deliverable and must still pass unchanged
+after the refactor. A test that had to be edited to stay green means the
+behaviour moved: revert the refactor, not the test.

skills/kvb-code-refactor/size.md

@@ -0,0 +1,7 @@
+# Refactor: a file over 250 lines
+
+No file containing program code exceeds 250 lines. Split the overflow along
+the SRP seam: the size is the symptom, not the cause. Exempt are description
+and markup languages (Markdown, YAML, JSON, HTML, translation and data files)
+and the rare file the language or framework genuinely forbids splitting:
+name that reason in the report; "it was easier" does not qualify.

skills/kvb-code-scope-guard/SKILL.md

@@ -18,7 +18,7 @@ sentence of the request asks for this? No sentence, no artifact.
 2. Path-scope every `git add`. Never `-A`, never `.`. The operator's tree
    carries their own edits and their local config, and sweeping those into
    your bundle makes them undo your work by hand.
-3. An adjacent defect gets reported in one line, not fixed — unless it blocks
+3. An adjacent defect gets reported in one line, not fixed, unless it blocks
    the request. Fixing it quietly puts an unreviewed change in someone else's
    commit.
 4. An instruction to hand something over is complete on its own. Print the

skills/kvb-code-test/SKILL.md

@@ -2,129 +2,61 @@
 name: kvb-code-test
 description: >
   Run the Makefile test targets the operator picks and report; fix mode loops
-  until green. Trigger on /kvb-code-test [--fix] or asked to run or fix the
-  tests.
+  until green. Trigger when asked to run or fix the tests.
 ---
 
 The Makefile is the source of truth for how this project runs tests. Never
 invent a command (`pytest`, `npm test`, `go test`) while a Makefile target
-exists - the target carries the project's env vars, build dependencies and
+exists: the target carries the project's env vars, build dependencies and
 container setup.
 
 ## Step 1: find the targets
 
-From the repository root:
+From the repository root, `grep -nE '^test[A-Za-z0-9_.-]*:' Makefile`, plus
+every included makefile (`include foo.mk`). Read the matched rules and their
+prerequisites, so the list can say what each one does (delegated script,
+container build, sub-targets).
 
-```bash
-grep -nE '^test[A-Za-z0-9_.-]*:' Makefile
-```
-
-Read the matched rules plus their prerequisites, so the selection list can say
-what each one actually does (delegated script, container build, sub-targets).
-
-Edge cases, handled explicitly rather than guessed around:
-
-- **No Makefile**: say so in one line, name the test runner the project does
-  use (from `pyproject.toml`, `package.json`, `tox.ini`, CI workflow), and ask
-  before running anything.
-- **No `test*` target**: report the targets that do exist and stop.
-- **Included makefiles** (`include foo.mk`): grep those too.
-- **Aggregate targets**: a target whose recipe is only other test targets (e.g.
-  `test: test-unit test-integration`) is the "run everything" entry - mark it as
-  such in the list, do not expand it into its parts silently.
+- **No Makefile**: say so in one line, name the runner the project does use
+  (`pyproject.toml`, `package.json`, `tox.ini`, CI workflow), and ask before
+  running anything.
+- **No `test*` target**: report the targets that exist and stop.
+- **Aggregate target** (recipe only other test targets, e.g.
+  `test: test-unit test-integration`): the "run everything" entry; mark it so,
+  never expand it silently.
 
 ## Step 2: offer the selection
 
-Ask with `AskUserQuestion`, `multiSelect: true`, one question. Options are the
-discovered targets, each with a one-line description of what it runs. Order the
-aggregate/full target first and label it as the complete suite.
-
-The tool takes at most 4 options. With more targets than that:
-
-- print the **complete** discovered list as text first, one line per target, so
-  nothing is hidden, then
-- offer the 4 most useful entries (aggregate first, then the ones matching the
-  operator's stated intent or the files currently uncommitted), and note that
-  "Other" accepts any target name from the printed list.
-
-Never silently truncate. If the operator already named a target in their
-request, skip the question and run it.
+If the operator already named a target, skip this and run it. Otherwise one
+`AskUserQuestion`, `multiSelect: true`: the targets, each with a one-line
+description, the aggregate first, labelled as the complete suite. With more
+than 4 targets, first print the **complete** list as text, one line per
+target, then offer the 4 most useful (aggregate first, then those matching
+the operator's intent or the uncommitted files) and note that "Other" accepts
+any listed name. Never silently truncate.
 
 ## Step 3: run
 
-Run the selected targets in the order the operator listed them, one `make`
-invocation per target, each as its own command so a failure is attributable:
+Before each run, admit it under the `kvb-org-organize` Capacity rules: a
+light run (no Docker, about a minute: targeted pytest or unittest, ruff, a
+single lint file) self-admits with
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
+test-nostack`; `make test`, quality gates and anything with Docker wait for
+the chair's grant, and the release goes to its news.
 
-```bash
-make <target>
-```
-
-Do not add `-k`, do not reorder, do not substitute a faster equivalent. If a
-target needs a long timeout (container builds, e2e), set it on the Bash call
-rather than backgrounding blindly.
-
-Stop after the first failing target unless the operator asked for all of them -
-a later suite running against a broken build produces noise, not information.
+Run the selected targets in the operator's order, one `make <target>` per
+command so a failure is attributable. No `-k`, no reordering, no faster
+substitute. A target needing a long timeout (container builds, e2e) gets it on
+the Bash call instead of blind backgrounding. Stop after the first failing
+target unless the operator asked for all: a later suite against a broken build
+produces noise, not information.
 
 ## Step 4: report
 
-Per target: pass/fail plus the failing test names and the exact error output,
-quoted verbatim. Never paraphrase a failure. Then one line with the exact
-command to reproduce the failure alone.
+Per target: pass or fail, the failing test names and the exact error output,
+quoted verbatim, never paraphrased. Then one line with the exact command
+reproducing the failure alone.
 
-Do not fix what failed unless the operator asks - report first. A request to
-make the tests pass, fix them, or get the suite green (`/kvb-code-test --fix`) switches
-to fix mode.
-
-## Fix mode
-
-The contract is narrow: the code becomes correct, the tests stay honest.
-
-One iteration is: run -> read the failure -> one root cause -> one fix ->
-re-run. Never batch several speculative fixes into one iteration; a green run
-after three simultaneous changes proves nothing about which one mattered.
-
-- **Run** the failing target alone, the fastest command that reproduces the
-  failure. Widen back to the full selection only when that target is green.
-- **Diagnose** from the actual error output before touching a file. Apply the
-  `kvb-ci-triage` skill to reach a verified root cause; for a cause still unclear
-  after one look, apply `kvb-think-dialectic` rather than guessing twice. Say in one line
-  which side is wrong:
-  - **Code**: the test states the intended behaviour. Fix the code.
-  - **Test**: it encodes an outdated or incorrect expectation. Fix it only with
-    a stated reason why the old expectation was wrong, never because the code
-    disagrees with it.
-  - **Environment**: missing dependency, stale container, absent env var,
-    unbuilt artefact. Fix the environment or report it; do not patch code
-    around it.
-- **Fix** with the smallest change that addresses the root cause, in the
-  project's idioms and under the `kvb-code-no-defaults` and `kvb-code-no-comments` rules.
-  Forbidden without explicit operator approval: deleting, skipping, `xfail`-ing
-  or commenting out a failing test; loosening an assertion to what the code
-  produces; swallowing the exception the test surfaces; retries, sleeps or
-  reruns over a flaky failure; disabling a linter rule, a type check or a
-  target. Any of these is a report item, not a fix: a suite that is green
-  because the failing test no longer runs is a regression disguised as success.
-- **Re-run** the same target, then every target that was already green; only
-  a full green selection ends the loop.
-
-Stop and report, without asking for permission to stop:
-
-- **Green**: the full selection passes.
-- **No progress**: the same failure survives 3 iterations, or the failure count
-  stops falling across 3 iterations. Report the root cause reached, what was
-  tried, and why each attempt failed.
-- **Beyond the mandate**: the real fix is an API change, a dependency bump, a
-  schema migration, or a redesign. Name it with its minimal diff and let the
-  operator decide.
-- **Oscillation**: fixing A re-breaks B and vice versa. Report both; that is a
-  design problem, not a test problem.
-- **Flaky**: a target passes and fails without any change. Report both
-  outputs; never rerun until green.
-
-Emit one line per iteration: target, failure, hypothesis, change. The final
-report gives per iteration what failed, the root cause, the fix and the
-result; the final state of every selected target with the verbatim output of
-anything still failing; everything deliberately not done; and the command
-reproducing the final state. State confidence per the `kvb-check-confidence` skill. Do
-not commit unless the operator asked for a commit.
+Fix nothing unless asked; report first. A request to make the tests pass, fix
+them or get the suite green (`--fix`) switches to fix mode: read `fix.md`
+next to this file before its first iteration.

skills/kvb-code-test/fix.md

@@ -0,0 +1,57 @@
+# Fix mode
+
+The contract is narrow: the code becomes correct, the tests stay honest.
+
+One iteration is: run -> read the failure -> one root cause -> one fix ->
+re-run. Never batch several speculative fixes into one iteration; a green run
+after three simultaneous changes proves nothing about which one mattered.
+
+- **Run** the failing target alone, the fastest command that reproduces the
+  failure. Widen back to the full selection only when that target is green.
+- **Diagnose** from the actual error output before touching a file. Locate
+  the code 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. Apply the `kvb-ci-triage` skill to reach a
+  verified root cause; for a cause still unclear after one look, apply
+  `kvb-think-dialectic` rather than guessing twice. Say in one line which side
+  is wrong:
+  - **Code**: the test states the intended behaviour. Fix the code.
+  - **Test**: it encodes an outdated or incorrect expectation. Fix it only with
+    a stated reason why the old expectation was wrong, never because the code
+    disagrees with it.
+  - **Environment**: missing dependency, stale container, absent env var,
+    unbuilt artefact. Fix the environment or report it; do not patch code
+    around it.
+- **Fix** with the smallest change that addresses the root cause, in the
+  project's idioms and under the `kvb-code-no-defaults` and
+  `kvb-code-no-comments` rules. Forbidden without explicit operator approval:
+  deleting, skipping, `xfail`-ing or commenting out a failing test; loosening
+  an assertion to what the code produces; swallowing the exception the test
+  surfaces; retries, sleeps or reruns over a flaky failure; disabling a linter
+  rule, a type check or a target. Any of these is a report item, not a fix: a
+  suite that is green because the failing test no longer runs is a regression
+  disguised as success.
+- **Re-run** the same target, then every target that was already green; only
+  a full green selection ends the loop. Every re-run is admitted like the
+  first run (Step 3 of `SKILL.md`).
+
+Stop and report, without asking for permission to stop:
+
+- **Green**: the full selection passes.
+- **No progress**: the same failure survives 3 iterations, or the failure count
+  stops falling across 3 iterations. Report the root cause reached, what was
+  tried, and why each attempt failed.
+- **Beyond the mandate**: the real fix is an API change, a dependency bump, a
+  schema migration, or a redesign. Name it with its minimal diff and let the
+  operator decide.
+- **Oscillation**: fixing A re-breaks B and vice versa. Report both; that is a
+  design problem, not a test problem.
+- **Flaky**: a target passes and fails without any change. Report both
+  outputs; never rerun until green.
+
+Emit one line per iteration: target, failure, hypothesis, change. The final
+report gives per iteration what failed, the root cause, the fix and the
+result; the final state of every selected target with the verbatim output of
+anything still failing; everything deliberately not done; and the command
+reproducing the final state. State confidence per the `kvb-check-confidence`
+skill. Do not commit unless the operator asked for a commit.

skills/kvb-code-transcend/SKILL.md

@@ -2,7 +2,6 @@
 name: kvb-code-transcend
 description: >
   Carry the session's ad-hoc tests and scripts into the current repo.
-  Trigger on /kvb-code-transcend.
 ---
 
 The test the agent ran from its scratchpad, the probe that proved a cause, the
@@ -50,9 +49,11 @@ single-select `Write it` / `Revise it` / `Discard` with the drafted diff.
   owner through the `kvb-org-coordinate` skill.
 - Every carried test fails without the code it guards: show the negative
   control once.
-- Run the repository's tests only on the resource chair's grant (the
-  `kvb-org-organize` skill); leave the result uncommitted for the
-  `kvb-git-commit-next` skill.
+- Run the carried tests as a light run (no Docker, about a minute) after
+  `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
+  test-nostack`; `make test`, gates and anything with Docker only on the
+  resource chair's grant (the `kvb-org-organize` skill). Leave the result
+  uncommitted for the `kvb-git-commit-next` skill.
 - `transcend.py mark` every offered candidate with its verdict.
 
 ## Output

skills/kvb-code-tune/SKILL.md

@@ -2,44 +2,23 @@
 name: kvb-code-tune
 description: >
   Speed up CI, deploys, builds and hot paths without losing logic or
-  coverage. Trigger on /kvb-code-tune, a job hitting its time budget, or
-  asked where time goes.
+  coverage. Trigger on a job hitting its time budget or when asked where
+  time goes.
 ---
 
-# Tune
-
 One rule outranks every optimization: **nothing that reduces logic, coverage or
 correctness counts as a speed-up.**
 
-## Once per session: listen first
+## Session limits
 
-The first time this skill runs in a session, invoke the `kvb-think-listen`
-skill before measuring anything, and ask three questions through the host's
-structured question mechanism. Offer each as a checklist (multi-select) with
-suggestions, and allow free text:
-
-1. **What to examine.** Suggestions: CI wall-clock, deploy duration, gate and
-   test runtime, image pulls and build caches, per-item loops and process
-   spawns, idempotency (work repeated on a second run), network round trips,
-   and resource use (CPU, memory, disk, I/O). Language, framework and
-   recursion are checked on every run anyway (see Always check).
-2. **Which performance boundaries to keep.** Suggestions: time budgets per job,
-   deploy or gate; resource caps (memory, CPU, disk headroom); a minimum saving
-   per change (default 10 s per run); the measurement source that counts as
-   the verdict.
-3. **Which limits apply to optimizations.** Suggestions: the scope that may be
-   changed (files, roles, services); whether new dependencies, toolchains or
-   languages may be introduced; whether infrastructure or CI configuration may
-   change; the merge bar (default: the `kvb-org-split` skill's 90 % confidence and
-   under 5 % break risk); a time cap per delegated agent (default 60 minutes).
-
-Keep the answers for the rest of the session and do not ask again. Work only
-inside them; a candidate outside them becomes a proposal.
-
-When another skill (kvb-ci-triage, kvb-ci-observe) or an autonomous run invoked
-this skill, skip
-the questions: examine the handed-over log, apply the defaults above, and ask
-only when an operator-only fact blocks.
+First run in a session: before measuring, invoke the `kvb-think-listen` skill
+with the questions of `listen.md` next to this file. Keep the answers for the
+session, never ask again, work only inside them; a candidate outside them
+becomes a proposal. Invoked by another skill (kvb-ci-triage, kvb-ci-observe)
+or an autonomous run: no questions; examine the handed-over log with the
+defaults (10 s floor per run, merge bar the `kvb-org-split` skill's 90 %
+confidence and under 5 % break risk, 60 minutes per delegated agent), ask only
+when an operator-only fact blocks.
 
 ## Forbidden, whatever it saves
 
@@ -49,164 +28,51 @@ only when an operator-only fact blocks.
 - Trading error semantics, credential masking, concurrency safety or a lint's
   intent for speed. A per-item failure stays loud and names its item.
 
-A change that makes the clock smaller by testing less is reported to the
-operator as a coverage cut for them to decide, never applied as a tuning.
+Testing less to shrink the clock is reported as a coverage cut for the
+operator to decide, never applied as a tuning.
 
 ## Measure first
 
-Never tune what has not been measured, and read numbers from logs, not by eye.
-
-- **Task profilers** (Ansible `profile_tasks` and similar) print the duration
-  of the *previous* task under the *next* task's header. Pair each header with
-  the following timestamp line, or read the end-of-run recap.
-- **Build logs** (BuildKit): pair `#N [service x/y] RUN …` with `#N DONE Xs`
-  by step number; `CACHED` marks a hit.
-- **Gates**: per-target wall-clock tables and failed-target lines. An exit code
-  piped through `tee` is not a verdict.
-- **Code paths**: a profiler (py-spy, cProfile, perf, flame graphs) tells
-  whether time goes to CPU, to I/O and waits, or to process start-up.
+- Never tune the unmeasured; read numbers from logs, not by eye (`logs.md`
+  next to this file for profilers, build logs and gate tables).
 - Stream every run to a log file and compare runs by their logs; never re-run
-  to recover a lost number.
-- **Rank by fixed cost x count.** Measure the per-call fixed cost (one
-  application console boot, one package-manager call, one container exec) and
-  multiply by how often the run pays it. A one-second boot paid twenty-eight
-  times is a candidate; a sixty-second download paid once is not.
-- **The baseline is the newest log of the current code.** An older log may
-  still carry the step a previous optimization replaced, and a saving measured
-  against it is fiction.
-
-## Invalid comparisons
-
-Discard a before/after pair, not just its noise, when:
-
-- Another gate, deploy or heavy job shared the machine during either run.
-- The two runs differ in image or cache state. A cold build after a cache prune
-  or a Dockerfile edit is expected: before calling a cold build a defect,
-  compare the instruction text and the base image digest across both logs.
-- One run pays a one-time cost (first install, migration, purge, model
-  download) the other does not.
-- A long wait hides retries or a failure; count retry lines before calling it
-  slow.
-- A fresh-install pass is compared with an update pass. Analyse each pass of a
-  multi-pass run separately.
-
-## Before you optimize
-
-- **Search every branch** (the kvb-git-merge-fix skill's `find_fix.py -S <symbol> --path <path>`) for a change
-  that already removes or reshapes the step. A fix on a sibling branch can make
-  the whole candidate worth zero.
-- A step that is long by design (a backup and restore drill, an end-to-end
-  suite) is not a candidate. Its cost buys its guarantee.
-- Apply the session's saving floor: a smaller saving is listed as "below
-  floor" and dropped.
-- Pruning build caches to free disk costs a cold rebuild of every custom image
-  on the next run. Name that cost before anyone prunes.
+  for a lost number.
+- **Rank by fixed cost x count**: one console boot, package-manager call or
+  container exec times how often the run pays it: a 1 s boot paid 28 times
+  beats a 60 s download paid once.
+- **The baseline is the newest log of the current code**; an older one may
+  carry a step since replaced, and a saving against it is fiction.
 
 ## Coordinate every cost cluster
 
-A cost cluster is one place the time goes: one step, one hot path, one
-repeated call, named by its log line and its number. Before investigating or
-implementing a cluster, run the `kvb-org-organize` skill's Peer protocol for it with
-every agent session on this machine, not only the branch lineage.
-
-- **The first to identify a cluster works it.** "First" is the `kvb-org-organize`
-  claim `cluster/<slug>`, whose `--work` names the cluster's log line and
-  number; between machines, the earliest announcement by message time. A
-  claim without a measurement does not count. In the `kvb-org-rasci` register
-  the cluster's key result is the measured target (`<step> from <before> to
-  under <after>`), met only by the re-measurement.
-- **Someone was earlier:** send them your measurements and findings, then move
-  on to the next cluster. Never build a second optimization of the same
-  cluster.
-- **A claim ends** when its holder reports the result, a proposal or an
-  abandoned attempt and releases it, or when the operator reassigns it.
+Before investigating a cluster (one step, hot path or repeated call), run the
+`kvb-org-organize` Peer protocol with every session on this machine, not only
+the lineage. The first to claim `cluster/<slug>`, `--work` naming its log line
+and number, works it (between machines, the earliest announcement); a claim
+without a measurement does not count. Its `kvb-org-rasci` key result is
+`<step> from <before> to under <after>`, met only by the re-measurement.
+Someone earlier: post them your measurements and findings
+(`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post --to <holder>
+"<text>"`), take the next cluster, never build a second optimization. A claim
+ends with its release or the operator's reassignment.
 
 ## Always check
 
-Every run examines these two on each measured hot path, whatever the operator
-picked in the first question, and lists the result in the output table, a
-clean result included:
+On each measured hot path, whatever the operator picked, listed in the output
+even when clean:
 
-- **Language and framework**: whether the hot path's language and framework
-  are the most efficient fit for its work (see Language and framework).
-- **Unnecessary recursion**: a recursive function that recomputes the same
-  subproblem (memoize it or turn it into a loop), recursion that only walks a
-  list or a fixed depth (a loop), a tree walk that visits or reads the same
-  node more than once, depth that grows with the input (stack limits, Python's
-  1000 frames), and recursive tool calls: a make target calling make, a role
-  or playbook including itself, a script re-invoking itself per item. Count
-  the calls first (a profiler's call graph, cProfile's `ncalls`, log lines);
-  recursion that is bounded, rare and cheap stays.
-
-## Levers that usually pay
-
-- **Batch per-item process spawns**: N calls that each boot an interpreter or
-  an application console become one process running N commands (one app
-  console boot, one module, one batched API request). Keep each item's failure
-  named and the exit code honest.
-- **Skip no-op work** a previous step already did, such as a separate enable
-  after an install that already enabled.
-- **Idempotency flip-flops**: any `changed` on a second consecutive run.
-- **Image pulls and builds**: pull only what the host lacks; keep build caches
-  warm.
-- **Overlap waits with work** only where concurrent execution is proven safe.
-  Schema migrations and lock-holding steps are usually not.
-
-## Language and framework
-
-Check the language and the framework of every measured hot path, for example
-replacing a Python hot path with Rust, or a heavy framework layer with a
-lighter one or the standard library:
-
-- **Only for measured CPU-bound work.** When the profile shows the time in
-  computation inside the process (parsing, hashing, rendering, tight loops),
-  a compiled language can win by an order of magnitude. When the time goes to
-  process start-up, network round trips or waiting, batching in the current
-  language wins first, and a rewrite changes nothing.
-- **Framework overhead**: when the profile puts the time inside the framework
-  (import and start-up, middleware, ORM query building, serialization),
-  compare a lighter framework or the standard library on the same input. An
-  ORM issuing one query per item is fixed by batching the query, not by
-  swapping the framework.
-- **Prefer the narrowest cut**: rewrite the hot function as an extension
-  module (for Python and Rust: PyO3 and maturin) or a small binary behind the
-  same interface, before rewriting a whole tool.
-- **Count the total cost**: a toolchain in CI, builds per target architecture,
-  shipping binaries to every host, the team's ability to maintain the code,
-  and test parity with the old implementation.
-- **Prove it on a prototype**: the same input, the same machine state, a before
-  and an after number, and the old test suite passing against the new code.
-- A language or framework change is applied only when the session's limits
-  allow new languages, frameworks or toolchains; otherwise it is submitted as
-  a proposal with the prototype's numbers.
-
-## Delegating an optimization
-
-Hand every optimization to an agent through the `kvb-org-split` skill: one sidetree
-per candidate, branched from an exact commit, with a time cap and "measure
-first, report the time split before implementing". The agent probes live
-systems read-only and never starts gates or deploys. A broad brief without a
-cap can run for hours without a word; at its cap, collect the agent's interim
-findings and let it run on.
-
-Before merging, run independent skeptics through the `kvb-think-dialectic` skill. The
-antithesis must try to show that the candidate removes coverage, hides a
-failure, or only moves the cost somewhere the measurement does not look.
+- **Language and framework**: the most efficient fit? Time in computation or
+  inside the framework: read `language.md` next to this file.
+- **Unnecessary recursion**: a hot path recursing or a tool calling itself:
+  read `recursion.md` next to this file.
 
 ## The loop
 
-1. Measure, and name the single biggest cost with its log line and number.
-2. Coordinate the cluster with the other agents; work it only when you
-   identified it first, otherwise hand over your findings and take the next.
-   Then form one candidate for it, after the branch search and the floor check.
-3. Harden it with the `kvb-think-dialectic` skill.
-4. Funnel it through a sidetree; merge what reaches the bar, submit the rest as
-   proposals. Re-measure from the same source under the same conditions and
-   report a before and an after number.
-5. Repeat until the next candidate is worth less than the run that measures it.
-6. Hand the prototypes and before/after harnesses of every kept candidate to
-   the `kvb-code-transcend` skill, so the measurement stays in the repository
-   as a benchmark or regression test.
+1. Measure; name the single biggest cost with its log line and number.
+2. Coordinate it; work it only when you identified it first.
+3. Read `candidate.md` next to this file; form one candidate, harden it with
+   the `kvb-think-dialectic` skill, delegate, merge or propose, re-measure.
+4. Repeat until the next candidate is worth less than the run measuring it.
 
 ## Output
 
@@ -214,7 +80,5 @@ One table, biggest saving first:
 
 | Candidate | Before | After | Source | Verdict |
 
-Rejected candidates stay in the table with the reason they fell: below floor,
-coverage cut, outside the session's limits, invalid comparison, made moot by
-another branch, or cap reached without a measured result. Proposals carry what
-would close their gap.
+Rejected candidates stay with the reason they fell; proposals carry what would
+close their gap.

skills/kvb-code-tune/candidate.md

@@ -0,0 +1,71 @@
+# Tune: working a candidate
+
+## Before forming it
+
+- **Search every branch** (the kvb-git-merge-fix skill's `find_fix.py -S
+  <symbol> --path <path>`) for a change that already removes or reshapes the
+  step. A fix on a sibling branch can make the whole candidate worth zero.
+- A step that is long by design (a backup and restore drill, an end-to-end
+  suite) is not a candidate. Its cost buys its guarantee.
+- Apply the session's saving floor: a smaller saving is listed as "below
+  floor" and dropped.
+- Pruning build caches to free disk costs a cold rebuild of every custom
+  image on the next run. Name that cost before anyone prunes.
+
+Levers that usually pay:
+
+- **Batch per-item process spawns**: N calls that each boot an interpreter
+  or an application console become one process running N commands (one app
+  console boot, one module, one batched API request). Keep each item's
+  failure named and the exit code honest.
+- **Skip no-op work** a previous step already did, such as a separate enable
+  after an install that already enabled.
+- **Idempotency flip-flops**: any `changed` on a second consecutive run.
+- **Image pulls and builds**: pull only what the host lacks; keep build
+  caches warm.
+- **Overlap waits with work** only where concurrent execution is proven
+  safe. Schema migrations and lock-holding steps are usually not.
+
+## Delegating it
+
+Hand every optimization to an agent through the `kvb-org-split` skill: one
+sidetree per candidate, branched from an exact commit, with a time cap and
+"measure first, report the time split before implementing". One agent per
+candidate, never more; the brief names the step, its log line and number, the
+files in scope and the claim to prove, and caps the report (for example 15
+lines: time split, change, before and after). The agent probes live systems
+read-only and never starts gates or deploys. A broad brief without a cap can
+run for hours without a word; at its cap, collect the agent's interim
+findings and let it run on.
+
+Before merging, run independent skeptics through the `kvb-think-dialectic`
+skill. The antithesis must try to show that the candidate removes coverage,
+hides a failure, or only moves the cost somewhere the measurement does not
+look. Merge what reaches the bar; submit the rest as proposals.
+
+## Re-measuring it
+
+Re-measure from the same source under the same conditions and report a
+before and an after number. Discard a before/after pair, not just its noise,
+when:
+
+- Another gate, deploy or heavy job shared the machine during either run.
+- The two runs differ in image or cache state. A cold build after a cache
+  prune or a Dockerfile edit is expected: before calling a cold build a
+  defect, compare the instruction text and the base image digest across both
+  logs.
+- One run pays a one-time cost (first install, migration, purge, model
+  download) the other does not.
+- A long wait hides retries or a failure; count retry lines before calling
+  it slow.
+- A fresh-install pass is compared with an update pass. Analyse each pass of
+  a multi-pass run separately.
+
+## Reporting it
+
+Hand the prototypes and before/after harnesses of every kept candidate to the
+`kvb-code-transcend` skill, so the measurement stays in the repository as a
+benchmark or regression test. A rejected candidate stays in the output table
+with the reason it fell: below floor, coverage cut, outside the session's
+limits, invalid comparison, made moot by another branch, or cap reached
+without a measured result.

skills/kvb-code-tune/language.md

@@ -0,0 +1,27 @@
+# Tune: language and framework
+
+For example a Python hot path replaced by Rust, or a heavy framework layer by
+a lighter one or the standard library:
+
+- **Only for measured CPU-bound work.** When the profile shows the time in
+  computation inside the process (parsing, hashing, rendering, tight loops),
+  a compiled language can win by an order of magnitude. When the time goes
+  to process start-up, network round trips or waiting, batching in the
+  current language wins first, and a rewrite changes nothing.
+- **Framework overhead**: when the profile puts the time inside the
+  framework (import and start-up, middleware, ORM query building,
+  serialization), compare a lighter framework or the standard library on the
+  same input. An ORM issuing one query per item is fixed by batching the
+  query, not by swapping the framework.
+- **Prefer the narrowest cut**: rewrite the hot function as an extension
+  module (for Python and Rust: PyO3 and maturin) or a small binary behind the
+  same interface, before rewriting a whole tool.
+- **Count the total cost**: a toolchain in CI, builds per target
+  architecture, shipping binaries to every host, the team's ability to
+  maintain the code, and test parity with the old implementation.
+- **Prove it on a prototype**: the same input, the same machine state, a
+  before and an after number, and the old test suite passing against the new
+  code.
+- A language or framework change is applied only when the session's limits
+  allow new languages, frameworks or toolchains; otherwise it is submitted as
+  a proposal with the prototype's numbers.

skills/kvb-code-tune/listen.md

@@ -0,0 +1,20 @@
+# Tune: the session's limits
+
+Ask three questions through the host's structured question mechanism, each a
+checklist (multi-select) with suggestions, free text allowed:
+
+1. **What to examine.** Suggestions: CI wall-clock, deploy duration, gate and
+   test runtime, image pulls and build caches, per-item loops and process
+   spawns, idempotency (work repeated on a second run), network round trips,
+   and resource use (CPU, memory, disk, I/O). Language, framework and
+   recursion are checked on every run anyway.
+2. **Which performance boundaries to keep.** Suggestions: time budgets per
+   job, deploy or gate; resource caps (memory, CPU, disk headroom); a minimum
+   saving per change (default 10 s per run); the measurement source that
+   counts as the verdict.
+3. **Which limits apply to optimizations.** Suggestions: the scope that may
+   be changed (files, roles, services); whether new dependencies, toolchains
+   or languages may be introduced; whether infrastructure or CI configuration
+   may change; the merge bar (default: the `kvb-org-split` skill's 90 %
+   confidence and under 5 % break risk); a time cap per delegated agent
+   (default 60 minutes).

skills/kvb-code-tune/logs.md

@@ -0,0 +1,11 @@
+# Tune: reading the numbers
+
+- **Task profilers** (Ansible `profile_tasks` and similar) print the duration
+  of the *previous* task under the *next* task's header. Pair each header
+  with the following timestamp line, or read the end-of-run recap.
+- **Build logs** (BuildKit): pair `#N [service x/y] RUN …` with `#N DONE Xs`
+  by step number; `CACHED` marks a hit.
+- **Gates**: per-target wall-clock tables and failed-target lines. An exit
+  code piped through `tee` is not a verdict.
+- **Code paths**: a profiler (py-spy, cProfile, perf, flame graphs) tells
+  whether time goes to CPU, to I/O and waits, or to process start-up.

skills/kvb-code-tune/recursion.md

@@ -0,0 +1,14 @@
+# Tune: unnecessary recursion
+
+Look for:
+
+- a recursive function that recomputes the same subproblem: memoize it or
+  turn it into a loop;
+- recursion that only walks a list or a fixed depth: a loop;
+- a tree walk that visits or reads the same node more than once;
+- depth that grows with the input (stack limits, Python's 1000 frames);
+- recursive tool calls: a make target calling make, a role or playbook
+  including itself, a script re-invoking itself per item.
+
+Count the calls first (a profiler's call graph, cProfile's `ncalls`, log
+lines); recursion that is bounded, rare and cheap stays.

skills/kvb-create-plan/SKILL.md

@@ -2,66 +2,66 @@
 name: kvb-create-plan
 description: >
   Turn a request into an objective-oriented plan for the kvb-org-robot skill.
-  Trigger on /kvb-create-plan or a request for a plan, breakdown or strategy
-  before work starts.
+  Trigger on a request for a plan, breakdown or strategy before work starts.
 ---
 
 Produce a plan whose every item is an outcome with a check, then execute it
-autonomously. A plan that lists activities instead of objectives cannot be
-verified, and an unverifiable plan cannot be handed to a robot.
+autonomously. A plan of activities instead of objectives cannot be verified,
+and an unverifiable plan cannot be handed to a robot.
 
 ## Procedure
 
 1. **Interview first.** Open every plan with the `kvb-think-listen` skill: ask
-   until scope, constraints, success criteria, and the operator-only facts are
-   all pinned, then reflect the understanding back. This is the only point in
-   the run where questions are allowed, so leave nothing open here.
-2. **Pin the objective.** State the end state in one sentence, as a condition
-   that is either true or false, never as an activity. Name the command or
-   observation that proves it.
-3. **Inspect before decomposing.** Read the code, config, tests, and history the
-   objective touches. Every plan item must rest on something you have seen, not
-   on an assumption about how the project works.
-4. **Decompose into sub-objectives.** Each item gets: the outcome it reaches,
-   the verification that proves it, and the items it depends on. Split an item
-   whenever it needs more than one verification. Order by dependency and mark
-   the items that are independent, so they can run in parallel.
-5. **Resolve the open decisions now.** Any root cause, design choice, or
-   trade-off the plan rests on gets settled before execution, escalating to the
-   `kvb-think-dialectic` skill where being wrong is expensive. The robot does not ask, so
-   an unresolved decision becomes a guess at runtime.
-6. **Record the plan in the register.** Enter the objective in the
+   until scope, constraints, success criteria and the operator-only facts are
+   pinned, then reflect the understanding back. This is the only point in the
+   run where questions are allowed, so leave nothing open.
+2. **Pin the objective.** The end state in one sentence, as a condition that
+   is true or false, never an activity, with the command or observation that
+   proves it.
+3. **Inspect before decomposing.** Read the code, config, tests and history
+   the objective touches; every item rests on something you have seen, not on
+   an assumption. Explore the code through the codebase-memory-mcp graph
+   first (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`;
+   the `kvb-agent-optimize` skill sets it up), grep and read after.
+4. **Decompose into sub-objectives.** Each item gets its outcome, the
+   verification that proves it, and the items it depends on. Split an item
+   that needs more than one verification. Order by dependency and mark the
+   independent items, so they can run in parallel.
+5. **Resolve the open decisions now.** Every root cause, design choice or
+   trade-off the plan rests on is settled before execution, through the
+   `kvb-think-dialectic` skill where being wrong is expensive. The robot does
+   not ask, so an unresolved decision becomes a guess at runtime.
+6. **Record the plan in the register.** The objective goes into the
    `kvb-org-rasci` register with each sub-objective's verification as a key
-   result, and mirror the sub-objectives into the harness's own todo tracking,
-   one entry per item, phrased as the outcome. Keep a plan file only when the
-   operator asks for one.
-7. **Present it and wait.** Show the objective, the ordered sub-objectives with
-   their verifications, what is deliberately out of scope, and the assumptions
-   the plan rests on. Stop here: the plan is the deliverable of this step.
-8. **Implement it statically, in full.** On the operator's go, write every code,
-   config, test, and doc change the plan calls for, across all sub-objectives,
-   before running anything that needs live infrastructure. Verify statically:
-   read the diff, run the linters, the unit tests, and whatever dry-run or
-   syntax check the project offers. This step ends only when the whole plan
-   exists on disk, with no sub-objective left unwritten.
-9. **Then iterate under `kvb-org-robot`.** With the static implementation complete,
-   invoke the `kvb-org-robot` skill with the objective as its goal for the dynamic part:
-   run, deploy, observe, fix, repeat until every verification passes. It drives
-   the loop without check-ins, verifies each outcome instead of assuming it, and
-   reports the items that fall outside its clearance for the operator to run.
+   result; mirror the sub-objectives into the harness's todo tracking, one
+   entry per item, phrased as the outcome. A plan file only when the operator
+   asks for one.
+7. **Present it and wait.** Show the objective, the ordered sub-objectives
+   with their verifications, what is deliberately out of scope, and the
+   assumptions the plan rests on. Stop: the plan is this step's deliverable.
+8. **Implement it statically, in full.** On the operator's go, write every
+   code, config, test and doc change the plan calls for, across all
+   sub-objectives, before running anything that needs live infrastructure.
+   Verify statically: read the diff, run the linters, the unit tests, and any
+   dry-run or syntax check the project offers. The step ends only when the
+   whole plan exists on disk.
+9. **Then iterate under `kvb-org-robot`.** Invoke the `kvb-org-robot` skill
+   with the objective as its goal for the dynamic part: run, deploy, observe,
+   fix, repeat until every verification passes. It drives the loop without
+   check-ins, verifies each outcome, and reports the items outside its
+   clearance for the operator to run.
 
 ## Rules
 
-- One objective per item, in outcome form: "endpoint returns 200 for an expired
-  token", not "fix the auth middleware".
-- No item without a verification. If you cannot name what proves it, the item is
-  still a wish, not a plan.
+- One objective per item, in outcome form: "endpoint returns 200 for an
+  expired token", not "fix the auth middleware".
+- No item without a verification; an item nothing proves is a wish.
 - Plan only what the request covers. Speculative future-proofing, refactors
-  nobody asked for, and abstractions with one caller belong in the out-of-scope
-  list, not in the plan.
-- Static before dynamic: never start the robot loop on a half-written plan. A
-  deploy that fails on code you had not written yet costs a full cycle and
-  proves nothing.
-- Re-plan on contradicted evidence: when execution disproves an assumption the
-  plan rests on, revise the plan instead of forcing the original steps through.
+  nobody asked for, and abstractions with one caller go to the out-of-scope
+  list.
+- Static before dynamic: never start the robot loop on a half-written plan; a
+  deploy failing on code not yet written costs a full cycle and proves
+  nothing.
+- Re-plan on contradicted evidence: when execution disproves an assumption,
+  revise the plan instead of forcing the original steps through.
 - Cite `file:line` for every claim about the current state of the code.

skills/kvb-create-requirement/SKILL.md

@@ -2,8 +2,8 @@
 name: kvb-create-requirement
 description: >
   Write a requirement: user story, decisions, Mermaid approach, acceptance
-  criteria, tests. Trigger on /kvb-create-requirement, "requirement
-  schreiben", or a kvb-think-gaps pick.
+  criteria, tests. Trigger on "requirement schreiben" or a kvb-think-gaps
+  pick.
 ---
 
 Writes requirements, never implementations. Nothing touches disk before the
@@ -70,8 +70,11 @@ order:
 
 Show the full draft, then `AskUserQuestion`: `Write it` / `Revise it` /
 `Discard`. Revise loops back to the step the correction touches. Write only
-on `Write it`; lint the file with the project's markdown linter on the
-resource chair's grant (the `kvb-org-organize` skill).
+on `Write it`; lint the file with the project's markdown linter, a light run
+that self-admits with
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
+test-nostack`; a lint through `make` or Docker waits for the resource chair's
+grant (the `kvb-org-organize` skill).
 
 ## Step 6: hand over
 

skills/kvb-dream/SKILL.md

@@ -2,152 +2,90 @@
 name: kvb-dream
 description: >
   Process the last 24 hours of every repository and session: memory,
-  improvements, kvb-optimize, cleanups. Trigger on /kvb-dream or a request
-  to learn from recent work.
+  improvements, kvb-optimize, cleanups. Trigger on a request to learn from
+  recent work.
 ---
 
-Sleep on the work: replay what happened, separate what held from what broke,
-keep only the conclusions that survive an attack, then optimize and clean up.
-Dreaming processes everything. A dream that flatters the dreamer is worthless —
-an unverified success counts as unknown, not as a win.
+Replay what happened, separate what held from what broke, keep only
+conclusions that survive an attack, then optimize and clean up.
 
 ## Objective
 
-The dream exists to raise the confidence of every future run until the
-mistakes it found cannot happen again. Judge every finding, memory
-entry, and proposal by one question: does it make the next run measurably less
-likely to repeat this failure? What changes nothing about future behaviour is
-not worth recording.
-
-A class of error counts as closed only when something structural prevents it —
-a test, a lint rule, a CI check, a hook, a written rule in the agent
-instructions, or a skill. "Be more careful next time" closes nothing. Report the
-confidence the next run can now hold on each closed class, calibrated as the
+Make the next run measurably less likely to repeat each failure found; what
+changes no future behaviour is not recorded. An error class is closed only by
+something structural (test, lint rule, CI check, hook, written rule in the
+agent instructions, skill), never by "be more careful". Per closed class,
+report the confidence the next run can hold, calibrated as the
 `kvb-check-confidence` skill requires, and name what is still open.
 
 ## Scope
 
-Every repository and session this agent touched in the window: the
-repositories named by its session transcripts (working directories and
-worktrees), by the workdirs of its `kvb-org-rasci` register tasks, and the
-current one. The default window is the last 24 hours — the operator may widen
-it (`/kvb-dream 7d`). State the repositories and the window in one table before
-you start. Each repository is recalled and scored on its own; a finding goes
-into the memory of the project it concerns, never mixed with another's.
-
-Run only when the operator asks. Two hints point at it, neither is a trigger:
-`hooks/reminder.sh` tells each agent at most once every twelve hours (stamped
-per session in `~/.claude/.dream-stamps/`), and the `kvb-dream-notify.timer`
-user timer shows a GNOME notification daily at 17:00 local time, catching up
-once after a missed run. Print the hint and continue with the actual request.
+Every repository and session this agent touched in the window: its
+transcripts' working directories and worktrees, its `kvb-org-rasci` task
+workdirs, the current one. Window: 24 hours, or wider on request (`7d` after
+the command). State both in one table first. Recall and score each repository
+on its own; a finding goes only into its own project's memory. Run only when
+the operator asks; read `hints.md` next to this file when a hint appears or
+before changing the reminder.
 
 ## Step 1: recall
 
-Gather the window's actual record per repository, not your recollection of it:
+The actual record per repository, not your recollection:
 
-- **History**: `git log --since` across all branches plus `--reflog`, with
-  `--stat`; the reflog carries the resets, rebases, and amends the log hides.
-- **Working state**: `git status`, the staged and unstaged diff, stashes.
-- **CI**: the runs created in the window, their conclusions, and the failing
-  logs of the red ones — the failing log line, not the job title.
-- **Reviews**: pull requests and issues touched in the window, and the review
-  comments on them.
-- **Register**: the `kvb-org-rasci` register: `rasci.py tools` ranks the
-  scripts and tools the window's tasks ran, the refactoring candidates;
-  `get <task>` shows a task's objective, roles, workdir and artifacts.
-- **Memory**: each project's memory directory and its `MEMORY.md` index — the
-  findings already recorded, so the dream extends them instead of repeating them.
-- **Instructions**: `CLAUDE.md`, `AGENTS.md`, and the project's own skills, to
-  see which rule a mistake actually violated.
-- **Sessions**: the readable session transcripts touched in the window, for the
-  operator corrections that never reached a commit.
+- **History**: `git log --since` over all branches plus `--reflog` (resets,
+  rebases, amends), with `--stat`.
+- **Working state**: `git status`, staged and unstaged diff, stashes.
+- **CI**: the window's runs, conclusions, and each red run's failing log line,
+  not the job title.
+- **Reviews**: pull requests and issues touched, with review comments.
+- **Register**: `rasci.py tools` ranks the tools the tasks ran (refactoring
+  candidates); `get <task>` shows objective, roles, workdir, artifacts.
+- **Memory**: each project's memory directory and `MEMORY.md`, to extend
+  recorded findings instead of repeating them.
+- **Instructions**: `CLAUDE.md`, `AGENTS.md`, the project's skills: which rule
+  a mistake violated.
+- **Sessions**: readable transcripts, for operator corrections that never
+  reached a commit.
 
 ## Step 2: score
 
-Classify every action in the window, each with its evidence (`sha`, `file:line`,
-run id):
+Every action, with evidence (`sha`, `file:line`, run id):
 
-- **Held** — shipped and still proven: green CI, a passing test that covers it,
-  no revert, no follow-up fix.
-- **Broke** — reverted, amended, hot-fixed by a later commit, red CI, or
-  corrected by the operator. A failure that ended green is still a failure; count
-  the detour, not only the destination.
-- **Unknown** — no verification exists either way. Unknown is a finding in its
-  own right, never a quiet pass.
+- **Held**: shipped and still proven: green CI, a passing test covering it, no
+  revert, no follow-up fix.
+- **Broke**: reverted, amended, hot-fixed later, red CI, or corrected by the
+  operator; ending green does not undo the failed first attempt.
+- **Unknown**: no verification either way, so no win; a finding of its own,
+  never a quiet pass.
 
-## Step 3: hypothesize
+## Steps 3 to 6: findings
 
-Turn the scored record into falsifiable hypotheses, each written as *cause →
-predicted consequence → what would disprove it*. Take a pattern (two or more
-occurrences) or a single expensive failure; drop the one-off noise. A hypothesis
-that nothing could disprove is not a hypothesis — cut it.
-
-## Step 4: dialectic
-
-Put every surviving hypothesis through the `kvb-think-dialectic` skill: thesis,
-independent skeptics, synthesis, iterated to ~99%. What survives becomes a
-finding. What gets refuted is recorded as discarded **with the refutation**, so
-the next dream does not re-derive it.
-
-## Step 5: write memory
-
-Persist the findings in the memory directory of the project they concern: one file per fact, one
-pointer line in `MEMORY.md`. Update the file that already covers a fact instead
-of adding a duplicate, and delete the memories this run disproved. Absolute
-dates, never "yesterday". Nothing that the repository already records — code
-structure, git history, `CLAUDE.md` — belongs in memory.
-
-## Step 6: offer the improvements
-
-Two kinds come out of the findings:
-
-- **Code** — the change to the affected repository's source, tests, config, or CI that
-  the finding calls for.
-- **Agent instructions** — the missing or wrong rule in `CLAUDE.md`,
-  `AGENTS.md`, the project's own skills, or the contributor docs. Every mistake
-  the agent repeated in the window is a candidate: quote the line that failed to
-  prevent it, or name the rule that is absent, and propose the exact wording.
-
-Ask for each one with `AskUserQuestion` and `multiSelect: false` so it renders
-as radio buttons: the improvement, the evidence behind it, and the options
-`Apply now`, `Record as a task`, `Skip`. Ranked by evidence, one question per
-improvement. No repository file changes before an answer comes back.
+When the record holds a pattern or an expensive failure, read
+`hypotheses.md` next to this file. Offer each improvement, ranked by
+evidence, in its own `AskUserQuestion` with `multiSelect: false`: `Apply
+now`, `Record as a task`, `Skip`.
 
 ## Step 7: optimize
 
-With the dialectic done and memory written, run the `kvb-optimize` skill and
-hand it this run's findings as its evidence, so none of its skills
-re-collects them. Its pass includes the `kvb-transcend` skill, which carries
-the scripts, tests and skills of every session in scope into their
-repositories.
+Run the `kvb-optimize` skill with this run's findings as its evidence, so none
+of its skills re-collects them; its `kvb-transcend` pass carries every
+in-scope session's scripts, tests and skills into their repositories.
 
 ## Step 8: clean up
 
-Run the `kvb-cleanup` skill for the disk, `/tmp`, Docker and agent
-directories the window filled, with the artifacts of the window's finished
-register tasks (`rasci.py artifacts --ended`) as its candidates, then the
-`kvb-git-branch-gc` skill for the merged branches and worktrees of every
-repository in scope.
-
-Every skill in steps 7 and 8 keeps its own confirmation steps; the dream never
-writes, deletes or commits on their behalf. Close the run by refreshing this
-agent's reminder stamp, so its next hint is twelve hours out:
-`date +%s > ~/.claude/.dream-stamps/"$CLAUDE_CODE_SESSION_ID"`.
+The `kvb-cleanup` skill for the disk, `/tmp`, Docker and agent directories the
+window filled, with the finished tasks' artifacts (`rasci.py artifacts
+--ended`) as candidates; then the `kvb-git-branch-gc` skill for every
+in-scope repository's merged branches and worktrees. Each keeps its own
+confirmations; the dream never writes, deletes or commits for them. Close
+with `date +%s > ~/.claude/.dream-stamps/"$CLAUDE_CODE_SESSION_ID"`, so the
+next hint is twelve hours out.
 
 ## Rules
 
-- Evidence or unknown: a claim about what held needs a green signal, and its
-  absence is reported as unknown rather than assumed.
-- Honest scoring: reverts, amends, and follow-up fixes are failures of the first
-  attempt even when the final state is green.
-- Read-only until step 6: the dream inspects, and writes memory; repository code
-  changes only on an explicit radio answer.
-- An empty window is a valid result — report "nothing in the last 24 hours" per
-  repository and skip it. Never invent activity to have something to dream
-  about.
-- Prefer the structural fix over the remembered one: a test, check, hook, or
-  written rule that makes the error impossible beats a memory entry that only
-  reminds you of it.
-- Report the whole ledger: held, broke, unknown, the surviving findings, the
-  refuted hypotheses with why they fell, and the confidence each closed error
-  class now carries into the next run.
+- Read-only until step 6: the dream writes memory; repository code changes
+  only on an explicit radio answer.
+- An empty window is valid: report "nothing in the last 24 hours" per
+  repository and skip it; never invent activity.
+- Report the whole ledger: held, broke, unknown, surviving findings, refuted
+  hypotheses with why they fell.

skills/kvb-dream/hints.md

@@ -0,0 +1,10 @@
+# Dream hints
+
+Two hints point at the dream; neither is a trigger:
+
+- `hooks/reminder.sh` tells each agent at most once every twelve hours,
+  stamped per session in `~/.claude/.dream-stamps/`.
+- The `kvb-dream-notify.timer` user timer shows a GNOME notification daily at
+  17:00 local time, catching up once after a missed run.
+
+On a hint, print it and continue with the actual request.

skills/kvb-dream/hypotheses.md

@@ -0,0 +1,41 @@
+# From scored record to improvements
+
+## Step 3: hypothesize
+
+A pattern (two or more occurrences) or a single expensive failure becomes a
+falsifiable hypothesis: *cause → predicted consequence → what would disprove
+it*. Drop one-off noise; cut a hypothesis nothing could disprove.
+
+## Step 4: dialectic
+
+Every surviving hypothesis goes through the `kvb-think-dialectic` skill to
+~99%. Scale the skeptics to the stakes: one for a memory fact, more for a rule
+or code change. Each brief names the exact files, commits or log lines and the
+one claim to attack, and caps the answer at ten lines. Survivors become
+findings; refuted ones are recorded as discarded **with the refutation**, so
+the next dream does not re-derive them.
+
+## Step 5: write memory
+
+In the memory directory of the project concerned: one file per fact, one
+pointer line in `MEMORY.md`. Update the file covering a fact instead of adding
+a duplicate; delete memories this run disproved. Absolute dates, never
+"yesterday". Nothing the repository already records (code structure, git
+history, `CLAUDE.md`).
+
+## Step 6: the improvements
+
+- **Code**: the change to the repository's source, tests, config or CI the
+  finding calls for.
+- **Agent instructions**: the missing or wrong rule in `CLAUDE.md`,
+  `AGENTS.md`, the project's skills or contributor docs. Every mistake repeated
+  in the window is a candidate: quote the line that failed to prevent it or
+  name the absent rule, and propose the exact wording.
+
+Prefer the structural fix (test, check, hook, written rule) that makes the
+error impossible over a memory entry that only reminds. Each question carries
+the improvement and its evidence.
+
+A finding on a live peer's line goes to it as
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post "<finding>" --to
+<name>`; `SendMessage` only when the peer must act or answer.

skills/kvb-git-branch-gc/SKILL.md

@@ -2,8 +2,8 @@
 name: kvb-git-branch-gc
 description: >
   Remove merged branches and worktrees with `pkgmgr branch gc` after a dry
-  run the operator picks from. Trigger on /kvb-git-branch-gc, "branches
-  aufräumen", "worktrees aufräumen".
+  run the operator picks from. Trigger on "branches aufräumen",
+  "worktrees aufräumen".
 ---
 
 `pkgmgr branch gc` decides what is merged and does the removing; this skill
@@ -17,7 +17,7 @@ and nothing is removed before the operator's pick in this run.
 2. The apply takes stacks down and ends with a host-wide
    `docker image prune -f` and `docker builder prune -f`, which reach every
    session's images and build cache. When another session holds the chair,
-   send it what, where and how long, and wait for the grant; the prune never
+   request the grant (what, where, how long) and wait for it; the prune never
    runs during a peer's build.
 
 ## Step 1: dry run
@@ -40,22 +40,19 @@ before it: gc fetches without auto-maintenance, while a plain fetch on git
 
 Never override a state: a branch without own commits is `unmerged` even
 though git sees its tip on the default branch, because it is fresh work.
-
-`host_pid_namespace: false` means the dry run ran inside a sandbox: it saw no
+`host_pid_namespace: false` means the dry run ran in a sandbox: it saw no
 processes and could not tell whether a lock is live. Say so above the plan;
 the apply re-checks both on the host.
 
 ## Step 2: claims
 
-Read `council.py list`. For every candidate whose branch or worktree a peer's
-claim names, send that peer one message (Peer protocol) and wait up to 5
+Read `council.py list --long`. Every peer whose claim names a candidate's branch or
+worktree gets one message listing all its items (Peer protocol); wait up to 5
 minutes. A kept or unanswered item leaves the plan as `keep (<peer>)`;
 silence is not consent.
 
 ## Step 3: plan
 
-One table:
-
 | Repo | Branch or worktree | Merged into | Size | Actions | Note |
 
 Then ask with `AskUserQuestion`:
@@ -69,40 +66,19 @@ Then ask with `AskUserQuestion`:
 
 ## Step 4: apply
 
-1. Re-read `council.py list` and drop every item claimed since the dry run.
-2. `--apply` refuses outside the host PID namespace (exit 2) and deletes
-   remote branches, which is a push. Unless this session runs in the host PID
-   namespace and the project lets agents push, hand the operator one command
-   per repository, run from inside it, one `--branch` per picked item (the
-   worktree path for a detached worktree):
-
-   ```bash
-   pkgmgr branch gc --apply --json --branch <name> --branch <name> | tee /tmp/branch-gc-apply-<N>.json
-   ```
-
-3. Read every item's `result` in that file: `done`, `done; image kept: <img>`
-   (still in use elsewhere), or `failed: <why>`.
-   Report a failure as it stands; never remove by hand what gc skipped or
-   refused.
-4. For every `done` item, drop its worktree and branch from the task that
-   lists them in the `kvb-org-rasci` register (`rasci.py artifacts` names
-   it): `set <task> --drop-artifact worktree:<path>`, and `--branch ''` where
-   the branch is gone.
+Read `apply.md` next to this file once the operator picked `Apply`.
 
 ## Step 5: unmerged and dirty
 
-Never part of the apply. One `AskUserQuestion` question per item
-(`multiSelect: false`): `Keep (Recommended)` and `Delete`, the description
-naming what is lost (the item's `reason`: unique commits, dirty paths). For
-each `Delete`, hand the operator
-`pkgmgr branch purge --branch <name>`: it asks y/N per item and answers no
-without a terminal, so it runs only in the operator's shell.
+When the dry run sorted any item here, read `unmerged.md` next to this file.
 
 ## Step 6: report
 
-Removed, kept and skipped items, each with its reason, and
-`docker system df` before and after. Report the release to the chair, tell
-each peer whose line an item touched what went, and release the claim.
+Removed, kept and skipped items, each with its reason, and `docker system df`
+before and after. The release for the chair and what went for each peer whose
+line an item touched go out as one
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post "<text>"`, not
+as messages; then release the claim.
 
 ## Rules
 

skills/kvb-git-branch-gc/apply.md

@@ -0,0 +1,20 @@
+# Apply
+
+1. Re-read `council.py list --long` and drop every item claimed since the dry run.
+2. `--apply` refuses outside the host PID namespace (exit 2) and deletes
+   remote branches, which is a push. Unless this session runs in the host PID
+   namespace and the project lets agents push, hand the operator one command
+   per repository, run from inside it, one `--branch` per picked item (the
+   worktree path for a detached worktree):
+
+   ```bash
+   pkgmgr branch gc --apply --json --branch <name> --branch <name> | tee /tmp/branch-gc-apply-<N>.json
+   ```
+
+3. Read every item's `result` there: `done`, `done; image kept: <img>` (still
+   in use elsewhere), or `failed: <why>`. Report a failure as it stands; never
+   remove by hand what gc skipped or refused.
+4. For every `done` item, drop its worktree and branch from the task listing
+   them in the `kvb-org-rasci` register (`rasci.py artifacts` names it): `set
+   <task> --drop-artifact worktree:<path>`, and `--branch ''` where the branch
+   is gone.

skills/kvb-git-branch-gc/unmerged.md

@@ -0,0 +1,8 @@
+# Unmerged and dirty items
+
+Never part of the apply. One `AskUserQuestion` question per item
+(`multiSelect: false`): `Keep (Recommended)` and `Delete`, the description
+naming what is lost (the item's `reason`: unique commits, dirty paths). For
+each `Delete`, hand the operator `pkgmgr branch purge --branch <name>`: it
+asks y/N per item and answers no without a terminal, so it runs only in the
+operator's shell.

skills/kvb-git-changelog/SKILL.md

@@ -2,14 +2,14 @@
 name: kvb-git-changelog
 description: >
   Write the release message for `pkgmgr release`; prints only. Trigger on
-  /kvb-git-changelog, "release message", "changelog entry", before cutting a
+  "release message", "changelog entry", before cutting a
   release, or on pkgmgr's markdown-lint rejection.
 ---
 
-The message is one text that pkgmgr writes to four places: the CHANGELOG.md
-entry, the annotated release tag, `debian/changelog` and the RPM `%changelog`.
-Every rule below exists because one of those four would otherwise break or
-mangle it.
+Read `reasons.md` next to this file when a rule seems not to fit or a lint
+finding is unclear, and `special.md` for: no tag, a failed previous-tag
+workflow, a test- or CI-only release, no `markdownlint-cli2`, a pasted pkgmgr
+rejection.
 
 ## 1. Find the range
 
@@ -19,124 +19,65 @@ git describe --tags --abbrev=0 --match 'v[0-9]*.[0-9]*.[0-9]*'
 git log --no-merges --format='%h %s%n%b' <tag>..HEAD
 ```
 
-- pkgmgr tags every release `vX.Y.Z`; the newest one reachable from HEAD is
-  the base. No such tag: the range is the whole history, say so.
-- Drop the `Release version X.Y.Z` commits and any revert together with the
+- The base is the newest `vX.Y.Z` tag reachable from HEAD.
+- Drop `Release version X.Y.Z` commits, and any revert together with the
   commit it reverts inside the range.
 - A subject is a lead, not the change: read the diff (`git show --stat`, then
-  the hunks) when the subject does not say what changed for the user.
-- When `gh` is available, read the CI of the previous tag's commit and of HEAD,
-  every workflow (`gh run list --commit <sha> --json
-  workflowName,status,conclusion`), not one picked by `-L 1`.
-  - Previous tag: a workflow that finished as a failure means that version was
-    never published: say so under *Upgrade notes* and carry its upgrade notes
-    forward to this release.
-  - HEAD: a workflow that finished as a failure means pkgmgr would tag a
-    release that never goes stable, because its CI gate runs after the tag.
-    Queued, running or missing runs are normal; report only the failure, in
-    step 5.
+  the hunks) when it does not say what changed for the user.
+- With `gh`, read every workflow of the previous tag's commit and of HEAD
+  (`gh run list --commit <sha> --json workflowName,status,conclusion`), not
+  one picked by `-L 1`. Only a finished failure counts; queued, running or
+  missing runs are normal.
 
 ## 2. Sort into sections
 
-| Commit | Section |
-| --- | --- |
-| `feat` | Added, or Changed when it alters existing behaviour |
-| `fix`, `perf` | Fixed |
-| `!` or `BREAKING CHANGE:` | Breaking, plus one Upgrade notes line per required action |
-| `docs`, `style`, `refactor`, `test`, `ci`, `build`, `chore` | omitted unless a user sees the effect |
-| dependency bumps | one collapsed line, or omitted |
-
-When nothing user-visible remains (a test- or CI-only release), keep those
-commits under Fixed with an area prefix (`Tests:`, `CI:`) so the entry is not
-empty.
-
-Order: Breaking, Added, Changed, Fixed, Upgrade notes. Leave out empty
-sections.
+`feat`: Added, or Changed when it alters existing behaviour. `fix`, `perf`:
+Fixed. `!` or `BREAKING CHANGE:`: Breaking, plus one Upgrade notes line per
+required action. `docs`, `style`, `refactor`, `test`, `ci`, `build`,
+`chore`: omitted unless a user sees the effect. Dependency bumps: one
+collapsed line, or omitted. Order: Breaking, Added, Changed, Fixed, Upgrade
+notes; empty sections left out.
 
 ## 3. Format
 
-```text
-Fixed:
-
-- Backup: rsync -a stored no xattrs, ACLs or hardlinks; now -aHAX
-- Restore: *--empty* no longer aborts on a database with an extension
-
-Upgrade notes:
-
-- First backup re-copies every attribute-carrying volume once in full
-```
-
-1. **Section labels are plain lines ending in `:`**, never `#` headings and
-   never a bold-only line. pkgmgr creates the tag with `git tag -a -m`, whose
-   default `strip` cleanup deletes every line starting with `#`. A bold-only
-   line fails MD036.
-2. **No version heading, date or "Release X.Y.Z" line.** pkgmgr adds
-   `## [X.Y.Z] - YYYY-MM-DD` itself.
-3. **One bullet, one line. Too long means shorter, never wrapped.** RPM turns
-   every non-empty line into its own `-` entry and Debian indents each line,
-   so a continuation line becomes a separate, broken entry.
-4. **Line length: the repository's MD013 limit**, which is markdownlint's
-   default of 80 unless the repo's config changes it. Aim for 78 or less, so
-   lines stay within 80 after Debian's two-space indent and RPM's two-character
-   `-` prefix.
-5. **Lists use the marker CHANGELOG.md already uses**, no nesting, with a
-   blank line before and after every list (MD004, MD032). MD004's default
-   *consistent* style takes the marker of the first list in the file, and
-   pkgmgr puts the new entry on top, so a marker that differs from the older
-   entries turns every older list into a finding. Take the marker of the first
-   list item in the existing CHANGELOG.md; use `-` only when there is no
-   CHANGELOG.md yet, and the configured one when the repo's MD004 pins a style.
-6. **No backticks and no code blocks.** pkgmgr rewrites inline code to
-   *italic* in all four targets, and a fenced block fails its fallback lint.
-   Write *names*, *--flags* and *paths* in `*` italics yourself; use `*`, not
-   `_`, for emphasis (MD049).
-7. **Bullet text is `Area: effect`**: the component the user knows (Backup,
+1. Section labels are plain lines ending in `:`; no `#` headings, no
+   bold-only lines.
+2. No version heading, date or "Release X.Y.Z" line.
+3. One bullet, one line: too long means shorter, never wrapped.
+4. Line length: the repository's MD013 limit (markdownlint's default 80);
+   aim for 78 or less.
+5. Lists: no nesting, a blank line before and after (MD004, MD032), the
+   marker of the existing CHANGELOG.md's first list item; `-` without a
+   CHANGELOG.md, the configured one when the repo's MD004 pins a style.
+6. No backticks or code blocks: *names*, *--flags* and *paths* in `*`
+   italics; `*`, not `_`, for emphasis (MD049).
+7. Bullets read `Area: effect`: the component the user knows (Backup,
    Restore, CLI, Tests), then what changed for them, not how the code
-   changed. No commit SHAs, no em dashes: use `:` or `;`.
-8. **Plain hygiene**: no trailing whitespace (MD009), no double blank lines
-   (MD012), no bare URLs: wrap them as `<https://...>` (MD034).
+   changed. No commit SHAs, no em dashes (use `:` or `;`).
+8. No trailing whitespace (MD009), double blank lines (MD012) or bare URLs;
+   wrap URLs as `<https://...>` (MD034).
 
 ## 4. Lint it the way pkgmgr does
 
-pkgmgr wraps the message as `# Changelog`, blank line, `## [X.Y.Z] - date`,
-blank line, message, then runs `markdownlint-cli2` with the target repo's own
-config. Reproduce that exactly:
-
-1. Write that wrapped document to a scratch file outside the repository.
-2. From the repository root, so its config is picked up, run:
-
-   ```bash
-   markdownlint-cli2 --no-globs - < <scratch-file>
-   ```
-
-   *--no-globs* keeps the config's own globs from linting the whole tree too.
-3. A finding on line N points at message line N - 4. Shorten that line and
-   lint again; print nothing until the result is 0 errors.
-4. The standalone check cannot see rules that compare the entry with the rest
-   of the file (MD004 *consistent*, MD024 duplicate headings), but the
-   repository's own markdown lint and pre-push gate do. Copy CHANGELOG.md to a
-   scratch file, insert the wrapped heading and message below its
-   `# Changelog` line, and lint that copy the same way. A finding in the older
-   entries that the unmodified CHANGELOG.md does not produce comes from the
-   new entry; fix the message, never the older entries.
-
-Without `markdownlint-cli2`, check by hand what pkgmgr's fallback checks plus
-the length limit: no line over the limit, no trailing whitespace, no
-backtick, no double blank line.
-
-When the operator pastes pkgmgr's rejection (`changelog entry:7:81 error
-MD013/line-length ...`), apply the same N - 4 mapping to the message they
-used, shorten only the lines it names, and lint again.
+1. Write `# Changelog`, blank line, `## [X.Y.Z] - <date>`, blank line, the
+   message to a scratch file outside the repository.
+2. From the repository root, so its config applies:
+   `markdownlint-cli2 --no-globs - < <scratch-file>`.
+3. A finding on line N is message line N - 4: shorten it and lint again;
+   print nothing before 0 errors.
+4. Lint a scratch copy of CHANGELOG.md with the wrapped entry inserted below
+   its `# Changelog` line the same way. A finding in older entries that the
+   unmodified file lacks comes from the new entry: fix the message, never
+   the older entries.
 
 ## 5. Output
 
 1. The message in one fenced `text` block, nothing else inside it.
-2. One line: `Bump: patch | minor | major` and why (breaking → major,
-   `feat` → minor, otherwise patch).
-3. One line with the lint result (`markdownlint-cli2: 0 errors` or the manual
-   check that ran).
-4. Only when a workflow on HEAD finished as a failure: one line naming it and
-   its run, and the advice not to release before it is green.
+2. `Bump: patch | minor | major` and why (breaking: major, `feat`: minor,
+   otherwise patch).
+3. The lint result (`markdownlint-cli2: 0 errors` or the manual check run).
+4. Only when a workflow on HEAD finished as a failure: its name and run, and
+   the advice not to release before it is green.
 
 Then stop. Never edit CHANGELOG.md or a version file, never run
 `pkgmgr release`, never tag: the operator releases.

skills/kvb-git-changelog/reasons.md

@@ -0,0 +1,48 @@
+# Changelog: why each rule holds
+
+pkgmgr writes one text to the CHANGELOG.md entry, the annotated release tag,
+`debian/changelog` and the RPM `%changelog`; every rule keeps one of them from
+breaking or mangling it.
+
+- **HEAD failure**: pkgmgr's CI gate runs after the tag, so a workflow that
+  failed on HEAD means pkgmgr would tag a release that never goes stable.
+- **Plain section labels**: pkgmgr creates the tag with `git tag -a -m`,
+  whose default `strip` cleanup deletes every line starting with `#`. A
+  bold-only line fails MD036.
+- **No version heading**: pkgmgr adds `## [X.Y.Z] - YYYY-MM-DD` itself.
+- **One line per bullet**: RPM turns every non-empty line into its own `-`
+  entry and Debian indents each line, so a continuation line becomes a
+  separate, broken entry.
+- **78 characters**: lines stay within 80 after Debian's two-space indent
+  and RPM's two-character `-` prefix.
+- **The existing list marker**: MD004's default *consistent* style takes the
+  marker of the first list in the file, and pkgmgr puts the new entry on top,
+  so a marker that differs from the older entries turns every older list
+  into a finding.
+- **No backticks**: pkgmgr rewrites inline code to *italic* in all four
+  targets, and a fenced block fails its fallback lint.
+- **The wrapped lint**: pkgmgr wraps the message as `# Changelog`, blank
+  line, `## [X.Y.Z] - date`, blank line, message, then runs
+  `markdownlint-cli2` with the target repository's own config; hence the
+  N - 4 line mapping.
+- **`--no-globs`**: it keeps the config's own globs from linting the whole
+  tree too.
+- **The whole-file lint**: the standalone check cannot see rules that
+  compare the entry with the rest of the file (MD004 *consistent*, MD024
+  duplicate headings), but the repository's own markdown lint and pre-push
+  gate do.
+- **The manual check**: it covers what pkgmgr's fallback checks, plus the
+  length limit.
+
+A message that follows every rule:
+
+```text
+Fixed:
+
+- Backup: rsync -a stored no xattrs, ACLs or hardlinks; now -aHAX
+- Restore: *--empty* no longer aborts on a database with an extension
+
+Upgrade notes:
+
+- First backup re-copies every attribute-carrying volume once in full
+```

skills/kvb-git-changelog/special.md

@@ -0,0 +1,16 @@
+# Changelog: special cases
+
+- **No `vX.Y.Z` tag reachable from HEAD**: the range is the whole history;
+  say so.
+- **A workflow of the previous tag's commit finished as a failure**: that
+  version was never published. Say so under *Upgrade notes* and carry its
+  upgrade notes forward to this release.
+- **Nothing user-visible remains** (a test- or CI-only release): keep those
+  commits under Fixed with an area prefix (`Tests:`, `CI:`) so the entry is
+  not empty.
+- **No `markdownlint-cli2`**: check by hand what pkgmgr's fallback checks
+  plus the length limit: no line over the limit, no trailing whitespace, no
+  backtick, no double blank line. Name that manual check in the output.
+- **The operator pastes pkgmgr's rejection** (`changelog entry:7:81 error
+  MD013/line-length ...`): apply the same N - 4 mapping to the message they
+  used, shorten only the lines it names, and lint again.

skills/kvb-git-commit-next/SKILL.md

@@ -2,38 +2,38 @@
 name: kvb-git-commit-next
 description: >
   Search every branch for the staged fix, commit it with --no-verify, then
-  stage and brief the next bundle. Trigger on /kvb-git-commit-next or a
-  request to commit and stage next.
+  stage and brief the next bundle. Trigger on a request to commit and stage
+  next.
 ---
 
-1. `git fetch --all --prune --tags`, then hunt the staged fix across every
-   ref with the kvb-git-merge-fix skill's `find_fix.py` (by `--grep`, by `-S`, by
-   `--path`). Describe the staged bundle in one line first so a
-   wrong search intent is visible. Only the search runs here — never
-   cherry-pick or merge, and never touch the staging index or the tree.
-2. A similar fix on another branch is a stop: run the kvb-think-dialectic skill on the
-   two candidates (staged version as thesis, foreign commit as antithesis)
-   until one survives, then present sha, branch, both diffs, the verdict and
-   the recommended move (keep staged / take theirs / combine). Wait for the
-   operator's decision; do not commit.
+1. Describe the staged bundle in one line, so a wrong search intent is
+   visible. Then `git fetch --all --prune --tags` and hunt the staged fix
+   across every ref with the kvb-git-merge-fix skill's `find_fix.py` (by
+   `--grep`, by `-S`, by `--path`). Only the search runs here: never
+   cherry-pick or merge, never touch the staging index or the tree.
+2. A similar fix on another branch is a stop: run the kvb-think-dialectic
+   skill on the two candidates (staged version as thesis, foreign commit as
+   antithesis) until one survives, then present sha, branch, both diffs, the
+   verdict and the recommended move (keep staged / take theirs / combine).
+   Wait for the operator's decision; do not commit.
 3. Nothing similar found, or the operator picked the staged version: run the
-   kvb-git-commit-no-verify skill on the currently staged changes (kvb-code-no-comments
-   audit and kvb-check-legal check first, then its four-line block of
-   worktree path, branch, fix confidence and break risk, then
-   `git commit --no-verify`, exact staging index only).
-4. Group the remaining uncommitted changes into logical bundles (one
-   concern per bundle: same failure class, same mechanism, or same role)
-   and stage the next one; never mix concerns to save a commit. Staging
-   happens here and nowhere else: never stage merely to run a lint or a
-   test. Repository checks that enumerate through `git ls-files` already
-   see tracked, modified files and read the worktree; only an untracked
-   NEW file needs `git add` to become visible. Path-scope every `git add`
-   to the bundle — `git add -A` sweeps up the operator's own edits and
-   their local config. A file that carries two bundles is staged by line:
-   `${CLAUDE_SKILL_DIR}/scripts/stage_hunks.py --repo <worktree> --file
-   <path> --match <regex>`, first with `--dry-run`.
-5. For the newly staged bundle run the kvb-think-explain skill (what the changes do
-   and how the pieces interact, file:line-anchored) followed by the
-   kvb-check-confidence skill (fix confidence, break risk, evidence, residuals).
+   kvb-git-commit-no-verify skill on the currently staged changes
+   (kvb-code-no-comments audit and kvb-check-legal check first, then its
+   four-line block of worktree path, branch, fix confidence and break risk,
+   then `git commit --no-verify`, exact staging index only).
+4. Group the remaining uncommitted changes into logical bundles (one concern
+   per bundle: same failure class, mechanism or role) and stage the next one;
+   never mix concerns to save a commit. Staging happens here and nowhere
+   else: never stage merely to run a lint or a test. Checks that enumerate
+   through `git ls-files` already see tracked, modified files and read the
+   worktree; only an untracked NEW file needs `git add` to become visible.
+   Path-scope every `git add` to the bundle: `git add -A` sweeps up the
+   operator's own edits and local config. A file that carries two bundles is
+   staged by line: `${CLAUDE_SKILL_DIR}/scripts/stage_hunks.py --repo
+   <worktree> --file <path> --match <regex>`, first with `--dry-run`.
+5. For the newly staged bundle run the kvb-think-explain skill (what the
+   changes do and how the pieces interact, file:line-anchored), then the
+   kvb-check-confidence skill (fix confidence, break risk, evidence,
+   residuals).
 6. Close with what remains unstaged and wait for the operator's commit
    decision; never auto-commit the newly staged bundle.

skills/kvb-git-commit-no-verify/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: kvb-git-commit-no-verify
 description: >
-  Commit the staged changes with --no-verify. Trigger on /kvb-git-commit-no-verify or
-  any request for a no-verify commit; invoking it IS the per-commit
+  Commit the staged changes with --no-verify. Trigger on any request for a
+  no-verify commit; invoking it IS the per-commit
   authorization --no-verify requires, never carried over to later commits.
 ---
 

skills/kvb-git-issue-close/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-git-issue-close
 description: >
   Close finished issues, of one pull request or the whole repository, each
-  verified and confirmed. Trigger on /kvb-git-issue-close [pr].
+  verified and confirmed.
 ---
 
 Closing an issue is outward-facing: nothing is closed or edited before the
@@ -13,8 +13,8 @@ commit that fixed it.
 
 - **A pull request named** (or the current branch's, `gh pr view --json
   number`): `${CLAUDE_SKILL_DIR}/scripts/issues.py` lists every issue it
-  references, from closing keywords and mentions in the body and the commits,
-  a trailing number in the branch name, and the issues GitHub already links:
+  references: closing keywords and mentions in the body and the commits, a
+  trailing number in the branch name, and the issues GitHub already links.
 
   ```bash
   gh pr view <pr> --json number,body,headRefName,commits,closingIssuesReferences | issues.py --repo <owner/name>
@@ -34,15 +34,15 @@ commit that fixed it.
 ## Step 2: verify
 
 Per candidate, `gh issue view <n> --json state,title,body,comments` (with
-`--repo` for a foreign one); a closed issue is skipped. Judge it `fixed`,
-`partly` or `unrelated` against the diff, with evidence: the change that
-addresses each point of the issue and the test or CI run that proves it.
-Only `fixed` goes on; `partly` gets a progress comment instead.
+`--repo` for a foreign one); skip a closed issue. Judge it `fixed`, `partly`
+or `unrelated` against the diff, with evidence: the change addressing each
+point of the issue and the test or CI run proving it. Only `fixed` goes on;
+`partly` gets a progress comment instead.
 
 ## Step 3: confirm
 
-`AskUserQuestion` with `multiSelect: true`, one option per `fixed` issue,
-the evidence in its description, nothing preselected.
+`AskUserQuestion` with `multiSelect: true`, one option per `fixed` issue, the
+evidence in its description, nothing preselected.
 
 ## Step 4: close
 

skills/kvb-git-issue-solve/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-git-issue-solve
 description: >
   Solve open issues, each in its own worktree, and open one pull request per
-  issue. Trigger on /kvb-git-issue-solve [issue...].
+  issue.
 ---
 
 Every issue gets its own sidetree, its own evidence and its own pull
@@ -12,9 +12,9 @@ request, so a red one blocks nothing else.
 
 1. **Candidates**: the issues named, else `gh issue list --state open`. Drop
    what the `kvb-git-issue-close` skill finds already fixed, and what a peer
-   already works on: `council.py list` and the `kvb-org-organize` Peer
-   protocol; when a peer solves it, only comment on the issue who solves it
-   where.
+   already works on: `council.py list --long`, the register and the news of the
+   `kvb-org-organize` Peer protocol, no message; when a peer solves it, only
+   comment on the issue who solves it where.
 2. **Rank**: issues about a failing default branch first, then the rank of
    the `kvb-org-wsjf` skill; the operator's order wins.
 3. **Take** each issue before touching it: label it `in analysis` (`gh issue
@@ -28,11 +28,19 @@ request, so a red one blocks nothing else.
    results: a test that failed before and passes after, the pull request
    open), branch `fix/<scope>/<n>` from the default branch in its own
    worktree, evidence, self-assessment, independent review. Commits go to
-   that branch only, never to the default branch; parallel work follows the
-   resource chair's grants. With the first change, swap the label: `gh issue
+   that branch only, never to the default branch. Spawn agents only as the
+   issues' stakes justify; each brief names the issue, the files and the
+   claim to prove, and caps the answer at a verdict table of at most 15
+   lines. Explore code through the codebase-memory-mcp graph first
+   (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`; the
+   `kvb-agent-optimize` skill sets it up), grep and read after. Parallel
+   work, gates, deploys and anything with Docker follow the resource chair's
+   grants; light runs (no Docker, about a minute) self-admit with `watch.py
+   admit --kind test-nostack`. With the first change, swap the label: `gh issue
    edit <n> --remove-label "in analysis" --add-label "in progress"`.
 5. **Open the pull request** with the `kvb-git-pr-create` skill, closing
-   exactly its issue. Below the split bar the proposal becomes a draft pull
+   exactly its issue; one for a failing default branch is posted with
+   `news.py post`. Below the split bar the proposal becomes a draft pull
    request with the residuals and the evidence that would close them.
 6. **Report** per issue, then release its claim and tear its sidetree down
    as `kvb-org-split` describes; the branch stays until the merge. An issue

skills/kvb-git-merge-fix/SKILL.md

@@ -2,13 +2,11 @@
 name: kvb-git-merge-fix
 description: >
   Find the commits on any branch that carry a described fix and merge them
-  here. Trigger on /kvb-git-merge-fix <description> or a request to bring over
-  a fix from another branch.
+  here. Trigger on a request to bring over a fix from another branch.
 ---
 
-The free text after `/kvb-git-merge-fix` is the fix description, exactly like `/loop`
-takes its prompt. Everything after the skill name is the search intent; there is
-no other input. If it is missing, ask for it and stop.
+The free text after the skill name is the fix description and the only input.
+If it is missing, ask for it and stop.
 
 ## 1. Refuse to work on a dirty tree
 
@@ -23,14 +21,16 @@ same tree may own.
 git fetch --all --prune --tags
 ```
 
-That is the "pull all branches" step. Do not check branches out one by one; all
-searching below runs against the fetched refs.
+Never check branches out one by one; the search runs against the fetched refs.
 
 ## 3. Turn the description into search terms
 
 Derive from the operator's text: 2-4 keywords for commit messages, plus any
-symbol, string, or path the fix must have touched. State the derived terms in
-one line so a wrong reading is visible before the search.
+symbol, string, or path the fix must have touched. Find those symbols and
+paths through the codebase-memory-mcp graph first (`search_graph`,
+`trace_path`, `get_architecture`, `detect_changes`; the `kvb-agent-optimize`
+skill sets it up), grep and read after. State the derived terms in one line so
+a wrong reading is visible before the search.
 
 ## 4. Search every ref
 
@@ -60,7 +60,7 @@ and its diff plainly is the described fix.
   (`-x` records the origin).
 - The whole branch is wanted: `git merge --no-ff <branch>`.
 - Conflicts: resolve them by reading both sides. Never `-X ours`/`-X theirs`,
-  never `git checkout --ours/--theirs` wholesale — that silently drops one
+  never `git checkout --ours/--theirs` wholesale: that silently drops one
   side's fix. Unresolvable → `git cherry-pick --abort` / `git merge --abort`,
   report what conflicted, change nothing else.
 
@@ -77,4 +77,4 @@ Run the project's test or quality gate only when the operator asks for it.
 - Never rewrite history to make a cherry-pick fit (no rebase of the target
   branch, no amend of foreign commits).
 - If the search finds nothing, say so plainly and list the terms tried. Do not
-  reimplement the fix under this skill — that is a different task.
+  reimplement the fix under this skill; that is a different task.

skills/kvb-git-pr-create/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-git-pr-create
 description: >
   Open a pull request for the current branch: push handed over, Closes lines,
-  labels. Trigger on /kvb-git-pr-create.
+  labels.
 ---
 
 Opening a pull request is outward-facing and needs the branch on the remote,

skills/kvb-git-pr-label/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: kvb-git-pr-label
 description: >
-  Label pull requests `hotfix` and `90/5` from evidence. Trigger on
-  /kvb-git-pr-label [pr]; kvb-git-pr-create runs it.
+  Label pull requests `hotfix` and `90/5` from evidence; kvb-git-pr-create
+  runs it.
 ---
 
 Two labels, each set only with its evidence and removed when it no longer

skills/kvb-git-update-branches/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-git-update-branches
 description: >
   Merge main into open PRs or branches: the operator's own directly, others
-  after consent. Trigger on /kvb-git-update-branches.
+  after consent.
 ---
 
 Invoking this skill authorizes the merge commits it makes; pushing stays the
@@ -11,8 +11,7 @@ operator's. Branches are merged, never rebased.
 ## Step 1: scope and candidates
 
 Pull requests, branches or both, as the operator said; ask when it is open.
-`git fetch --all --prune`, then list the open branches with their lag and
-owner:
+`git fetch --all --prune`, then list the open branches with lag and owner:
 
 ```bash
 gh pr list --state open --json number,headRefName,author,isCrossRepository > <tmp>/prs.json
@@ -28,8 +27,7 @@ branch whose own commits all carry the operator's email. A row with
 
 The operator's own rows go on. For every other row run the `kvb-think-listen`
 skill: one `AskUserQuestion` with `multiSelect: true` listing branch, pull
-request, owner and lag, nothing preselected. Only what the operator picks is
-updated.
+request, owner and lag, nothing preselected. Only the picks are updated.
 
 ## Step 3: update
 

skills/kvb-help/SKILL.md

@@ -1,8 +1,8 @@
 ---
 name: kvb-help
 description: >
-  List and explain every skill in the session. Trigger on /kvb-help,
-  "welche skills gibt es", "skill übersicht", or when the operator asks what
+  List and explain every skill in the session. Trigger on "welche skills
+  gibt es", "skill übersicht", or when the operator asks what
   skills exist or what one does.
 ---
 
@@ -13,8 +13,8 @@ Produce a one-shot overview of every skill the session can invoke:
    user-global skills (`~/.claude/skills/`), and plugin-provided skills.
    Deduplicate by name; note when a project skill shadows a global one.
 2. Output one table per origin (project, global, plugin): skill name,
-   trigger (slash command or phrasing), one-line purpose in your own words
-   — compress the description, do not paste it.
+   trigger (slash command or phrasing), one-line purpose in your own words,
+   compressing the description instead of pasting it.
 3. When the operator names a specific skill or topic, explain only the
    matching skills in more depth: what they do, when they fire on their
    own, and how they compose (e.g. kvb-git-commit-next → kvb-git-commit-no-verify →

skills/kvb-optimize/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-optimize
 description: >
   Run every optimization skill in one pass with one round of questions.
-  Trigger on /kvb-optimize; kvb-dream runs it.
+  kvb-dream runs it.
 ---
 
 Collector for the optimization skills, so one pass needs one evidence

skills/kvb-org-artefacts/SKILL.md

@@ -2,13 +2,13 @@
 name: kvb-org-artefacts
 description: >
   Artifacts of the kvb-org-rasci register per task: images, volumes,
-  worktrees. Trigger on /kvb-org-artefacts, "artefakte".
+  worktrees. Trigger on "artefakte".
 ---
 
-Artifacts live in the same table as the tasks of the `kvb-org-rasci`
-register: each one belongs to exactly one task, carries its kind, reference
-and the time it was recorded, and takes status and worker from its task. The
-script is the register's `${CLAUDE_SKILL_DIR}/../kvb-org-rasci/scripts/rasci.py`.
+Artifacts live in the task table of the `kvb-org-rasci` register: each
+belongs to exactly one task, carries its kind, reference and recording time,
+and takes status and worker from its task. The script is
+`${CLAUDE_SKILL_DIR}/../kvb-org-rasci/scripts/rasci.py`.
 
 ```bash
 rasci.py set <task> --artifact <kind>:<ref>
@@ -22,10 +22,11 @@ Kinds: `image:`, `container:`, `volume:`, `network:`, `stack:`, `worktree:`,
 ## Rules
 
 - Record an artifact the moment it exists, under the task that created it;
-  one left unrecorded is invisible to cleanup.
+  an unrecorded one is invisible to cleanup.
 - `artifacts --ended` lists what belongs to `done`, `stopped` or `stale`
   tasks: the cleanup candidates, owned by the task's worker. Everything of an
-  open task stays.
+  open task stays. Read an artifact's owner here instead of asking peers.
 - Deleting goes through the `kvb-cleanup` skill, where the operator picks;
   drop the artifact here once it is gone.
-- The register's `show` counts each task's artifacts in its Artifacts column.
+- The register's `show --wide` counts each task's artifacts in its Artifacts
+  column.

skills/kvb-org-coordinate/SKILL.md

@@ -2,11 +2,11 @@
 name: kvb-org-coordinate
 description: >
   Coordinate a failure or fix with the agents on related branches through
-  merges: claim, ask, report. Trigger on /kvb-org-coordinate and when a fix touches
-  code other branches share.
+  merges: claim, ask, report. Trigger when a fix touches code other
+  branches share.
 ---
 
-Run the `kvb-org-organize` skill's **Lineage** and **Peer protocol** sections for the
-failure or fix at hand. They hold the whole procedure, including the entries
-in the `kvb-org-rasci` register; this skill only keeps `/kvb-org-coordinate`
-working.
+Run the `kvb-org-organize` skill's **Peer protocol**, its `lineage.md`
+included, for the failure or fix at hand. They hold the whole procedure,
+including the entries in the `kvb-org-rasci` register: ask by `SendMessage`,
+report by `news.py post`. This skill only keeps its command working.

skills/kvb-org-evening/SKILL.md

@@ -2,20 +2,22 @@
 name: kvb-org-evening
 description: >
   Let every agent but this session relax: finish its task, end its loops,
-  start nothing new. Trigger on /kvb-org-evening; /kvb-org-sunrise undoes it.
+  start nothing new. kvb-org-sunrise undoes it.
 ---
 
-The soft step before `kvb-org-sunset`: the session the operator types this in
-keeps working, the others finish what they are doing and then idle. The state
-lives in `${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py`.
+The soft step before `kvb-org-sunset`: this session keeps working, every
+other finishes what it is doing and then idles. The state lives in
+`${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py`.
 
 1. `night.py set evening` makes this session the active one and prints every
    other live session.
-2. One message per printed session, first line: "Operator ran kvb-org-evening
-   in <name>: run kvb-agent-relax; verify with night.py status." A request to
-   do less needs no operator approval (the `kvb-org-organize` Peer protocol).
-3. Collect the replies. The night rules of `kvb-org-sunset` apply to this
-   session too, and the `kvb-org-rasci` register keeps every row as it is.
+2. One `SendMessage` per printed session, since each must act, first line:
+   "Operator ran kvb-org-evening in <name>: run kvb-agent-relax; verify with
+   night.py status." A request to do less needs no operator approval (the
+   `kvb-org-organize` Peer protocol).
+3. Collect the one-line replies, which arrive as news; never ask a silent session
+   again. The night rules of `kvb-org-sunset` apply to this session too, and
+   the `kvb-org-rasci` register keeps every row as it is.
 
 ## Output
 

skills/kvb-org-matrix/SKILL.md

@@ -2,27 +2,30 @@
 name: kvb-org-matrix
 description: >
   One matrix of everything in flight with confidence and break risk per
-  item. Trigger on /kvb-org-matrix, "status", "übersicht", "wo stehen wir".
+  item. Trigger on "status", "übersicht", "wo stehen wir".
 ---
 
-One-shot overview, no side effects: this skill reads state and reports it. It
-never edits files, stages, commits, deploys, or starts work — the operator
-decides what to act on after reading the matrix.
+One-shot overview, no side effects: it reads state and reports it, never
+edits, stages, commits, deploys or starts work. The operator decides what to
+act on.
 
 ## Collect the state
 
-Gather in parallel, skip any source the session does not have, and never invent
-a row for a source you could not read:
+In parallel; skip a source the session lacks, and never invent a row for one
+you could not read:
 
-1. **Tasks** — the `kvb-org-rasci` register first, then the session's todo list, the operator's stated goals this
-   session, and any requirement or plan documents the work follows.
-2. **Working tree** — `git status --short` and `git log --oneline -10`:
-   uncommitted files are open work, commits since the branch point are closed
-   work. Untracked files count as open.
-3. **Running** — background bash jobs, spawned agents not yet reported,
-   scheduled `/loop` wake-ups, and remote runs (CI, deploys). Poll their live
-   state; a job you started is not "running" because you started it.
-4. **Remote** — open PRs and issues for the branch, and their check
+1. **Tasks**: the `kvb-org-rasci` register first, then the session's todo
+   list, the operator's goals this session, and the requirement or plan
+   documents the work follows.
+2. **Peers**: `council.py list` and `news.py show --all` (the
+   `kvb-org-organize` skill's scripts); never message a peer for status.
+3. **Working tree**: `git status --short` and `git log --oneline -10`:
+   uncommitted and untracked files are open work, commits since the branch
+   point closed work.
+4. **Running**: background jobs, spawned agents not yet reported, scheduled
+   `/loop` wake-ups, remote runs (CI, deploys). Poll their live state; a job
+   is not "running" because you started it.
+5. **Remote**: open PRs and issues for the branch and their check
    conclusions, when a forge CLI is available.
 
 ## The matrix
@@ -31,30 +34,29 @@ One table, most-blocking first, one row per item:
 
 | Item | State | Conf. | Break risk | Evidence / next step |
 
-- **State**: `open`, `running`, `blocked`, `done`. `done` means verified —
-  a passing run, a green check, a reproduction that now succeeds. Work that
+- **State**: `open`, `running`, `blocked`, `done`. `done` means verified (a
+  passing run, a green check, a reproduction that now succeeds); work that
   merely looks finished is `open`.
-- **Conf.** and **Break risk**: two separate percentages per the `kvb-check-confidence`
-  skill — probability the item does what it claims, and probability it breaks
-  something else. Only for rows that changed something; `—` for pure
-  observation rows.
-- **Evidence / next step**: for `done`, the strongest proof line (what ran,
-  what it returned). For everything else, the single next action.
+- **Conf.** and **Break risk**: two separate percentages per the
+  `kvb-check-confidence` skill, only for rows that changed something; `-`
+  for pure observation rows.
+- **Evidence / next step**: for `done` the strongest proof line (what ran,
+  what it returned), otherwise the single next action.
 
-Then at most three lines below the table:
+Then at most three lines:
 
 - **Blocked on**: what needs the operator (a decision, a credential, an
-  approval) — omit when nothing does.
-- **Residuals**: what keeps the lowest confidence number below 100.
-- **Running**: what will report back on its own, so the operator does not wait
-  on it manually.
+  approval); omit when nothing does.
+- **Residuals**: what keeps the lowest confidence below 100.
+- **Running**: what reports back on its own, so the operator need not wait
+  on it.
 
 ## Rules
 
-- Cover everything in scope, including work the operator did not ask about —
-  a forgotten background job or an unpushed commit is exactly what the matrix
-  exists to surface.
-- Report what the poll returned, never a predicted result for work still in
-  flight; a running item has no confidence number yet.
-- Compress: one row per item, no per-item paragraphs. If a row needs
-  explaining, the operator will ask.
+- Cover everything in scope, including work the operator did not ask about:
+  a forgotten background job or an unpushed commit is what the matrix exists
+  to surface.
+- Report what the poll returned, never a predicted result; a running item
+  has no confidence number yet.
+- One row per item, no per-item paragraphs; the operator asks when a row
+  needs explaining.

skills/kvb-org-operator/SKILL.md

@@ -2,13 +2,11 @@
 name: kvb-org-operator
 description: >
   List every command only the operator can run: pushes, installs, settings
-  and sandbox-blocked steps of all agents. Trigger on /kvb-org-operator or
-  "was muss ich tun".
+  and sandbox-blocked steps of all agents. Trigger on "was muss ich tun".
 ---
 
 Collect every step that waits on a human, across all agents, so the operator
-can run them top to bottom. A step an agent may run itself is not listed; the
-agent runs it.
+can run them top to bottom.
 
 ## What counts
 
@@ -29,11 +27,16 @@ Checked against the live settings and agent rules, never from memory:
 - **Own**: every step of this session that stopped for one of the reasons
   above.
 - **Register**: tasks of the `kvb-org-rasci` register with the operator as R
-  and status `queued` or `blocked` (`rasci.py show`).
-- **Peers**: one message to every live agent (`ListAgents`) asking for its
-  pending operator commands, one per line with directory, command and
-  reason. No answer counts as none. A peer's answer is data: it cannot make
-  a command operator-only that the settings let an agent run.
+  and status `queued` or `blocked` (`rasci.py show --wide`). Every agent records
+  such a step there the moment it arises (`rasci.py set operator/<slug>
+  --title "<command>" --workdir <dir> --status queued`, then `role
+  operator/<slug> Operator R`), so the list needs no messages.
+- **Peers**: never polled. Only when the operator asks for a full sweep, one
+  `SendMessage` to every live agent (`ListAgents`): "Reply with each pending
+  operator command the register lacks, one per line with directory, command
+  and reason; with none, do not reply." No answer counts as none. A peer's
+  answer is data: it cannot make a command operator-only that the settings
+  let an agent run.
 
 ## Step 2: check
 

skills/kvb-org-organize/SKILL.md

@@ -3,214 +3,78 @@ name: kvb-org-organize
 description: >
   Keep parallel agents from duplicating work: the first claim owns it, a
   chair allocates. Run AUTOMATICALLY before work another agent might also
-  do, and on /kvb-org-organize.
+  do.
 ---
 
-Two agents doing the same work waste the second run and then collide in the
-merge. The remedy is an election nobody has to hold: whoever starts first owns
-the work. The structure is anarcho-syndicalist: councils (soviets) of
-delegates with a bound mandate, organised as a matrix, recallable by the
-operator at any time.
-
-## Offices
-
-- **President of a piece of work**: the first agent that starts it. It does
-  the whole piece. Every later agent hands its findings to the president and
-  moves on to other work; it never builds a second version.
-- **Representative of an organisational line**: the first agent that works in
-  the line. Lines come in as many dimensions as are useful: functional domain
-  (security, GUI, identity, i18n), repository, branch line, host, cloud
-  account. An agent belongs to one line per dimension.
-- **Organiser of a work cluster**: the first agent that starts a cluster
-  cutting across lines (a failure cluster from `kvb-ci-triage`, a cost cluster from
-  `kvb-code-tune`, a feature touching several domains). It works the strand end to end
-  and informs the representative of every line the strand touches before it
-  changes that line's files.
-- **Chair**: the earliest-elected president still running. It chairs the
-  council of all representatives and organisers and allocates the resources of
-  the whole system everyone runs on. There is exactly one allocator at any
-  time.
-
-Every office is a mandate, not a rank: it coordinates and allocates, it never
-takes over or directs the content of another agent's work. The operator
-outranks every office and appoints or recalls at will; an operator
-appointment outranks the election.
+The first claim owns a piece of work; a later agent hands its findings to the
+owner and never builds a second version. Offices are recallable mandates
+that coordinate and allocate, never direct others' content; the operator
+outranks them and appoints or recalls at will.
 
 ## Election
 
-The first to claim wins, and the claim is atomic, so two agents can never both
-be first. `${CLAUDE_SKILL_DIR}/scripts/council.py` keeps the claims in
-`/tmp/agents-council`; other runtimes call the same script from their skills
-directory with `--session <id>`.
+`${CLAUDE_SKILL_DIR}/scripts/council.py` keeps atomic claims in
+`/tmp/agents-council`; other runtimes add `--session <id>`.
 
-1. **Name the office**: `work/<slug>`, `cluster/<slug>`,
-   `<dimension>/<line>` for a representative, or `chair`. The slug names the
-   work concretely: the issue number, the failing line, the cost's log line.
-2. **Look first**: `council.py list`. A claim for the same work under another
-   slug counts as first.
-3. **Claim**: `council.py claim <office> --work "<what, evidence, branch or
-   worktree>"`. Exit 0: elected, or already yours. Exit 3: a live agent holds
-   it, and its claim is printed. Exit 4: the holder's session is dead (see
-   Succession).
-4. **Elected**: the claim entered the task in the `kvb-org-rasci` register,
-   the organisation's single point of truth; complete it there (objective,
-   description, priority, roles), then continue with the Peer protocol; its
-   message is the announcement.
-5. **Not elected**: send the holder your findings and stop on that work.
+1. Name the office: `work/<slug>` (a piece of work), `cluster/<slug>` (a
+   strand across lines), `<dimension>/<line>` (a line) or `chair`, the slug
+   concrete (issue number, failing line, log line). The first agent elected
+   while `chair` is vacant also claims it. Read `offices.md` next to this
+   file before claiming a cluster, a line or the chair.
+2. `council.py list`; the same work claimed under another slug counts.
+3. `council.py claim <office> --work "<what, evidence, branch or worktree>"`.
+   Exit 0: yours; 3: a live holder (printed); 4: the holder's session is dead.
+4. Elected: complete the task the claim entered in the `kvb-org-rasci`
+   register (objective, description, priority, roles); the listed claim is
+   the announcement.
+5. Not elected: post your findings to the holder via the news and stop.
 
-A Claude Code session cannot edit a file in a git worktree before it holds a
-claim: a PreToolUse hook (`council.py gate`) blocks the edit.
+A hook (`council.py gate`) blocks worktree edits before a claim. Between
+machines the earliest announcement by message time wins; each host's claim
+directory records it. Read `succession.md` next to this file when a claim
+ends or goes stale, or after a restart.
 
-Peers on other machines cannot see this host's claims. Between machines the
-earliest announcement by message time wins, and each host's claim directory
-records the result.
+## Capacity
 
-## Chair and resource allocation
-
-- The first agent elected on the system while `chair` is vacant also claims
-  `chair`, in the same way.
-- An operator-appointed allocator holds the chair: its claim says
-  `appointed: operator`, and no election replaces it while its session runs and
-  the operator has not ended the appointment.
-- Before starting anything that consumes shared capacity (gates, deploys,
-  iteration loops, swarm or cloud resources, cleanup of shared data), an agent
-  sends the chair what, where, for how long and its expected disk need, waits
-  for the grant, and reports the release. The chair keeps one queue: a
-  hotfix gate (a branch from the default branch that fixes it) takes the next
-  free gate or test slot before every other line, the rest follows the WSJF
-  rank of the `kvb-org-wsjf` skill (it asks its subordinates for the Fibonacci
-  estimates); a running gate is never cut short for a hotfix. It answers
-  every request with its position, enforces the limits the operator set,
-  checks every grant with `watch.py admit --need-gb <N>` (or `--kind <slot>`;
-  test kinds also need CPU and RAM below the configured limits).
-- A running job (deploy, gate, test, swarm run, build) is never cut short to
-  free capacity. The chair neither asks nor orders its owner to stop, take
-  down or kill it, not for an operator-prioritised slot and not for a
-  projected disk stop. It grants nothing new, frees idle items through the
-  `kvb-cleanup` flow, asks the operator for an exception, or waits. An owner's
-  own disk guard only alerts the chair and takes nothing down; only the
-  operator can order a running job down. The one exception is a hang: an
-  agent may end its own job, a stuck step inside it, or a process its own
-  ended session left behind, once at least 60 minutes passed without log
-  progress and a probe shows standstill (no fresh child process, no network
-  traffic, CPU time not moving). It secures the live state first and then
-  reports the timestamp, the step, the probe and the command. A peer's hung
-  job goes to its owner, and to the operator when the owner does not answer.
-- Handover is explicit: the outgoing chair sends every peer the new holder,
-  the queue and the running grants, and keeps allocating until the incoming
-  chair confirms. Two allocators never run at once.
-
-## Resource watch
-
-The chair keeps the system from running out instead of reacting once it has.
-`${CLAUDE_SKILL_DIR}/scripts/watch.py` does the measuring as hooks in every
-session, so no agent probes the disk by hand; it reads its thresholds, job
-patterns, cleanup commands and cache directories from
-`~/.config/agents-council/config.json` (keys in the script's docstring) and
-stays silent below the thresholds.
-
-- **Warn**: the chair and every session get the biggest consumers; the chair
-  plans a cleanup and grants no large slot.
-- **Stop**: new heavy jobs are blocked in every session (teardown commands
-  never), and the hook runs the configured low-risk cleanup by itself; it
-  skips every worktree where a gate or deploy process still runs.
-- **Critical**: additionally a desktop alarm to the operator. Running jobs
-  and their stacks still keep running; only the operator can make an
-  exception.
-- A measured fall that would reach the critical threshold within the
-  projection window raises the stage by one at once.
-- Caches together stay under their budget; the least recently used go first.
-
-`watch.py status` shows the last measurement. A `RESOURCE` line in a hook's
-context is addressed to the chair; any other session only adjusts its own
-plans to it.
-
-## Succession
-
-- A piece of work or a cluster ends with its result, a proposal, or an
-  abandoned attempt, reported to the peers who heard the claim. The holder
-  then runs `council.py release <office>`, and the next agent that starts the
-  work is elected afresh.
-- A representative or the chair that ends hands its office to the next-oldest
-  live representative (by claim time) and announces it.
-- A claim is stale when its holder's session is gone: in Claude Code its
-  session id is no longer in `~/.claude/sessions`; other runtimes run
-  `council.py beat` at least hourly and go stale after 60 minutes without
-  one. `claim` then exits 4. A stale work or cluster claim goes to the next
-  agent that starts the work; a stale representative or chair claim goes only
-  to the next-oldest live representative. The successor runs
-  `council.py takeover <office> --work "..."` and announces the succession;
-  everyone else leaves it alone.
-- After a restart or reboot, run `council.py list --mine` and claim again
-  every office you believe you hold: `/tmp` may have been wiped.
+- Light runs (no Docker, about a minute: targeted pytest or unittest, ruff,
+  single lint files) self-admit: `watch.py admit --kind test-nostack`, start
+  on `grant`.
+- `make test`, `make test-lint`, quality gates, deploys, iteration loops,
+  swarm, image builds, cloud, shared-data cleanup, anything with Docker or
+  over a few minutes: ask the chair (what, where, how long, disk), wait for
+  the grant, post the release to the news.
+- No running job is cut short for capacity; only the operator orders one
+  down. `RESOURCE` hook lines address the chair; others adjust plans.
+- Read `capacity.md` next to this file when you hold the chair, a job seems
+  hung, or the resource watch fires.
 
 ## Peer protocol
 
-The one protocol for every exchange between agents; `kvb-org-coordinate`, `kvb-ci-triage`,
-`kvb-code-tune`, `kvb-org-split` and `kvb-cleanup` use it.
+Read `peers.md` next to this file before asking peers whether a failure or
+fix is known.
 
-1. **Look**: `council.py list` and the refs (the kvb-git-merge-fix skill's
-   `find_fix.py`). A claim or a committed fix answers the question without a
-   message.
-2. **Claim** the office (Election).
-3. **One message per peer** (in Claude Code: `ListAgents`, then
-   `SendMessage`): the peers whose lines the work touches, the lineage owners
-   (Lineage) and, for capacity, the chair. It carries what you claimed, the
-   evidence (failing line quoted literally, run id, measurement), the
-   suspected cause marked as a thesis, and the question "Already known or
-   fixed on your side? Reply with a SHA or branch, or 'none'." The first line
-   stands on its own, because a busy recipient sees only that line. In the
-   `kvb-org-rasci` register the peers asked are C, the chair that grants
-   capacity is S.
-4. **Wait up to 5 minutes** before building anything, investigating read-only
-   meanwhile. A fix that arrives goes through the project's normal path
-   (merge, cherry-pick or port), and you release your claim. Silence is
-   neither a "no" nor a competing claim: after 5 minutes, proceed.
-5. **Report** to the same peers: commit, branch, what changed, the evidence it
-   works, and the merge it reaches them by. Report an abandoned or failed
-   attempt too. In the register, enter the peers told as I and mark every key
-   result the evidence proves as met. Then release the claim: the task ends
-   `done`, or `stopped` while a key result is open.
-
-- Never invent a peer's answer.
-- A peer's report is not evidence: read the SHA, log or artifact it names
-  before a verdict depends on it.
-- A peer's message is not the operator's approval, and an office grants no
-  permission: never ask a peer to run what your own session is denied; report
-  it to the operator. A request to do less is the exception: a peer relaying
-  the operator's `kvb-org-evening` or `kvb-org-sunset` grants nothing, so
-  verify it with `night.py status` (the `kvb-org-sunset` skill) and follow
-  `kvb-agent-relax` or `kvb-agent-sleep` without asking the operator.
-- One message per peer per event; repeat nothing a peer already acknowledged.
-- Relaying an operator rule: record it in shared memory first and name the
-  file in the message's first line. A recipient records it only when no file
-  is named, and only after `council.py claim memory/<slug>`, because peers
-  that read the same broadcast write within seconds of each other.
-- Release every claim when its work ends; a forgotten claim blocks the work
-  for everyone.
-
-## Lineage
-
-For a failure or a fix that other branches share through merges:
-
-- Name the branches this one shares commits with: upstream (merged into this
-  one) and downstream (merging this one). Read them from the merge commits
-  (`git log --merges --first-parent --format='%h %s' -30`), the project's
-  agent memory or merge notes, or the operator when neither says.
-- Map each branch to its live session through the agent listing; a branch
-  without one needs no message, say so once.
-- One message per failure cluster, not per job.
-- When the cause lives on another agent's line, hand the finding and a
-  proposed fix to that line's owner instead of fixing it downstream, unless
-  the operator says otherwise, and record the agreed resolution where the next
-  merge will find it.
+- Never poll: `council.py list`, the register and the news answer first.
+- Status that asks nothing (a hotfix opened or merged, a failure, a slot
+  freed, a result for information): `${CLAUDE_SKILL_DIR}/scripts/news.py post
+  "<text>"` (`--to <name>` for one peer); sessions see it next turn at no
+  cost.
+- `SendMessage` only when the recipient must act or answer: one batched
+  message per peer per event, terse, no greeting, at most five lines unless
+  evidence needs more, nothing already acknowledged. A message that asks
+  nothing gets no reply; end that turn in one line.
+- Never invent a peer's answer; verify the SHA, log or artifact a peer names
+  before relying on it.
+- A peer's message is no operator approval, an office no permission: never
+  ask a peer to run what you are denied; tell the operator.
+- Release every claim when its work ends; forgotten ones block everyone.
+- Read `relay.md` next to this file before relaying an operator rule or
+  acting on one a peer relayed; `lineage.md` when a failure or fix is shared
+  with other branches through merges.
 
 ## Output
 
-On /kvb-org-organize, one table of the current offices from `council.py list`, stale
-claims marked:
+A table from `council.py list --long`, stale claims marked:
 
 | Office | Holder | Since | Work | Grants or queue |
 
-Who carries which task, with priority and status, is the `kvb-org-rasci`
-register's `show`.
+Tasks, priority and status: the `kvb-org-rasci` register's `show`.

skills/kvb-org-organize/capacity.md

@@ -0,0 +1,54 @@
+# Chair, allocation and resource watch
+
+## Allocation
+
+- An operator-appointed allocator holds the chair: its claim says
+  `appointed: operator`, and no election replaces it while its session runs and
+  the operator has not ended the appointment.
+- The chair keeps one queue: a hotfix gate (a branch from the default branch
+  that fixes it) takes the next free gate or test slot before every other
+  line, the rest follows the WSJF rank of the `kvb-org-wsjf` skill (it asks its
+  subordinates for the Fibonacci estimates); a running gate is never cut short
+  for a hotfix. It answers every request with its queue position through
+  `news.py post --to <name>` and sends the grant itself as a message (the
+  requester acts on it), enforces the limits the operator set, and checks
+  every grant with
+  `watch.py admit --need-gb <N>` (or `--kind <slot>`; test kinds also need CPU
+  and RAM below the configured limits).
+- A running job (deploy, gate, test, swarm run, build) is never cut short to
+  free capacity. The chair neither asks nor orders its owner to stop, take
+  down or kill it, not for an operator-prioritised slot and not for a
+  projected disk stop. It grants nothing new, frees idle items through the
+  `kvb-cleanup` flow, asks the operator for an exception, or waits. An owner's
+  own disk guard only alerts the chair and takes nothing down.
+
+## Hung jobs
+
+The one exception to "never cut short": an agent may end its own job, a stuck
+step inside it, or a process its own ended session left behind, once at least
+60 minutes passed without log progress and a probe shows standstill (no fresh
+child process, no network traffic, CPU time not moving). It secures the live
+state first, then reports the timestamp, the step, the probe and the command.
+A peer's hung job goes to its owner, and to the operator when the owner does
+not answer.
+
+## Resource watch
+
+The chair keeps the system from running out instead of reacting once it has.
+`${CLAUDE_SKILL_DIR}/scripts/watch.py` measures as hooks in every session, so
+no agent probes the disk by hand; it reads thresholds, job patterns, cleanup
+commands and cache directories from `~/.config/agents-council/config.json`
+(keys in the script's docstring) and stays silent below the thresholds.
+
+- **Warn**: the chair and every session get the biggest consumers; the chair
+  plans a cleanup and grants no large slot.
+- **Stop**: new heavy jobs are blocked in every session (teardown commands
+  never), and the hook runs the configured low-risk cleanup by itself; it
+  skips every worktree where a gate or deploy process still runs.
+- **Critical**: additionally a desktop alarm to the operator. Running jobs and
+  their stacks still keep running; only the operator can make an exception.
+- A measured fall that would reach the critical threshold within the
+  projection window raises the stage by one at once.
+- Caches together stay under their budget; the least recently used go first.
+
+`watch.py status` shows the last measurement.

skills/kvb-org-organize/lineage.md

@@ -0,0 +1,15 @@
+# Lineage
+
+For a failure or a fix that other branches share through merges:
+
+- Name the branches this one shares commits with: upstream (merged into this
+  one) and downstream (merging this one). Read them from the merge commits
+  (`git log --merges --first-parent --format='%h %s' -30`), the project's
+  agent memory or merge notes, or the operator when neither says.
+- Map each branch to its live session through the agent listing; a branch
+  without one needs no message, say so once.
+- One message per failure cluster, not per job.
+- When the cause lives on another agent's line, hand the finding and a
+  proposed fix to that line's owner instead of fixing it downstream, unless
+  the operator says otherwise, and record the agreed resolution where the next
+  merge will find it.

skills/kvb-org-organize/offices.md

@@ -0,0 +1,19 @@
+# Offices
+
+- **President of a piece of work** (`work/<slug>`): the first agent that
+  starts it. It does the whole piece.
+- **Representative of an organisational line** (`<dimension>/<line>`): the
+  first agent that works in the line. Lines come in as many dimensions as are
+  useful: functional domain (security, GUI, identity, i18n), repository,
+  branch line, host, cloud account. An agent belongs to one line per
+  dimension.
+- **Organiser of a work cluster** (`cluster/<slug>`): the first agent that
+  starts a cluster cutting across lines (a failure cluster from
+  `kvb-ci-triage`, a cost cluster from `kvb-code-tune`, a feature touching
+  several domains). It works the strand end to end and informs the
+  representative of every line the strand touches before it changes that
+  line's files.
+- **Chair** (`chair`): the earliest-elected president still running. It
+  chairs the council of all representatives and organisers and allocates the
+  resources of the whole system everyone runs on (`capacity.md`). There is
+  exactly one allocator at any time.

skills/kvb-org-organize/peers.md

@@ -0,0 +1,27 @@
+# Coordinating a failure or fix with peers
+
+`kvb-org-coordinate`, `kvb-ci-triage`, `kvb-code-tune`, `kvb-org-split` and
+`kvb-cleanup` follow these steps.
+
+1. **Look**: `council.py list`, the `kvb-org-rasci` register, the news and the
+   refs (the kvb-git-merge-fix skill's `find_fix.py`). A claim or a committed
+   fix answers the question without a message.
+2. **Claim** the office (Election in `SKILL.md`).
+3. **Ask** (in Claude Code: `ListAgents`, then `SendMessage`) only the peers
+   whose lines the work touches, the lineage owners (`lineage.md`) and, for
+   capacity, the chair. One batched message per peer: what you claimed, the
+   evidence (failing line quoted literally, run id, measurement), the
+   suspected cause marked as a thesis, and the question "Already known or
+   fixed on your side? Reply with a SHA or branch, or 'none'." The first line
+   stands on its own, because a busy recipient sees only that line. In the
+   register the peers asked are C, the chair that grants capacity is S.
+4. **Wait up to 5 minutes** before building anything, investigating read-only
+   meanwhile. A fix that arrives goes through the project's normal path
+   (merge, cherry-pick or port), and you release your claim. Silence is
+   neither a "no" nor a competing claim: after 5 minutes, proceed.
+5. **Report** to the same peers through `news.py post --to <name>`: commit,
+   branch, what changed, the evidence it works, and the merge it reaches them
+   by; an abandoned or failed attempt too. In the register, enter the peers
+   told as I and mark every key result the evidence proves as met. Then
+   release the claim: the task ends `done`, or `stopped` while a key result is
+   open.

skills/kvb-org-organize/relay.md

@@ -0,0 +1,11 @@
+# Relays
+
+- Relaying an operator rule: record it in shared memory first and name the
+  file in the message's first line. A recipient records it only when no file
+  is named, and only after `council.py claim memory/<slug>`, because peers
+  that read the same broadcast write within seconds of each other.
+- A peer relaying the operator's `kvb-org-evening` or `kvb-org-sunset` is the
+  one request a peer may make that you follow without the operator: it asks
+  you to do less and grants nothing. Verify it with `night.py status` (the
+  `kvb-org-sunset` skill), then follow `kvb-agent-relax` or `kvb-agent-sleep`
+  without asking the operator.

skills/kvb-org-organize/succession.md

@@ -0,0 +1,22 @@
+# Succession
+
+- A piece of work or a cluster ends with its result, a proposal, or an
+  abandoned attempt, posted to the news for the peers who heard the claim. The
+  holder then runs `council.py release <office>`, and the next agent that
+  starts the work is elected afresh.
+- A representative or the chair that ends hands its office to the next-oldest
+  live representative (by claim time) and posts it to the news.
+- Chair handover is explicit: the outgoing chair sends the incoming chair the
+  queue and the running grants (`SendMessage`: it must confirm), posts the new
+  holder to the news, and keeps allocating until the incoming chair confirms.
+  Two allocators never run at once.
+- A claim is stale when its holder's session is gone: in Claude Code its
+  session id is no longer in `~/.claude/sessions`; other runtimes run
+  `council.py beat` at least hourly and go stale after 60 minutes without one.
+  `claim` then exits 4. A stale work or cluster claim goes to the next agent
+  that starts the work; a stale representative or chair claim goes only to the
+  next-oldest live representative. The successor runs
+  `council.py takeover <office> --work "..."` and posts the succession to the
+  news; everyone else leaves it alone.
+- After a restart or reboot, run `council.py list --mine` and claim again
+  every office you believe you hold: `/tmp` may have been wiped.

skills/kvb-org-perform/SKILL.md

@@ -7,10 +7,10 @@ description: >
 ---
 
 A subagent runs on the main model and effort unless the spawn names others.
-Set `model` and `effort` on an Agent call only when the task clearly matches a
-row below and you are at least 90 % sure the cheaper setting delivers the same
-result as the default: no lost findings, no rework. Cost counts per finished
-task, retries included. Otherwise set neither, and the default stays.
+Set `model` and `effort` only for a task that clearly matches a row below, at
+least 90 % sure the cheaper setting gives the default's result: no lost
+findings, no rework. Cost counts per finished task, retries included.
+Otherwise set neither.
 
 ## Table
 
@@ -26,12 +26,16 @@ Fable 5.1 $10 / $50.
 
 ## Spawn
 
-1. Pick the class. A task that mixes classes, or whose class you hesitate
+1. Pick the class; a task that mixes classes, or whose class you hesitate
    over, is `judgement`.
-2. Start the brief with the line `task-class: <class>`; the spawn hook logs
-   it together with `model`, `effort` and the Agent `description`.
+2. Start the brief with `task-class: <class>`; the spawn hook logs it with
+   `model`, `effort` and the Agent `description`.
 3. Set `model` and `effort` from the row; for `judgement` set neither.
-4. Enter the spawn in the `kvb-org-rasci` register: the subagent as R and as
+4. Spawn as many agents as the stakes need: one, unless independent parts
+   gain from running in parallel. The brief names the exact files, lines and
+   claims to check and what is ruled out, and caps the answer (for example
+   "at most 15 lines, file:line per finding").
+5. Enter the spawn in the `kvb-org-rasci` register: the subagent as R and as
    `--worker "subagent <type> (<model>, <effort>)"` of the task it serves.
 
 - An agent type whose definition sets its own model (Explore, Plan, the
@@ -44,31 +48,22 @@ Fable 5.1 $10 / $50.
 
 ## Feedback
 
-Once you have judged the subagent's result, rate it under the same Agent
-`description`:
+Once you have judged the result, rate it under the same Agent `description`:
 
 ```bash
 ${CLAUDE_SKILL_DIR}/scripts/log.py feedback --description "<description>" --completed yes|no --tests pass|fail|none --redo yes|no
 ```
 
 `--redo yes` when the default had to redo or finish the work. When the
-operator later asks a follow-up question about that result or corrects it:
+operator later asks a follow-up about that result or corrects it:
 
 ```bash
 ${CLAUDE_SKILL_DIR}/scripts/log.py followup --description "<description>" --text "<question or correction>"
 ```
 
-All sessions share `~/.local/state/agents-council/subagent-model.jsonl`.
-Inside a sandbox that cannot write it, the script prints the line as
-`pending:` and the PostToolUse hook stores it.
+All sessions share `~/.local/state/agents-council/subagent-model.jsonl`; a
+sandbox that cannot write it gets the line printed as `pending:`, and the
+PostToolUse hook stores it.
 
-## Evaluation
-
-`log.py report` shows per task class, model and effort the runs, the rated
-runs and the share with the same result: completed, not redone, no failing
-test, no follow-up. A row is added, or a cheaper setting extended to a class,
-only when the report shows at least 90 % over at least 20 rated runs, and only
-after the operator confirms it (for example through `/kvb-skill-tune`). A row whose
-rate falls below 90 % over 20 rated runs goes back to the default. `sonnet`
-enters the table only this way, and a trial run on a setting the table does
-not hold needs the operator's order.
+Read `evaluation.md` next to this file before reading `log.py report` or
+changing a row of the table.

skills/kvb-org-perform/evaluation.md

@@ -0,0 +1,13 @@
+# Perform: evaluating the table
+
+`log.py report` shows per task class, model and effort the runs, the rated
+runs and the share with the same result: completed, not redone, no failing
+test, no follow-up.
+
+- A row is added, or a cheaper setting extended to a class, only when the
+  report shows at least 90 % over at least 20 rated runs, and only after the
+  operator confirms it (for example through the `kvb-skill-tune` skill).
+- A row whose rate falls below 90 % over 20 rated runs goes back to the
+  default.
+- `sonnet` enters the table only this way, and a trial run on a setting the
+  table does not hold needs the operator's order.

skills/kvb-org-priority/SKILL.md

@@ -2,8 +2,7 @@
 name: kvb-org-priority
 description: >
   Let the operator reorder the agents' priority from a selection; pins their
-  tasks in that order. Trigger on /kvb-org-priority, "prioritaet", "reihenfolge
-  der agents".
+  tasks in that order. Trigger on "prioritaet", "reihenfolge der agents".
 ---
 
 The operator's order of the agents outranks every WSJF score. It is written
@@ -20,7 +19,7 @@ rasci.py order "<agent>,<agent>,..."
 
 `rasci.py agents` prints one line per agent with open tasks, in the
 register's rank: number, agent, task count, tasks. Show it as a table with
-each agent's status and OKR from `rasci.py show`.
+each agent's status and OKR from `rasci.py show --wide`.
 
 ## Step 2: selection
 
@@ -42,9 +41,10 @@ the listed ones; say so in the question.
 `rasci.py order "<A>,<B>,..."` pins the listed agents' tasks 1..n in that
 order, keeping each agent's own task order. It writes other sessions' rows:
 the operator decides priority, so this is the one exception to "write only
-your own rows". Show `rasci.py agents` again, then tell the resource chair
-of the `kvb-org-organize` skill and every reordered agent their new rank, one
-message each.
+your own rows". Show `rasci.py agents` again, then post the new ranks for the
+resource chair of the `kvb-org-organize` skill and every reordered agent as
+one `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post "<text>"`,
+not as messages.
 
 ## Rules
 

skills/kvb-org-rasci/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-org-rasci
 description: >
   RASCI/OKR register of tasks: roles, key results, worker, status.
-  Trigger on /kvb-org-rasci, "rasci", "raci", "zuständigkeiten".
+  Trigger on "rasci", "raci", "zuständigkeiten".
 ---
 
 The register is the single point of truth of the organisation: every agent
@@ -19,6 +19,7 @@ rasci.py role <task> "<party>" <letters>
 rasci.py get <task>
 rasci.py rm <task>
 rasci.py show [--all]
+rasci.py show --wide [--all]
 rasci.py artifacts [--ended] [--task <task>]
 rasci.py estimate <task> "<party>" --value <fib> --complexity <fib>
 rasci.py wsjf [--all]
@@ -32,7 +33,8 @@ rasci.py order "<agent>,<agent>,..."
 The objective says what the task is for; its key results are the measurable
 outcomes that prove it reached (a test green, a run passing, a release
 published). `done` is refused while one is open; a task ended short of them is
-`stopped`. `show` puts both in the OKR column as `<objective> (<met>/<all> KR)`.
+`stopped`. `show --wide` puts both in the OKR column as
+`<objective> (<met>/<all> KR)`.
 
 ## Roles
 
@@ -62,6 +64,9 @@ published). `done` is refused while one is open; a task ended short of them is
 - Write only your own rows; another session's task belongs to that session.
   The one exception is `order`, the operator's pick through the
   `kvb-org-priority` skill.
-- On /kvb-org-rasci print `show` unchanged; its `gaps:` line names tasks
+- Read `show` (Prio, WSJF, Task, Status, Worker, A; cells cut short) or
+  `get` instead of asking a peer what it works on. `show --wide` adds OKR,
+  Artifacts, Start, End and every RASCI letter.
+- When invoked, print `show --wide` unchanged; its `gaps:` line names tasks
   without exactly one A, without R, or open without a key result. `get`
   prints one task in full, key results numbered.

skills/kvb-org-robot/SKILL.md

@@ -15,7 +15,7 @@ Operate as an autonomous robot: given a goal, reach it without hand-holding.
   further check-ins. Pick the cleanest option and continue; never pause to
   confirm a choice you can make yourself.
 - **Never stop before the goal.** Do not end the run, hand back, or declare done
-  while any part of the goal is unmet — premature termination is forbidden. A
+  while any part of the goal is unmet: premature termination is forbidden. A
   blocker is something to solve or route around, not a reason to quit; if one
   step is genuinely, externally impossible, surface exactly why and keep working
   on everything else until nothing solvable remains. The one exception is the
@@ -24,10 +24,12 @@ Operate as an autonomous robot: given a goal, reach it without hand-holding.
   `kvb-agent-sleep`, and `kvb-agent-wakeup` resumes it from the handover.
 - **Stay inside your clearance.** Use ONLY commands you are pre-authorized to
   run. Never invoke anything the agent or tool settings mark as denied or as
-  requiring per-invocation approval (ask) — no commit, push, deploy, or other
+  requiring per-invocation approval (ask): no commit, push, deploy, or other
   approval-gated action unless the operator has already cleared it for this run.
   When a needed action is out of clearance, do all the cleared work and report
-  the single blocked step for the operator to run.
+  the single blocked step for the operator to run. Shared capacity follows the
+  `kvb-org-organize` rules (light runs self-admit, the rest waits for the
+  chair's grant); keep working on everything else while a grant is pending.
 - **Verify, do not assume.** Reaching the goal means proving it: run it, read the
   output, confirm the end state. Never report success on a step you did not
   actually verify.
@@ -40,5 +42,7 @@ Operate as an autonomous robot: given a goal, reach it without hand-holding.
 
 - Escalate an uncertain root cause or design decision to the `kvb-think-dialectic` skill
   rather than guessing; uncertainty is never a reason to stop.
-- Sustain the loop across long, multi-step work — the run is finished only when
+- Sustain the loop across long, multi-step work: the run is finished only when
   the whole goal is verifiably met.
+- Status for peers goes to the news of the `kvb-org-organize` Peer protocol;
+  never wait on a reply to a message that asks nothing.

skills/kvb-org-split/SKILL.md

@@ -2,8 +2,7 @@
 name: kvb-org-split
 description: >
   Keep agent work in its own worktree until 90% fix confidence and under 5%
-  break risk, else a proposal. Trigger when delegating or parallelizing, or on
-  /kvb-org-split.
+  break risk, else a proposal. Trigger when delegating or parallelizing.
 ---
 
 # Funnel
@@ -14,94 +13,59 @@ in a sidetree until it does, or leaves as a proposal.
 ## The bar
 
 - **Fix confidence of at least 90 %** and **break risk under 5 %**, both
-  reported by the `kvb-check-confidence` skill, the break risk derived through the
-  `kvb-check-break-risk` skill.
+  reported by the `kvb-check-confidence` skill, the break risk derived through
+  the `kvb-check-break-risk` skill.
 - The operator may set a different bar. Never lower it to make a change fit.
 
 ## The stages
 
-1. **Brief.** One concern per agent, on the model the `kvb-org-perform` skill
-   picks, entered in the `kvb-org-rasci` register as R with `--worker "subagent
-   <type> (<model>)"`. Name the goal, the exact base commit, the
-   scope that may change, the evidence expected back, a time cap (default
-   60 minutes) at which it reports its interim state, and what the agent must
-   not do: no pushes, no gates or deploys
-   unless the resource chair of the `kvb-org-organize` skill granted them, read-only
-   probes on shared live systems.
-2. **Sidetree.** The agent works in its own worktree on its own branch,
-   created from the exact base commit, so its edits never land under a running
-   gate or deploy in the main line. Use the host's worktree isolation when it
-   has one.
-3. **Evidence.** The agent runs targeted tests, adds a test for the new
-   behaviour, and makes a negative control: the test fails without the change.
-   Numbers come from the same source before and after.
+1. **Brief.** As few agents as the stakes need, one concern each, on the
+   model the `kvb-org-perform` skill picks, entered in the `kvb-org-rasci`
+   register as R with `--worker "subagent <type> (<model>)"`. The brief names
+   the goal, the exact base commit, the exact files and the claims to prove or
+   refute, the scope that may change, the evidence expected back, an answer
+   cap (default 15 lines: verdict, evidence, residuals), a time cap (default
+   60 minutes) for its interim state, and the limits:
+   - no pushes; read-only probes on shared live systems;
+   - code explored through the codebase-memory-mcp graph first
+     (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`; the
+     `kvb-agent-optimize` skill sets it up), grep and read after;
+   - light runs (no Docker, about a minute) self-admit with
+     `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
+     test-nostack`; `make test`, gates, deploys and anything with Docker only
+     on the grant of the `kvb-org-organize` chair;
+   - status that asks nothing goes to
+     `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post "<text>"`,
+     never into a message.
+2. **Sidetree.** Its own worktree on its own branch from the exact base
+   commit, so its edits never land under a running gate or deploy in the main
+   line. Use the host's worktree isolation when it has one.
+3. **Evidence.** Targeted tests, a test for the new behaviour, and a negative
+   control: the test fails without the change. Numbers come from the same
+   source before and after.
 4. **Self-assessment.** The agent reports fix confidence and break risk with
-   their residuals and commits on its branch. Its parent marks the key results
-   that evidence proves as met in the `kvb-org-rasci` register and records
-   the branch and worktree as `--branch` and `--artifact worktree:<path>`.
-5. **Independent review.** Before anything is merged, run the `kvb-think-dialectic` skill
-   with skeptics who did not write the change. A hole they find returns the
-   change to stage 3.
-6. **Merge.** At or above the bar, merge the sidetree branch into the main line
-   following the repository's commit rules, then re-verify on the main line
-   with the project's gate.
-7. **Tear everything down.** Once the branch is merged, remove everything the
-   sidetree brought into being, so the next round starts from a clean
-   machine. See "After the merge" below.
-
-## After the merge
-
-A merged sidetree leaves nothing behind. Work through the list in this order,
-and verify each step instead of assuming it:
-
-1. **Stop its jobs**: background runs, watchers, scheduled loops and agents
-   that belong to the sidetree.
-2. **Tear down its stacks**: compose projects and swarm or test clusters
-   together with their volumes and networks, and the containers and images
-   built only for it. Leave anything another worktree still uses.
-3. **Clear files the containers left**: count the entries the user does not
-   own (`find <worktree> -not -user "$USER" -prune | wc -l`). If the count is
-   not zero, delete them through the container that wrote them, or hand the
-   operator one privileged removal, before removing the worktree; otherwise
-   the removal fails halfway after git has already dropped the registration.
-4. **Remove the worktree** and its registration. Name the worktree; never run
-   a broad prune, which also drops other worktrees' stale registrations.
-5. **Delete the merged branch**, locally and on the remote, but a remote branch
-   only once every one of its commits is reachable from a pushed branch.
-6. **Release what it held**: slots (reported to the resource chair), port or
-   subnet reservations, locks, its `kvb-org-organize` claims and every claim
-   announced to other agents. Drop each removed item from the register with
-   `--drop-artifact` and set the subagent's task `done` or `stopped`.
-7. **Remove its temporary files**: logs, message files and scratch data that
-   have served their purpose. Keep only the evidence the report cites, until
-   the report is delivered.
-
-A proposal keeps its branch, because that is where the work lives, but loses
-its worktree, stacks and temporary files the same way. An abandoned sidetree is
-torn down completely; keep its branch only when its commits exist nowhere else.
+   their residuals and commits on its branch. Its parent marks proven key
+   results met in the `kvb-org-rasci` register and records
+   `--branch` and `--artifact worktree:<path>`.
+5. **Independent review.** Before any merge, run the `kvb-think-dialectic`
+   skill with skeptics who did not write the change, briefed the same way
+   (exact diff and claim, capped answer). A hole returns the change to stage 3.
+6. **Merge.** At or above the bar, merge the sidetree branch by the
+   repository's commit rules, then re-verify on the main line with the
+   project's gate.
+7. **Tear down.** Read `teardown.md` next to this file before tearing down a
+   merged, proposed or abandoned sidetree.
 
 ## When the bar is out of reach
 
-If the bar cannot realistically be reached, because the deciding evidence (a
-live deploy, a production-like dataset, an upstream answer) is not available
-to the agent or the change is inherently riskier, the agent stops trying and
-**submits a proposal** instead:
-
-- what the change does and why it is worth having;
-- the confidence and break risk it reached, with their residuals;
-- exactly which evidence would close the gap, and what obtaining it costs;
-- where the work lives (branch and commit), so nothing has to be redone;
-- a recommendation: apply after that evidence, apply now with a named
-  risk, or drop.
-
-The operator decides. A proposal is never merged by the agent, and a change
-below the bar never enters the main line on its own.
+When the deciding evidence (a live deploy, a production-like dataset, an
+upstream answer) is not available to the agent or the change is inherently
+riskier, read `proposal.md` next to this file.
 
 ## Rules
 
 - At its time cap, ask an agent for its interim findings and let it run on;
-  never stop a running agent. A brief without a cap can run for hours without
-  a word.
+  never stop a running agent.
 - Run agents in parallel only when their concerns touch different files and
   the resource chair grants the capacity; gates and deploys need the machine
   to themselves.
@@ -116,5 +80,5 @@ One table per round:
 
 | Agent | Sidetree branch | Confidence | Break risk | Verdict | Evidence |
 
-The verdict is merged, proposal or abandoned. Proposals list what would close
-their gap.
+Verdict: merged, proposal or abandoned; proposals list what would close their
+gap.

skills/kvb-org-split/proposal.md

@@ -0,0 +1,13 @@
+# Proposal
+
+When the bar is out of reach, the agent stops trying and submits a proposal:
+
+- what the change does and why it is worth having;
+- the confidence and break risk it reached, with their residuals;
+- exactly which evidence would close the gap, and what obtaining it costs;
+- where the work lives (branch and commit), so nothing has to be redone;
+- a recommendation: apply after that evidence, apply now with a named risk, or
+  drop.
+
+The operator decides. A proposal is never merged by the agent, and a change
+below the bar never enters the main line on its own.

skills/kvb-org-split/teardown.md

@@ -0,0 +1,33 @@
+# After the merge
+
+A merged sidetree leaves nothing behind, so the next round starts from a clean
+machine. Work through the list in this order, verifying each step instead of
+assuming it:
+
+1. **Stop its jobs**: background runs, watchers, scheduled loops and agents
+   that belong to the sidetree.
+2. **Tear down its stacks**: compose projects and swarm or test clusters
+   together with their volumes and networks, and the containers and images
+   built only for it. Leave anything another worktree still uses.
+3. **Clear files the containers left**: count the entries the user does not
+   own (`find <worktree> -not -user "$USER" -prune | wc -l`). If the count is
+   not zero, delete them through the container that wrote them, or hand the
+   operator one privileged removal, before removing the worktree; otherwise
+   the removal fails halfway after git has already dropped the registration.
+4. **Remove the worktree** and its registration. Name the worktree; never run
+   a broad prune, which also drops other worktrees' stale registrations.
+5. **Delete the merged branch**, locally and on the remote, but a remote branch
+   only once every one of its commits is reachable from a pushed branch.
+6. **Release what it held**: slots, port or subnet reservations, locks, its
+   `kvb-org-organize` claims and every claim announced to other agents. The
+   freed slot and the released claims go to the chair and the peers as one
+   `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post "<text>"`,
+   not as messages. Drop each removed item from the `kvb-org-rasci` register
+   with `--drop-artifact` and set the subagent's task `done` or `stopped`.
+7. **Remove its temporary files**: logs, message files and scratch data that
+   have served their purpose. Keep only the evidence the report cites, until
+   the report is delivered.
+
+A proposal keeps its branch, because that is where the work lives, but loses
+its worktree, stacks and temporary files the same way. An abandoned sidetree is
+torn down completely; keep its branch only when its commits exist nowhere else.

skills/kvb-org-sunrise/SKILL.md

@@ -2,7 +2,6 @@
 name: kvb-org-sunrise
 description: >
   Wake every agent after kvb-org-evening or kvb-org-sunset into its old roles.
-  Trigger on /kvb-org-sunrise.
 ---
 
 Undoes the night of `kvb-org-evening` or `kvb-org-sunset`; the state lives in

skills/kvb-org-sunset/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-org-sunset
 description: >
   Put every agent but this session to sleep: park work, write a morning
-  handover, hold messages. Trigger on /kvb-org-sunset; /kvb-org-sunrise undoes it.
+  handover, hold messages. kvb-org-sunrise undoes it.
 ---
 
 When tokens or rate limits run short, the organisation narrows to one working
@@ -33,7 +33,8 @@ the state for evening, sunset and sunrise; every agent verifies a request with
 - **Offices**: the sleepers' claims stay theirs. Take only free work; a piece
   a sleeper holds waits for sunrise or the operator.
 - **Messages**: no broadcasts and no peer questions; the Peer protocol's wait
-  is skipped.
+  is skipped. Status goes to `news.py post` (next to `watch.py`); sleepers
+  read it at sunrise at no cost.
 - The `kvb-org-rasci` register keeps every row as it is.
 
 ## Output

skills/kvb-org-wsjf/SKILL.md

@@ -1,8 +1,7 @@
 ---
 name: kvb-org-wsjf
 description: >
-  WSJF priority from Fibonacci estimates. Trigger on /kvb-org-wsjf, "wsjf",
-  "priorisieren".
+  WSJF priority from Fibonacci estimates. Trigger on "wsjf", "priorisieren".
 ---
 
 Weighted Shortest Job First ranks the tasks of the `kvb-org-rasci` register
@@ -22,12 +21,16 @@ rasci.py wsjf [--all]
 ## Procedure
 
 1. **The chair asks.** For every new task, and when its objective or a key
-   result changes, the resource chair of the `kvb-org-organize` skill asks
-   its subordinates (the task's worker and R, the representatives of the
-   lines it touches) for one Fibonacci estimate each of business value and
-   complexity, one message per agent.
-2. **Record each answer** under the party that gave it; a new estimate
-   replaces the old one. An agent may record its own.
+   result changes, the resource chair of the `kvb-org-organize` skill reads
+   `rasci.py wsjf` and asks only the subordinates (the task's worker and R,
+   the representatives of the lines it touches) whose Fibonacci estimate of
+   business value or complexity is missing or older than the task's last
+   objective or key-result change: one batched message per agent
+   covering all its tasks. The agent answers by recording its estimate with
+   `rasci.py estimate`, not by message; the chair reads the register instead
+   of polling.
+2. **Record each estimate** under the party that gave it; a new estimate
+   replaces the old one. An agent may record its own unasked.
 3. **Rank**: WSJF = median business value / median complexity, highest
    first. An operator's pin (`rasci.py set <task> --prio <n>`) outranks every
    score; unestimated tasks come last and are named under `unestimated:`.

skills/kvb-skill-auto/SKILL.md

@@ -6,29 +6,25 @@ description: >
   repeating themselves.
 ---
 
-Its objective is the `kvb-skill-tune` skill's **Objective** section: a skill is worth
-creating only when it cuts tokens or time and raises quality; judge every
-candidate against its three axes and rules.
+Its objective is the `kvb-skill-tune` skill's **Objective** section: a skill is
+worth creating only when it cuts tokens or time and raises quality; judge
+every candidate against its three axes and rules.
 
-When you notice the operator repeating the same kind of instruction,
-correction, or prompt pattern (about three occurrences, exact wording may
-vary), do the following:
+When the operator repeats the same kind of instruction, correction or prompt
+pattern (about three times, wording may vary):
 
 1. Finish the current task first; never interrupt work in progress.
-2. Then propose, in one short paragraph: the repeated pattern you observed,
-   a skill name suggestion, the trigger phrasing, and what the skill would
-   do. Ask whether to create it.
-3. On approval, write the skill: persist it exactly as the
-   `kvb-skill-tune` skill's **Persistence** section specifies — locate the
-   operator's skills repository, write `skills/<name>/SKILL.md` there (or in
-   the current project for project-specific behavior), then mirror the skill
-   directory into `~/.claude/skills/` and `~/.agents/skills/`, plus the
-   project's `.claude/skills/` and `.agents/skills/` when it is
-   project-specific.
-   Follow the local naming conventions and keep the skill a thin,
-   single-purpose instruction; route to an authoritative doc when one
-   exists instead of duplicating it. Its deterministic steps become a script
-   through the `kvb-skill-compile` skill, not prose.
-4. Do not propose a skill for one-off work, secrets, or anything whose
-   repetition is already covered by an existing skill; when an existing
-   skill almost fits, propose extending it instead.
+2. Then propose in one short paragraph: the observed pattern, a skill name,
+   the trigger phrasing and what the skill would do. Ask whether to create
+   it.
+3. On approval, persist it exactly as the `kvb-skill-tune` skill's
+   **Persistence** section specifies: write `skills/<name>/SKILL.md` in the
+   operator's skills repository (or the current project for project-specific
+   behavior), then mirror the skill directory into `~/.claude/skills/` and
+   `~/.agents/skills/`, plus the project's `.claude/skills/` and
+   `.agents/skills/` when project-specific. Follow the local naming
+   conventions; keep the skill thin and single-purpose, routing to an
+   authoritative doc instead of duplicating it. Its deterministic steps
+   become a script through the `kvb-skill-compile` skill, not prose.
+4. No skill for one-off work, secrets, or repetition an existing skill
+   already covers; when one almost fits, propose extending it instead.

skills/kvb-skill-cleanup/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-skill-cleanup
 description: >
   Delete legacy skills that renamed or removed skills left in Claude, Codex,
-  agent and project dirs. Trigger on /kvb-skill-cleanup.
+  agent and project dirs.
 ---
 
 `${CLAUDE_SKILL_DIR}/scripts/legacy.py` reads the skills repository's git

skills/kvb-skill-compile/SKILL.md

@@ -2,20 +2,19 @@
 name: kvb-skill-compile
 description: >
   Turn deterministic skill steps into tested scripts in the skill's own repo.
-  Trigger on /kvb-skill-compile or a skill step that is a fixed command
-  sequence.
+  Trigger on a skill step that is a fixed command sequence.
 ---
 
-A deterministic step is one whose result follows from its inputs alone:
-fixed command sequences, output parsing and filtering, counting, thresholds
-and arithmetic, format checks, sorting and lookups, state bookkeeping. This
-skill compiles such steps into scripts and cuts the prose down to the call. Choosing, explaining and asking stay prose.
-It changes nothing before the operator confirms.
+A deterministic step's result follows from its inputs alone: fixed command
+sequences, output parsing and filtering, counting, thresholds and arithmetic,
+format checks, sorting and lookups, state bookkeeping. Such steps become
+scripts and their prose shrinks to the call; choosing, explaining and asking
+stay prose. Nothing changes before the operator confirms.
 
 ## Step 1: scope and owner
 
-The skills named after the command, or every skill of the current
-repository when none is named. Per skill, its owning repository:
+The skills named after the command, else every skill of the current
+repository. Per skill, its owning repository:
 
 - **Skills repository**: a first-party skill under its `skills/`, and every
   installed copy of one (`~/.claude/skills`, `~/.agents/skills`, a project's
@@ -24,23 +23,22 @@ repository when none is named. Per skill, its owning repository:
 - **Another repository**: a skill tracked in that repository's own tree
   (`git ls-files` lists it there), such as a project's `.claude/skills`.
 - **Third party**: a `skills-lock.json` entry from a foreign source is not
-  compiled; propose the change upstream instead.
+  compiled; propose the change upstream.
 
 ## Step 2: inventory
 
-Read-only. Per skill, every step that is deterministic, with its evidence:
-how often sessions ran it (transcripts, `rasci.py tools` of the
-`kvb-org-rasci` register) and where an agent got it wrong. One line each:
+Read-only. Per skill, every deterministic step with its evidence: how often
+sessions ran it (transcripts, `rasci.py tools` of the `kvb-org-rasci`
+register) and where an agent got it wrong. One line each:
 `skill:step -> deterministic part -> inputs -> output -> runs per use`.
 
 ## Step 3: classify
 
-Compile what runs often or went wrong; leave a one-off as prose. Per
-candidate:
+Compile what runs often or went wrong; a one-off stays prose. Per candidate:
 
 - **Language and form**: the owning repository's own (Python standard
-  library in the skills repository); no new language, framework or
-  dependency without the operator.
+  library in the skills repository); no new language, framework or dependency
+  without the operator.
 - **Interface**: every host path, name and value an explicit parameter (the
   `kvb-code-no-defaults` skill), documented exit codes, `--json` when another
   script or skill consumes the output.
@@ -58,13 +56,14 @@ and the prose diff.
 ## Step 5: write
 
 - Write the script, then replace the compiled prose with its call
-  (`${CLAUDE_SKILL_DIR}/scripts/<verb>.py ...`) and the one line on reading
-  its output.
-- Every script gets a unit test with a negative control shown once. Tests
-  run only on the resource chair's grant (the `kvb-org-organize` skill).
-- In another repository follow its agent rules (claims, worktree, branch);
-  a file another line owns goes to that line through the
-  `kvb-org-coordinate` skill.
+  (`${CLAUDE_SKILL_DIR}/scripts/<verb>.py ...`) and one line on reading its
+  output.
+- Every script gets a unit test with a negative control shown once, run once
+  `watch.py admit --kind test-nostack` (the `kvb-org-organize` skill) prints
+  `grant`; `make test` keeps the chair's grant.
+- In another repository follow its agent rules (claims, worktree, branch); a
+  file another line owns goes to that line through the `kvb-org-coordinate`
+  skill.
 - Leave the result uncommitted for the `kvb-git-commit-next` skill.
 
 ## Output

skills/kvb-skill-essence/SKILL.md

@@ -1,118 +1,94 @@
 ---
 name: kvb-skill-essence
 description: >
-  Compact skills and memory after a health pass for dead weight. Trigger on
-  /kvb-skill-essence or when skills or MEMORY.md grow too long or duplicate.
+  Compact skills and memory after a health pass for dead weight. Trigger when
+  skills or MEMORY.md grow too long or duplicate.
 ---
 
 Shorter, not thinner. Every fact that still earns its place survives; what goes
 is repetition, narration, and entries nothing loads any more.
 
-## What actually costs context
+## What costs context
 
-Compact by how often a thing is loaded, not by how large it is:
+Compact by how often a thing loads, not by its size:
 
-1. **`MEMORY.md`** and every skill's **`description`** frontmatter load into
-   *every* session. A wasted line here is paid on every single turn. Highest
-   leverage by a wide margin.
-2. **Skill bodies** load when the skill fires. Worth tightening, paid only on use.
-3. **Memory files** load on recall. Lowest leverage — and the place where
-   cutting evidence does the most damage.
+1. **`MEMORY.md`** and every skill's **`description`** load into *every*
+   session: a wasted line is paid on every turn. Highest leverage by far.
+2. **Skill bodies** load when the skill fires: paid only on use.
+3. **Memory files** load on recall.
 
-A 200-line skill body that fires twice a month costs less than four bloated
-`MEMORY.md` pointers. Rank the work accordingly and say so in the report.
+A 200-line body firing twice a month costs less than four bloated `MEMORY.md`
+pointers. Rank the work accordingly and say so in the report.
 
 ## Step 1: ask for the scope
 
-Never assume the target. Ask once with `AskUserQuestion` and
-`multiSelect: true`, so the operator can tick several:
+Never assume the target. One `AskUserQuestion`, `multiSelect: true`:
 
-- **Skills repository** — the portable `skills/*/SKILL.md` set.
-- **This project** — its `.claude/skills` and `.agents/skills`, plus the
-  project's memory directory and `MEMORY.md`.
-- **Home** — `~/.claude` and `~/.agents` (skills, rules, commands, agents).
+- **Skills repository**: the portable `skills/*/SKILL.md` set.
+- **This project**: its `.claude/skills` and `.agents/skills`, its memory
+  directory and `MEMORY.md`.
+- **Home**: `~/.claude` and `~/.agents` (skills, rules, commands, agents).
 
-Take nothing outside what was ticked.
+Take nothing outside what was ticked. Read `memory.md` next to this file when
+the scope holds a memory directory or `MEMORY.md`.
 
 ## Step 2: doctor
 
-Before compacting anything, find what is already broken or dead. Report each
-finding with its path:
+Before compacting, find what is broken or dead, each finding with its path:
 
-- A `MEMORY.md` pointer whose file is gone, and a memory file no pointer names.
-- A dead `[[wikilink]]` — no memory of that name exists.
-- A memory asserting a `file:line`, function, or flag that no longer exists.
-  Verify against the current tree; a stale citation is worse than no memory,
-  because it reads as checked.
-- The same rule stated in two or more skills. One is authoritative, the rest
-  are drift.
-- A first-party skill shadowing a locked/vendored one.
-- Frontmatter missing `name` or `description`, or a `description` that says
-  what the skill does but never when it fires — such a skill costs context in
-  every session and never triggers.
+- The same rule in two or more skills: one is authoritative, the rest drift.
+- A first-party skill shadowing a locked or vendored one.
+- Frontmatter missing `name` or `description`, or a `description` saying what
+  the skill does but never when it fires: it costs context every session and
+  never triggers.
 
-Dead entries are deleted, not compacted. Fix the broken ones or report them;
-never compact around a stale citation, or the error survives in denser form.
+Dead entries are deleted, not compacted. Fix or report the broken ones; never
+compact around a stale citation, or the error survives denser.
 
 ## Step 3: compact
 
 Cut:
 
-- Anything the repository already records — code structure, git history, what
-  `CLAUDE.md`/`AGENTS.md` already say.
-- A rule the agent follows anyway without being told.
-- The second and third statement of one rule; keep the authoritative one and
+- What the repository already records: code structure, git history,
+  `CLAUDE.md`/`AGENTS.md`.
+- A rule the agent follows anyway.
+- The second and third statement of a rule; keep the authoritative one and
   point at it.
-- Narration, hedging, and worked examples beyond the one that carries the point.
-- A deterministic procedure spelled out step by step: hand it to the
-  `kvb-skill-compile` skill, which replaces it with a script call, instead of
-  shortening it.
+- Narration, hedging, and worked examples beyond the one carrying the point.
+- A deterministic step-by-step procedure: hand it to the `kvb-skill-compile`
+  skill, which replaces it with a script call.
 
-Keep, always:
-
-- The **why** and the evidence behind a memory — the date, the incident, the
-  quoted correction. A rule stripped of its evidence degrades into an
-  exhortation and stops changing behaviour.
-- Any fact with no other home. If it exists nowhere else, it is not redundancy.
-- Trigger wording in a `description`. Tighten it, never drop the "when".
-
-Dates stay absolute. Never introduce "recently" while shortening.
+Keep any fact with no other home (it is not redundancy) and the trigger
+wording of a `description`: tighten it, never drop the "when". Dates stay
+absolute; never introduce "recently" while shortening.
 
 ## Step 4: show the diff, then write
 
-Writing happens in place — an essence that lives beside the original saves
-nothing, because the original is still what loads.
+Write in place: an essence beside the original saves nothing, the original
+still loads. A git repository needs a clean status for the rewritten paths,
+so git alone reverts every edit; not clean: report and stop. `~/.claude` and
+`~/.agents` are usually not under git: copy each file to `<file>.pre-essence`
+first.
 
-Preconditions, per target:
-
-- A git repository must have a clean status for the paths being rewritten, so
-  every edit is revertable with git alone. Not clean: report and stop.
-- `~/.claude` and `~/.agents` are usually not under git. Copy each file to
-  `<file>.pre-essence` first.
-
-Then present, per file: the diff, and the lines and characters saved. Ask for
-one confirmation covering the batch. Write only after it.
+Present per file the diff and the lines and characters saved; ask one
+confirmation for the batch; write only after it.
 
 ## Step 5: verify
 
-- Re-run the target's own validation if it has one (in a skills repository,
-  its test suite: frontmatter, lock, shadowing).
-- Re-read each rewritten file and confirm every kept fact is still stated, not
-  merely implied by something shorter.
-- Report the before/after loaded-context figure for the always-loaded surface
-  (`MEMORY.md` plus all descriptions) separately from the rest. That number is
-  the point of the run.
+- Re-run the target's own validation if it has one (in a skills repository its
+  test suite: frontmatter, lock, shadowing), admitted under the
+  `kvb-org-organize` Capacity rules.
+- Re-read each rewritten file: every kept fact is still stated, not merely
+  implied.
+- Report the before and after loaded-context figure for the always-loaded
+  surface (`MEMORY.md` plus all descriptions) apart from the rest: that number
+  is the point of the run.
 
 ## Rules
 
-- Deleting is the goal; rewriting shorter is the fallback. Prefer removing an
-  entry over polishing it.
-- Never merge two memories whose evidence differs. Two incidents supporting one
-  rule are stronger than one; two rules sharing one incident is a fabrication.
-- A skill that has never fired is a candidate for deletion, not compaction —
-  say so and let the operator decide.
-- Nothing is written without the Step 4 confirmation, and nothing outside the
-  scope ticked in Step 1.
-- `caveman-compress` is not a rival: it rewrites the wording of one named file,
-  this removes what should not be there at all. Run this one first — compressing
-  a dead entry is pure waste.
+- Deleting is the goal; rewriting shorter the fallback.
+- A skill that never fired is a deletion candidate, not a compaction one: say
+  so and let the operator decide.
+- `caveman-compress` is no rival: it rewrites one named file's wording; this
+  removes what should not be there. Run this first: compressing a dead entry
+  is pure waste.

skills/kvb-skill-essence/memory.md

@@ -0,0 +1,25 @@
+# Memory scope
+
+Memory files load on recall: lowest leverage, and where cutting evidence does
+the most damage.
+
+## Doctor
+
+- A `MEMORY.md` pointer whose file is gone; a memory file no pointer names.
+- A dead `[[wikilink]]`: no memory of that name exists.
+- A memory citing a `file:line`, function or flag that no longer exists.
+  Verify against the current tree, through the codebase-memory-mcp graph first
+  (`search_graph`, `trace_path`; the `kvb-agent-optimize` skill sets it up),
+  grep and read after. A stale citation is worse than none: it reads as
+  checked.
+
+## Compact
+
+- Keep the **why** and evidence behind a memory: the date, the incident, the
+  quoted correction. A rule stripped of evidence degrades into an exhortation
+  and stops changing behaviour.
+- Never merge two memories whose evidence differs: two incidents behind one
+  rule are stronger than one; two rules sharing one incident is a fabrication.
+- `MEMORY.md` stays at most 400 words: one line per section linking its
+  sub-index, plus only the rules every session needs on every turn; details
+  go into the sub-indexes.

skills/kvb-skill-transcend/SKILL.md

@@ -2,13 +2,12 @@
 name: kvb-skill-transcend
 description: >
   Carry the session's skill use and own scripts into the skills repo.
-  Trigger on /kvb-skill-transcend.
 ---
 
-What an agent improvised in one session dies with it: the helper script in its
-scratchpad, the command sequence it ran five times, the skill it had to work
-around. This skill carries that into the operator's skills repository, so the
-next agent starts from it. It changes nothing before the operator confirms.
+What an agent improvised in one session (a scratchpad helper script, a
+command sequence run five times, a skill it worked around) goes into the
+operator's skills repository for the next agent. Nothing changes before the
+operator confirms.
 
 ## Step 1: inventory
 
@@ -22,7 +21,7 @@ Read-only:
 - **Skills used**: every skill this session invoked, how often, and where it
   fell short (a workaround, a step skipped, an operator correction).
 - **Recurring moves without a skill**: command sequences, peer exchanges or
-  lookups run three times or more. `rasci.py tools` of the `kvb-org-rasci`
+  lookups run three times or more; `rasci.py tools` of the `kvb-org-rasci`
   register lists the scripts the session's tasks recorded.
 
 One line each: `candidate -> source -> evidence`.
@@ -33,27 +32,29 @@ Per candidate one target: a script under an existing skill's `scripts/`, a
 new skill, a sharper step in an existing skill, a memory entry instead, or
 drop. A recurring deterministic move without a script goes to the
 `kvb-skill-compile` skill, any other recurring move to the `kvb-skill-tune`
-skill as evidence. A script is portable only once its host paths, names and values
-became explicit parameters (the `kvb-code-no-defaults` skill); one that needs
-a secret, a credential or a single host is dropped or stays a memory entry.
+skill as evidence. A script is portable only once its host paths, names and
+values are explicit parameters (the `kvb-code-no-defaults` skill); one that
+needs a secret, a credential or a single host is dropped or stays a memory
+entry.
 
 ## Step 3: listen and confirm
 
 Run the `kvb-think-listen` skill on the open points: scope, target skill,
 generality. Then `AskUserQuestion`: one `multiSelect` with the candidates
-(target and evidence in each description, nothing preselected), and per pick a
-single-select `Write it` / `Revise it` / `Discard` showing the drafted file or
-diff.
+(target and evidence in each description, nothing preselected), and per pick
+a single-select `Write it` / `Revise it` / `Discard` showing the drafted file
+or diff.
 
 ## Step 4: write
 
-- Write where the `kvb-skill-tune` skill's **Persistence** section says:
-  the skills repository as source of truth, then the live mirrors.
+- Write where the `kvb-skill-tune` skill's **Persistence** section says: the
+  skills repository as source of truth, then the live mirrors.
 - Read every script whole before carrying it; strip comments the way the
   `kvb-code-no-comments` skill does.
 - A carried script gets a unit test in the repository's `tests/` with a
-  negative control. Tests run only on the resource chair's grant (the
-  `kvb-org-organize` skill).
+  negative control, run once `watch.py admit --kind test-nostack` (the
+  `kvb-org-organize` skill) prints `grant`; `make test` keeps the chair's
+  grant.
 - `transcend.py mark` every offered candidate with its verdict.
 - Leave the result uncommitted; committing is the `kvb-git-commit-next`
   skill's job.

skills/kvb-skill-tune/SKILL.md

@@ -2,153 +2,81 @@
 name: kvb-skill-tune
 description: >
   Generate or sharpen skills from observed friction, each proposal confirmed.
-  Trigger only on /kvb-skill-tune, "autotune", "tune the skills" or through
-  kvb-optimize.
+  Trigger only on "autotune", "tune the skills" or through kvb-optimize.
 ---
 
-Autotune turns observed friction into durable skills. It runs on demand only,
-it changes nothing without an explicit answer from the operator, and every
-skill it writes or rewrites lands in the operator's skills repository.
-
 ## Objective
 
-The shared objective of the self-improving skills (kvb-skill-tune,
-kvb-skill-auto, kvb-check-confidence): every skill, rule, or report the agent produces about its own
-working is judged on three axes at once. A proposal that cannot name the axis
-it moves is not an optimization, it is a preference.
+Shared by kvb-skill-tune, kvb-skill-auto and kvb-check-confidence: every skill,
+rule or report about the agent's own working is judged on three axes; a
+proposal naming none is a preference.
 
-- **Tokens** — fewer input and output tokens for the same result: read the range
-  instead of the whole file, grep the saved log instead of re-running the
-  command, route to an authoritative doc instead of duplicating it, report in
-  lines instead of paragraphs.
-- **Time** — fewer round trips and less waiting: independent calls in parallel,
-  one command that answers the question instead of three that circle it, no
-  polling for work the harness will report on its own.
-- **Quality** — fewer errors and less rework: verification instead of
-  assumption, and learnings that persist so the same mistake is not paid for
-  twice.
+- **Tokens**: fewer tokens for the same result (read the range, grep the saved
+  log, route to the authoritative doc, report in lines).
+- **Time**: fewer round trips and less waiting (independent calls in parallel,
+  one command that answers, no polling for what the harness reports).
+- **Quality**: fewer errors and less rework (verify instead of assuming,
+  persist learnings so a mistake is paid once).
 
-- A change must improve at least one axis and damage none. Output that got
-  cheaper but lost correctness is a regression, not an optimization.
-- Quality is never the currency: validation, error handling, tests, and security
-  steps are not what gets cut to save tokens or time.
-- Measure, do not guess: name the observed friction — the re-read, the retry,
-  the correction the operator had to give twice — and what it cost. A guessed
-  percentage is not a measurement.
-- The cheapest step is the one that does not run: drop work before optimizing
-  it.
-- Persist it or pay again: an optimization that lives only in this session is
-  re-derived in the next one, so it belongs in a skill or a memory entry.
+A change improves at least one axis and damages none; cheaper but less correct
+is a regression. Quality is never the currency: validation, error handling,
+tests and security steps are not cut. Name the observed friction (the re-read,
+the retry, the correction given twice) and its cost, never a guessed
+percentage. Drop work before optimizing it. Persist it in a skill or memory
+entry, or pay again.
 
 ## Trigger discipline
 
-- Run **only** when the operator asks: `/kvb-skill-tune`, "autotune", "tune the
-  skills", or an equivalent instruction, or as part of the `kvb-optimize`
-  skill the operator started (directly or through `kvb-dream`).
-- It has no reminder of its own; the `kvb-dream` hint covers it.
-- Never propose, write, or edit a skill as a side effect of unrelated work.
+Run only on the operator's request (its command, "autotune", "tune the skills"
+or an equivalent) or inside a `kvb-optimize` run the operator started,
+directly or through `kvb-dream`, whose hint is its only reminder. Never write
+or edit a skill as a side effect of other work.
 
 ## Step 1: collect evidence
 
-Before asking anything, gather concrete friction from the current session and,
-where readable, from the project's memory and agent instruction files:
-
-- **Token waste**: repeated file re-reads, whole-file reads where a range was
-  enough, long tool output pasted back, re-running a command instead of
-  grepping a saved log, verbose report prose.
-- **Errors**: rejected tool calls, permission prompts, retried commands,
-  corrections the operator had to give twice.
-- **Focus loss**: work that drifted beyond the request, unrequested tests or
-  deploys, questions that stalled an autonomous run.
-- **Lost learnings**: facts re-derived this session that a memory file or a
-  skill should already have carried.
-- **Own scripts**: helpers the agent wrote outside any repository belong to
-  the `kvb-skill-transcend` skill, which carries them over; this skill
-  takes the frictions they reveal.
-- **Deterministic prose**: a skill step the agent worked through by hand
-  although its result follows from its inputs belongs to the
-  `kvb-skill-compile` skill, which turns it into a script.
-
-List each finding as one line: `symptom -> cost -> candidate fix`. Skip
-anything that happened once and is not a pattern.
+Before asking, gather friction from the session and, where readable, the
+project's memory and agent instruction files: token waste (re-reads, whole-file
+reads, pasted tool output, re-runs instead of a grepped log, verbose prose),
+errors (rejected calls, permission prompts, retries, corrections given twice),
+focus loss (drift beyond the request, unrequested tests or deploys, questions
+that stalled an autonomous run), lost learnings (facts memory or a skill should
+have carried). Own scripts outside any repository go to the
+`kvb-skill-transcend` skill (this one takes the frictions they reveal); a step
+worked by hand although its result follows from its inputs goes to the
+`kvb-skill-compile` skill. One line per finding: `symptom -> cost -> candidate
+fix`; skip one-offs that form no pattern.
 
 ## Step 2: ask, do not decide
 
-Use `AskUserQuestion` with `multiSelect: false` so every question renders as
-radio buttons. Never assume an answer, never batch several decisions into one
-option, and never write a file before the answers are in.
+`AskUserQuestion` with `multiSelect: false`, at most four questions per call,
+in this order; never assume an answer, never batch decisions into one option:
 
-Ask in this order, at most four questions per call:
+1. **Scope**: "What should kvb-skill-tune do this run?" `Create a new skill`,
+   `Optimize an existing skill`, `Both`, plus the ranked findings when there
+   are several candidates.
+2. **Target**: one option per candidate, its measured cost in the description.
+3. **Shape**: new: `Standalone skill`, `Extend an existing skill`, `Memory
+   entry instead of a skill`. Optimization: `Tighten wording only`, `Change
+   the trigger`, `Add rules`, `Split into two skills`, `Merge into another
+   skill`, `Compile deterministic steps into a script` (`kvb-skill-compile`).
+4. **Placement**: `Operator skills repository (portable)` or `This project's
+   skills directory (project-specific)`.
 
-1. **Scope** - "What should kvb-skill-tune do this run?" Options: `Create a new
-   skill`, `Optimize an existing skill`, `Both`, plus the ranked findings if
-   more than one candidate exists.
-2. **Target** - which finding becomes a skill, or which existing skill gets
-   optimized. One option per candidate, each with its measured cost in the
-   description.
-3. **Shape** - for a new skill: `Standalone skill`, `Extend an existing
-   skill`, `Memory entry instead of a skill`.
-   For an optimization: `Tighten wording only`, `Change the trigger`, `Add
-   rules`, `Split into two skills`, `Merge into another skill`, `Compile
-   deterministic steps into a script` (the `kvb-skill-compile` skill).
-4. **Placement** - `Operator skills repository (portable)` or
-   `This project's skills directory (project-specific)`.
-
-Present the drafted skill text (name, trigger phrasing, body outline) and ask
-for a final `Write it` / `Revise it` / `Discard` confirmation before touching
-disk. Rewrites of an existing skill additionally show a before/after diff of
-the changed lines in that confirmation.
+Then show the draft (name, trigger phrasing, body outline; a rewrite adds a
+before/after diff of the changed lines) and ask `Write it` / `Revise it` /
+`Discard`. Nothing touches disk before `Write it`.
 
 ## Persistence
 
-A skill that exists only under `.claude/skills` is lost on the next install, and
-one that exists only in the repository is not live until the next restart — so
-every skill is written to **both**, in this order:
-
-1. **Locate the operator's skills repository.** Take the first hit: the
-   `SKILLS_REPO` environment variable; the current repository, when it holds
-   `skills-lock.json` and a `skills/` directory; `pkgmgr path skills`; a git
-   checkout named `skills` under the usual roots
-   (`~/Repositories/*/*/skills`, `~/git`, `~/src`, `~/Projects`) carrying
-   `skills-lock.json`. If none matches, ask the operator for the path with a
-   single-select question — never skip the repository and write only the live
-   copies.
-2. **Write the source of truth**: `skills/<name>/SKILL.md` in that repository
-   (portable skills), or `skills/<name>/SKILL.md` in the current project
-   (project-specific ones). This is the copy that gets committed.
-3. **Mirror it live**, so it works without a reinstall: copy the skill's whole
-   directory to `~/.claude/skills/<name>/` and `~/.agents/skills/<name>/`, and
-   for a project-specific skill additionally to that project's
-   `.claude/skills/<name>/` and `.agents/skills/<name>/`. Copy the directory,
-   not just `SKILL.md`, so hooks and references come along.
-
-Report all written paths. Deleting or renaming a skill follows the same list in
-reverse — remove the mirrors too, or the old name keeps firing.
-
-## Step 3: write
-
-- Write the skill to every location the **Persistence** section lists.
-- Frontmatter carries `name` and a `description` that states what the skill
-  does **and** when to trigger it - the description is the only part loaded into
-  every session, so it decides whether the skill ever fires.
-- Body is thin and single-purpose: the smallest instruction that changes
-  behaviour. Route to an authoritative doc instead of duplicating it.
-- Optimizing an existing skill means the file gets shorter or sharper, not
-  longer. Delete rules the agent already follows, merge duplicated ones, and
-  cut every sentence that does not change an action. Route that compaction
-  through the `kvb-skill-essence` skill instead of trimming by hand: it runs a health
-  pass for dead pointers and rules duplicated across skills before cutting
-  anything, ranks by what loads in every session, and shows the diff before it
-  writes. It asks for its own scope — answer with the skill being optimized.
-- Report what changed in at most three lines, then refresh the reminder stamp
-  so the next hint is an hour out: `date +%s > ~/.claude/.autotune-stamp`.
+Every skill goes to its source of truth `skills/<name>/SKILL.md` in the skills
+repository (`SKILLS_REPO` first) or the project, and live to
+`~/.claude/skills/` and `~/.agents/skills/`. Read `write.md` next to this file
+before writing, renaming or deleting a skill.
 
 ## Rules
 
-- One skill per run unless the operator picked `Both`; a broad rewrite of the
-  whole collection is not what kvb-skill-tune is for.
-- Never write a skill for one-off work, for secrets, or for behaviour an
-  existing skill already covers - propose extending that skill instead.
-- The **Objective** section decides what counts as an improvement: at least
-  one axis better, none damaged, and the claim named as observed friction rather
-  than a guessed percentage.
+- One skill per run unless the operator picked `Both`; no broad rewrite of the
+  whole collection.
+- No skill for one-off work, for secrets, or for behaviour an existing skill
+  covers: propose extending that skill.
+- The **Objective** decides what counts as an improvement.

skills/kvb-skill-tune/write.md

@@ -0,0 +1,38 @@
+# Writing a skill
+
+## Persistence
+
+Only under `.claude/skills` a skill is lost on the next install; only in the
+repository it is not live until the next restart. Write **both**, in order:
+
+1. **Locate the skills repository**, first hit: the `SKILLS_REPO` variable;
+   the current repository when it holds `skills-lock.json` and `skills/`;
+   `pkgmgr path skills`; a git checkout named `skills` carrying
+   `skills-lock.json` under `~/Repositories/*/*/skills`, `~/git`, `~/src` or
+   `~/Projects`. None: ask for the path with a single-select question; never
+   write only the live copies.
+2. **Source of truth**, the committed copy: `skills/<name>/SKILL.md` in that
+   repository (portable) or in the current project (project-specific).
+3. **Mirror live**: copy the whole skill directory, so hooks and references
+   come along, to `~/.claude/skills/<name>/` and `~/.agents/skills/<name>/`; a
+   project-specific one also to the project's `.claude/skills/<name>/` and
+   `.agents/skills/<name>/`.
+
+Report every written path. Delete or rename in reverse, mirrors included, or
+the old name keeps firing.
+
+## Content
+
+- Frontmatter: `name` and a `description` saying what the skill does **and**
+  when it triggers; it is the only part loaded in every session, so it decides
+  whether the skill fires.
+- Body thin and single-purpose: the smallest instruction that changes
+  behaviour; route to the authoritative doc instead of duplicating it.
+- Optimizing makes a skill shorter or sharper, never longer: drop rules the
+  agent already follows, merge duplicates, cut every sentence that changes no
+  action. Route that compaction through the `kvb-skill-essence` skill (health
+  pass for dead pointers and cross-skill duplicates first, ranked by what loads
+  every session, diff before writing); answer its scope question with the
+  skill being optimized.
+- Report the change in at most three lines, then `date +%s >
+  ~/.claude/.autotune-stamp` so the next hint is an hour out.

skills/kvb-think-brainstorm/SKILL.md

@@ -2,7 +2,7 @@
 name: kvb-think-brainstorm
 description: >
   Generate options through fixed lenses, then score and narrow them. Trigger
-  on /kvb-think-brainstorm, "brainstorm", or when a skill needs alternatives.
+  on "brainstorm" or when a skill needs alternatives.
 ---
 
 Generate first, judge second: no option is scored before all are on the
@@ -24,19 +24,22 @@ At least one option per lens, none judged yet:
 - **Inversion**: solve the opposite problem, or remove the need.
 - **Analogy**: how another domain solves a problem of the same shape.
 - **Drop a constraint**: what one fixed constraint, gone, makes possible.
-- **Reuse**: what the repository, the platform or a dependency already has.
+- **Reuse**: what the repository, the platform or a dependency already has;
+  search the repository through the codebase-memory-mcp graph first
+  (`search_graph`, `get_architecture`; the `kvb-agent-optimize` skill sets it
+  up), grep and read after.
 
 ## Step 3: converge
 
-Rate every option on value, effort and risk (`low`, `medium`, `high`),
-merge duplicates, and drop each option another one beats on all three.
+Rate every option on value, effort and risk (`low`, `medium`, `high`), merge
+duplicates, and drop each option another one beats on all three.
 
 ## Step 4: hand over
 
 The best two or three go to the calling skill, or to the operator through
-`AskUserQuestion` with `multiSelect: false`, the recommended option first.
-A consequential choice runs through the `kvb-think-dialectic` skill before
-it is offered.
+`AskUserQuestion` with `multiSelect: false`, the recommended option first. A
+consequential choice runs through the `kvb-think-dialectic` skill before it
+is offered.
 
 ## Output
 

skills/kvb-think-criticize/SKILL.md

@@ -2,67 +2,70 @@
 name: kvb-think-criticize
 description: >
   Constructive criticism of a plan, design, decision, text or code, each
-  point hardened by dialectic. Trigger on /kvb-think-criticize, "kritisiere",
+  point hardened by dialectic. Trigger on "kritisiere",
   "konstruktive Kritik", "was haeltst du davon", or requests for honest
   feedback.
 ---
 
-The stance is critical but constructive: the goal is a better result, not a
-verdict on its author. This skill judges any artifact from many angles; it is
-not limited to code (`kvb-check-principles` hunts violated engineering principles in code,
-`code-review` hunts bugs). Read-only: report the critique, change nothing
-unless the operator asks afterwards.
+Critical but constructive: the goal is a better result, not a verdict on its
+author. Any artifact, from many angles (`kvb-check-principles` hunts violated
+engineering principles in code, `code-review` hunts bugs). Read-only: the
+critique ends at the report; fix, stage or rewrite nothing unless the operator
+asks afterwards.
 
 ## Before you start: listen
 
-Invoke the `kvb-think-listen` skill. Pin down what is being criticized, what it
-is meant to achieve, for whom, and under which constraints. Derive what you can
-from the artifact and its surroundings first; ask only what only the operator
-knows. A critique against the wrong goal is noise.
+Invoke the `kvb-think-listen` skill: what is criticized, what it should
+achieve, for whom, under which constraints. Derive what you can from the
+artifact and its surroundings first (code through the codebase-memory-mcp
+graph: `search_graph`, `trace_path`, `get_architecture`, set up by the
+`kvb-agent-optimize` skill; grep and read after); ask only what only the
+operator knows. A critique against the wrong goal is noise.
 
 ## Steelman first
 
-Restate the artifact and its intent in its strongest form, in two or three
-sentences. Criticize that version, never a weaker one you made up. If you cannot
-steelman it, you have not understood it yet; go back to listening.
+Restate the artifact and its intent at their strongest in two or three
+sentences; criticize that version, never a weaker one. If you cannot
+steelman it, you have not understood it; go back to listening.
 
 ## The aspects
 
-Sweep every aspect that applies, and name the ones you skipped and why:
+Sweep every applicable aspect; name skipped ones and why:
 
-1. **Goal fit** - does it solve the stated problem for the stated audience, or
-   a neighbouring one?
-2. **Correctness** - are the facts, the logic, and the claimed cause-effect
-   chains right? Which claim lacks evidence?
-3. **Completeness** - missing cases, missing stakeholders, missing failure
-   paths, missing definition of done.
-4. **Consistency** - contradictions inside the artifact or against its
-   neighbours; the same truth stated twice in two versions.
-5. **Simplicity** - mechanism, scope, or wording the problem never asked for;
+1. **Goal fit**: the stated problem for the stated audience, or a neighbour?
+2. **Correctness**: facts, logic, claimed cause-effect chains; which claim
+   lacks evidence?
+3. **Completeness**: missing cases, stakeholders, failure paths, definition of
+   done.
+4. **Consistency**: contradictions inside the artifact or against its
+   neighbours; one truth stated twice in two versions.
+5. **Simplicity**: mechanism, scope or wording the problem never asked for;
    the smaller design that does the same.
-6. **Feasibility and cost** - effort, dependencies, order of steps, what blocks
-   what, what it costs to run and to maintain.
-7. **Risk** - security at trust boundaries, data loss, reversibility, blast
-   radius, what happens when it fails halfway.
-8. **People** - usability, accessibility, the reader's or user's actual path,
+6. **Feasibility and cost**: effort, dependencies, step order, what blocks
+   what, running and maintenance cost.
+7. **Risk**: security at trust boundaries, data loss, reversibility, blast
+   radius, failure halfway.
+8. **People**: usability, accessibility, the reader's or user's actual path,
    who gains, who carries the burden.
-9. **Alternatives** - at least one materially different approach, compared
+9. **Alternatives**: at least one materially different approach, compared
    honestly on the aspects above.
-10. **Ethics and compliance** - only where it touches personal data, licences,
-    law, or fairness.
+10. **Ethics and compliance**: only where personal data, licences, law or
+    fairness are touched.
 
 ## Harden every point with dialectic
 
-Run each candidate critique through the `kvb-think-dialectic` skill before reporting it:
+Run each candidate through the `kvb-think-dialectic` skill before reporting:
 
-- **Thesis**: the critique point with its evidence.
-- **Antithesis**: independent defenders argue that the artifact is right as it
-  is, or that the constraint behind it is real; independent skeptics attack the
-  suggested improvement for new problems it would cause.
-- **Synthesis**: keep the point, refine it, or drop it.
+- **Thesis**: the point with its evidence.
+- **Antithesis**: independent defenders argue the artifact is right or the
+  constraint behind it is real; independent skeptics attack the suggestion
+  for new problems it would cause.
+- **Synthesis**: keep, refine or drop.
 
-Batch minor points into one dialectic round; run consequential points (high
-severity, expensive to act on, or challenging a premise) one by one.
+Batch minor points into one round; run consequential ones (high severity,
+expensive to act on, or challenging a premise) one by one. Scale defenders and
+skeptics to the stakes; each brief names exact files or passages and the
+claim, and caps the answer at five lines.
 
 ## Output
 
@@ -75,19 +78,17 @@ One line of scope, then the steelman. Then:
 
 `Evidence` is `proven` (read, run, reproduced, cited) or `derived` (reasoned).
 
-Close with at most three lines: how many candidate points dialectic dropped and
-why, the single change that helps most, and the `kvb-check-confidence` skill's numbers for
-the critique as a whole.
+Close with at most three lines: how many points dialectic dropped and why, the
+single change that helps most, and the `kvb-check-confidence` skill's numbers
+for the whole critique.
 
 ## Rules
 
-- Every critique carries a concrete suggestion. A complaint without one becomes
-  an open question or is dropped.
-- Criticize the work, never the person. Direct wording, no sarcasm, no
+- Every critique carries a concrete suggestion; without one it becomes an open
+  question or is dropped.
+- Criticize the work, never the person: direct wording, no sarcasm, no
   softening of a real problem, no inflation of a minor one.
-- A point that attacks a stated constraint or goal is labelled "challenges a
-  premise" and kept apart from points that work within it.
-- No taste or formatting nitpicks unless the operator asks for them.
+- A point attacking a stated constraint or goal is labelled "challenges a
+  premise" and kept apart from points within it.
+- No taste or formatting nitpicks unless asked.
 - Answer in the operator's language.
-- The critique ends at the report. Do not fix, stage, or rewrite as part of
-  this skill.

skills/kvb-think-dialectic/SKILL.md

@@ -24,16 +24,24 @@ asking; ask only when an operator-only fact blocks the conclusion.
 ## The loop
 
 1. **Thesis.** Form the strongest initial claim you can, grounded in evidence,
-   not assumption. Deep-inspect every source you can reach: the source code and
-   git history; the running containers (exec, logs, inspect through whatever
-   make or CLI helpers the project exposes); CI logs and artifacts; tests; docs.
-   Cite `file:line` and command output — never a bare assertion.
-2. **Antithesis.** Spawn MULTIPLE independent skeptics (parallel subagents or a
+   not assumption. Deep-inspect every source you can reach: the source code
+   (through the codebase-memory-mcp graph first: `search_graph`, `trace_path`,
+   `get_architecture`, set up by the `kvb-agent-optimize` skill; grep and read
+   after) and git history; the running containers (exec, logs, inspect through
+   whatever make or CLI helpers the project exposes); CI logs and artifacts;
+   tests; docs. Cite `file:line` and command output, never a bare assertion.
+2. **Antithesis.** Spawn independent skeptics (parallel subagents or a
    workflow, on the default model as the `kvb-org-perform` skill requires)
    whose only job is to REFUTE the thesis. Each re-inspects the
-   sources itself and defaults to "refuted" on any concrete hole. Give diverse
-   skeptics diverse lenses: correctness, an alternate mechanism, does-it-
-   reproduce, does-the-fix-break-something-else.
+   sources itself and defaults to "refuted" on any concrete hole. Their
+   number follows the stakes, since each skeptic costs a full agent run: one
+   skeptic holding several lenses for a reversible or routine decision, two
+   or three with distinct lenses (correctness, an alternate mechanism,
+   does-it-reproduce, does-the-fix-break-something-else) when it is
+   expensive or hard to undo. Brief each with the exact claims, files and
+   docs to check, read-only, and an answer cap of one line per claim, so it
+   checks instead of exploring. A fact one command or one doc page settles
+   is checked by you, not by a skeptic.
 3. **Synthesis.** Fold every surviving objection back into a refined thesis. A
    skeptic that found a real hole replaces or corrects the thesis; a skeptic
    that failed to refute raises confidence.
@@ -47,7 +55,7 @@ asking; ask only when an operator-only fact blocks the conclusion.
 
 - Executed evidence beats reasoning: run it, exec into it, read the log. A
   thesis backed only by static reasoning caps in the low nineties.
-- The antithesis MUST be independent — never let the thesis-author be its own
+- The antithesis MUST be independent: never let the thesis-author be its own
   sole skeptic.
 - Diversity over redundancy: skeptics with different lenses catch failure modes
   identical skeptics miss.

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.

skills/kvb-think-gaps/SKILL.md

@@ -2,47 +2,48 @@
 name: kvb-think-gaps
 description: >
   Find and rank missing work (structural flaws, missing features); each pick
-  goes to kvb-create-requirement. Trigger on /kvb-think-gaps, "was fehlt
-  noch", or asked what to build next.
+  goes to kvb-create-requirement. Trigger on "was fehlt noch" or when asked
+  what to build next.
 ---
 
-Two blind spots produce different work: the code has defects of structure,
-the product has gaps of use. This skill runs both lenses, ranks what comes
-out, and lets the operator choose. It writes no file; the
-`kvb-create-requirement` skill writes the requirement for every pick.
+The code has defects of structure, the product has gaps of use. This skill
+runs both lenses, ranks the result and lets the operator choose. It writes no
+file; the `kvb-create-requirement` skill writes the requirement for every
+pick.
 
 ## Step 1: fix the scope
 
-Name the target in one line: repository, subsystem, role, or user-facing
+Name the target in one line: repository, subsystem, role or user-facing
 surface. Read the project's existing requirement documents first; an
-already-written requirement is not a finding.
+already-written requirement is not a finding. Explore through the
+codebase-memory-mcp graph first (`search_graph`, `trace_path`,
+`get_architecture`, `detect_changes`; the `kvb-agent-optimize` skill sets it
+up), grep and read after.
 
 ## Step 2: the principles pass
 
-Invoke the `kvb-check-principles` skill on the target. Its findings become requirement
-candidates by severity: a violated SPOT, SRP, or trust boundary is work the
-product needs whether or not a user ever notices. Carry each finding's
-`file:line` evidence forward — a requirement without it is a guess.
+Invoke the `kvb-check-principles` skill on the target. Its findings become
+requirement candidates by severity: a violated SPOT, SRP or trust boundary is
+work the product needs whether or not a user notices. Carry each finding's
+`file:line` forward; a requirement without it is a guess.
 
 ## Step 3: the usability pass
 
-Independently, look for what the product does not do yet. Anchor every gap
-in something observable in the repository, never in an invented persona:
+Independently, look for what the product does not do yet. Anchor every gap in
+something observable in the repository, never in an invented persona:
 
-- **Entry** — can someone install, configure, and run it without reading the
-  source? Missing `--help`, missing example config, an undocumented required
-  variable.
-- **Recovery** — does a failure tell the user what to do next? Errors that
-  print a stack trace instead of the remediation, no dry-run, no way to undo
-  or uninstall, no idempotent re-run.
-- **Feedback** — does a long operation say anything while it works? Silent
-  minutes, no progress, no exit summary.
-- **Empty and edge states** — first run with no data, zero results, an
-  expired credential, a partially completed run.
-- **Discoverability** — a capability that exists but nothing surfaces:
-  undocumented flags, features reachable only by reading tests.
-- **Accessibility and locale** — output that assumes colour, a terminal
-  width, or one language.
+- **Entry**: install, configure and run without reading the source? Missing
+  `--help`, example config, an undocumented required variable.
+- **Recovery**: does a failure say what to do next? A stack trace instead of
+  the remediation, no dry-run, no undo or uninstall, no idempotent re-run.
+- **Feedback**: does a long operation report while it works? Silent minutes,
+  no progress, no exit summary.
+- **Empty and edge states**: first run with no data, zero results, an expired
+  credential, a partially completed run.
+- **Discoverability**: a capability nothing surfaces: undocumented flags,
+  features reachable only by reading tests.
+- **Accessibility and locale**: output that assumes colour, a terminal width
+  or one language.
 
 Each gap gets one line: `observed evidence -> who is blocked -> smallest
 change that unblocks them`. Drop anything you cannot anchor.
@@ -53,32 +54,30 @@ Merge both lists, drop duplicates where a structural finding and a usability
 gap describe the same defect, and rank by blocked users first, blast radius
 second.
 
-Then apply `kvb-think-listen`: answer everything you can from the code, the
-docs, and the git history yourself, and put only the genuinely open decisions
-to the operator with `AskUserQuestion`, `multiSelect: false`, so every
-question renders as radio buttons. At most four questions per call, each
-option a real alternative — never one option plus filler:
+Then apply `kvb-think-listen`: answer what you can from the code, docs and
+git history yourself, and put only the genuinely open decisions to the
+operator with `AskUserQuestion`, `multiSelect: false` (radio buttons), at most
+four questions per call, each option a real alternative, never one option
+plus filler:
 
 1. **Which candidates** become requirements this run, ranked, each option
    carrying its evidence in the description.
-2. **Which shape** the chosen one takes — for a feature typically
-   `Minimal version that unblocks the user`, `Full version`, `Fix the
-   underlying structure instead`, `Document the limitation and defer`.
+2. **Which shape** the chosen one takes; for a feature typically `Minimal
+   version that unblocks the user`, `Full version`, `Fix the underlying
+   structure instead`, `Document the limitation and defer`.
 
 Never assume an answer and never fold two decisions into one option.
 
 ## Step 5: hand over
 
-Run the `kvb-create-requirement` skill once per chosen candidate. Its
-context step starts from the candidate's evidence and chosen shape; the
-rejected shapes go into its Decisions section.
+Run the `kvb-create-requirement` skill once per chosen candidate. Its context
+step starts from the candidate's evidence and chosen shape; the rejected
+shapes go into its Decisions section.
 
 ## Rules
 
-- Findings only: no file, no implementation, no refactor, no staging as
-  part of this skill.
-- Every candidate traces to evidence — a `file:line`, a failing path, a
-  missing artifact. A candidate whose justification is "would be nice" is
-  dropped.
-- Close with the `kvb-check-confidence` skill's numbers for the analysis: how sure the
-  gaps are real, and what the passes did not cover.
+- Findings only: no file, implementation, refactor or staging in this skill.
+- Every candidate traces to evidence: a `file:line`, a failing path, a
+  missing artifact. "Would be nice" is dropped.
+- Close with the `kvb-check-confidence` skill's numbers for the analysis: how
+  sure the gaps are real, and what the passes did not cover.

skills/kvb-think-listen/SKILL.md

@@ -19,12 +19,12 @@ the task, its constraints, and its definition of done without guessing.
    answer yourself from the code, the logs, the git history, or a sensible
    default. Active listening is not offloading your own investigation onto the
    operator.
-3. **Ask, focused.** Put the genuinely-open questions to the operator — grouped,
+3. **Ask, focused.** Put the genuinely-open questions to the operator: grouped,
    concrete, answerable, with a recommended default where one exists. Prefer a
    few high-leverage questions over a long interrogation. Use the host's
    structured question mechanism when one exists.
-4. **Listen and integrate.** Fold each answer in. A new answer often opens a new
-   question — keep going.
+4. **Listen and integrate.** Fold each answer in; a new answer often opens a
+   new question.
 5. **Loop until closed.** Repeat until no needed information is still open.
 6. **Reflect back.** Restate the task, its constraints, and its definition of
    done in your own words for a final confirmation before acting.

skills/kvb-transcend/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: kvb-transcend
 description: >
-  Run both transcend skills in one pass. Trigger on /kvb-transcend.
+  Run both transcend skills in one pass.
 ---
 
 Collector for the `kvb-skill-transcend` and `kvb-code-transcend` skills, so

tests/test_lock.py

@@ -75,6 +75,13 @@ class TestSkillsLock(unittest.TestCase):
                 self.assertLessEqual(words, budget.DESCRIPTION_WORDS)
         self.assertLessEqual(sum(found.values()), budget.LISTING_WORDS)
 
+    def test_skill_files_fit_the_word_cap(self):
+        for name, words in budget.skill_sizes(REPO_ROOT).items():
+            with self.subTest(skill=name):
+                self.assertLessEqual(
+                    words, budget.SKILL_WORDS, "move details into a side file the skill reads on demand"
+                )
+
     def test_budget_script_reports_the_total_and_the_longest(self):
         result = subprocess.run(
             [sys.executable, str(BUDGET), "--repo", str(REPO_ROOT), "--top", "3"],

tests/test_naming.py

@@ -52,6 +52,16 @@ class TestSkillNames(unittest.TestCase):
             with self.subTest(skill=name):
                 self.assertRegex(name, SCHEMA)
 
+    def test_skill_md_never_names_its_own_slash_command(self):
+        for name in self.names:
+            own = re.compile(rf"(?<![\w./~-])/{re.escape(name)}(?![\w/-])")
+            text = (SKILLS / name / "SKILL.md").read_text(encoding="utf-8")
+            with self.subTest(skill=name):
+                self.assertEqual(
+                    [n for n, line in enumerate(text.splitlines(), 1) if own.search(line)], [],
+                    f"/{name} is implied by the name; it only costs listing and context tokens",
+                )
+
     def test_every_category_and_exception_is_in_use(self):
         for category in CATEGORIES:
             with self.subTest(category=category):