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
+  and lean agent instructions; kvb-optimize runs it.
-  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
+instead of parking it, and keep answering the operator. Reply through the
-in one line, `relaxed: <what still runs>`. Waking up is 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
+5. **Reply** to the sender in one line, `asleep: <handover path>`, by
-   turn. Offices stay claimed and register rows unchanged.
+   `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
+4. Check `council.py list`, `news.py show` and the default branch instead of
-   state: messages held overnight beyond 100 were dropped.
+   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
+touch: not the inverse of fix confidence, not a mood. Derive it by the steps
-by the steps below; a number produced without them is a guess wearing a
+below; without them a number is a guess.
-percent sign.
 
 ## 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
+1. **Fix confidence** (percent): probability the change does what it claims.
-reports the number it derives and never estimates one itself.
+   **Break risk** (percent): probability it breaks anything else, from the
-
+   `kvb-check-break-risk` skill. Two numbers, never one blended figure.
-1. **Fix confidence** (percent): probability the change does what it
+2. **Evidence**: the strongest proof lines only: what was executed,
-   claims. **Break risk** (percent): probability it breaks anything else,
+   reproduced, enumerated, or read from an authoritative source. Mark proven
-   derived via the `kvb-check-break-risk` skill. Two separate numbers, never one
+   (ran it, saw it) apart from derived (reasoned statically).
-   blended figure.
+3. **Residuals**: exactly what keeps the number below 100 and what would
-2. **Evidence**: the strongest proof lines only — what was executed,
+   close the gap (live deploy, missing artifact, unexercised path). Never a
-   reproduced, enumerated, or read from authoritative source. Distinguish
+   bare percentage without its residuals.
-   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.
 
 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
+Objective: the `kvb-skill-tune` skill's **Objective** section. Two figures
-hedging paragraph and save the operator a verification round trip.
+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
+report says so in one line. Leaked secrets belong to `kvb-check-security`,
-principles to `kvb-check-principles`.
+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.
+- A `<ref>` or `<a>..<b>` after the command: that commit or range.
-- `/kvb-check-legal` alone: the index if it is non-empty, else `HEAD`.
+- 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
+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
+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,
+seven checks.
-attribution, copied snippets, data protection, trademarks).
 
 ## Severity
 
-- **Blocker** - the commit would distribute what the project may not
+- **Blocker**: the commit would distribute what the project may not: an
-  distribute: an incompatible inbound or dependency licence, or non-trivial
+  incompatible inbound or dependency licence, or non-trivial code or assets
-  code or assets without a licence.
+  without a licence.
-- **Finding** - fixable while keeping the change: missing attribution, NOTICE,
+- **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
+Harden every blocker with the `kvb-think-dialectic` skill before reporting
-antithesis tries: the code is trivial or the operator's own; the dependency is
+it. The antithesis tries: the code is trivial or the operator's own; the
-build- or test-only and never distributed; an exception applies (linking or
+dependency is build- or test-only and never distributed; an exception applies
-Classpath exception, dual licensing, a licence grant in the issue or commit
+(linking or Classpath exception, dual licensing, a licence grant in the issue
-history). A blocker that survives stops the commit: present it with the
+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
+proceed and never carries over. Findings and notes never stop a commit.
-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
+  repository, path or diff. Trigger on "sei skeptisch", "kritische
-  skeptisch", "kritische analyse", or "review the architecture".
+  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 —
+bloat (`ponytail-audit`) or leaked secrets (`kvb-check-security`). Read-only:
-report the findings, change nothing unless the operator asks afterwards.
+report, change nothing unless the operator asks afterwards.
 
 ## Scope
 
-The operator names the target: a repository, a directory, a role, or a diff.
+The operator names the target: a repository, directory, role or diff.
-Without a target, take the whole repository and rank by blast radius. State
+Without one, take the whole repository and rank by blast radius. State the
-the scope in one line before reporting, and name explicitly what you did not
+scope in one line and name what you did not read; a silent half-audit reads
-read — an audit that silently covered half the tree reads as clean.
+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
+1. **SPOT**: one truth, one place. A value, version, hostname, schema or list
-   schema, a list of names that exists twice is a divergence waiting to
+   of names that exists twice will diverge. Name both locations and the
-   happen. Name both locations and the drift they will cause.
+   drift.
-2. **DRY** — repeated *knowledge*, not repeated text. Two blocks that look
+2. **DRY**: repeated *knowledge*, not text. Look-alike blocks that change for
-   alike but change for different reasons are correctly separate; merging
+   different reasons are correctly separate; merging them is the violation.
-   them is the violation. Prove the shared reason to change, or drop the
+   Prove the shared reason to change, or drop the finding.
-   finding.
+3. **SRP**: one reason to change per unit: the module that parses and
-3. **SRP** — one reason to change per unit. Look for the module that both
+   persists, the function named "x and y", the role that configures, deploys
-   parses and persists, the function whose name contains "and", the role
+   and monitors. Name the two stakeholders who would each demand a change.
-   that configures and deploys and monitors. The test: name the two
+4. **KISS**: mechanism nobody asked for: an abstraction with one
-   stakeholders who would each demand a change here.
+   implementation, a config value that never varies, a cache with no measured
-4. **KISS** — mechanism the problem never asked for: an abstraction with one
+   pressure, a retry loop around a deterministic call.
-   implementation, a config value that never varies, a cache with no
+5. **Security**, only at trust boundaries: unvalidated input reaching a
-   measured pressure, a retry loop around a deterministic call.
+   query, shell, template or path; authorization checked in the caller
-5. **Security** — only at trust boundaries: unvalidated input crossing into
+   instead of the resource; a secret in a default, log or image layer; a
-   a query, a shell, a template, or a path; authorization checked in the
+   permission wider than the operation needs. Defensive findings only.
-   caller instead of the resource; a secret in a default, a log, or an
+6. **Silent defaults**: a fallback substituting a guess for a value the
-   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
    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
+- **Graph first**: explore through the codebase-memory-mcp graph
-  read. Grep for the sibling occurrences before calling something a
+  (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`; the
-  duplicate — one hit is not a pattern.
+  `kvb-agent-optimize` skill sets it up), grep and read after.
-- **Name the failure.** A finding must state what concretely goes wrong:
+- **Evidence before verdict**: every finding carries a `file:line` you read.
-  which value drifts, which caller breaks, which input reaches which sink.
+  Grep the sibling occurrences before calling something a duplicate; one hit
-  A finding whose worst case is "feels wrong" gets deleted, not softened.
+  is not a pattern.
-- **Attack your own finding.** For anything consequential or expensive to
+- **Name the failure**: which value drifts, which caller breaks, which input
-  fix, run it through the `kvb-think-dialectic` skill before reporting it — the
+  reaches which sink. A finding whose worst case is "feels wrong" is deleted,
-  strongest counter-argument is usually "these two are not the same
+  not softened.
-  knowledge" or "this boundary is already checked upstream".
+- **Attack your own finding**: run anything consequential or expensive to fix
-- **Respect intent.** A deliberate marker (`ponytail:`, a documented
+  through the `kvb-think-dialectic` skill before reporting it; the strongest
-  exception, a nocheck directive with a reason) is a known ceiling, not a
+  counter is usually "not the same knowledge" or "already checked upstream".
-  finding. Report it only when the ceiling has since been exceeded.
+  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
+Then at most three lines: what the scope excluded, which findings survived
-survived `kvb-think-dialectic` versus which are still derived-only, and the single
+`kvb-think-dialectic` and which are still derived-only, and the one to fix
-finding to fix first. No per-finding paragraphs — the operator asks when a
+first. No per-finding paragraphs; the operator asks when a row needs it.
-row needs unpacking.
 
 ## Rules
 
-- Never report formatting, naming taste, or missing comments; a linter owns
+- Never report formatting, naming taste or missing comments.
-  those and the operator did not ask.
+- Mark each finding proven (grepped, read, reproduced) or derived (reasoned
-- Distinguish proven (grepped, read, reproduced) from derived (reasoned
+  statically), and close with the `kvb-check-confidence` skill's numbers for
-  statically) per finding, and close with the `kvb-check-confidence` skill's numbers
+  the audit.
-  for the audit as a whole.
 - 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
+- Skepticism ends at the report: no fix, stage or refactor in this skill.
-  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
+  security scans, vetting a repo, leaked secrets in chat or shell history.
-  /kvb-check-security. Defensive only.
+  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
+  Trigger on a request to keep monitoring and fix regressions.
-  regressions.
 ---
 
-Keep a target under continuous watch and act only when it degrades. The loop is
+Keep a target under watch and act only when it degrades: the loop watches,
-the watcher; triage is the response. Do not re-investigate failures already
+triage responds. Never re-investigate a failure already resolved this
-resolved this session, and do not idle-poll work the harness will notify you
+session, and never poll work the harness will notify you about.
-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
+branch's checks, a build, or a log file. Restate it in one line and record
-current failure set as the baseline (the failures already known or already
+the current failure set (known or already fixed this session) as the
-fixed this session). Everything the watch reports is diffed against that
+baseline. Every observation is diffed against it; a stale baseline
-baseline, so a stale baseline re-triages solved failures.
+re-triages solved failures.
 
 ## The loop
 
-Drive this with `/loop` in dynamic mode (no fixed interval unless the operator
+Drive it with `/loop` in dynamic mode (no fixed interval unless the operator
-gave one): after each observation, schedule the next wake-up yourself and pass
+gave one): after each observation, schedule the next wake-up and pass this
-the same `/kvb-ci-observe` prompt back so the next firing repeats the watch.
+skill's prompt back unchanged.
 
-1. **Poll the target.** Pull its current state (job list, check conclusions, the
+1. **Poll the target**: its job list, check conclusions or log tail; for a
-   log's tail); for a GitHub Actions run, the kvb-ci-artifacts skill's
+   GitHub Actions run, the `kvb-ci-artifacts` skill's `ci_failures.py <run>`.
-   `ci_failures.py <run>`. Enumerate the failures exactly as the `kvb-ci-triage` skill's step 1
+   Enumerate failures as the `kvb-ci-triage` skill's step 1 does: failure,
-   does: failure, cancelled, timed-out; a downstream aggregate that fails only
+   cancelled, timed-out; a downstream aggregate that fails only because an
-   because an upstream did is not its own failure.
+   upstream did is not its own failure.
-2. **Diff against the baseline.** A failure is *new* only if it is not in the
+2. **Diff against the baseline.** A failure is new only if it is neither in
-   baseline and was not already triaged this session. If nothing is new, log one
+   the baseline nor triaged this session. Nothing new: log one short line
-   short line ("still green" / "N known failures, no change") and reschedule.
+   ("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 —
+3. **Triage each new failure** with the `kvb-ci-triage` skill on the new set
-   which applies `kvb-think-dialectic` per failing job to a ~99% root cause and a real
+   only; it applies `kvb-think-dialectic` per failing job to a ~99% root
-   fix. Never mask (no retry-until-pass, no disabled check, no soft-skip). Fold
+   cause and a real fix. Never mask (no retry-until-pass, disabled check or
-   each newly fixed failure into the baseline so it is not re-triaged.
+   soft skip). A new failure and its verdict go to peers as news, never as a
-4. **Reschedule.** Pick the next delay from what you are waiting on: an active
+   message: `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post
-   run that changes every few minutes gets a check matched to its cadence; a
+   "<target>: <job> <failing line> -> <verdict>"`. Fold each newly fixed
-   quiet or long-running target gets a long fallback (1200s+). Keep watching
+   failure into the baseline.
-   until the target reaches a terminal state (run completed, pipeline finished)
+4. **Reschedule** by what you wait on: an active run that changes every few
-   AND every failure it produced has a verified fix, then stop the loop.
+   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
+- The loop is a fallback timer, not a busy-wait: for tracked work the
-  when tracked work finishes (a background task, a spawned agent), wait for that
+  harness reports (a background task, a spawned agent), wait for that
-  notification instead of polling for it; reserve the timed wake-up for external
+  notification; reserve the timed wake-up for state the harness cannot see
-  state the harness cannot see (a remote CI run, a deploy queue).
+  (a remote CI run, a deploy queue).
-- Executed evidence beats reasoning: read the actual failing log line and the
+- Executed evidence beats reasoning: read the failing log line and the
-  artifact, not the job title — kvb-ci-triage and kvb-think-dialectic carry this through.
+  artifact, not the job title.
-- One baseline, updated in place: dedup every observation against all failures
+- One baseline, updated in place: dedup every observation against all
-  seen so far, or a flaky-then-fixed failure reappears every cycle and the watch
+  failures seen so far, or a flaky-then-fixed failure reappears every cycle
-  never converges.
+  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
+Drive a red pipeline green by root cause. Every failing job is its own
-failing job as its own investigation, and do not declare a fix until that job's
+investigation; no fix before its root cause is proven. For GitHub Actions,
-root cause is proven.
+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>`
+0. **Run against HEAD, first**: `git log --oneline <run-sha>..HEAD | wc -l`.
-does the mechanics of steps 0 to 2 in one call: distance to HEAD, the failed
+   Zero: the run speaks for the current tree. Otherwise read `stale-run.md`
-jobs' logs, and a first clustering. The judgement in those steps stays yours.
+   next to this file before anything else.
-
+1. **Enumerate** every job that failed, was cancelled or timed out. An
-0. **Check the run against HEAD before anything else.** A CI run is a snapshot
+   aggregate job failing only because an upstream one did is noted, not a
-   of one commit, and the branch has moved since. Run
+   root cause.
-   `git log --oneline <run-sha>..HEAD | wc -l` as the first command of the
+2. **Cluster** by the actual failing line, not the job name; messages that
-   triage. Zero means the run speaks for the current tree and you proceed.
+   differ beyond interpolated identifiers (host, app, port, path) are
-   Non-zero means it does not, and you scope the job set down **before**
+   separate clusters.
-   enumerating, clustering, or spawning anything — every job you investigate
+3. **Coordinate** each cluster via the `kvb-org-organize` Peer protocol,
-   against stale code is work thrown away, and a fix proposed there risks
+   lineage included: claim it; read `council.py list`, the register, the news
-   reverting someone else's. Two cheap discriminators do it without opening an
+   and `find_fix.py`; then ask every live peer for known fixes, one batched
-   artifact: `git diff --name-only <run-sha>..HEAD -- <source dir> | cut -d/ -f2 | sort -u`
+   `SendMessage` per peer for all clusters nothing there answers. Investigate
-   for which components already moved, and a grep of the saved job logs for the
+   while waiting; take their fix or keep yours. Register (`kvb-org-rasci`):
-   literal error signature of each cause already fixed in that range. What
+   objective the root cause fixed, one key result per failing job passing.
-   survives both is the job set the rest of this procedure applies to; say how
+4. **Artifacts** per cluster (the `kvb-ci-artifacts` skill: in-progress
-   many jobs you dropped and why.
+   logs, which bundle, grep hygiene): every artifact of one representative
-1. **Enumerate every failing job.** Pull the run's job list and isolate each job
+   job (reports, rescue diagnostics, inventories, container logs); a second
-   whose conclusion is failure, cancelled, or timed-out. A downstream aggregate
+   member's only when the first leaves part of the cluster unexplained. Pull
-   job that fails only because an upstream job did is not a separate root cause —
+   them even when the log looks conclusive: it only names the artifact; the
-   note it and move on.
+   assertion, server-side exception and state dumps are inside.
-2. **Cluster the failures by error message.** Group the failing jobs by their
+5. **One funnel per cluster** via the `kvb-org-split` skill: one agent per
-   actual failing line, not by job name. Jobs whose messages differ in anything
+   claimed cluster, its own worktree and branch from the exact current HEAD,
-   but the interpolated identifiers (host, app, port, path) belong in separate
+   that cluster its only concern, worked as `funnel.md` next to this file
-   clusters.
+   says (dialectic, shared vs hidden causes, root fix); read it before
-3. **Coordinate every cluster.** Run the `kvb-org-organize` skill's Lineage and Peer
+   working one yourself. Spawn only as many as the stakes justify; each
-   protocol for each cluster before fixing it: claim it, ask the lineage
+   brief names that file, the failing line, artifact paths, files and the
-   whether someone already fixes it, and take their fix or keep yours. Keep
+   claim to prove or refute, a time cap for the interim report and an answer
-   investigating while you wait for answers. In the `kvb-org-rasci` register
+   cap (verdict table, at most 15 lines). Parallel only when the fixes touch
-   the cluster's objective is the root cause fixed, its key results are the
+   different files and the machine has room.
-   failing jobs passing again, one per job.
+6. **Timeouts**: only for a cluster whose jobs died on their time budget, or
-4. **Download artifacts per cluster.** Use the `kvb-ci-artifacts` skill for the
+   on operator request, hand the furthest-running job log to `kvb-code-tune`;
-   mechanics — it covers per-job logs while a run is still in progress, which
+   its candidates get funnels of their own and never delay the fix.
-   bundle to pull, and the grep hygiene that keeps a false positive from
+7. **Follow** a run still in progress and triage each newly failed job; done
-   becoming a root cause. For each cluster, fetch every artifact of
+   when the run finished and every failure has a verified fix.
-   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.
 
 ## Rules
 
-- Executed evidence beats reasoning: read the actual failing log line and the
+- Explore code through the codebase-memory-mcp graph first (`search_graph`,
-  artifact, not the job title.
+  `trace_path`, `get_architecture`, `detect_changes`; the
-- A derived source is not evidence. A conversation summary, your own earlier
+  `kvb-agent-optimize` skill sets it up), grep and read after.
-  message, a cluster table you built ten minutes ago, or a subagent's report
+- Only the job log, the artifact, the code at the run's commit and command
-  proves nothing on its own. Only the job log, the artifact, the code at the
+  output you just ran count as evidence, quoted literally; a summary, your
-  run's commit, and command output you just ran count. Quote them literally; if
+  earlier message, an old cluster table or a subagent's report proves
-  you cannot quote it, you do not know it.
+  nothing. After a context compaction, rebuild every attribution from the job
-- Re-derive after a context compaction. A summary carried across a compaction
+  logs before acting on it.
-  boundary preserves your conclusions but not the evidence under them, and a
+- Classify each failure: real defect (fix), flake or infra (prove it
-  cluster assignment that was wrong stays wrong while reading as settled fact.
+  transient first), or fixed by a later commit (compare `<run-sha>..HEAD`,
-  Before acting on any pre-compaction attribution, rebuild it from the job logs.
+  never the run's commit alone; name the fixing commit).
-- Classify each failure: a real defect (fix it), a flake or infra hiccup (prove
+- Per job verdict: root cause, the proving artifact path and line, the fix,
-  it is transient before dismissing), or already-fixed-by-a-later-commit. For
+  the sidetree branch, the funnel verdict (merged or proposal). A verdict
-  that last class the comparison is `<run-sha>..HEAD`, never the run's commit
+  citing only the job log has not finished step 4.
-  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.

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
+Delete only what the operator picked in this run; questions, inventory and
-its owner, its size, and its risk.
+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
+Shared resources belong to the `kvb-org-organize` chair; its resource watch
-another session holds the chair, send it the cleanup request and stop, unless
+already runs the configured low-risk cleanup. Another session chairs: send it
-the operator ordered the cleanup in this session; then tell the chair before
+the request and stop, or, when the operator ordered the cleanup here, first
-step 1, so its grants and queue stay consistent. The `kvb-org-organize` resource
+`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post --to <chair>
-watch already runs the configured low-risk cleanup at its stop threshold; this
+"<plan>"`.
-skill covers everything that needs the operator's pick.
 
-## Step 1: ask the peers
+## Step 1: inventory
 
-List every agent the host can message (in Claude Code: `ListAgents`). Only
+Read-only, in parallel, with sizes, only in the agent write scope (Claude
-peers sharing this machine's filesystem and Docker daemon count: local
+Code: `sandbox.filesystem.allowWrite`) and session scratch dirs, even where
-sessions and your own subagents. Cloud sessions and remote sessions on other
+more is readable; never another user's files. Prefer the project's cleanup
-machines hold nothing here; skip them.
+and teardown targets; obey rules forbidding raw commands.
 
-Send each local peer one message (`SendMessage`) and go on with step 2 while
+- **/tmp**: `du -sh` per own top-level entry; system entries (`.X11-unix`,
-they answer:
+  `.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
+## Step 2: ask the owners
-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: 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
+First match wins: claimed by a peer, `keep`; in a register task not `done`,
-  sandbox or permission config (in Claude Code:
+`stopped` or `stale`, `keep (task <task>)` (an ended task's items are its
-  `sandbox.filesystem.allowWrite` in `.claude/settings.json`) plus the session
+worker's candidates); a running deploy, gate, test, swarm run or build, `keep
-  scratch dirs. Anything outside is out of scope, even when readable.
+(running)`; a silent peer's, `keep (no answer from <peer>)`, silence is not
-- **/tmp**: `du -sh` per top-level entry the current user owns. System entries
+consent; sandboxed, anything touched within 24 hours (`find -mtime +0` lists
-  (`.X11-unix`, `.ICE-unix`, `systemd-private-*`, `ssh-*`, `tmux-*`, sockets)
+the older), `keep (recent, possibly in use)`; archive duty,
-  are never candidates.
+`archive first`, never a plain delete. Else a candidate:
-- **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.
 
-Prefer the project's own cleanup and teardown targets (Makefile, scripts) over
+- **low**, regenerated cheaply: stopped containers without volumes, dangling
-raw commands where they exist, and obey project rules that forbid raw
+  images, unused networks, finished sessions' scratch and logs.
-commands.
+- **medium**, regenerated slowly, rate-limited or networked: unused tagged
-
+  images, build cache, package caches, clean worktrees already merged.
-## Step 3: attribute
+- **high**, data loss or a broken run: volumes, stopped containers with
-
+  volumes, running unclaimed containers or stacks, dirty or unpushed
-Give every candidate an owner: a peer's reply, a session id in the path, a
+  worktrees, unread reports, anything `unknown`.
-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` |
 
 ## 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 |
+1. `multiSelect: true`, at most four questions: `/tmp`, `Docker`, `Other
-
+   dirs`, `High risk` (every high-risk candidate); size, risk and worst case
-Below it: reclaimable size per risk class, and every `keep` row grouped by
+   in each option's description. Over four options: group by owner or risk,
-reason, so the operator sees what was protected and why.
+   or call again. Only ticks select; nothing preselected.
-
+2. `multiSelect: false`: `Execute: <n> items, <size> (Recommended)` naming
-Then ask with `AskUserQuestion` in two calls.
+   the ticked items' worst case, `Revise the selection` (repeats 1), `Abort`.
-
-**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`.
 
 ## Step 5: execute
 
-- Re-check claims, open handles and running state right before each delete: a
+After `Execute`, read `execute.md` next to this file first.
-  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.
 
 ## 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
+skipped or failed item with its reason. `news.py post --to <peer>` tells each
-the removed items lay near its own.
+answering peer which 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.

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

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
+A default is a guess written where the caller's intent is least known: it
-least known, and it turns a missing value into a plausible wrong answer instead
+turns a missing value into a plausible wrong answer instead of an error, and
-of an error. Two callers then read the same call differently: one means "use the
+two callers read the same call differently (one means "use the default", the
-default", the other simply forgot. That ambiguity is the defect this rule exists
+other forgot). Never write a substantive default: require the value, and when
-to prevent.
+it is absent fail immediately, loudly, naming the missing thing.
-
-Never write a substantive default. Require the value. When it is absent, fail
-immediately, loudly, and with a message that names 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
+2. A missing value MUST abort at the earliest moment (argument parsing,
-   parsing, config load, container start — never at the point of use, and never
+   config load, container start), never at the point of use and never by
-   by proceeding with a substitute.
+   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
+4. Genuine optionality MUST be an explicit named case the call site handles,
-   explicit named case that the call site handles, never as a silent
+   never a silent substitution: `None`/`null` in a visible branch is fine, a
-   substitution. `None`/`null` handled in a visible branch is fine; a fallback
+   fallback baked into the accessor is not.
-   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
+`false`, `null` (`None`, `nil`, `undefined`) and `""` MAY be defaults without
-used as defaults without justification. They are the one class that carries no
+justification: they denote absence itself, not a guessed value. `${VAR:-}`,
-guess: they denote absence itself rather than inventing a value the caller might
+`d.get(k)`, `a ?? null` and `def f(a=None)` are fine.
-have meant. `${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
+Every other default (a number, a non-empty string, list or map, an enum
-map, an enum member, a path, a timeout, a retry count — MUST carry an inline
+member, a path, a timeout, a retry count) MUST carry an inline comment saying
-comment stating why that specific value is correct for every caller that omits
+why that specific value is right for every caller that omits it; no comment,
-it. No comment, no default. Use whatever exception-comment form the project
+no default. Use the project's sanctioned exception-comment form, else a plain
-sanctions; where none exists, a plain comment on or directly above the default.
+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
+"Sensible", "standard", "usual", "it is conventional", "every other project
-can disagree with it. "Sensible", "standard", and "usual" name nothing — if the
+does it", "the value is obvious" and "it keeps the signature short" justify
-justification does not survive being written down, the default does not survive
+nothing: they assert someone else made the choice. A valid justification
-either.
+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
-## Banned constructs, by language
+it without a comment.
-
-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 |
 
 ## How to apply
 
-Before writing any parameter, ask: what happens if the caller omits it? If the
+- Before writing any parameter, ask what happens if the caller omits it;
-answer is anything other than "it fails and says so", rewrite it.
+  anything but "it fails and says so" gets rewritten.
-
+- While editing, treat every `default`, `?:`, `??`, `||`, `:-`, `:=`, `or`,
-While editing, treat every `default`, `?:`, `??`, `||`, `:-`, `:=`, `or`,
+  `fallback` and `getOrElse` in a value-resolution position as a finding
-`fallback`, and `getOrElse` in a value-resolution position as a finding unless
+  unless its substitute is `false`, `null` or `""` or a comment justifies it.
-its substitute is `false`, `null` or `""`, or a comment already justifies it.
+  Grep your own diff for them before presenting 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 not a fix: a caller that passes a constant it
+- Pushing a default one layer up is no fix: a caller passing a constant it
-invented has only moved the guess. Follow the value to its true owner —
+  invented only moved the guess. Follow the value to its true owner (the
-the operator, the inventory, the deployment config — and require it there.
+  operator, the inventory, the deployment config) and require it there.
-
+- Removing an existing default is a behaviour change, never a silent
-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
-drive-by: name it, and let the operator decide whether it lands in this change
+  change or its own.
-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.
 
 ## Penalty
 
-If this audit finds an unjustified default you wrote yourself: say so in the
+An unjustified default you wrote yourself: say so in the report with file and
-report, with file and count and no excuses; lower the confidence numbers for the affected
+count and no excuses, lower the confidence numbers for the affected bundle,
-bundle; and write the incident to persistent agent memory, recording the date
+and write the incident with the date and the construct you reached for to
-and the construct you reached for, so the calibration survives the session.
+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,
+  changing behaviour. Trigger when asked to clean up, tidy or polish the
-  tidy or polish the current changes.
+  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
+stays identical: a refactor that changes what the code does is a bug.
-cleanup.
 
 ## 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
+Never `git stash` or revert a working-tree file to compare: others share this
-git status --porcelain
+tree. Read the committed version with `git show HEAD:<path>` into a temporary
-```
+file.
-
-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.
 
 ## Step 2: get a safety net first
 
-A refactor is only provably behaviour-preserving if something failed before it
+Behaviour stays provable only through a check before and after: tests that
-and passes after it. Before editing, check what covers the change set:
+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
+Light runs (targeted tests, ruff, single lint files) start once `watch.py
-  was already red gets reported, not refactored around.
+admit --kind test-nostack` of the `kvb-org-organize` skill prints `grant`; no
-- **No coverage and the code is testable logic**: write the characterization
+chair request.
-  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.
 
 ## Step 3: refactor each file
 
-Read the whole file first, then apply the standards that the surrounding code
+Read the whole file first; the project's own standards (formatter config,
-and the project's own config already establish (formatter config, linter rules,
+linter rules, existing idioms) outrank generic preference. Find callers,
-existing idioms) over any generic preference of your own.
+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
+Never reformat a region without a substantive fix: cosmetic churn buries the
-  unit that needs an "and" to describe it is two units.
+real change. An architectural problem the change set cannot fix is reported,
-- **SPOT**: every fact - a constant, a path, a schema, a rule - lives in exactly
+not half-done.
-  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.
 
 ## Step 4: keep behaviour provable
 
-- Re-run the step 2 net and require the same green result as the baseline.
+- Re-run the step 2 net; require the baseline's green result.
-- Never fold a bug fix, a feature, or a dependency change into a refactor.
+- Never fold a bug fix, feature or dependency change into a refactor; name a
-  Found a real bug? Name it in the report and leave it for a separate change.
+  found bug in the report for a separate change.
-- Run the cheap checks the project already has for the touched files (formatter,
+- Run the project's cheap checks for the touched files (formatter, linter,
-  linter, the module's own unit tests). Do not start a full suite, a build, or a
+  the module's unit tests). Never start a full suite, build or deploy on your
-  deploy on your own initiative - propose it and let the operator trigger it.
+  own: propose it for the operator to trigger.
-- State plainly what was verified and what was not. An unverified refactor is
+- Report what was verified and what was not, an unverified refactor as
-  reported as unverified.
+  unverified.
 
 ## Step 5: report
 
-One line per file: what changed and why it is safe. Then one line naming what
+One line per file: what changed and why it is safe. Then one line on what was
-was deliberately left alone (architectural findings, bugs, files skipped) and
+deliberately left alone (architectural findings, bugs, skipped files) and the
-the exact command the operator can run to validate. Do not commit unless the
+exact command the operator can run to validate. Commit only when the operator
-operator asked for a commit.
+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
+  until green. Trigger when asked to run or fix the tests.
-  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
+- **No Makefile**: say so in one line, name the runner the project does use
-grep -nE '^test[A-Za-z0-9_.-]*:' Makefile
+  (`pyproject.toml`, `package.json`, `tox.ini`, CI workflow), and ask before
-```
+  running anything.
-
+- **No `test*` target**: report the targets that exist and stop.
-Read the matched rules plus their prerequisites, so the selection list can say
+- **Aggregate target** (recipe only other test targets, e.g.
-what each one actually does (delegated script, container build, sub-targets).
+  `test: test-unit test-integration`): the "run everything" entry; mark it so,
-
+  never expand it silently.
-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.
 
 ## Step 2: offer the selection
 
-Ask with `AskUserQuestion`, `multiSelect: true`, one question. Options are the
+If the operator already named a target, skip this and run it. Otherwise one
-discovered targets, each with a one-line description of what it runs. Order the
+`AskUserQuestion`, `multiSelect: true`: the targets, each with a one-line
-aggregate/full target first and label it as the complete suite.
+description, the aggregate first, labelled as the complete suite. With more
-
+than 4 targets, first print the **complete** list as text, one line per
-The tool takes at most 4 options. With more targets than that:
+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
-- print the **complete** discovered list as text first, one line per target, so
+any listed name. Never silently truncate.
-  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.
 
 ## Step 3: run
 
-Run the selected targets in the order the operator listed them, one `make`
+Before each run, admit it under the `kvb-org-organize` Capacity rules: a
-invocation per target, each as its own command so a failure is attributable:
+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
+Run the selected targets in the operator's order, one `make <target>` per
-make <target>
+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
-Do not add `-k`, do not reorder, do not substitute a faster equivalent. If a
+target unless the operator asked for all: a later suite against a broken build
-target needs a long timeout (container builds, e2e), set it on the Bash call
+produces noise, not information.
-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.
 
 ## Step 4: report
 
-Per target: pass/fail plus the failing test names and the exact error output,
+Per target: pass or fail, the failing test names and the exact error output,
-quoted verbatim. Never paraphrase a failure. Then one line with the exact
+quoted verbatim, never paraphrased. Then one line with the exact command
-command to reproduce the failure alone.
+reproducing the failure alone.
 
-Do not fix what failed unless the operator asks - report first. A request to
+Fix nothing unless asked; report first. A request to make the tests pass, fix
-make the tests pass, fix them, or get the suite green (`/kvb-code-test --fix`) switches
+them or get the suite green (`--fix`) switches to fix mode: read `fix.md`
-to fix mode.
+next to this file before its first iteration.
-
-## 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.

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
+- Run the carried tests as a light run (no Docker, about a minute) after
-  `kvb-org-organize` skill); leave the result uncommitted for the
+  `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
-  `kvb-git-commit-next` skill.
+  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
+  coverage. Trigger on a job hitting its time budget or when asked where
-  asked where time goes.
+  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`
+First run in a session: before measuring, invoke the `kvb-think-listen` skill
-skill before measuring anything, and ask three questions through the host's
+with the questions of `listen.md` next to this file. Keep the answers for the
-structured question mechanism. Offer each as a checklist (multi-select) with
+session, never ask again, work only inside them; a candidate outside them
-suggestions, and allow free text:
+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
-1. **What to examine.** Suggestions: CI wall-clock, deploy duration, gate and
+defaults (10 s floor per run, merge bar the `kvb-org-split` skill's 90 %
-   test runtime, image pulls and build caches, per-item loops and process
+confidence and under 5 % break risk, 60 minutes per delegated agent), ask only
-   spawns, idempotency (work repeated on a second run), network round trips,
+when an operator-only fact blocks.
-   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.
 
 ## 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
+Testing less to shrink the clock is reported as a coverage cut for the
-operator as a coverage cut for them to decide, never applied as a tuning.
+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.
+- Never tune the unmeasured; read numbers from logs, not by eye (`logs.md`
-
+  next to this file for profilers, build logs and gate tables).
-- **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.
 - Stream every run to a log file and compare runs by their logs; never re-run
-  to recover a lost number.
+  for a lost number.
-- **Rank by fixed cost x count.** Measure the per-call fixed cost (one
+- **Rank by fixed cost x count**: one console boot, package-manager call or
-  application console boot, one package-manager call, one container exec) and
+  container exec times how often the run pays it: a 1 s boot paid 28 times
-  multiply by how often the run pays it. A one-second boot paid twenty-eight
+  beats a 60 s download paid once.
-  times is a candidate; a sixty-second download paid once is not.
+- **The baseline is the newest log of the current code**; an older one may
-- **The baseline is the newest log of the current code.** An older log may
+  carry a step since replaced, and a saving against it is fiction.
-  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.
 
 ## Coordinate every cost cluster
 
-A cost cluster is one place the time goes: one step, one hot path, one
+Before investigating a cluster (one step, hot path or repeated call), run the
-repeated call, named by its log line and its number. Before investigating or
+`kvb-org-organize` Peer protocol with every session on this machine, not only
-implementing a cluster, run the `kvb-org-organize` skill's Peer protocol for it with
+the lineage. The first to claim `cluster/<slug>`, `--work` naming its log line
-every agent session on this machine, not only the branch lineage.
+and number, works it (between machines, the earliest announcement); a claim
-
+without a measurement does not count. Its `kvb-org-rasci` key result is
-- **The first to identify a cluster works it.** "First" is the `kvb-org-organize`
+`<step> from <before> to under <after>`, met only by the re-measurement.
-  claim `cluster/<slug>`, whose `--work` names the cluster's log line and
+Someone earlier: post them your measurements and findings
-  number; between machines, the earliest announcement by message time. A
+(`${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/news.py post --to <holder>
-  claim without a measurement does not count. In the `kvb-org-rasci` register
+"<text>"`), take the next cluster, never build a second optimization. A claim
-  the cluster's key result is the measured target (`<step> from <before> to
+ends with its release or the operator's reassignment.
-  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.
 
 ## Always check
 
-Every run examines these two on each measured hot path, whatever the operator
+On each measured hot path, whatever the operator picked, listed in the output
-picked in the first question, and lists the result in the output table, a
+even when clean:
-clean result included:
 
-- **Language and framework**: whether the hot path's language and framework
+- **Language and framework**: the most efficient fit? Time in computation or
-  are the most efficient fit for its work (see Language and framework).
+  inside the framework: read `language.md` next to this file.
-- **Unnecessary recursion**: a recursive function that recomputes the same
+- **Unnecessary recursion**: a hot path recursing or a tool calling itself:
-  subproblem (memoize it or turn it into a loop), recursion that only walks a
+  read `recursion.md` next to this file.
-  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.
 
 ## The loop
 
-1. Measure, and name the single biggest cost with its log line and number.
+1. Measure; name the single biggest cost with its log line and number.
-2. Coordinate the cluster with the other agents; work it only when you
+2. Coordinate it; work it only when you identified it first.
-   identified it first, otherwise hand over your findings and take the next.
+3. Read `candidate.md` next to this file; form one candidate, harden it with
-   Then form one candidate for it, after the branch search and the floor check.
+   the `kvb-think-dialectic` skill, delegate, merge or propose, re-measure.
-3. Harden it with the `kvb-think-dialectic` skill.
+4. Repeat until the next candidate is worth less than the run measuring it.
-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.
 
 ## 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,
+Rejected candidates stay with the reason they fell; proposals carry what would
-coverage cut, outside the session's limits, invalid comparison, made moot by
+close their gap.
-another branch, or cap reached without a measured result. 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
+  Trigger on a request for a plan, breakdown or strategy before work starts.
-  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
+autonomously. A plan of activities instead of objectives cannot be verified,
-verified, and an unverifiable plan cannot be handed to a robot.
+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
+   until scope, constraints, success criteria and the operator-only facts are
-   all pinned, then reflect the understanding back. This is the only point in
+   pinned, then reflect the understanding back. This is the only point in the
-   the run where questions are allowed, so leave nothing open here.
+   run where questions are allowed, so leave nothing open.
-2. **Pin the objective.** State the end state in one sentence, as a condition
+2. **Pin the objective.** The end state in one sentence, as a condition that
-   that is either true or false, never as an activity. Name the command or
+   is true or false, never an activity, with the command or observation that
-   observation that proves it.
+   proves it.
-3. **Inspect before decomposing.** Read the code, config, tests, and history the
+3. **Inspect before decomposing.** Read the code, config, tests and history
-   objective touches. Every plan item must rest on something you have seen, not
+   the objective touches; every item rests on something you have seen, not on
-   on an assumption about how the project works.
+   an assumption. Explore the code through the codebase-memory-mcp graph
-4. **Decompose into sub-objectives.** Each item gets: the outcome it reaches,
+   first (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`;
-   the verification that proves it, and the items it depends on. Split an item
+   the `kvb-agent-optimize` skill sets it up), grep and read after.
-   whenever it needs more than one verification. Order by dependency and mark
+4. **Decompose into sub-objectives.** Each item gets its outcome, the
-   the items that are independent, so they can run in parallel.
+   verification that proves it, and the items it depends on. Split an item
-5. **Resolve the open decisions now.** Any root cause, design choice, or
+   that needs more than one verification. Order by dependency and mark the
-   trade-off the plan rests on gets settled before execution, escalating to the
+   independent items, so they can run in parallel.
-   `kvb-think-dialectic` skill where being wrong is expensive. The robot does not ask, so
+5. **Resolve the open decisions now.** Every root cause, design choice or
-   an unresolved decision becomes a guess at runtime.
+   trade-off the plan rests on is settled before execution, through the
-6. **Record the plan in the register.** Enter the objective in 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,
+   result; mirror the sub-objectives into the harness's todo tracking, one
-   one entry per item, phrased as the outcome. Keep a plan file only when the
+   entry per item, phrased as the outcome. A plan file only when the operator
-   operator asks for one.
+   asks for one.
-7. **Present it and wait.** Show the objective, the ordered sub-objectives with
+7. **Present it and wait.** Show the objective, the ordered sub-objectives
-   their verifications, what is deliberately out of scope, and the assumptions
+   with their verifications, what is deliberately out of scope, and the
-   the plan rests on. Stop here: the plan is the deliverable of this step.
+   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,
+8. **Implement it statically, in full.** On the operator's go, write every
-   config, test, and doc change the plan calls for, across all sub-objectives,
+   code, config, test and doc change the plan calls for, across all
-   before running anything that needs live infrastructure. Verify statically:
+   sub-objectives, before running anything that needs live infrastructure.
-   read the diff, run the linters, the unit tests, and whatever dry-run or
+   Verify statically: read the diff, run the linters, the unit tests, and any
-   syntax check the project offers. This step ends only when the whole plan
+   dry-run or syntax check the project offers. The step ends only when the
-   exists on disk, with no sub-objective left unwritten.
+   whole plan exists on disk.
-9. **Then iterate under `kvb-org-robot`.** With the static implementation complete,
+9. **Then iterate under `kvb-org-robot`.** Invoke the `kvb-org-robot` skill
-   invoke the `kvb-org-robot` skill with the objective as its goal for the dynamic part:
+   with the objective as its goal for the dynamic part: run, deploy, observe,
-   run, deploy, observe, fix, repeat until every verification passes. It drives
+   fix, repeat until every verification passes. It drives the loop without
-   the loop without check-ins, verifies each outcome instead of assuming it, and
+   check-ins, verifies each outcome, and reports the items outside its
-   reports the items that fall outside its clearance for the operator to run.
+   clearance for the operator to run.
 
 ## Rules
 
-- One objective per item, in outcome form: "endpoint returns 200 for an expired
+- One objective per item, in outcome form: "endpoint returns 200 for an
-  token", not "fix the auth middleware".
+  expired token", not "fix the auth middleware".
-- No item without a verification. If you cannot name what proves it, the item is
+- No item without a verification; an item nothing proves is a wish.
-  still a wish, not a plan.
 - Plan only what the request covers. Speculative future-proofing, refactors
-  nobody asked for, and abstractions with one caller belong in the out-of-scope
+  nobody asked for, and abstractions with one caller go to the out-of-scope
-  list, not in the plan.
+  list.
-- Static before dynamic: never start the robot loop on a half-written plan. A
+- 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
+  deploy failing on code not yet written costs a full cycle and proves
-  proves nothing.
+  nothing.
-- Re-plan on contradicted evidence: when execution disproves an assumption the
+- Re-plan on contradicted evidence: when execution disproves an assumption,
-  plan rests on, revise the plan instead of forcing the original steps through.
+  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
+  criteria, tests. Trigger on "requirement schreiben" or a kvb-think-gaps
-  schreiben", or a kvb-think-gaps pick.
+  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
+on `Write it`; lint the file with the project's markdown linter, a light run
-resource chair's grant (the `kvb-org-organize` skill).
+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
+  improvements, kvb-optimize, cleanups. Trigger on a request to learn from
-  to learn from recent work.
+  recent work.
 ---
 
-Sleep on the work: replay what happened, separate what held from what broke,
+Replay what happened, separate what held from what broke, keep only
-keep only the conclusions that survive an attack, then optimize and clean up.
+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.
 
 ## Objective
 
-The dream exists to raise the confidence of every future run until the
+Make the next run measurably less likely to repeat each failure found; what
-mistakes it found cannot happen again. Judge every finding, memory
+changes no future behaviour is not recorded. An error class is closed only by
-entry, and proposal by one question: does it make the next run measurably less
+something structural (test, lint rule, CI check, hook, written rule in the
-likely to repeat this failure? What changes nothing about future behaviour is
+agent instructions, skill), never by "be more careful". Per closed class,
-not worth recording.
+report the confidence the next run can hold, calibrated as the
-
-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
 `kvb-check-confidence` skill requires, and name what is still open.
 
 ## Scope
 
-Every repository and session this agent touched in the window: the
+Every repository and session this agent touched in the window: its
-repositories named by its session transcripts (working directories and
+transcripts' working directories and worktrees, its `kvb-org-rasci` task
-worktrees), by the workdirs of its `kvb-org-rasci` register tasks, and the
+workdirs, the current one. Window: 24 hours, or wider on request (`7d` after
-current one. The default window is the last 24 hours — the operator may widen
+the command). State both in one table first. Recall and score each repository
-it (`/kvb-dream 7d`). State the repositories and the window in one table before
+on its own; a finding goes only into its own project's memory. Run only when
-you start. Each repository is recalled and scored on its own; a finding goes
+the operator asks; read `hints.md` next to this file when a hint appears or
-into the memory of the project it concerns, never mixed with another's.
+before changing the reminder.
-
-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.
 
 ## 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
+- **History**: `git log --since` over all branches plus `--reflog` (resets,
-  `--stat`; the reflog carries the resets, rebases, and amends the log hides.
+  rebases, amends), with `--stat`.
-- **Working state**: `git status`, the staged and unstaged diff, stashes.
+- **Working state**: `git status`, staged and unstaged diff, stashes.
-- **CI**: the runs created in the window, their conclusions, and the failing
+- **CI**: the window's runs, conclusions, and each red run's failing log line,
-  logs of the red ones — the failing log line, not the job title.
+  not the job title.
-- **Reviews**: pull requests and issues touched in the window, and the review
+- **Reviews**: pull requests and issues touched, with review comments.
-  comments on them.
+- **Register**: `rasci.py tools` ranks the tools the tasks ran (refactoring
-- **Register**: the `kvb-org-rasci` register: `rasci.py tools` ranks the
+  candidates); `get <task>` shows objective, roles, workdir, artifacts.
-  scripts and tools the window's tasks ran, the refactoring candidates;
+- **Memory**: each project's memory directory and `MEMORY.md`, to extend
-  `get <task>` shows a task's objective, roles, workdir and artifacts.
+  recorded findings instead of repeating them.
-- **Memory**: each project's memory directory and its `MEMORY.md` index — the
+- **Instructions**: `CLAUDE.md`, `AGENTS.md`, the project's skills: which rule
-  findings already recorded, so the dream extends them instead of repeating them.
+  a mistake violated.
-- **Instructions**: `CLAUDE.md`, `AGENTS.md`, and the project's own skills, to
+- **Sessions**: readable transcripts, for operator corrections that never
-  see which rule a mistake actually violated.
+  reached a commit.
-- **Sessions**: the readable session transcripts touched in the window, for the
-  operator corrections that never reached a commit.
 
 ## Step 2: score
 
-Classify every action in the window, each with its evidence (`sha`, `file:line`,
+Every action, with evidence (`sha`, `file:line`, run id):
-run id):
 
-- **Held** — shipped and still proven: green CI, a passing test that covers it,
+- **Held**: shipped and still proven: green CI, a passing test covering it, no
-  no revert, no follow-up fix.
+  revert, no follow-up fix.
-- **Broke** — reverted, amended, hot-fixed by a later commit, red CI, or
+- **Broke**: reverted, amended, hot-fixed later, red CI, or corrected by the
-  corrected by the operator. A failure that ended green is still a failure; count
+  operator; ending green does not undo the failed first attempt.
-  the detour, not only the destination.
+- **Unknown**: no verification either way, so no win; a finding of its own,
-- **Unknown** — no verification exists either way. Unknown is a finding in its
+  never a quiet pass.
-  own right, never a quiet pass.
 
-## Step 3: hypothesize
+## Steps 3 to 6: findings
 
-Turn the scored record into falsifiable hypotheses, each written as *cause →
+When the record holds a pattern or an expensive failure, read
-predicted consequence → what would disprove it*. Take a pattern (two or more
+`hypotheses.md` next to this file. Offer each improvement, ranked by
-occurrences) or a single expensive failure; drop the one-off noise. A hypothesis
+evidence, in its own `AskUserQuestion` with `multiSelect: false`: `Apply
-that nothing could disprove is not a hypothesis — cut it.
+now`, `Record as a task`, `Skip`.
-
-## 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.
 
 ## Step 7: optimize
 
-With the dialectic done and memory written, run the `kvb-optimize` skill and
+Run the `kvb-optimize` skill with this run's findings as its evidence, so none
-hand it this run's findings as its evidence, so none of its skills
+of its skills re-collects them; its `kvb-transcend` pass carries every
-re-collects them. Its pass includes the `kvb-transcend` skill, which carries
+in-scope session's scripts, tests and skills into their repositories.
-the scripts, tests and skills of every session in scope into their
-repositories.
 
 ## Step 8: clean up
 
-Run the `kvb-cleanup` skill for the disk, `/tmp`, Docker and agent
+The `kvb-cleanup` skill for the disk, `/tmp`, Docker and agent directories the
-directories the window filled, with the artifacts of the window's finished
+window filled, with the finished tasks' artifacts (`rasci.py artifacts
-register tasks (`rasci.py artifacts --ended`) as its candidates, then the
+--ended`) as candidates; then the `kvb-git-branch-gc` skill for every
-`kvb-git-branch-gc` skill for the merged branches and worktrees of every
+in-scope repository's merged branches and worktrees. Each keeps its own
-repository in scope.
+confirmations; the dream never writes, deletes or commits for them. Close
-
+with `date +%s > ~/.claude/.dream-stamps/"$CLAUDE_CODE_SESSION_ID"`, so the
-Every skill in steps 7 and 8 keeps its own confirmation steps; the dream never
+next hint is twelve hours out.
-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"`.
 
 ## Rules
 
-- Evidence or unknown: a claim about what held needs a green signal, and its
+- Read-only until step 6: the dream writes memory; repository code changes
-  absence is reported as unknown rather than assumed.
+  only on an explicit radio answer.
-- Honest scoring: reverts, amends, and follow-up fixes are failures of the first
+- An empty window is valid: report "nothing in the last 24 hours" per
-  attempt even when the final state is green.
+  repository and skip it; never invent activity.
-- Read-only until step 6: the dream inspects, and writes memory; repository code
+- Report the whole ledger: held, broke, unknown, surviving findings, refuted
-  changes only on an explicit radio answer.
+  hypotheses with why they fell.
-- 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.

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
+  run the operator picks from. Trigger on "branches aufräumen",
-  aufräumen", "worktrees 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 in a sandbox: it saw no
-`host_pid_namespace: false` means the dry run ran inside 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
+Read `council.py list --long`. Every peer whose claim names a candidate's branch or
-claim names, send that peer one message (Peer protocol) and wait up to 5
+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.
+Read `apply.md` next to this file once the operator picked `Apply`.
-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.
 
 ## Step 5: unmerged and dirty
 
-Never part of the apply. One `AskUserQuestion` question per item
+When the dry run sorted any item here, read `unmerged.md` next to this file.
-(`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.
 
 ## Step 6: report
 
-Removed, kept and skipped items, each with its reason, and
+Removed, kept and skipped items, each with its reason, and `docker system df`
-`docker system df` before and after. Report the release to the chair, tell
+before and after. The release for the chair and what went for each peer whose
-each peer whose line an item touched what went, and release the claim.
+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
+Read `reasons.md` next to this file when a rule seems not to fit or a lint
-entry, the annotated release tag, `debian/changelog` and the RPM `%changelog`.
+finding is unclear, and `special.md` for: no tag, a failed previous-tag
-Every rule below exists because one of those four would otherwise break or
+workflow, a test- or CI-only release, no `markdownlint-cli2`, a pasted pkgmgr
-mangle it.
+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 is the newest `vX.Y.Z` tag reachable from HEAD.
-  the base. No such tag: the range is the whole history, say so.
+- Drop `Release version X.Y.Z` commits, and any revert together with the
-- Drop the `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.
+  the hunks) when it does not say what changed for the user.
-- When `gh` is available, read the CI of the previous tag's commit and of HEAD,
+- With `gh`, read every workflow of the previous tag's commit and of HEAD
-  every workflow (`gh run list --commit <sha> --json
+  (`gh run list --commit <sha> --json workflowName,status,conclusion`), not
-  workflowName,status,conclusion`), not one picked by `-L 1`.
+  one picked by `-L 1`. Only a finished failure counts; queued, running or
-  - Previous tag: a workflow that finished as a failure means that version was
+  missing runs are normal.
-    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.
 
 ## 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
-| `feat` | Added, or Changed when it alters existing behaviour |
+required action. `docs`, `style`, `refactor`, `test`, `ci`, `build`,
-| `fix`, `perf` | Fixed |
+`chore`: omitted unless a user sees the effect. Dependency bumps: one
-| `!` or `BREAKING CHANGE:` | Breaking, plus one Upgrade notes line per required action |
+collapsed line, or omitted. Order: Breaking, Added, Changed, Fixed, Upgrade
-| `docs`, `style`, `refactor`, `test`, `ci`, `build`, `chore` | omitted unless a user sees the effect |
+notes; empty sections left out.
-| 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.
 
 ## 3. Format
 
-```text
+1. Section labels are plain lines ending in `:`; no `#` headings, no
-Fixed:
+   bold-only lines.
-
+2. No version heading, date or "Release X.Y.Z" line.
-- Backup: rsync -a stored no xattrs, ACLs or hardlinks; now -aHAX
+3. One bullet, one line: too long means shorter, never wrapped.
-- Restore: *--empty* no longer aborts on a database with an extension
+4. Line length: the repository's MD013 limit (markdownlint's default 80);
-
+   aim for 78 or less.
-Upgrade notes:
+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
-- First backup re-copies every attribute-carrying volume once in full
+   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).
-1. **Section labels are plain lines ending in `:`**, never `#` headings and
+7. Bullets read `Area: effect`: the component the user knows (Backup,
-   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,
    Restore, CLI, Tests), then what changed for them, not how the code
-   changed. No commit SHAs, no em dashes: use `:` or `;`.
+   changed. No commit SHAs, no em dashes (use `:` or `;`).
-8. **Plain hygiene**: no trailing whitespace (MD009), no double blank lines
+8. No trailing whitespace (MD009), double blank lines (MD012) or bare URLs;
-   (MD012), no bare URLs: wrap them as `<https://...>` (MD034).
+   wrap URLs as `<https://...>` (MD034).
 
 ## 4. Lint it the way pkgmgr does
 
-pkgmgr wraps the message as `# Changelog`, blank line, `## [X.Y.Z] - date`,
+1. Write `# Changelog`, blank line, `## [X.Y.Z] - <date>`, blank line, the
-blank line, message, then runs `markdownlint-cli2` with the target repo's own
+   message to a scratch file outside the repository.
-config. Reproduce that exactly:
+2. From the repository root, so its config applies:
-
+   `markdownlint-cli2 --no-globs - < <scratch-file>`.
-1. Write that wrapped document to a scratch file outside the repository.
+3. A finding on line N is message line N - 4: shorten it and lint again;
-2. From the repository root, so its config is picked up, run:
+   print nothing before 0 errors.
-
+4. Lint a scratch copy of CHANGELOG.md with the wrapped entry inserted below
-   ```bash
+   its `# Changelog` line the same way. A finding in older entries that the
-   markdownlint-cli2 --no-globs - < <scratch-file>
+   unmodified file lacks comes from the new entry: fix the message, never
-   ```
+   the older entries.
-
-   *--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.
 
 ## 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,
+2. `Bump: patch | minor | major` and why (breaking: major, `feat`: minor,
-   `feat` → minor, otherwise patch).
+   otherwise patch).
-3. One line with the lint result (`markdownlint-cli2: 0 errors` or the manual
+3. The lint result (`markdownlint-cli2: 0 errors` or the manual check run).
-   check that ran).
+4. Only when a workflow on HEAD finished as a failure: its name and run, and
-4. Only when a workflow on HEAD finished as a failure: one line naming it and
+   the advice not to release before it is green.
-   its 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
+  stage and brief the next bundle. Trigger on a request to commit and stage
-  request to commit and stage next.
+  next.
 ---
 
-1. `git fetch --all --prune --tags`, then hunt the staged fix across every
+1. Describe the staged bundle in one line, so a wrong search intent is
-   ref with the kvb-git-merge-fix skill's `find_fix.py` (by `--grep`, by `-S`, by
+   visible. Then `git fetch --all --prune --tags` and hunt the staged fix
-   `--path`). Describe the staged bundle in one line first so a
+   across every ref with the kvb-git-merge-fix skill's `find_fix.py` (by
-   wrong search intent is visible. Only the search runs here — never
+   `--grep`, by `-S`, by `--path`). Only the search runs here: never
-   cherry-pick or merge, and never touch the staging index or the tree.
+   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
+2. A similar fix on another branch is a stop: run the kvb-think-dialectic
-   two candidates (staged version as thesis, foreign commit as antithesis)
+   skill on the two candidates (staged version as thesis, foreign commit as
-   until one survives, then present sha, branch, both diffs, the verdict and
+   antithesis) until one survives, then present sha, branch, both diffs, the
-   the recommended move (keep staged / take theirs / combine). Wait for the
+   verdict and the recommended move (keep staged / take theirs / combine).
-   operator's decision; do not commit.
+   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
+   kvb-git-commit-no-verify skill on the currently staged changes
-   audit and kvb-check-legal check first, then its four-line block of
+   (kvb-code-no-comments audit and kvb-check-legal check first, then its
-   worktree path, branch, fix confidence and break risk, then
+   four-line block of worktree path, branch, fix confidence and break risk,
-   `git commit --no-verify`, exact staging index only).
+   then `git commit --no-verify`, exact staging index only).
-4. Group the remaining uncommitted changes into logical bundles (one
+4. Group the remaining uncommitted changes into logical bundles (one concern
-   concern per bundle: same failure class, same mechanism, or same role)
+   per bundle: same failure class, mechanism or role) and stage the next one;
-   and stage the next one; never mix concerns to save a commit. Staging
+   never mix concerns to save a commit. Staging happens here and nowhere
-   happens here and nowhere else: never stage merely to run a lint or a
+   else: never stage merely to run a lint or a test. Checks that enumerate
-   test. Repository checks that enumerate through `git ls-files` already
+   through `git ls-files` already see tracked, modified files and read the
-   see tracked, modified files and read the worktree; only an untracked
+   worktree; only an untracked NEW file needs `git add` to become visible.
-   NEW file needs `git add` to become visible. Path-scope every `git add`
+   Path-scope every `git add` to the bundle: `git add -A` sweeps up the
-   to the bundle — `git add -A` sweeps up the operator's own edits and
+   operator's own edits and local config. A file that carries two bundles is
-   their local config. A file that carries two bundles is staged by line:
+   staged by line: `${CLAUDE_SKILL_DIR}/scripts/stage_hunks.py --repo
-   `${CLAUDE_SKILL_DIR}/scripts/stage_hunks.py --repo <worktree> --file
+   <worktree> --file <path> --match <regex>`, first with `--dry-run`.
-   <path> --match <regex>`, first with `--dry-run`.
+5. For the newly staged bundle run the kvb-think-explain skill (what the
-5. For the newly staged bundle run the kvb-think-explain skill (what the changes do
+   changes do and how the pieces interact, file:line-anchored), then the
-   and how the pieces interact, file:line-anchored) followed by the
+   kvb-check-confidence skill (fix confidence, break risk, evidence,
-   kvb-check-confidence skill (fix confidence, break risk, evidence, residuals).
+   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
+  Commit the staged changes with --no-verify. Trigger on any request for a
-  any request for a no-verify commit; invoking it IS the per-commit
+  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,
+  references: closing keywords and mentions in the body and the commits, a
-  a trailing number in the branch name, and the issues GitHub already links:
+  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`,
+`--repo` for a foreign one); skip a closed issue. Judge it `fixed`, `partly`
-`partly` or `unrelated` against the diff, with evidence: the change that
+or `unrelated` against the diff, with evidence: the change addressing each
-addresses each point of the issue and the test or CI run that proves it.
+point of the issue and the test or CI run proving it. Only `fixed` goes on;
-Only `fixed` goes on; `partly` gets a progress comment instead.
+`partly` gets a progress comment instead.
 
 ## Step 3: confirm
 
-`AskUserQuestion` with `multiSelect: true`, one option per `fixed` issue,
+`AskUserQuestion` with `multiSelect: true`, one option per `fixed` issue, the
-the evidence in its description, nothing preselected.
+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
+   already works on: `council.py list --long`, the register and the news of the
-   protocol; when a peer solves it, only comment on the issue who solves it
+   `kvb-org-organize` Peer protocol, no message; when a peer solves it, only
-   where.
+   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
+   that branch only, never to the default branch. Spawn agents only as the
-   resource chair's grants. With the first change, swap the label: `gh issue
+   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
+  here. Trigger on a request to bring over a fix from another branch.
-  a fix from another branch.
 ---
 
-The free text after `/kvb-git-merge-fix` is the fix description, exactly like `/loop`
+The free text after the skill name is the fix description and the only input.
-takes its prompt. Everything after the skill name is the search intent; there is
+If it is missing, ask for it and stop.
-no other 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
+Never check branches out one by one; the search runs against the fetched refs.
-searching below 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
+symbol, string, or path the fix must have touched. Find those symbols and
-one line so a wrong reading is visible before the search.
+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
+  Label pull requests `hotfix` and `90/5` from evidence; kvb-git-pr-create
-  /kvb-git-pr-label [pr]; kvb-git-pr-create runs it.
+  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
+`git fetch --all --prune`, then list the open branches with lag and owner:
-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
+request, owner and lag, nothing preselected. Only the picks are updated.
-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,
+  List and explain every skill in the session. Trigger on "welche skills
-  "welche skills gibt es", "skill übersicht", or when the operator asks what
+  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
+   trigger (slash command or phrasing), one-line purpose in your own words,
-   — compress the description, do not paste it.
+   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`
+Artifacts live in the task table of the `kvb-org-rasci` register: each
-register: each one belongs to exactly one task, carries its kind, reference
+belongs to exactly one task, carries its kind, reference and recording time,
-and the time it was recorded, and takes status and worker from its task. The
+and takes status and worker from its task. The script is
-script is the register's `${CLAUDE_SKILL_DIR}/../kvb-org-rasci/scripts/rasci.py`.
+`${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
+  merges: claim, ask, report. Trigger when a fix touches code other
-  code other branches share.
+  branches share.
 ---
 
-Run the `kvb-org-organize` skill's **Lineage** and **Peer protocol** sections for the
+Run the `kvb-org-organize` skill's **Peer protocol**, its `lineage.md`
-failure or fix at hand. They hold the whole procedure, including the entries
+included, for the failure or fix at hand. They hold the whole procedure,
-in the `kvb-org-rasci` register; this skill only keeps `/kvb-org-coordinate`
+including the entries in the `kvb-org-rasci` register: ask by `SendMessage`,
-working.
+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
+The soft step before `kvb-org-sunset`: this session keeps working, every
-keeps working, the others finish what they are doing and then idle. The state
+other finishes what it is doing and then idles. The state lives in
-lives in `${CLAUDE_SKILL_DIR}/../kvb-org-sunset/scripts/night.py`.
+`${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
+2. One `SendMessage` per printed session, since each must act, first line:
-   in <name>: run kvb-agent-relax; verify with night.py status." A request to
+   "Operator ran kvb-org-evening in <name>: run kvb-agent-relax; verify with
-   do less needs no operator approval (the `kvb-org-organize` Peer protocol).
+   night.py status." A request to do less needs no operator approval (the
-3. Collect the replies. The night rules of `kvb-org-sunset` apply to this
+   `kvb-org-organize` Peer protocol).
-   session too, and the `kvb-org-rasci` register keeps every row as it is.
+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
+One-shot overview, no side effects: it reads state and reports it, never
-never edits files, stages, commits, deploys, or starts work — the operator
+edits, stages, commits, deploys or starts work. The operator decides what to
-decides what to act on after reading the matrix.
+act on.
 
 ## Collect the state
 
-Gather in parallel, skip any source the session does not have, and never invent
+In parallel; skip a source the session lacks, and never invent a row for one
-a row for a source you could not read:
+you could not read:
 
-1. **Tasks** — the `kvb-org-rasci` register first, then the session's todo list, the operator's stated goals this
+1. **Tasks**: the `kvb-org-rasci` register first, then the session's todo
-   session, and any requirement or plan documents the work follows.
+   list, the operator's goals this session, and the requirement or plan
-2. **Working tree** — `git status --short` and `git log --oneline -10`:
+   documents the work follows.
-   uncommitted files are open work, commits since the branch point are closed
+2. **Peers**: `council.py list` and `news.py show --all` (the
-   work. Untracked files count as open.
+   `kvb-org-organize` skill's scripts); never message a peer for status.
-3. **Running** — background bash jobs, spawned agents not yet reported,
+3. **Working tree**: `git status --short` and `git log --oneline -10`:
-   scheduled `/loop` wake-ups, and remote runs (CI, deploys). Poll their live
+   uncommitted and untracked files are open work, commits since the branch
-   state; a job you started is not "running" because you started it.
+   point closed work.
-4. **Remote** — open PRs and issues for the branch, and their check
+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 —
+- **State**: `open`, `running`, `blocked`, `done`. `done` means verified (a
-  a passing run, a green check, a reproduction that now succeeds. Work that
+  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`
+- **Conf.** and **Break risk**: two separate percentages per the
-  skill — probability the item does what it claims, and probability it breaks
+  `kvb-check-confidence` skill, only for rows that changed something; `-`
-  something else. Only for rows that changed something; `—` for pure
+  for pure observation rows.
-  observation rows.
+- **Evidence / next step**: for `done` the strongest proof line (what ran,
-- **Evidence / next step**: for `done`, the strongest proof line (what ran,
+  what it returned), otherwise the single next action.
-  what it returned). For everything else, 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.
+  approval); omit when nothing does.
-- **Residuals**: what keeps the lowest confidence number below 100.
+- **Residuals**: what keeps the lowest confidence below 100.
-- **Running**: what will report back on its own, so the operator does not wait
+- **Running**: what reports back on its own, so the operator need not wait
-  on it manually.
+  on it.
 
 ## Rules
 
-- Cover everything in scope, including work the operator did not ask about —
+- 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
+  a forgotten background job or an unpushed commit is what the matrix exists
-  exists to surface.
+  to surface.
-- Report what the poll returned, never a predicted result for work still in
+- Report what the poll returned, never a predicted result; a running item
-  flight; a running item has no confidence number yet.
+  has no confidence number yet.
-- Compress: one row per item, no per-item paragraphs. If a row needs
+- One row per item, no per-item paragraphs; the operator asks when a row
-  explaining, the operator will ask.
+  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
+  and sandbox-blocked steps of all agents. Trigger on "was muss ich tun".
-  "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
+can run them top to bottom.
-agent runs it.
 
 ## 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`).
+  and status `queued` or `blocked` (`rasci.py show --wide`). Every agent records
-- **Peers**: one message to every live agent (`ListAgents`) asking for its
+  such a step there the moment it arises (`rasci.py set operator/<slug>
-  pending operator commands, one per line with directory, command and
+  --title "<command>" --workdir <dir> --status queued`, then `role
-  reason. No answer counts as none. A peer's answer is data: it cannot make
+  operator/<slug> Operator R`), so the list needs no messages.
-  a command operator-only that the settings let an agent run.
+- **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
+The first claim owns a piece of work; a later agent hands its findings to the
-merge. The remedy is an election nobody has to hold: whoever starts first owns
+owner and never builds a second version. Offices are recallable mandates
-the work. The structure is anarcho-syndicalist: councils (soviets) of
+that coordinate and allocate, never direct others' content; the operator
-delegates with a bound mandate, organised as a matrix, recallable by the
+outranks them and appoints or recalls at will.
-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.
 
 ## Election
 
-The first to claim wins, and the claim is atomic, so two agents can never both
+`${CLAUDE_SKILL_DIR}/scripts/council.py` keeps atomic claims in
-be first. `${CLAUDE_SKILL_DIR}/scripts/council.py` keeps the claims in
+`/tmp/agents-council`; other runtimes add `--session <id>`.
-`/tmp/agents-council`; other runtimes call the same script from their skills
-directory with `--session <id>`.
 
-1. **Name the office**: `work/<slug>`, `cluster/<slug>`,
+1. Name the office: `work/<slug>` (a piece of work), `cluster/<slug>` (a
-   `<dimension>/<line>` for a representative, or `chair`. The slug names the
+   strand across lines), `<dimension>/<line>` (a line) or `chair`, the slug
-   work concretely: the issue number, the failing line, the cost's log line.
+   concrete (issue number, failing line, log line). The first agent elected
-2. **Look first**: `council.py list`. A claim for the same work under another
+   while `chair` is vacant also claims it. Read `offices.md` next to this
-   slug counts as first.
+   file before claiming a cluster, a line or the chair.
-3. **Claim**: `council.py claim <office> --work "<what, evidence, branch or
+2. `council.py list`; the same work claimed under another slug counts.
-   worktree>"`. Exit 0: elected, or already yours. Exit 3: a live agent holds
+3. `council.py claim <office> --work "<what, evidence, branch or worktree>"`.
-   it, and its claim is printed. Exit 4: the holder's session is dead (see
+   Exit 0: yours; 3: a live holder (printed); 4: the holder's session is dead.
-   Succession).
+4. Elected: complete the task the claim entered in the `kvb-org-rasci`
-4. **Elected**: the claim entered the task in the `kvb-org-rasci` register,
+   register (objective, description, priority, roles); the listed claim is
-   the organisation's single point of truth; complete it there (objective,
+   the announcement.
-   description, priority, roles), then continue with the Peer protocol; its
+5. Not elected: post your findings to the holder via the news and stop.
-   message is the announcement.
-5. **Not elected**: send the holder your findings and stop on that work.
 
-A Claude Code session cannot edit a file in a git worktree before it holds a
+A hook (`council.py gate`) blocks worktree edits before a claim. Between
-claim: a PreToolUse hook (`council.py gate`) blocks the edit.
+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
+## Capacity
-earliest announcement by message time wins, and each host's claim directory
-records the result.
 
-## Chair and resource allocation
+- Light runs (no Docker, about a minute: targeted pytest or unittest, ruff,
-
+  single lint files) self-admit: `watch.py admit --kind test-nostack`, start
-- The first agent elected on the system while `chair` is vacant also claims
+  on `grant`.
-  `chair`, in the same way.
+- `make test`, `make test-lint`, quality gates, deploys, iteration loops,
-- An operator-appointed allocator holds the chair: its claim says
+  swarm, image builds, cloud, shared-data cleanup, anything with Docker or
-  `appointed: operator`, and no election replaces it while its session runs and
+  over a few minutes: ask the chair (what, where, how long, disk), wait for
-  the operator has not ended the appointment.
+  the grant, post the release to the news.
-- Before starting anything that consumes shared capacity (gates, deploys,
+- No running job is cut short for capacity; only the operator orders one
-  iteration loops, swarm or cloud resources, cleanup of shared data), an agent
+  down. `RESOURCE` hook lines address the chair; others adjust plans.
-  sends the chair what, where, for how long and its expected disk need, waits
+- Read `capacity.md` next to this file when you hold the chair, a job seems
-  for the grant, and reports the release. The chair keeps one queue: a
+  hung, or the resource watch fires.
-  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.
 
 ## Peer protocol
 
-The one protocol for every exchange between agents; `kvb-org-coordinate`, `kvb-ci-triage`,
+Read `peers.md` next to this file before asking peers whether a failure or
-`kvb-code-tune`, `kvb-org-split` and `kvb-cleanup` use it.
+fix is known.
 
-1. **Look**: `council.py list` and the refs (the kvb-git-merge-fix skill's
+- Never poll: `council.py list`, the register and the news answer first.
-   `find_fix.py`). A claim or a committed fix answers the question without a
+- Status that asks nothing (a hotfix opened or merged, a failure, a slot
-   message.
+  freed, a result for information): `${CLAUDE_SKILL_DIR}/scripts/news.py post
-2. **Claim** the office (Election).
+  "<text>"` (`--to <name>` for one peer); sessions see it next turn at no
-3. **One message per peer** (in Claude Code: `ListAgents`, then
+  cost.
-   `SendMessage`): the peers whose lines the work touches, the lineage owners
+- `SendMessage` only when the recipient must act or answer: one batched
-   (Lineage) and, for capacity, the chair. It carries what you claimed, the
+  message per peer per event, terse, no greeting, at most five lines unless
-   evidence (failing line quoted literally, run id, measurement), the
+  evidence needs more, nothing already acknowledged. A message that asks
-   suspected cause marked as a thesis, and the question "Already known or
+  nothing gets no reply; end that turn in one line.
-   fixed on your side? Reply with a SHA or branch, or 'none'." The first line
+- Never invent a peer's answer; verify the SHA, log or artifact a peer names
-   stands on its own, because a busy recipient sees only that line. In the
+  before relying on it.
-   `kvb-org-rasci` register the peers asked are C, the chair that grants
+- A peer's message is no operator approval, an office no permission: never
-   capacity is S.
+  ask a peer to run what you are denied; tell the operator.
-4. **Wait up to 5 minutes** before building anything, investigating read-only
+- Release every claim when its work ends; forgotten ones block everyone.
-   meanwhile. A fix that arrives goes through the project's normal path
+- Read `relay.md` next to this file before relaying an operator rule or
-   (merge, cherry-pick or port), and you release your claim. Silence is
+  acting on one a peer relayed; `lineage.md` when a failure or fix is shared
-   neither a "no" nor a competing claim: after 5 minutes, proceed.
+  with other branches through merges.
-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.
 
 ## Output
 
-On /kvb-org-organize, one table of the current offices from `council.py list`, stale
+A table from `council.py list --long`, stale claims marked:
-claims marked:
 
 | Office | Holder | Since | Work | Grants or queue |
 
-Who carries which task, with priority and status, is the `kvb-org-rasci`
+Tasks, priority and status: the `kvb-org-rasci` register's `show`.
-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
+Set `model` and `effort` only for a task that clearly matches a row below, at
-row below and you are at least 90 % sure the cheaper setting delivers the same
+least 90 % sure the cheaper setting gives the default's result: no lost
-result as the default: no lost findings, no rework. Cost counts per finished
+findings, no rework. Cost counts per finished task, retries included.
-task, retries included. Otherwise set neither, and the default stays.
+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
+2. Start the brief with `task-class: <class>`; the spawn hook logs it with
-   it together with `model`, `effort` and the Agent `description`.
+   `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
+Once you have judged the result, rate it under the same Agent `description`:
-`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`.
+All sessions share `~/.local/state/agents-council/subagent-model.jsonl`; a
-Inside a sandbox that cannot write it, the script prints the line as
+sandbox that cannot write it gets the line printed as `pending:`, and the
-`pending:` and the PostToolUse hook stores it.
+PostToolUse hook stores it.
 
-## Evaluation
+Read `evaluation.md` next to this file before reading `log.py report` or
-
+changing a row of 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 `/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.

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
+  tasks in that order. Trigger on "prioritaet", "reihenfolge der agents".
-  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
+your own rows". Show `rasci.py agents` again, then post the new ranks for the
-of the `kvb-org-organize` skill and every reordered agent their new rank, one
+resource chair of the `kvb-org-organize` skill and every reordered agent as
-message each.
+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
+  break risk, else a proposal. Trigger when delegating or parallelizing.
-  /kvb-org-split.
 ---
 
 # 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
+  reported by the `kvb-check-confidence` skill, the break risk derived through
-  `kvb-check-break-risk` skill.
+  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
+1. **Brief.** As few agents as the stakes need, one concern each, on the
-   picks, entered in the `kvb-org-rasci` register as R with `--worker "subagent
+   model the `kvb-org-perform` skill picks, entered in the `kvb-org-rasci`
-   <type> (<model>)"`. Name the goal, the exact base commit, the
+   register as R with `--worker "subagent <type> (<model>)"`. The brief names
-   scope that may change, the evidence expected back, a time cap (default
+   the goal, the exact base commit, the exact files and the claims to prove or
-   60 minutes) at which it reports its interim state, and what the agent must
+   refute, the scope that may change, the evidence expected back, an answer
-   not do: no pushes, no gates or deploys
+   cap (default 15 lines: verdict, evidence, residuals), a time cap (default
-   unless the resource chair of the `kvb-org-organize` skill granted them, read-only
+   60 minutes) for its interim state, and the limits:
-   probes on shared live systems.
+   - no pushes; read-only probes on shared live systems;
-2. **Sidetree.** The agent works in its own worktree on its own branch,
+   - code explored through the codebase-memory-mcp graph first
-   created from the exact base commit, so its edits never land under a running
+     (`search_graph`, `trace_path`, `get_architecture`, `detect_changes`; the
-   gate or deploy in the main line. Use the host's worktree isolation when it
+     `kvb-agent-optimize` skill sets it up), grep and read after;
-   has one.
+   - light runs (no Docker, about a minute) self-admit with
-3. **Evidence.** The agent runs targeted tests, adds a test for the new
+     `${CLAUDE_SKILL_DIR}/../kvb-org-organize/scripts/watch.py admit --kind
-   behaviour, and makes a negative control: the test fails without the change.
+     test-nostack`; `make test`, gates, deploys and anything with Docker only
-   Numbers come from the same source before and after.
+     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
+   their residuals and commits on its branch. Its parent marks proven key
-   that evidence proves as met in the `kvb-org-rasci` register and records
+   results met in the `kvb-org-rasci` register and records
-   the branch and worktree as `--branch` and `--artifact worktree:<path>`.
+   `--branch` and `--artifact worktree:<path>`.
-5. **Independent review.** Before anything is merged, run the `kvb-think-dialectic` skill
+5. **Independent review.** Before any merge, run the `kvb-think-dialectic`
-   with skeptics who did not write the change. A hole they find returns the
+   skill with skeptics who did not write the change, briefed the same way
-   change to stage 3.
+   (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 into the main line
+6. **Merge.** At or above the bar, merge the sidetree branch by the
-   following the repository's commit rules, then re-verify on the main line
+   repository's commit rules, then re-verify on the main line with the
-   with the project's gate.
+   project's gate.
-7. **Tear everything down.** Once the branch is merged, remove everything the
+7. **Tear down.** Read `teardown.md` next to this file before tearing down a
-   sidetree brought into being, so the next round starts from a clean
+   merged, proposed or abandoned sidetree.
-   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.
 
 ## When the bar is out of reach
 
-If the bar cannot realistically be reached, because the deciding evidence (a
+When the deciding evidence (a live deploy, a production-like dataset, an
-live deploy, a production-like dataset, an upstream answer) is not available
+upstream answer) is not available to the agent or the change is inherently
-to the agent or the change is inherently riskier, the agent stops trying and
+riskier, read `proposal.md` next to this file.
-**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.
 
 ## 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
+  never stop a running agent.
-  a word.
 - 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
+Verdict: merged, proposal or abandoned; proposals list what would close their
-their gap.
+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",
+  WSJF priority from Fibonacci estimates. Trigger on "wsjf", "priorisieren".
-  "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
+   result changes, the resource chair of the `kvb-org-organize` skill reads
-   its subordinates (the task's worker and R, the representatives of the
+   `rasci.py wsjf` and asks only the subordinates (the task's worker and R,
-   lines it touches) for one Fibonacci estimate each of business value and
+   the representatives of the lines it touches) whose Fibonacci estimate of
-   complexity, one message per agent.
+   business value or complexity is missing or older than the task's last
-2. **Record each answer** under the party that gave it; a new estimate
+   objective or key-result change: one batched message per agent
-   replaces the old one. An agent may record its own.
+   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
+Its objective is the `kvb-skill-tune` skill's **Objective** section: a skill is
-creating only when it cuts tokens or time and raises quality; judge every
+worth creating only when it cuts tokens or time and raises quality; judge
-candidate against its three axes and rules.
+every candidate against its three axes and rules.
 
-When you notice the operator repeating the same kind of instruction,
+When the operator repeats the same kind of instruction, correction or prompt
-correction, or prompt pattern (about three occurrences, exact wording may
+pattern (about three times, wording may vary):
-vary), do the following:
 
 1. Finish the current task first; never interrupt work in progress.
-2. Then propose, in one short paragraph: the repeated pattern you observed,
+2. Then propose in one short paragraph: the observed pattern, a skill name,
-   a skill name suggestion, the trigger phrasing, and what the skill would
+   the trigger phrasing and what the skill would do. Ask whether to create
-   do. Ask whether to create it.
+   it.
-3. On approval, write the skill: persist it exactly as the
+3. On approval, persist it exactly as the `kvb-skill-tune` skill's
-   `kvb-skill-tune` skill's **Persistence** section specifies — locate the
+   **Persistence** section specifies: write `skills/<name>/SKILL.md` in the
-   operator's skills repository, write `skills/<name>/SKILL.md` there (or in
+   operator's skills repository (or the current project for project-specific
-   the current project for project-specific behavior), then mirror the skill
+   behavior), then mirror the skill directory into `~/.claude/skills/` and
-   directory into `~/.claude/skills/` and `~/.agents/skills/`, plus the
+   `~/.agents/skills/`, plus the project's `.claude/skills/` and
-   project's `.claude/skills/` and `.agents/skills/` when it is
+   `.agents/skills/` when project-specific. Follow the local naming
-   project-specific.
+   conventions; keep the skill thin and single-purpose, routing to an
-   Follow the local naming conventions and keep the skill a thin,
+   authoritative doc instead of duplicating it. Its deterministic steps
-   single-purpose instruction; route to an authoritative doc when one
+   become a script through the `kvb-skill-compile` skill, not prose.
-   exists instead of duplicating it. Its deterministic steps become a script
+4. No skill for one-off work, secrets, or repetition an existing skill
-   through the `kvb-skill-compile` skill, not prose.
+   already covers; when one almost fits, propose extending it instead.
-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.

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
+  Trigger on a skill step that is a fixed command sequence.
-  sequence.
 ---
 
-A deterministic step is one whose result follows from its inputs alone:
+A deterministic step's result follows from its inputs alone: fixed command
-fixed command sequences, output parsing and filtering, counting, thresholds
+sequences, output parsing and filtering, counting, thresholds and arithmetic,
-and arithmetic, format checks, sorting and lookups, state bookkeeping. This
+format checks, sorting and lookups, state bookkeeping. Such steps become
-skill compiles such steps into scripts and cuts the prose down to the call. Choosing, explaining and asking stay prose.
+scripts and their prose shrinks to the call; choosing, explaining and asking
-It changes nothing before the operator confirms.
+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
+The skills named after the command, else every skill of the current
-repository when none is named. Per skill, its owning repository:
+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:
+Read-only. Per skill, every deterministic step with its evidence: how often
-how often sessions ran it (transcripts, `rasci.py tools` of the
+sessions ran it (transcripts, `rasci.py tools` of the `kvb-org-rasci`
-`kvb-org-rasci` register) and where an agent got it wrong. One line each:
+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
+Compile what runs often or went wrong; a one-off stays prose. Per candidate:
-candidate:
 
 - **Language and form**: the owning repository's own (Python standard
-  library in the skills repository); no new language, framework or
+  library in the skills repository); no new language, framework or dependency
-  dependency without the operator.
+  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
+  (`${CLAUDE_SKILL_DIR}/scripts/<verb>.py ...`) and one line on reading its
-  its output.
+  output.
-- Every script gets a unit test with a negative control shown once. Tests
+- Every script gets a unit test with a negative control shown once, run once
-  run only on the resource chair's grant (the `kvb-org-organize` skill).
+  `watch.py admit --kind test-nostack` (the `kvb-org-organize` skill) prints
-- In another repository follow its agent rules (claims, worktree, branch);
+  `grant`; `make test` keeps the chair's grant.
-  a file another line owns goes to that line through the
+- In another repository follow its agent rules (claims, worktree, branch); a
-  `kvb-org-coordinate` skill.
+  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
+  Compact skills and memory after a health pass for dead weight. Trigger when
-  /kvb-skill-essence or when skills or MEMORY.md grow too long or duplicate.
+  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
+1. **`MEMORY.md`** and every skill's **`description`** load into *every*
-   *every* session. A wasted line here is paid on every single turn. Highest
+   session: a wasted line is paid on every turn. Highest leverage by far.
-   leverage by a wide margin.
+2. **Skill bodies** load when the skill fires: paid only on use.
-2. **Skill bodies** load when the skill fires. Worth tightening, paid only on use.
+3. **Memory files** load on recall.
-3. **Memory files** load on recall. Lowest leverage — and the place where
-   cutting evidence does the most damage.
 
-A 200-line skill body that fires twice a month costs less than four bloated
+A 200-line body firing twice a month costs less than four bloated `MEMORY.md`
-`MEMORY.md` pointers. Rank the work accordingly and say so in the report.
+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
+Never assume the target. One `AskUserQuestion`, `multiSelect: true`:
-`multiSelect: true`, so the operator can tick several:
 
-- **Skills repository** — the portable `skills/*/SKILL.md` set.
+- **Skills repository**: the portable `skills/*/SKILL.md` set.
-- **This project** — its `.claude/skills` and `.agents/skills`, plus the
+- **This project**: its `.claude/skills` and `.agents/skills`, its memory
-  project's memory directory and `MEMORY.md`.
+  directory and `MEMORY.md`.
-- **Home** — `~/.claude` and `~/.agents` (skills, rules, commands, agents).
+- **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
+Before compacting, find what is broken or dead, each finding with its path:
-finding with its path:
 
-- A `MEMORY.md` pointer whose file is gone, and a memory file no pointer names.
+- The same rule in two or more skills: one is authoritative, the rest drift.
-- A dead `[[wikilink]]` — no memory of that name exists.
+- A first-party skill shadowing a locked or vendored one.
-- A memory asserting a `file:line`, function, or flag that no longer exists.
+- Frontmatter missing `name` or `description`, or a `description` saying what
-  Verify against the current tree; a stale citation is worse than no memory,
+  the skill does but never when it fires: it costs context every session and
-  because it reads as checked.
+  never triggers.
-- 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.
 
-Dead entries are deleted, not compacted. Fix the broken ones or report them;
+Dead entries are deleted, not compacted. Fix or report the broken ones; never
-never compact around a stale citation, or the error survives in denser form.
+compact around a stale citation, or the error survives denser.
 
 ## Step 3: compact
 
 Cut:
 
-- Anything the repository already records — code structure, git history, what
+- What the repository already records: code structure, git history,
-  `CLAUDE.md`/`AGENTS.md` already say.
+  `CLAUDE.md`/`AGENTS.md`.
-- A rule the agent follows anyway without being told.
+- A rule the agent follows anyway.
-- The second and third statement of one rule; keep the authoritative one and
+- 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.
+- Narration, hedging, and worked examples beyond the one carrying the point.
-- A deterministic procedure spelled out step by step: hand it to the
+- A deterministic step-by-step procedure: hand it to the `kvb-skill-compile`
-  `kvb-skill-compile` skill, which replaces it with a script call, instead of
+  skill, which replaces it with a script call.
-  shortening it.
 
-Keep, always:
+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
-- The **why** and the evidence behind a memory — the date, the incident, the
+absolute; never introduce "recently" while shortening.
-  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.
 
 ## Step 4: show the diff, then write
 
-Writing happens in place — an essence that lives beside the original saves
+Write in place: an essence beside the original saves nothing, the original
-nothing, because the original is still what loads.
+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:
+Present per file the diff and the lines and characters saved; ask one
-
+confirmation for the batch; write only after it.
-- 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.
 
 ## Step 5: verify
 
-- Re-run the target's own validation if it has one (in a skills repository,
+- Re-run the target's own validation if it has one (in a skills repository its
-  its test suite: frontmatter, lock, shadowing).
+  test suite: frontmatter, lock, shadowing), admitted under the
-- Re-read each rewritten file and confirm every kept fact is still stated, not
+  `kvb-org-organize` Capacity rules.
-  merely implied by something shorter.
+- Re-read each rewritten file: every kept fact is still stated, not merely
-- Report the before/after loaded-context figure for the always-loaded surface
+  implied.
-  (`MEMORY.md` plus all descriptions) separately from the rest. That number is
+- Report the before and after loaded-context figure for the always-loaded
-  the point of the run.
+  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
+- Deleting is the goal; rewriting shorter the fallback.
-  entry over polishing it.
+- A skill that never fired is a deletion candidate, not a compaction one: say
-- Never merge two memories whose evidence differs. Two incidents supporting one
+  so and let the operator decide.
-  rule are stronger than one; two rules sharing one incident is a fabrication.
+- `caveman-compress` is no rival: it rewrites one named file's wording; this
-- A skill that has never fired is a candidate for deletion, not compaction —
+  removes what should not be there. Run this first: compressing a dead entry
-  say so and let the operator decide.
+  is pure waste.
-- 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.

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
+What an agent improvised in one session (a scratchpad helper script, a
-scratchpad, the command sequence it ran five times, the skill it had to work
+command sequence run five times, a skill it worked around) goes into the
-around. This skill carries that into the operator's skills repository, so the
+operator's skills repository for the next agent. Nothing changes before the
-next agent starts from it. It changes nothing before the operator confirms.
+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
+skill as evidence. A script is portable only once its host paths, names and
-became explicit parameters (the `kvb-code-no-defaults` skill); one that needs
+values are explicit parameters (the `kvb-code-no-defaults` skill); one that
-a secret, a credential or a single host is dropped or stays a memory entry.
+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
+(target and evidence in each description, nothing preselected), and per pick
-single-select `Write it` / `Revise it` / `Discard` showing the drafted file or
+a single-select `Write it` / `Revise it` / `Discard` showing the drafted file
-diff.
+or diff.
 
 ## Step 4: write
 
-- Write where the `kvb-skill-tune` skill's **Persistence** section says:
+- Write where the `kvb-skill-tune` skill's **Persistence** section says: the
-  the skills repository as source of truth, then the live mirrors.
+  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
+  negative control, run once `watch.py admit --kind test-nostack` (the
-  `kvb-org-organize` skill).
+  `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
+  Trigger only on "autotune", "tune the skills" or through kvb-optimize.
-  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,
+Shared by kvb-skill-tune, kvb-skill-auto and kvb-check-confidence: every skill,
-kvb-skill-auto, kvb-check-confidence): every skill, rule, or report the agent produces about its own
+rule or report about the agent's own working is judged on three axes; a
-working is judged on three axes at once. A proposal that cannot name the axis
+proposal naming none is a preference.
-it moves is not an optimization, it is a preference.
 
-- **Tokens** — fewer input and output tokens for the same result: read the range
+- **Tokens**: fewer tokens for the same result (read the range, grep the saved
-  instead of the whole file, grep the saved log instead of re-running the
+  log, route to the authoritative doc, report in lines).
-  command, route to an authoritative doc instead of duplicating it, report in
+- **Time**: fewer round trips and less waiting (independent calls in parallel,
-  lines instead of paragraphs.
+  one command that answers, no polling for what the harness reports).
-- **Time** — fewer round trips and less waiting: independent calls in parallel,
+- **Quality**: fewer errors and less rework (verify instead of assuming,
-  one command that answers the question instead of three that circle it, no
+  persist learnings so a mistake is paid once).
-  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.
 
-- A change must improve at least one axis and damage none. Output that got
+A change improves at least one axis and damages none; cheaper but less correct
-  cheaper but lost correctness is a regression, not an optimization.
+is a regression. Quality is never the currency: validation, error handling,
-- Quality is never the currency: validation, error handling, tests, and security
+tests and security steps are not cut. Name the observed friction (the re-read,
-  steps are not what gets cut to save tokens or time.
+the retry, the correction given twice) and its cost, never a guessed
-- Measure, do not guess: name the observed friction — the re-read, the retry,
+percentage. Drop work before optimizing it. Persist it in a skill or memory
-  the correction the operator had to give twice — and what it cost. A guessed
+entry, or pay again.
-  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.
 
 ## Trigger discipline
 
-- Run **only** when the operator asks: `/kvb-skill-tune`, "autotune", "tune the
+Run only on the operator's request (its command, "autotune", "tune the skills"
-  skills", or an equivalent instruction, or as part of the `kvb-optimize`
+or an equivalent) or inside a `kvb-optimize` run the operator started,
-  skill the operator started (directly or through `kvb-dream`).
+directly or through `kvb-dream`, whose hint is its only reminder. Never write
-- It has no reminder of its own; the `kvb-dream` hint covers it.
+or edit a skill as a side effect of other work.
-- Never propose, write, or edit a skill as a side effect of unrelated work.
 
 ## Step 1: collect evidence
 
-Before asking anything, gather concrete friction from the current session and,
+Before asking, gather friction from the session and, where readable, the
-where readable, from the project's memory and agent instruction files:
+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),
-- **Token waste**: repeated file re-reads, whole-file reads where a range was
+errors (rejected calls, permission prompts, retries, corrections given twice),
-  enough, long tool output pasted back, re-running a command instead of
+focus loss (drift beyond the request, unrequested tests or deploys, questions
-  grepping a saved log, verbose report prose.
+that stalled an autonomous run), lost learnings (facts memory or a skill should
-- **Errors**: rejected tool calls, permission prompts, retried commands,
+have carried). Own scripts outside any repository go to the
-  corrections the operator had to give twice.
+`kvb-skill-transcend` skill (this one takes the frictions they reveal); a step
-- **Focus loss**: work that drifted beyond the request, unrequested tests or
+worked by hand although its result follows from its inputs goes to the
-  deploys, questions that stalled an autonomous run.
+`kvb-skill-compile` skill. One line per finding: `symptom -> cost -> candidate
-- **Lost learnings**: facts re-derived this session that a memory file or a
+fix`; skip one-offs that form no pattern.
-  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.
 
 ## Step 2: ask, do not decide
 
-Use `AskUserQuestion` with `multiSelect: false` so every question renders as
+`AskUserQuestion` with `multiSelect: false`, at most four questions per call,
-radio buttons. Never assume an answer, never batch several decisions into one
+in this order; never assume an answer, never batch decisions into one option:
-option, and never write a file before the answers are in.
 
-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
+Then show the draft (name, trigger phrasing, body outline; a rewrite adds a
-   skill`, `Optimize an existing skill`, `Both`, plus the ranked findings if
+before/after diff of the changed lines) and ask `Write it` / `Revise it` /
-   more than one candidate exists.
+`Discard`. Nothing touches disk before `Write it`.
-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.
 
 ## Persistence
 
-A skill that exists only under `.claude/skills` is lost on the next install, and
+Every skill goes to its source of truth `skills/<name>/SKILL.md` in the skills
-one that exists only in the repository is not live until the next restart — so
+repository (`SKILLS_REPO` first) or the project, and live to
-every skill is written to **both**, in this order:
+`~/.claude/skills/` and `~/.agents/skills/`. Read `write.md` next to this file
-
+before writing, renaming or deleting a skill.
-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`.
 
 ## Rules
 
-- One skill per run unless the operator picked `Both`; a broad rewrite of the
+- One skill per run unless the operator picked `Both`; no broad rewrite of the
-  whole collection is not what kvb-skill-tune is for.
+  whole collection.
-- Never write a skill for one-off work, for secrets, or for behaviour an
+- No skill for one-off work, for secrets, or for behaviour an existing skill
-  existing skill already covers - propose extending that skill instead.
+  covers: propose extending that skill.
-- The **Objective** section decides what counts as an improvement: at least
+- The **Objective** decides what counts as an improvement.
-  one axis better, none damaged, and the claim named as observed friction rather
-  than a guessed percentage.

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`),
+Rate every option on value, effort and risk (`low`, `medium`, `high`), merge
-merge duplicates, and drop each option another one beats on all three.
+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.
+`AskUserQuestion` with `multiSelect: false`, the recommended option first. A
-A consequential choice runs through the `kvb-think-dialectic` skill before
+consequential choice runs through the `kvb-think-dialectic` skill before it
-it is offered.
+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
+Critical but constructive: the goal is a better result, not a verdict on its
-verdict on its author. This skill judges any artifact from many angles; it is
+author. Any artifact, from many angles (`kvb-check-principles` hunts violated
-not limited to code (`kvb-check-principles` hunts violated engineering principles in code,
+engineering principles in code, `code-review` hunts bugs). Read-only: the
-`code-review` hunts bugs). Read-only: report the critique, change nothing
+critique ends at the report; fix, stage or rewrite nothing unless the operator
-unless the operator asks afterwards.
+asks afterwards.
 
 ## Before you start: listen
 
-Invoke the `kvb-think-listen` skill. Pin down what is being criticized, what it
+Invoke the `kvb-think-listen` skill: what is criticized, what it should
-is meant to achieve, for whom, and under which constraints. Derive what you can
+achieve, for whom, under which constraints. Derive what you can from the
-from the artifact and its surroundings first; ask only what only the operator
+artifact and its surroundings first (code through the codebase-memory-mcp
-knows. A critique against the wrong goal is noise.
+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
+Restate the artifact and its intent at their strongest in two or three
-sentences. Criticize that version, never a weaker one you made up. If you cannot
+sentences; criticize that version, never a weaker one. If you cannot
-steelman it, you have not understood it yet; go back to listening.
+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
+1. **Goal fit**: the stated problem for the stated audience, or a neighbour?
-   a neighbouring one?
+2. **Correctness**: facts, logic, claimed cause-effect chains; which claim
-2. **Correctness** - are the facts, the logic, and the claimed cause-effect
+   lacks evidence?
-   chains right? Which claim lacks evidence?
+3. **Completeness**: missing cases, stakeholders, failure paths, definition of
-3. **Completeness** - missing cases, missing stakeholders, missing failure
+   done.
-   paths, missing definition of done.
+4. **Consistency**: contradictions inside the artifact or against its
-4. **Consistency** - contradictions inside the artifact or against its
+   neighbours; one truth stated twice in two versions.
-   neighbours; the same truth stated twice in two versions.
+5. **Simplicity**: mechanism, scope or wording the problem never asked for;
-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
+6. **Feasibility and cost**: effort, dependencies, step order, what blocks
-   what, what it costs to run and to maintain.
+   what, running and maintenance cost.
-7. **Risk** - security at trust boundaries, data loss, reversibility, blast
+7. **Risk**: security at trust boundaries, data loss, reversibility, blast
-   radius, what happens when it fails halfway.
+   radius, failure halfway.
-8. **People** - usability, accessibility, the reader's or user's actual path,
+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,
+10. **Ethics and compliance**: only where personal data, licences, law or
-    law, or fairness.
+    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.
+- **Thesis**: the point with its evidence.
-- **Antithesis**: independent defenders argue that the artifact is right as it
+- **Antithesis**: independent defenders argue the artifact is right or the
-  is, or that the constraint behind it is real; independent skeptics attack the
+  constraint behind it is real; independent skeptics attack the suggestion
-  suggested improvement for new problems it would cause.
+  for new problems it would cause.
-- **Synthesis**: keep the point, refine it, or drop it.
+- **Synthesis**: keep, refine or drop.
 
-Batch minor points into one dialectic round; run consequential points (high
+Batch minor points into one round; run consequential ones (high severity,
-severity, expensive to act on, or challenging a premise) one by one.
+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
+Close with at most three lines: how many points dialectic dropped and why, the
-why, the single change that helps most, and the `kvb-check-confidence` skill's numbers for
+single change that helps most, and the `kvb-check-confidence` skill's numbers
-the critique as a whole.
+for the whole critique.
 
 ## Rules
 
-- Every critique carries a concrete suggestion. A complaint without one becomes
+- Every critique carries a concrete suggestion; without one it becomes an open
-  an open question or is dropped.
+  question or is dropped.
-- Criticize the work, never the person. Direct wording, no sarcasm, no
+- 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
+- A point attacking a stated constraint or goal is labelled "challenges a
-  premise" and kept apart from points that work within it.
+  premise" and kept apart from points within it.
-- No taste or formatting nitpicks unless the operator asks for them.
+- 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
+   not assumption. Deep-inspect every source you can reach: the source code
-   git history; the running containers (exec, logs, inspect through whatever
+   (through the codebase-memory-mcp graph first: `search_graph`, `trace_path`,
-   make or CLI helpers the project exposes); CI logs and artifacts; tests; docs.
+   `get_architecture`, set up by the `kvb-agent-optimize` skill; grep and read
-   Cite `file:line` and command output — never a bare assertion.
+   after) and git history; the running containers (exec, logs, inspect through
-2. **Antithesis.** Spawn MULTIPLE independent skeptics (parallel subagents or a
+   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
+   sources itself and defaults to "refuted" on any concrete hole. Their
-   skeptics diverse lenses: correctness, an alternate mechanism, does-it-
+   number follows the stakes, since each skeptic costs a full agent run: one
-   reproduce, does-the-fix-break-something-else.
+   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
+  does, how a mechanism works or why components interact.
-  a file, function, role or module.
 ---
 
 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
+   order: inputs, transformations, side effects, outputs, with real files
-   files and line references.
+   and line references.
-3. Make the interactions explicit: which component induces, triggers, or
+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)
+   trip-wires (non-obvious ordering, escaping, caching, permission edges) in
-   as part of the flow, not as an appendix.
+   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
+  goes to kvb-create-requirement. Trigger on "was fehlt noch" or when asked
-  noch", or asked what to build next.
+  what to build next.
 ---
 
-Two blind spots produce different work: the code has defects of structure,
+The code has defects of structure, the product has gaps of use. This skill
-the product has gaps of use. This skill runs both lenses, ranks what comes
+runs both lenses, ranks the result and lets the operator choose. It writes no
-out, and lets the operator choose. It writes no file; the
+file; the `kvb-create-requirement` skill writes the requirement for every
-`kvb-create-requirement` skill writes the requirement for every pick.
+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
+Invoke the `kvb-check-principles` skill on the target. Its findings become
-candidates by severity: a violated SPOT, SRP, or trust boundary is work the
+requirement candidates by severity: a violated SPOT, SRP or trust boundary is
-product needs whether or not a user ever notices. Carry each finding's
+work the product needs whether or not a user notices. Carry each finding's
-`file:line` evidence forward — a requirement without it is a guess.
+`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
+Independently, look for what the product does not do yet. Anchor every gap in
-in something observable in the repository, never in an invented persona:
+something observable in the repository, never in an invented persona:
 
-- **Entry** — can someone install, configure, and run it without reading the
+- **Entry**: install, configure and run without reading the source? Missing
-  source? Missing `--help`, missing example config, an undocumented required
+  `--help`, example config, an undocumented required variable.
-  variable.
+- **Recovery**: does a failure say what to do next? A stack trace instead of
-- **Recovery** — does a failure tell the user what to do next? Errors that
+  the remediation, no dry-run, no undo or uninstall, no idempotent re-run.
-  print a stack trace instead of the remediation, no dry-run, no way to undo
+- **Feedback**: does a long operation report while it works? Silent minutes,
-  or uninstall, no idempotent re-run.
+  no progress, no exit summary.
-- **Feedback** — does a long operation say anything while it works? Silent
+- **Empty and edge states**: first run with no data, zero results, an expired
-  minutes, no progress, no exit summary.
+  credential, a partially completed run.
-- **Empty and edge states** — first run with no data, zero results, an
+- **Discoverability**: a capability nothing surfaces: undocumented flags,
-  expired credential, a partially completed run.
+  features reachable only by reading tests.
-- **Discoverability** — a capability that exists but nothing surfaces:
+- **Accessibility and locale**: output that assumes colour, a terminal width
-  undocumented flags, features reachable only by reading tests.
+  or one language.
-- **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
+Then apply `kvb-think-listen`: answer what you can from the code, docs and
-docs, and the git history yourself, and put only the genuinely open decisions
+git history yourself, and put only the genuinely open decisions to the
-to the operator with `AskUserQuestion`, `multiSelect: false`, so every
+operator with `AskUserQuestion`, `multiSelect: false` (radio buttons), at most
-question renders as radio buttons. At most four questions per call, each
+four questions per call, each option a real alternative, never one option
-option a real alternative — never one option plus filler:
+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
+2. **Which shape** the chosen one takes; for a feature typically `Minimal
-   `Minimal version that unblocks the user`, `Full version`, `Fix the
+   version that unblocks the user`, `Full version`, `Fix the underlying
-   underlying structure instead`, `Document the limitation and defer`.
+   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
+Run the `kvb-create-requirement` skill once per chosen candidate. Its context
-context step starts from the candidate's evidence and chosen shape; the
+step starts from the candidate's evidence and chosen shape; the rejected
-rejected shapes go into its Decisions section.
+shapes go into its Decisions section.
 
 ## Rules
 
-- Findings only: no file, no implementation, no refactor, no staging as
+- Findings only: no file, implementation, refactor or staging in this skill.
-  part of this skill.
+- Every candidate traces to evidence: a `file:line`, a failing path, a
-- Every candidate traces to evidence — a `file:line`, a failing path, a
+  missing artifact. "Would be nice" is dropped.
-  missing artifact. A candidate whose justification is "would be nice" is
+- Close with the `kvb-check-confidence` skill's numbers for the analysis: how
-  dropped.
+  sure the gaps are real, and what the passes did not cover.
-- 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
+4. **Listen and integrate.** Fold each answer in; a new answer often opens a
-   question — keep going.
+   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):