These skills coordinate long-running agent work, durable learning, and user-intent discovery.
k-ai-kb
k-proof
| Field | Value |
|---|
| Use when | an explicit proof-ledger/receipt request, auditable security/auth/data-migration/destructive effect, or named handoff/resume consumer needs a durable freeform receipt |
| Source | exact_k-proof |
| CLI | ,proof stores proof state outside worktrees under $AGENT_PROOF_HOME, $XDG_STATE_HOME, or ~/.local/state; reports require a finalized ledger with an intact seal |
| Boundary | runtime/UI/external checks, multi-file scope, failed commands, and late completion challenges use inline evidence unless one of the receipt triggers above independently applies |
k-proof is available in two ways. Explicit receipt requests route through the skill frontmatter and SKILL.md. Non-review/non-build iteration gets the same narrow receipt gate from the always-on SOP and the shared verification prefix injected by session hooks, Pi, tmux prompt wrapping, and subagent profile templates. The ledger is a durable receipt, not verification itself: evidence collection remains mandatory and inline by default. When a receipt trigger applies, choose the topic and criteria before ledger-bound evidence collection, finalize the ledger, and only then generate a report.
| Field | Value |
|---|
| Routing | model-invoked only after that explicit user intent; ordinary task size, complexity, or instructions to continue never trigger it |
k-interview-me
| Field | Value |
|---|
| Use when | reverse-interviewing the user until intent is fully clear |
| Source | exact_k-interview-me |
| Routing | manual |
k-spec
| Field | Value |
|---|
| Use when | developing an idea, feature request, or bug into a spec packet with red-capable acceptance checks |
| Source | exact_k-spec |
Fork-closing consults a domain overlay's planning fork checklist when the verified target repo has one (currently k-elastic-domain for elastic/kibana). Forks that cannot close locally (external sign-off, another team's decision) go in the packet's External dependencies section — owner, blocked criteria, recommended default — instead of blocking assembly; consumers must not start blocked criteria.
k-build
| Field | Value |
|---|
| Use when | hands-free in-session implementation of an approved spec packet (two human gates: packet approval, final report) |
| Source | exact_k-build |
| Routing | manual |
k-text-tournament
| Field | Value |
|---|
| Use when | automatically comparing three plausible edits before a material human-maintained prose rewrite |
| Source | exact_k-text-tournament |
| Routing | model-invoked |
| Boundary | interactive turns use only a cross-family two-order winner; detached orchestration relies on its scheduled review stages instead of a nested judge |
k-improve-local
| Field | Value |
|---|
| Use when | proposing one evidence-backed improvement to local changes |
| Source | exact_k-improve-local |
| Routing | manual |
k-improve-branch
| Field | Value |
|---|
| Use when | proposing one evidence-backed improvement to the current branch, PR, or issue goal |
| Source | exact_k-improve-branch |
| Routing | manual |
k-improve-targeted
| Field | Value |
|---|
| Use when | proposing one evidence-backed improvement to a targeted codebase area |
| Source | exact_k-improve-targeted |
| Routing | manual |
k-improve-codebase
| Field | Value |
|---|
| Use when | proposing one evidence-backed improvement to the whole codebase |
| Source | exact_k-improve-codebase |
| Routing | manual |