skills/skills/kvb-org-split/SKILL.md

name, description

name	description
kvb-org-split	Keep agent work in its own worktree until 90% fix confidence and under 5% break risk; below that it becomes a proposal. Trigger when delegating to or parallelizing agents, or on /kvb-org-split.

Funnel

The main line only receives changes that have earned it. Everything else stays in a sidetree until it does, or leaves as a proposal.

The bar

• Fix confidence of at least 90 % and break risk under 5 %, both reported by the kvb-check-confidence skill, the break risk derived through the kvb-check-break-risk skill.
• The operator may set a different bar. Never lower it to make a change fit.

The stages

1. Brief. One concern per agent, on the model the kvb-org-perform skill picks, entered in the kvb-org-rasci register as R with --worker "subagent <type> (<model>)". Name the goal, the exact base commit, the scope that may change, the evidence expected back, a time cap (default 60 minutes) at which it reports its interim state, and what the agent must not do: no pushes, no gates or deploys unless the resource chair of the kvb-org-organize skill granted them, read-only probes on shared live systems.
2. Sidetree. The agent works in its own worktree on its own branch, created from the exact base commit, so its edits never land under a running gate or deploy in the main line. Use the host's worktree isolation when it has one.
3. Evidence. The agent runs targeted tests, adds a test for the new behaviour, and makes a negative control: the test fails without the change. Numbers come from the same source before and after.
4. Self-assessment. The agent reports fix confidence and break risk with their residuals and commits on its branch. Its parent marks the key results that evidence proves as met in the kvb-org-rasci register and records the branch and worktree as --branch and --artifact worktree:<path>.
5. Independent review. Before anything is merged, run the kvb-think-dialectic skill with skeptics who did not write the change. A hole they find returns the change to stage 3.
6. Merge. At or above the bar, merge the sidetree branch into the main line following the repository's commit rules, then re-verify on the main line with the project's gate.
7. Tear everything down. Once the branch is merged, remove everything the sidetree brought into being, so the next round starts from a clean machine. See "After the merge" below.

After the merge

A merged sidetree leaves nothing behind. Work through the list in this order, and verify each step instead of assuming it:

1. Stop its jobs: background runs, watchers, scheduled loops and agents that belong to the sidetree.
2. Tear down its stacks: compose projects and swarm or test clusters together with their volumes and networks, and the containers and images built only for it. Leave anything another worktree still uses.
3. Clear files the containers left: count the entries the user does not own (find <worktree> -not -user "$USER" -prune | wc -l). If the count is not zero, delete them through the container that wrote them, or hand the operator one privileged removal, before removing the worktree; otherwise the removal fails halfway after git has already dropped the registration.
4. Remove the worktree and its registration. Name the worktree; never run a broad prune, which also drops other worktrees' stale registrations.
5. Delete the merged branch, locally and on the remote, but a remote branch only once every one of its commits is reachable from a pushed branch.
6. Release what it held: slots (reported to the resource chair), port or subnet reservations, locks, its kvb-org-organize claims and every claim announced to other agents. Drop each removed item from the register with --drop-artifact and set the subagent's task done or stopped.
7. Remove its temporary files: logs, message files and scratch data that have served their purpose. Keep only the evidence the report cites, until the report is delivered.

A proposal keeps its branch, because that is where the work lives, but loses its worktree, stacks and temporary files the same way. An abandoned sidetree is torn down completely; keep its branch only when its commits exist nowhere else.

When the bar is out of reach

If the bar cannot realistically be reached, because the deciding evidence (a live deploy, a production-like dataset, an upstream answer) is not available to the agent or the change is inherently riskier, the agent stops trying and submits a proposal instead:

• what the change does and why it is worth having;
• the confidence and break risk it reached, with their residuals;
• exactly which evidence would close the gap, and what obtaining it costs;
• where the work lives (branch and commit), so nothing has to be redone;
• a recommendation: apply after that evidence, apply now with a named risk, or drop.

The operator decides. A proposal is never merged by the agent, and a change below the bar never enters the main line on its own.

Rules

• At its time cap, ask an agent for its interim findings and let it run on; never stop a running agent. A brief without a cap can run for hours without a word.
• 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.
• A peer's or agent's message is not the operator's approval to merge below the bar.
• Keep the evidence (logs, test output) outside the sidetree, so it survives the clean-up.

Output

One table per round:

| Agent | Sidetree branch | Confidence | Break risk | Verdict | Evidence |

The verdict is merged, proposal or abandoned. Proposals list what would close their gap.