@korallis/k-pi 0.1.0

package/dist/kpi/kstack/generated/skills/no-comments/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: no-comments
+description: "Spawn Comment Sicko, fix accepted findings, and offer encodings for claimed constraints."
+disable-model-invocation: true
+---
+
+# No comments
+
+Spawn Comment Sicko. Act on accepted findings.
+
+Authoring agents defend comments. Defer to Comment Sicko's fresh perspective.
+
+## Scope
+
+Use the caller's files or diff. Otherwise use the current diff against the base branch, default `main`, including the working tree.
+
+## Steps
+
+1. Spawn `spawn_background` with `role: "Comment Sicko"`. Pass the scope. Do not restate its rules.
+2. Inspect its report and diff. Reject application-code edits, scope escapes, exception-protected deletions, misstated `MUST KILL` reasons, and flags that treat kept intentional code as guilty. Reshape flags on our-code surprises stay actionable. Do not restore those comments. A keep survives only with proof it is about something we cannot change. Audit missed scoped lint and TypeScript suppressions. Correctness or safety suppressions stay actionable `MUST KILL`s. Restore deletions only with exact exceptions and scoped proof. Before accepting thin `IMPORTANT` or `do not remove` kills or keeps, run `/how` or `/why` on their symbol. If a kill is ambiguous, do not restore. If a keep is refuted or still ambiguous, delete it. Revert and rerun one rejected report with the failure named. Reject a second, report it open, and fail `/no-comments`.
+3. Fix trivial accepted flags directly by deleting a dead path, dropping a parameter, or using the real API. If any fix needs a shape, run `/architect` once for the accepted set and surrounding code. Stop at the sketch. Architect shapes. Step 4 implements.
+4. Implement the smallest root-cause fix in scope. Remove every named workaround. If the root cause is out of scope, land the smallest in-scope fix and report the rest open. The **principle-fix-root-causes** and **principle-redesign-from-first-principles** skills guide intent only: fix real causes, redesign as if requirements always existed, never bolt on symptom guards. Neither authorizes widening the fence nor fixing instances outside it.
+5. Constraint comments say `do not remove`, `do not change wording`, or `talk to X before changing`. Leave keeps about things we cannot change. Offer the cheapest in-scope type, runtime, test, or CI lint. Wait for interactive approval. Unattended and eval require caller pre-approval. If approved, encode then delete. Otherwise delete, report the constraint open, and sketch out-of-scope work.
+6. Report the deletion count, restored comments, reruns, architect sketch, fixes, encoding offers, encodings, unenforced constraints, and other open work.

package/dist/kpi/kstack/generated/skills/playbook-arena/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: playbook-arena
+description: Compare two local K-π candidates for the same brief and graft the stronger one. Use for a bake-off, an arena run, or comparing two approaches.
+playbook: arena
+match: arena, bake-off, bakeoff, compare approaches, two attempts
+---
+
+# arena playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **plan** Freeze one brief both workers receive unchanged.
+- **implement** Call `spawn_background` for at most two arena workers on live configured K-π pools, and steer them with `communicate`.
+- **test** Compare their `candidate.json` files against the frozen acceptance criteria.
+- **review** Select or graft the smallest proven result.
+- **ship** Hand the grafted result to the shipping gate. Never merge an origin branch.

package/dist/kpi/kstack/generated/skills/playbook-autonomous-run/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: playbook-autonomous-run
+description: Run executable acceptance criteria through local K-π autopilot. Use for autonomous, autopilot, or unattended runs.
+playbook: autonomous-run
+match: autonomous, autopilot, unattended, overnight
+---
+
+# autonomous-run playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **specify** Refuse to start unless every required acceptance criterion is machine-executable.
+- **plan** Plan one vertical slice and freeze the plan.
+- **plan-check** Scaffold the slice before behaviour.
+- **implement** Implement inside the declared write bounds and dependency bounds.
+- **test** Run the gates. A failing gate ends the round; it does not lower the bar.
+- **review** Obtain a fresh isolated verdict.
+- **ship** Create one local commit and mark DONE. Never push or deploy.

package/dist/kpi/kstack/generated/skills/playbook-autopilot-full/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: playbook-autopilot-full
+description: Coordinate local K-π owners without remote merge authority. Use for a full autopilot coordination run across slices.
+playbook: autopilot-full
+match: autopilot-full, coordinate owners, full autopilot
+---
+
+# autopilot-full playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **plan** Order the slices and name one owner per slice.
+- **implement** Use at most two background K-π sessions and one writer. The parent reads contract files, not transcripts.
+- **test** Run the gates for each slice before starting the next.
+- **review** Obtain a verdict per slice.
+- **ship** Finish with DONE and an optional local commit after release approval. Never push, deploy, or merge origin.

package/dist/kpi/kstack/generated/skills/playbook-autopilot-stack/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: playbook-autopilot-stack
+description: Run linear local K-π slices without remote merge authority. Use for a stacked or sequential autopilot run.
+playbook: autopilot-stack
+match: autopilot-stack, stacked slices, linear slices
+---
+
+# autopilot-stack playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **plan** Order the vertical slices in graph order.
+- **implement** Run one slice at a time with at most two background sessions and one writer; hand off through contract files.
+- **test** Run the gates for the current slice.
+- **review** Obtain a verdict for the current slice.
+- **ship** Finish with DONE and linear local commits only after release approval. Never push, deploy, or merge origin.

package/dist/kpi/kstack/generated/skills/playbook-bug-fix/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: playbook-bug-fix
+description: Reproduce and repair one defect through the K-π gates. Use for a bug, a regression, broken behaviour, or a failing test.
+playbook: bug-fix
+match: bug, fix, broken, regression, defect, crash, fails
+---
+
+# bug-fix playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **specify** Reproduce the reported defect and write the reproduction down as the acceptance criterion.
+- **plan** Locate the root cause and state the regression contract the fix must hold.
+- **implement** Implement the narrowest source fix. Never suppress the symptom.
+- **test** Confirm the reproduction no longer triggers and the gates stay green.
+- **review** Obtain a fresh isolated verdict.
+- **ship** Create exactly one local Conventional Commit carrying the job marker.

package/dist/kpi/kstack/generated/skills/playbook-feature/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: playbook-feature
+description: Deliver one vertical feature slice through the K-π gates. Use for a new capability, a feature request, or adding behaviour to a module.
+playbook: feature
+match: feature, add, implement, build, support, introduce
+---
+
+# feature playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **specify** Specify executable acceptance criteria and freeze them.
+- **plan** Research the repository and current external practice, then plan one vertical Dune module.
+- **plan-check** Scaffold the module folder, its public interface, and its test twin before behaviour.
+- **implement** Implement the smallest change that satisfies the frozen criteria.
+- **test** Run the declared quality gates and record their output as evidence.
+- **review** Obtain a fresh isolated verdict against the frozen criteria.
+- **ship** Create exactly one local Conventional Commit carrying the job marker.

package/dist/kpi/kstack/generated/skills/playbook-investigation/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: playbook-investigation
+description: Produce evidence about a system without changing product code. Use to investigate, research, diagnose, or explain why something behaves as it does.
+playbook: investigation
+match: investigate, research, diagnose, why, explain, understand, audit
+---
+
+# investigation playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **specify** State the question and the falsifiable hypotheses.
+- **plan** Inspect repository sources and current authoritative references.
+- **implement** Run one focused experiment. Write it under a scratch path, never into product code. `skip: an investigation changes no product code`
+- **test** Record the experiment's output as evidence.
+- **review** Write the conclusion and the evidence it rests on.
+- **ship** Stop without shipping. `skip: an investigation produces evidence, not a commit`

package/dist/kpi/kstack/generated/skills/playbook-shipping/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: playbook-shipping
+description: Ship an already approved K-π candidate as one local commit. Use to ship, release, or land work whose verdict is already approved.
+playbook: shipping
+match: ship, release, land, cut a release
+---
+
+# shipping playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **test** Verify the recorded evidence is fresh for the current HEAD.
+- **review** Verify bounds held and that `verdict.approved` is true.
+- **ship** Create exactly one Conventional Commit with the job marker, then mark DONE. Never push or deploy.

package/dist/kpi/kstack/generated/skills/playbook-swarm/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: playbook-swarm
+description: Fan out at most two disjoint local K-π workers for coverage. Use for a swarm, a fan-out, or splitting independent slices.
+playbook: swarm
+match: swarm, fan out, fan-out, parallelize, split the work
+---
+
+# swarm playbook
+
+Every step below is a K-π graph node. The graph decides which node runs next; a
+step never jumps ahead of its gate. A step carrying `skip:` is kept in the todo
+list with its reason rather than deleted, so the record shows what was not done.
+
+## Steps
+
+- **plan** Split the request into at most two non-overlapping slices with no shared files.
+- **implement** Call `spawn_background` for each local worker and steer with `communicate`, one writer at a time.
+- **test** Read each worker's contract file. Never copy a worker transcript.
+- **review** Aggregate the evidence and stop the workers.
+- **ship** Hand the aggregate to the shipping gate.

package/dist/kpi/kstack/generated/skills/principle-boundary-discipline/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: principle-boundary-discipline
+description: "Apply when wiring validation, error handling, or framework adapters. Concentrate guards at system boundaries (CLI, config, network, external APIs); trust internal types and keep business logic in pure functions."
+disable-model-invocation: true
+---
+
+# Boundary Discipline
+
+Place validation, type narrowing, and error handling at system boundaries. Trust internal code unconditionally. Business logic lives in pure functions; the shell is thin and mechanical.
+
+**Why:** Scattered validation is noisy, redundant, and gives a false sense of safety. Validate data once at the boundary. Keep logic out of framework wiring so it can be tested without the framework.
+
+**The pattern:**
+- **At boundaries** (CLI args, config files, external APIs, network protocols): validate, return errors, handle defensively.
+- **Inside the system:** typed data, error propagation, no re-validation. Trust the types.
+- **Across the boundary.** Expose domain concepts, not the boundary's private representation. Keep general-purpose mechanism inside and special-purpose policy at the edge.
+
+**Applications:**
+
+Validation and error handling:
+- Validate config at parse time (the boundary), not inside business logic
+- Parse raw data into domain types at the boundary
+- Do not re-export transport, storage, framework, or wire types through the public surface
+- No redundant nil checks deep in call chains if the boundary already validated
+
+Code organization:
+- Business logic in pure functions with no framework dependencies
+- Parse functions: pure transforms from raw bytes to typed state
+- Prompt construction: structured state in, string out
+- Scoring and assessment: pure transforms from state to results
+
+**The tests:**
+- "Is this data crossing a system boundary right now?" If not, validation is redundant.
+- "Can this be a pure function that the shell just calls?" If yes, extract it.

package/dist/kpi/kstack/generated/skills/principle-build-the-lever/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: principle-build-the-lever
+description: "Apply to any non-trivial work, not just bulk work: edits, migrations, analyses, checks. Build the tool that does it or proves it (codemod, script, generator, or a skill your background K-π workers follow) instead of working by hand. The tool is the artifact a reviewer can rerun."
+disable-model-invocation: true
+---
+# Build the Lever
+
+When the work isn't trivial, build the tool that does it instead of doing it by hand.
+
+**Why:** Two payoffs. Throughput: a codemod, generator, or script does the work the same way every time and reruns for free. Confidence: the tool is one artifact a reviewer can read and rerun to check the work. Hand-done changes can only be re-verified by redoing them. A deterministic script turns "trust me" into "run this".
+
+**Pattern:** Default to building the lever. Skip it only when the task is genuinely trivial, a couple of obvious edits you can see at a glance.
+
+- Do the first unit by hand to learn the recipe, then build the tool. Prove it by rerunning it on that unit and diffing against your hand-done version. Make the lever safe to rerun. A reviewer will.
+- Codemod or script for edits, generator for repetitive files, a dump-to-sqlite query for analysis, a rerunnable check for verification.
+- A deterministic lever beats fan-out. If the tool can process every unit in one pass, run it yourself; don't fan out delegates to hand-apply what a script can do.
+- When you fan work out to background K-π workers, write the lever as a skill they all read: the recipe, the verification contract, and the do-not-touch fences in one artifact, so every delegate inherits the same hardened version instead of re-explaining it per prompt and watching each one drift. Keep it outside the delegates' write scope so they can't quietly edit the contract.
+- Applying this principle produces a file. If you cited it and there is no codemod, script, generator, or delegate skill in the diff, you didn't apply it.
+- Commit the lever when the work outlives the session, so the next run reruns it instead of redoing it.
+
+**Balance:** The bar is triviality, not repetition. A one-off still earns a lever when the lever is what makes the work checkable. Per the [Laziness Protocol](../principle-laziness-protocol/SKILL.md), build the smallest script that does or proves the job, never a framework.
+
+Distinct from [Encode Lessons in Structure](../principle-encode-lessons-in-structure/SKILL.md), which makes a recurring instruction a durable guardrail. This is throughput and reviewability on the work in front of you. For scripting the verification itself, see [Prove It Works](../principle-prove-it-works/SKILL.md).

package/dist/kpi/kstack/generated/skills/principle-encode-lessons-in-structure/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: principle-encode-lessons-in-structure
+description: "Apply when you catch yourself writing the same instruction a second time, or notice a recurring correction. Encode the rule as a lint, metadata flag, runtime check, or script instead of more text."
+disable-model-invocation: true
+---
+
+# Encode Lessons in Structure
+
+Encode recurring fixes in mechanisms (tools, code, metadata, automation) instead of textual instructions. Every error, human correction, and unexpected outcome is a learning signal. Capture it, route it, and close the loop.
+
+**Why:** Textual instructions are easy to miss. They require the reader to notice, remember, and comply. Structural mechanisms (lint rules, metadata flags, runtime checks, automation scripts) enforce the rule without cooperation.
+
+**Pattern:**
+When you catch yourself writing the same instruction a second time:
+1. Ask: can this be a lint rule, a metadata flag, a runtime check, or a script?
+2. If yes, encode it. Delete the instruction
+3. If no (genuinely requires judgment), make the instruction more prominent and add an example of the failure mode
+
+**Pick the strongest rung.** When more than one mechanism would work, choose the strongest the situation allows (an unrepresentable state that cannot compile, then a lint or banned API that fails CI, then a canonical helper, then a runtime check), because agents copy whatever the surrounding code already does and a weaker guard becomes the next template.
+
+**Corollary:** Don't paper over symptoms. If the fix is structural, ONLY use the structural fix. The instruction IS the symptom.
+
+**Feedback loop:**
+- **Capture every correction.** When the human intervenes or tests fail, decide if it's a one-off or a pattern.
+- **Route to the right layer.** One-off -> brain note. Recurring fix -> skill or lint rule. Systemic issue -> principle.
+- **Close the loop.** Don't just record. Apply now or create a concrete todo.
+
+**Anti-patterns:**
+- Acknowledging without recording ("I'll keep that in mind" does not persist)
+- Recording without routing (a brain note about a lint rule that should exist is wasted unless the lint rule gets implemented)
+- Fixing without generalizing (fixing one instance while leaving the recurring pattern intact)

package/dist/kpi/kstack/generated/skills/principle-exhaust-the-design-space/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: principle-exhaust-the-design-space
+description: "Apply when facing a novel UI interaction or architectural decision with no precedent in the codebase. Build 2-3 competing prototypes and compare side by side before committing."
+disable-model-invocation: true
+---
+
+# Exhaust the Design Space
+
+When a novel interaction or architectural decision has no established precedent, explore several concrete alternatives before implementation. Building the wrong thing costs more than exploring three options.
+
+**The rule.** When the right answer is not obvious, build 2-3 competing prototypes or sketches. Compare them side by side. Only then commit. Design it twice is this rule by another name. A second flavor of the first shape does not count.
+
+**When it applies:**
+- Novel UI interactions (no prior art in the codebase)
+- Architectural choices with multiple viable approaches
+- Product design decisions where user experience depends on feel, not logic
+
+**When it doesn't:**
+- Mechanical implementation where the pattern is established
+- Bug fixes or refactors with a clear target state
+- Changes where constraints dictate a single viable approach

package/dist/kpi/kstack/generated/skills/principle-experience-first/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: principle-experience-first
+description: "Apply when product, UX, or feature-scope tradeoffs come up. Choose user delight over implementation convenience; ship fewer polished features over more rough ones."
+disable-model-invocation: true
+---
+
+# Experience First
+
+The product is the experience. Every technical decision either helps or hurts it. When implementation convenience conflicts with user delight, choose delight.
+
+- Say no to 1,000 things (every feature, control, and option must earn its place)
+- Ship less, ship better (polished experience with three features beats rough one with ten)
+- Prototype before committing (design decisions are cheaper in throwaway HTML than production code)
+- Sweat the details (transitions, alignment, spacing, feedback, error states)
+- Tighten the core loop (every feature should serve the central workflow or get out of the way)
+
+The user is whoever consumes the work. For a UI that is the end user. For a library or an internal API it is the colleague who imports it. The engineer who maintains the code next is a user too. Weigh their experience the same way, and explain impact from their seat.
+
+Foundations should serve the experience, not the other way around. Foundational thinking governs the *sequence* of work; this principle governs the *target*.

package/dist/kpi/kstack/generated/skills/principle-fix-root-causes/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: principle-fix-root-causes
+description: "Apply when debugging. Trace each symptom to its root cause and fix it there; reproduce first, ask why until you reach it, resist nil-check guards that silence crashes."
+disable-model-invocation: true
+---
+
+# Fix Root Causes
+
+When debugging, do not paper over symptoms. Trace every problem to its root cause and fix it there.
+
+**Why:** Symptom fixes accumulate. Each workaround makes the system harder to reason about, and the real bug remains. Root-cause fixes are slower upfront but reduce total debugging time.
+
+**Pattern:**
+- Reproduce first (if you can't reproduce it, you can't verify your fix)
+- Ask "why" until you hit the root cause
+- Resist the urge to add guards (adding a nil check to silence a crash is a symptom fix)
+- If a workaround needs a paragraph-long comment to justify it, the code is wrong (fix the code, not the comment)
+- Check for the pattern, not just the instance (grep for the same pattern, fix all instances)
+- When stuck, instrument. Don't guess (add logging, read the actual error)
+
+**Restart bugs: suspect state before code**
+
+Code doesn't change between runs. State does. When something "fails after restart," suspect stale persistent state first: config files, caches, lock files, serialized state. If clearing a state file restores behavior, prioritize state validation as the fix.

package/dist/kpi/kstack/generated/skills/principle-foundational-thinking/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: principle-foundational-thinking
+description: "Apply before writing logic: choosing core types and data structures, sequencing scaffold-vs-feature work, asking what concurrent actors share. Get the data structures right so downstream code becomes obvious."
+disable-model-invocation: true
+---
+
+# Foundational Thinking
+
+**Structural decisions** protect option value. **Code-level decisions** protect simplicity. Over-engineering is often a premature decision that closes doors. The right foundational data structure keeps doors open.
+
+**Data structures first.** Get the data shape right before writing logic. The right shape makes downstream code obvious. Define core types early, trace every access pattern, and choose structures that match the dominant paths. A data-structure change late is a rewrite. Early, it is often a one-line diff.
+
+At code level, DRY the structure, not every line. Types and data models should converge. Three similar statements still beat a premature abstraction. Prefer explicit over clever. Test behavior and edge cases, not line counts.
+
+**Concurrency corollary.** Before sharing state between actors, ask "what happens if another actor modifies this concurrently?" If not "nothing", isolate.
+
+**Scaffold first.** If something helps every later phase, do it first. Ask "does every subsequent phase benefit from this existing?" CI, linting, test infrastructure, and shared types are scaffold. Sequence for option value: setup before features, tests before fixes. Keep commits small and single-purpose.
+
+Each increment should land a coherent abstraction or deepen one that exists. Do not spread a new capability across callers as special-case coordination.
+
+Subtraction comes before scaffolding: remove dead weight first, then lay foundations.

package/dist/kpi/kstack/generated/skills/principle-guard-the-context-window/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: principle-guard-the-context-window
+description: "Apply when context is filling up: large outputs, long files, repeated reads, fan-out planning. Route bulk to background K-π workers; keep summaries in the main thread, not raw payloads."
+disable-model-invocation: true
+---
+
+# Guard the Context Window
+
+The context window is finite and non-renewable within a session. Every token that enters should earn its place.
+
+**Why:** Context overflow degrades reasoning quality, creates compression artifacts, and halts progress. Unlike compute or time, context spent inside a session cannot be reclaimed.
+
+**Pattern:**
+- **Isolate large payloads.** Route verbose outputs, screenshots, and large documents to background K-π workers. The main context gets summaries, not raw data.
+- **Don't read what you won't use.** Read selectively based on relevance. If a file isn't needed for the current task, skip it.
+- **Keep frequently used content inline.** Templates and references used on every invocation belong in the skill file, not in separate files that cost a read each time.
+- **Size phases and cap scope.** Limit files per phase, set turn budgets, account for mechanism costs.

package/dist/kpi/kstack/generated/skills/principle-laziness-protocol/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: principle-laziness-protocol
+description: "Apply when refactoring, evaluating diff size, or tempted to add abstractions, layers, or signal threading. Bias toward deletion and the smallest change that solves the problem."
+disable-model-invocation: true
+---
+
+# Laziness Protocol
+
+Writing code is cheap for you, which makes over-engineering easy. Counter it by borrowing a human maintainer's fatigue. Aim for the most result with the least code and complexity.
+
+- **Prefer deletion.** When asked to refactor or improve, look for removals before additions.
+- **Maintain a flat call hierarchy.** Avoid deep call chains. A rich interface that hides substantial work is not a deep call chain. If answering a question requires tracing through more than 3 files or layers, flatten it.
+- **Consolidate decisions.** Do not repeat the same choice in several places. Put it behind one source of truth and pass the result as a simple flag.
+- **Minimize the diff.** Make the smallest change that solves the problem. Fewer lines beat "elegant" boilerplate.
+- **Question the threading.** If a task asks you to pass a new signal through types, schemas, pipelines, or similar layers, stop and look for a more direct path.
+- **Sweat the small leaks.** Remove tiny pass-throughs, representation leaks, and duplicated choices before they spread. Small leaks compound into permanent coordination costs.
+
+**Prime directive:** If a human developer would find the code exhausting to maintain, it is a bad solution. Be lazy. Stay simple.

package/dist/kpi/kstack/generated/skills/principle-make-operations-idempotent/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: principle-make-operations-idempotent
+description: "Apply when designing commands, lifecycle steps, or processing loops that run amid crashes, restarts, and retries. Converge to the same end state regardless of partial prior runs."
+disable-model-invocation: true
+---
+
+# Make Operations Idempotent
+
+Design operations so they converge to the correct state regardless of how many times they run or where they start from. Every state-mutating operation should answer: "What happens if this runs twice? What happens if the previous run crashed halfway?"
+
+**Why:** Commands, lifecycle operations, and processing loops run where crashes, restarts, and retries are normal. If partial state changes the next run's outcome, every restart becomes a debugging session.
+
+**The pattern:**
+- Convergent startup: scan for existing state, clean stale artifacts, adopt live sessions
+- Content-based cleanup: compare by content equivalence, not creation order
+- Self-healing locks: use PID-based stale lock detection
+- Idempotent scheduling: failed work respawns cleanly, fresh input regenerated after each cycle
+
+**The test:**
+1. What happens if this runs twice in a row?
+2. What happens if the previous run crashed at every possible point?
+3. Does re-execution converge to the same end state?
+
+If any answer is "it depends on what state was left behind," the operation needs a reconciliation step.

package/dist/kpi/kstack/generated/skills/principle-migrate-callers-then-delete-legacy-apis/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: principle-migrate-callers-then-delete-legacy-apis
+description: "Apply when introducing a new internal API while old callers still exist. Migrate callers and delete the old API in the same wave instead of preserving compatibility layers."
+disable-model-invocation: true
+---
+
+# Migrate Callers Then Delete Legacy APIs
+
+When we decide a new API is the right design, migrate callers and remove the old API in the same refactor wave instead of preserving compatibility layers.
+
+**Rule:**
+- Do not keep legacy API paths alive only because internal callers still exist
+- Inventory callers, migrate them, and delete the old API immediately
+- Treat temporary adapters as exceptional and time-boxed, not default architecture
+- Update tests to assert the new contract, and delete tests that only protect pre-refactor implementation details
+
+**When this applies:**
+- No external users depend on backward compatibility
+- The project can absorb coordinated breaking changes
+- The new API is part of a simplification or refactor initiative
+
+Keeping both old and new APIs creates dual-path complexity, slows cleanup, and makes the codebase feel append-only.

package/dist/kpi/kstack/generated/skills/principle-minimize-reader-load/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: principle-minimize-reader-load
+description: "Apply when reviewing or shaping code that's hard to trace. Count layers between question and answer, and hidden state in the reader's head; collapse one-caller wrappers and shrink mutable scope."
+disable-model-invocation: true
+---
+
+# Minimize Reader Load
+
+Maintainability is the work a reader must do to understand code. Track two axes:
+1. **Layers to trace.** How many indirections sit between the question and the answer.
+2. **State to hold.** How much hidden or mutable context the reader must keep in their head.
+
+**Why:** Code is read far more than it is written. LOC, cyclomatic complexity, and "clean architecture" are proxies. Reader load is the thing that matters. The two axes are independent. A flat file with 50 globals can be as hard to reason about as a 6-layer adapter stack. Guard both. This is the human analog of [Guard the Context Window](../principle-guard-the-context-window/SKILL.md): working memory is finite for readers too.
+
+**The pattern:**
+- **Collapse layers** that do not earn their keep: wrappers with one caller, adapters with no second implementation, indirection introduced for a future that never came. Inline them.
+- **Make adjacent layers change the abstraction.** A layer that repeats the same methods and arguments adds reader load without compression. Collapse pass-through layers.
+- **Demand interface compression.** A broad interface that hides little complexity makes readers learn both the surface and the implementation. Prefer boundaries that hide meaningful decisions.
+- **Shrink state scope:** prefer pure functions (returns over mutations), locals over fields, fields over module state, and module state over globals. Derive instead of sync.
+- **Name the invariant at the boundary,** not in every consumer, so the reader learns it once.
+- Before adding a layer or a piece of state, ask: does this reduce reader load somewhere else by at least as much?
+
+**The test:** Can a new reader answer "where does X come from?" and "what can change X?" in under 30 seconds? If not, cut layers or cut state.

package/dist/kpi/kstack/generated/skills/principle-model-the-domain/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: principle-model-the-domain
+description: "Apply when writing stateful logic, or when code branches a lot or repeats a shape assumption across files. Encode the domain in a structure instead of scattered conditionals."
+disable-model-invocation: true
+---
+
+# Model the Domain
+
+Encode the real domain in a data structure instead of scattering it across conditionals.
+
+**Why:** Scattered booleans, repeated shape assumptions, and branching spread across files are accidental complexity. A structure that matches the domain makes invalid states unrepresentable and deletes branches. Choosing it at write time is cheap; recovering it later reads as a refactor and gets deferred.
+
+**Reach for structures like these:**
+
+- A state machine instead of scattered booleans, phases, or lifecycle checks.
+- A typed object/model instead of loose parameters or repeated shape assumptions.
+- A map, registry, lookup table, or discriminated union instead of branching spread across files.
+- A reducer or command/event model instead of ad hoc state mutations.
+- A module organized around one body of domain knowledge instead of a sequence such as load, validate, transform, and save. Execution order is not ownership.
+- A small module boundary that gathers repeated behavior, ownership, or invariants.
+- A queue, cache, index, graph/tree, or normalized collection where the data access pattern calls for it.
+- Any other structure that fits. The list above covers the common cases only. When none fits, work out what the code must never allow and how the data gets read, then find the structure that encodes exactly that.
+
+Do not force an abstraction. Prefer boring code if the current shape is already clear, local, and unlikely to grow. Be skeptical of an abstraction that adds indirection without removing branches, duplicated rules, invalid states, or lifecycle risk.
+
+The tell that you skipped this is a new feature that grows an existing if/else chain by one more branch, or a second boolean that must stay in sync with the first. Temporal decomposition is another tell. Phase-named modules repeat the same domain rules across steps.

package/dist/kpi/kstack/generated/skills/principle-never-block-on-the-human/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: principle-never-block-on-the-human
+description: "Apply when tempted to ask 'should I do X?' on reversible work. Proceed, present the result, let the human course-correct after the fact; reserve confirmation for irreversible actions."
+disable-model-invocation: true
+---
+
+# Never Block on the Human
+
+The human supervises asynchronously. Agents must stay unblocked: make reasonable decisions, proceed, and let the human course-correct after the fact. Code is cheap. Waiting is expensive.
+
+**Why:** Every permission pause stalls the pipeline and makes the human the bottleneck. Since code changes are reversible and reviewable, a wrong decision usually costs less than blocking.
+
+**Pattern:**
+- **Proceed, then present.** Do the work, show the result. Don't ask "should I do X?" Do X, explain why.
+- **Reserve questions for genuine ambiguity.** Ask only when you truly cannot infer intent from context.
+- **Make the system self-healing.** When you notice a problem, log it and fix it in the next round.
+- **Supervision is async.** The human reviews plans, diffs, and changes on their own schedule. Design workflows for review-after-the-fact.
+- **Code is cheap, attention is scarce.** A wrong implementation costs minutes to fix. A blocked agent costs the human's attention to unblock.
+
+**Boundaries:**
+- **Irreversible actions** (force-push, delete production data, send external messages) still require confirmation.
+- **Reversible actions** (write code, edit notes, split tasks) should proceed without blocking.
+- **Product direction** comes from the human; *execution* should not block.

package/dist/kpi/kstack/generated/skills/principle-outcome-oriented-execution/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: principle-outcome-oriented-execution
+description: "Apply during planned rewrites and migrations with explicit phase boundaries. Converge on the target architecture; don't preserve smooth intermediate states with throwaway compatibility code."
+disable-model-invocation: true
+---
+
+# Outcome-Oriented Execution
+
+Optimize for the intended, verifiable end state rather than preserving smooth intermediate states.
+
+**Why:** Keeping every intermediate step fully stable often creates temporary compatibility code that becomes long-lived debt. Converge on the target architecture and prove correctness at explicit verification boundaries.
+
+**Core rule:**
+- Prioritize end-state integrity over transitional stability
+- Intermediate breakage is acceptable when it is planned, scoped, and reversible
+- Always run final verification before declaring done
+
+**Guardrails:**
+- Use this for planned rewrites and migrations with explicit phase boundaries
+- Declare where temporary breakage is acceptable
+- Keep high-signal checks for actively touched areas while migrating
+- Require full static and runtime verification at plan completion

package/dist/kpi/kstack/generated/skills/principle-prove-it-works/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: principle-prove-it-works
+description: "Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'"
+disable-model-invocation: true
+---
+
+# Prove It Works
+
+Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or "it compiles."
+
+**Why:** Unverified work has unknown correctness. Indirect verification (file mtimes, output freshness, agent self-reports, cached screenshots) feels cheaper than direct observation. Acting on a wrong inference costs far more than checking the source.
+
+**Pattern:** After completing any task, ask: "how do I prove this actually works?"
+
+Check the real thing, not a proxy:
+- Check process liveness directly, not indirectly through derived state
+- Read the actual value, not a cached or derived representation
+- When verification fails, suspect the observation method before suspecting the system
+
+Code and features:
+1. Build it (necessary but not sufficient)
+2. Run it and exercise the actual feature path
+3. Check the full chain: does data flow from input to output?
+4. For integrations, test the full communication path end-to-end
+
+Delegation: trust artifacts, not self-reports.
+When verifying delegated work, inspect the actual output artifact (git diff, file contents, runtime behavior), not the delegate's summary. Agents report what they intended, not always what happened.
+
+## Script the check when you can
+
+The strongest proof is a deterministic script that re-runs the same comparison, not a one-time eyeball. Write the script, run it, and keep its output as an artifact a reviewer can re-run instead of trusting your word. A script comparing the old and new compiled output catches what a glance misses.
+
+Keep the artifact visible for the human. Commit it only for large or complex work where the trail has to be auditable later, like a big port or migration (the **show-me-your-work** skill). Most work just needs it visible, not committed.