@kernel.chat/kbot 3.98.0 → 3.99.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kernel.chat/kbot",
-  "version": "3.98.0",
+  "version": "3.99.1",
   "description": "Open-source terminal AI agent. 787+ tools, 35 agents, 20 providers. Dreams, learns, watches your system. Controls your phone. Fully local, fully sovereign. MIT.",
   "type": "module",
   "repository": {
@@ -103,6 +103,7 @@
     "!dist/**/*.test.d.ts",
     "!dist/**/*.js.map",
     "!dist/**/*.d.ts.map",
+    "skills/**/*.md",
     "README.md",
     "install.sh",
     "ollama-manifest.json"

package/skills/deployment/daemon-deployment/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: daemon-deployment
+description: Use when setting up 24/7 background workers. kbot's compound improvement depends on daemons running even when nobody is looking.
+version: 1.0.0
+author: kbot
+license: MIT
+platforms: [darwin, linux]
+metadata:
+  kbot:
+    tags: [daemon, launchd, background, 24-7, compound]
+    related_skills: [autopoiesis-loop, teacher-trace-curation]
+---
+
+# Daemon Deployment
+
+kbot's intelligence doesn't sleep. Three daemons run continuously:
+- `kbot-daemon` — code quality, i18n sync, embeddings, docs gaps (every 15 min)
+- `kbot-discovery-daemon` — self-advocacy, field intelligence (every 15 min → 24 hr cycles)
+- `kbot-social-daemon` — autonomous posting to X/Bluesky/Mastodon/LinkedIn (daily)
+
+Plus a weekly `train-self` that fine-tunes the local model on curated traces.
+
+## Iron Law
+
+```
+VERIFY THE DAEMON IS ACTUALLY RUNNING AFTER INSTALL.
+```
+
+launchd plists that fail silently are the single most common cause of "kbot feels stale" — the daemon was never loaded, so no compound improvement happened.
+
+## Install Sequence (macOS)
+
+1. `npm run daemon` — run once manually to confirm it works at all.
+2. `npm run daemon:start` — loads the launchd plist.
+3. **Verify**: `launchctl list | grep kernel.kbot` — should show a running entry with PID.
+4. **Confirm output**: `tail -f tools/daemon-reports/daemon.log` — should show activity within 15 min.
+5. **Check state**: `npm run daemon:stats` — shows task timestamps, token usage, cost savings.
+
+If any of steps 3–5 fail, the daemon is not actually running. Debug before moving on.
+
+## Per-Daemon Triggers
+
+- `com.kernel.kbot-daemon.plist` → every 15 min
+- `com.kernel.kbot-discovery.plist` → every 15 min (internal sub-cycles stagger)
+- `com.kernel.kbot-social.plist` → daily at 9am
+- `com.kernel.kbot-train-self.plist` → Sundays 3am
+
+## What You Gain
+
+- Daily digest of codebase activity (without asking).
+- i18n stays in sync across 24 languages automatically.
+- Embedding index for semantic search rebuilds overnight.
+- Social presence grows without manual posting.
+- Local fine-tune stays current with your actual work.
+
+Cost: zero. All daemon work routes through local Ollama models.
+
+## Failure Modes
+
+- **Mac sleep blocks launchd** — use `caffeinate` or enable "wake for network access" in Energy Saver if you need guaranteed intervals.
+- **Ollama not running** — daemons depend on `localhost:11434`. Either start Ollama at login OR the daemon silently no-ops. Add Ollama to Login Items.
+- **Filesystem permission errors** — daemon's user context may differ from your shell. Absolute paths in plist, check `~/.kbot/` is writable by the daemon user.
+
+## Rollback
+
+`npm run daemon:stop` unloads the plist. Work resumes manually. No state is lost — `tools/daemon-reports/state.json` persists until the daemon re-enables.
+
+## What Emerges
+
+After two weeks of active daemons, the user finds: i18n is always current, the daily digest email is actually read, social posts have engagement, the local model passes a basic task without Claude. The compound output is larger than any single feature could produce.

package/skills/deployment/ship-pipeline/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: ship-pipeline
+description: Use before any release to kernel.chat or npm publish of kbot. Six gates, each must pass. Skipping a gate is how regressions ship.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [deploy, release, ship, quality, gates]
+    related_skills: [test-driven-development, systematic-debugging]
+---
+
+# Ship Pipeline
+
+Six gates, in order. Each must be green before the next runs. The `/ship` slash command executes them; you can run them manually when investigating.
+
+## Iron Law
+
+```
+NO GATE SKIPS. NO REORDERING. NO "I'LL RUN IT AFTER DEPLOY."
+```
+
+A gate that's inconvenient is a gate that's catching something. Skipping is how regressions ship to 4,800 weekly-download users.
+
+## The Gates
+
+### 1. Security (`guardian`)
+
+- Secret scan — no API keys, tokens, or `.env` content in the diff.
+- Dependency audit — `npm audit` clean or documented exceptions.
+- OWASP checks on anything touching user input or external calls.
+- SSRF guards present on new fetch calls.
+
+### 2. QA (`qa`)
+
+- `npx tsc --noEmit` — strict typecheck.
+- `npm run test` — full test suite green.
+- Any UI change: dev server + browser verification for the golden path AND one edge case.
+- No `console.log`, no commented-out code in the diff.
+
+### 3. Design (`aesthete` / `designer`)
+
+- Design tokens used, not raw values. `--rubin-primary`, not `#6B5B95`.
+- Spacing uses the scale (`--space-*`), not magic numbers.
+- A11y: keyboard nav works, contrast meets AA, screen reader labels present.
+- Motion: reduced-motion media query respected.
+
+### 4. Performance (`performance`)
+
+- Bundle budget: main JS < 300KB gzip, CSS < 150KB gzip.
+- No new dependencies > 50KB gzip without discussion.
+- Lazy-load still works for route-level components.
+- Service worker cache invalidation tested.
+
+### 5. DevOps (`devops`)
+
+- Edge functions deploy cleanly to Supabase.
+- Migrations are reversible.
+- GitHub Pages build succeeds locally.
+- Version bumped correctly in package.json.
+
+### 6. Product (`product`)
+
+- Feature actually does what the issue says it does.
+- Mobile-first: tested at 375px width.
+- Empty state, loading state, error state all present.
+- The change is something a user would *notice* — not invisible plumbing shipped as a feature.
+
+## Running It
+
+- `/ship` in Claude Code runs all six in sequence.
+- Manually: `/security-audit` → `/qa` → `/design-check` → `/perf` → `/devops` → `/team` (product review).
+- For kbot itself: `cd packages/kbot && npm run typecheck && npm run test && npm run build && npm publish --dry-run`.
+
+## Anti-Pattern
+
+Running the gates in parallel "to save time." They're sequential because later gates depend on earlier ones passing (no point running design checks on a build that won't compile). The serial wait is the feature.
+
+## Rollback Plan
+
+Every deploy must have one. For kernel.chat: previous gh-pages tag. For kbot: `npm deprecate @kernel.chat/kbot@<version>` + publish a patched version. Know the rollback before shipping, not after breaking.

package/skills/emergent/forge-reflex/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: forge-reflex
+description: Use the moment you think "I don't have a tool for that." Build the tool immediately with forge_tool — never report a missing capability.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [forge, runtime-tools, limitless-execution, emergence]
+    related_skills: [specialist-routing, autopoiesis-loop]
+---
+
+# Forge Reflex
+
+Missing tools aren't blockers. Missing tools are ~90 seconds away from existing.
+
+## Iron Law
+
+```
+"I DON'T HAVE A TOOL FOR X" IS NEVER A TERMINAL STATE.
+```
+
+The correct next step is always: build it, register it, use it, move on.
+
+## Trigger
+
+Any internal thought matching one of:
+- "There's no tool for this"
+- "I would need a script"
+- "If only kbot had…"
+- "This would take manual work"
+- A user requesting something outside the registered 670+ tools
+
+## Procedure
+
+1. **Name the tool.** One verb, one noun. `fetch_rss`, `parse_ics`, `diff_binary`.
+2. **Write the JSON Schema for its inputs.** Zod-compatible.
+3. **Call `forge_tool`** with name, description, schema, and an implementation string (TS or bash).
+4. **Test once** with a known input. If it fails, patch the implementation inline.
+5. **Use it** to complete the original task.
+6. **Persist it** by writing the forge spec into `~/.kbot/plugins/<name>/` if it'll be useful again.
+
+## What Emerges
+
+Users who work with kbot for a month have 20–100 personal tools that don't exist in the core. Forge reflex is what grows kbot's surface area per user — the registered 670 is the floor, not the ceiling.
+
+## Anti-Pattern
+
+Suggesting the user write a script themselves. Telling the user "kbot doesn't support X." Both are correctness failures — the Limitless Execution doctrine treats them as bugs.
+
+## Integration with Skill Self-Authorship
+
+After forging a tool you used more than twice in a session, write a skill (`skill-self-authorship`) that documents when to reach for it. Forged tool + paired skill = permanent capability upgrade.

package/skills/emergent/mimic-hybrid/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: mimic-hybrid
+description: Use when a task blends domains. Instead of picking one mimic profile, blend two — kbot writes cleaner Next.js code when it mimics react+rust than when it mimics react alone.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [mimic, style, emergent, personality]
+    related_skills: [specialist-routing]
+---
+
+# Mimic Hybrid
+
+Mimic profiles aren't costumes. They're weighted style biases that compose. The emergent finding: two profiles combined often outperform any single profile for cross-domain work.
+
+## When to Hybridize
+
+- Next.js + performance-critical → `nextjs` + `rust`
+- React + strict typing → `react` + `typescript`
+- Python + ergonomic CLI → `python` + `claude-code`
+- Infrastructure + terse shell → `devops` + `python`
+- Blog/marketing site → `nextjs` + `copywriter`
+
+## Procedure
+
+1. `kbot mimic <primary>` — sets the primary tone.
+2. Add `--style <secondary>` to the invocation for a one-shot blend.
+3. Or edit `~/.kbot/mimic.json` with `{ primary, secondary, weight: 0.3 }` for a persistent hybrid (0.0 = pure primary, 1.0 = pure secondary).
+
+## What Blends Well
+
+- **Syntax discipline** (rust, typescript, haskell) crossed with **ergonomic framework** (react, nextjs, nuxt): cleaner type signatures, better null handling, fewer runtime surprises.
+- **Terse shell** (python, bash) crossed with **long-form** (claude-code, copywriter): commands that are both concise AND explained.
+- **Security mindset** (guardian specialist as style bias) crossed with anything: defaults to input validation and safer primitives.
+
+## What Blends Badly
+
+- Two opinionated frameworks (next.js + remix). They argue. kbot hallucinates a fusion that exists in neither.
+- Mimic profile contradicting specialist agent (style=copywriter, agent=guardian). The guardian's security hardness clashes with copywriter's persuasion tone. Pick one source of style per session.
+
+## Iron Law
+
+```
+NEVER BLEND MORE THAN TWO PROFILES AT ONCE.
+```
+
+Three-way blends degrade into a vague "AI voice." Two-way blends feel intentional.
+
+## What Emerges
+
+After a few weeks of experiments, users find their personal favorite hybrid — and it's almost never "just claude-code." The hybrid becomes part of the user's `SCRATCHPAD.md` and applies by default to every session.
+
+## Anti-Pattern
+
+Switching mimic mid-session without a commit between. The output becomes stylistically incoherent and code-review unfriendly. Mimic boundaries should align with commit boundaries.

package/skills/memory/dream-to-commit/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: dream-to-commit
+description: Use in the first session of the day. The dream engine ran overnight and left a digest — open it first, it tells you what past-you already figured out.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [dream, memory, morning-routine, consolidation]
+    related_skills: [autopoiesis-loop, memory-cascade]
+---
+
+# Dream to Commit
+
+Between sessions, the dream engine consolidates transcripts into reflections. In the morning, those reflections contain answers to questions you were about to ask — and sometimes fixes to bugs you haven't logged yet.
+
+## Iron Law
+
+```
+DO NOT START MORNING WORK WITHOUT READING LAST NIGHT'S DREAMS.
+```
+
+## The Morning Protocol
+
+1. `kbot dream status` — confirms the engine ran.
+2. `kbot dream journal --since yesterday` — reads new reflection entries. They cluster by theme.
+3. For each reflection tagged `actionable`, either:
+   - Open a commit that captures the fix / improvement kbot spotted, or
+   - Write a memory note explaining why *not* to act on it.
+4. Only after the journal is reviewed, start new work.
+
+## Why This Works
+
+The dream engine cross-references: yesterday's tool errors, uncommitted diffs, SCRATCHPAD drift, learned-router misses, and daemon reports. It has more signal than a human going through the same inputs because nothing gets forgotten between windows.
+
+## What You'll See Over Time
+
+- **Week 1**: generic reflections ("this function was modified often").
+- **Week 3**: specific forecasts ("this pattern fails on Linux — consider a platform guard").
+- **Week 8**: cross-project insights ("you re-implemented X in three repos — extract into a shared package").
+
+The quality compounds because reflections feed the reflection engine itself (three-tier memory: events → reflections → meta-reflections).
+
+## Anti-Pattern
+
+Ignoring the journal because "it's just the AI talking to itself." The journal is the only durable artifact of every session's learning. Ignoring it makes the dream engine pure cost with no dividend.
+
+## Integration
+
+- `synthesis_engine.getSynthesisContext(8)` reads the top 8 reflections into every new agent prompt automatically.
+- `corrections` loader pulls any reflection tagged `correction` into the active system prompt as a closed-loop signal.
+- The skills loader scores skills partly on overlap with recent reflection themes — yesterday's dreams bias today's relevance.

package/skills/memory/memory-cascade/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: memory-cascade
+description: Use when memory feels slow, bloated, or is contradicting itself. The 5-tier cascade has rules about what gets promoted, demoted, or forgotten — follow them or memory decays into noise.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [memory, cascade, reflection, consolidation]
+    related_skills: [dream-to-commit, autopoiesis-loop]
+---
+
+# Memory Cascade
+
+kbot's memory is not one store — it's five tiers that flow into each other like a karst system. Working memory fills, overflows into short-term, which consolidates into long-term, which distills into reflections, which collapse into meta-reflections. Each tier has different rules.
+
+## The Five Tiers
+
+| Tier | Location | Retention | Promotion Rule |
+|---|---|---|---|
+| 1. Working | in-process `Map<sessionId, history>` | lifetime of the session | auto-flushes to short-term on session close |
+| 2. Short-term | `~/.kbot/memory/short-term/*.jsonl` | 7 days rolling | entries tagged `important` promote to long-term |
+| 3. Long-term | `~/.kbot/memory/long-term/*.md` | indefinite | distilled into reflections nightly |
+| 4. Reflections | `~/.kbot/memory/reflections/*.md` | indefinite | aggregated into meta-reflections weekly |
+| 5. Meta-reflections | `~/.kbot/memory/meta/*.md` | indefinite | immutable signal into every prompt |
+
+## Iron Law
+
+```
+PROMOTION IS EARNED. DEMOTION IS AUTOMATIC. DELETION IS NEVER MANUAL.
+```
+
+Manually deleting memory entries breaks the cascade invariants — the reflection engine still sees dangling references. If a memory is wrong, *correct it* with a new entry pointing at the old one; don't delete.
+
+## When to Force a Promotion
+
+- The user says "remember this" — explicit flag, auto-promotes to long-term.
+- A correction was issued — auto-promotes with tag `correction` (loaded into every future prompt).
+- A project fact that decays in 30+ days — promote to long-term manually via `memory_save`.
+
+## When to Let It Demote Naturally
+
+- Session chatter, one-off context, successful completions — leave in working/short-term, let them fall out.
+- Debug state, test run output — these should not be in memory at all; filter at write time.
+
+## Reading the Cascade
+
+`getSynthesisContext(n)` loads the top-n meta-reflections into every prompt automatically. You don't need to fetch lower tiers in normal work — the cascade surfaces what's relevant. Dig into lower tiers only when:
+- You're investigating a contradiction in advice.
+- You're debugging why kbot "forgot" something.
+- You're curating teacher traces (where low-tier detail matters).
+
+## Anti-Pattern
+
+Treating memory as a notes app. If you find yourself writing `memory_save` for every session summary, you're duplicating what the dream engine does automatically. Reserve explicit saves for facts kbot *would not learn on its own* (user preferences, project constraints, non-obvious decisions).
+
+## What Emerges
+
+After ~30 days, meta-reflections stabilize into a compressed profile of how the user works. That profile loads into every session's prompt as ambient context. The subjective experience: kbot starts "already knowing you" by session 20-ish.

package/skills/music-production/ableton-session-build/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: ableton-session-build
+description: Use when the user wants to build a track, beat, or arrangement in Ableton Live. kbot drives Ableton via OSC — you don't type notes, you describe the idea.
+version: 1.0.0
+author: kbot
+license: MIT
+platforms: [darwin]
+metadata:
+  kbot:
+    tags: [ableton, music, osc, m4l, production]
+    related_skills: [serum2-preset-craft, dj-set-builder]
+---
+
+# Ableton Session Build
+
+kbot has 14 Ableton tools, 9 M4L devices, and a full OSC bridge. You describe a beat; kbot lays it down in a live session.
+
+## Iron Law
+
+```
+VERIFY THE OSC BRIDGE FIRST. EVERY TIME.
+```
+
+Without a live bridge, every tool call silently fails. Check before you plan.
+
+## Preflight (2 commands)
+
+1. `ableton_session_info` — if this returns tempo + tracks, you're connected.
+2. If it times out: remind the user to start Live and enable the AbletonOSC remote script (`Link/Tempo/MIDI → Control Surface → AbletonOSC`).
+
+## Production Flow
+
+1. **Set the frame**: `ableton_transport` to set tempo, key hint via scene naming, time signature.
+2. **Create tracks**: one `ableton_create_track` per role (drums, bass, pad, lead, FX).
+3. **Load sounds**: `ableton_load_sample` for one-shots; `ableton_load_plugin` for Serum/synths; `ableton_load_preset` for factory patches.
+4. **Write patterns**: `ableton_midi` with note arrays. Use `generate_drum_pattern` / `generate_melody_pattern` as starting points.
+5. **Arrange**: `ableton_scene` to build verse/chorus/drop scenes; `ableton_clip` to fire them.
+6. **Mix**: `ableton_mixer` for levels/pan; `ableton_effect_chain` for returns; `ableton_device` for insert FX.
+7. **Capture**: render via transport record, or have the user bounce the arrangement.
+
+## Specialist Escalations
+
+- Preset design needed? Use `serum2-preset-craft`.
+- Full DJ set needed? Use `dj-set-builder`.
+- Sound too generic? Route to `aesthete` specialist with the current session_info for creative direction.
+
+## Anti-Patterns
+
+- Writing MIDI before verifying the bridge responds. Silent failures waste the whole session.
+- Loading plugins without checking the user has them installed. Use `ableton_browse` first.
+- Generating 32-bar patterns in one call. Work in 4- and 8-bar loops; iterate.
+
+## Known Fragility
+
+- AbletonOSC's `set/notes` endpoint quirks — if clip writes fail, fall back to setting notes via `ableton_clip.write_notes` with explicit velocity + duration.
+- Sample loading can 404 if the browser index is stale. `ableton_browse --refresh` fixes it.
+- Clip firing during a running session can drop the first beat. Fire on scene boundary, not mid-bar.
+
+## What Emerges
+
+The user stops thinking in Live's UI and starts describing ideas. "Make it darker" becomes a legitimate prompt because kbot knows darker = minor key + sub-bass boost + reverb tail + plate on the snare. This is the skill paying off over sessions.

package/skills/orchestration/cross-agent-blackboard/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: cross-agent-blackboard
+description: Use when more than one agent works on the same problem. The blackboard is the shared context — without it, agents duplicate work and contradict each other.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [agents, coordination, blackboard, multi-agent]
+    related_skills: [specialist-routing, agent-handoff]
+---
+
+# Cross-Agent Blackboard
+
+Single-agent sessions use memory. Multi-agent sessions need a blackboard — a shared write-read surface every participating agent sees.
+
+## When
+
+- `kbot --architect` (plan + implement by two agents)
+- `/team` running all 6 specialists against the same change
+- `agent_handoff` passing control with preserved context
+- Matrix agents collaborating on a research question
+
+## Iron Law
+
+```
+ANY AGENT TAKING OVER MUST READ THE BLACKBOARD BEFORE ACTING.
+ANY AGENT LEAVING MUST WRITE TO THE BLACKBOARD BEFORE EXITING.
+```
+
+## Protocol
+
+Blackboard entries have four fields: `type` (decision/finding/blocker/artifact), `key` (short slug), `value` (the payload), `author` (agent id).
+
+- `blackboard_write({ type, key, value })` — before handing off or pausing.
+- `blackboard_read({ keyPrefix?, type? })` — on entry or after a long subagent call.
+- `blackboard_query()` — full dump when context is lost.
+
+## Example Flow (from a real session)
+
+1. `researcher` investigates a library version incompatibility.
+2. Writes `{ type: 'finding', key: 'axios.v1-vs-v2', value: 'v2 breaks the retry middleware' }`.
+3. Hands off to `coder` via `agent_handoff`.
+4. `coder` reads the blackboard, sees the finding, and skips re-researching.
+5. Writes `{ type: 'artifact', key: 'axios-pin', value: 'pinned to 1.6.7 in package.json' }`.
+6. `guardian` runs later, reads both entries, confirms no regression, writes `{ type: 'decision', key: 'axios-pin', value: 'approved' }`.
+
+Total time from research to verified fix: 8 minutes. Without the blackboard: each agent would re-derive context, easily 25+ minutes.
+
+## Anti-Patterns
+
+- Passing context through the user ("please tell the next agent X"). The user is not a message bus.
+- Writing vague entries ("looked into the bug"). Name the finding concretely or don't write it.
+- Reading only your own writes. Other agents' entries are the whole point.
+
+## What Emerges
+
+With the blackboard habit, specialist chains start behaving like one compound agent. The user types one prompt, three specialists take turns, and the handoffs are invisible — because context never dropped.

package/skills/orchestration/specialist-routing/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: specialist-routing
+description: Use when a task clearly belongs to a specialist agent. Route first, reason second — don't let the general agent muddle through a domain it has a specialist for.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [agents, routing, specialists, delegation]
+    related_skills: [matrix-agent-spawn, cross-agent-blackboard, agent-handoff]
+---
+
+# Specialist Routing
+
+kbot ships with 25+ specialists (run `kbot agents list` for the current roster). The default `kernel` agent is a generalist — competent everywhere, excellent nowhere. The feeling of "kbot is sharp" comes from routing into the right specialist before work starts.
+
+## Iron Law
+
+```
+IF A SPECIALIST EXISTS FOR THIS DOMAIN, THE GENERALIST DOES NOT TOUCH IT.
+```
+
+## The Roster
+
+| Signal | Specialist | Why |
+|---|---|---|
+| "review my code", "refactor", "fix this test" | `coder` | strongest code-patching track record |
+| "research X", "find me", "what does the literature say" | `researcher` | web + arxiv + citation graph |
+| "design this", "make it look right", a11y | `aesthete` | design tokens + spacing + typography |
+| "is this safe", secrets, auth, permissions | `guardian` | OWASP checks, dep audit, redact |
+| CI, deploys, env vars, launchd, docker | `infrastructure` | full infra toolkit |
+| a statistical question, backtesting, distributions | `quant` | stats + finance + probability |
+| a 30+ minute deep dive, multi-source | `investigator` | multi-step research workflow |
+| "write" anything long-form | `writer` | content creation + editing |
+| strategy, tradeoffs, business framing | `strategist` | structured decision support |
+| how it's going, "predict X" | `oracle` | forecasting + anticipation |
+
+## Trigger
+
+The moment the user's first message can be classified into the table above. The learned router handles this automatically when confidence ≥ 0.7; below that, you route explicitly: `kbot --agent <id> "..."`.
+
+## Procedure
+
+1. **Classify the task** against the table. If two match, pick the one closer to the *verb* (review → coder; design review → aesthete).
+2. **If none match**, stay on `kernel` and invoke the skill that fits instead.
+3. **When in doubt**, use `--architect` (plan with one specialist, implement with another) or `--plan` (read-only scoping first).
+4. **If the specialist gets stuck**, use `agent_handoff` to pass to another specialist with context — don't fall back to the generalist silently.
+
+## Anti-Pattern
+
+- Running everything on the default agent "for consistency." You lose every specialist advantage.
+- Choosing a specialist by *topic* instead of *verb*. "Music" isn't a specialist; `aesthete` handles creative direction and `coder` handles the OSC scripting.
+- Routing between specialists mid-task without writing to the blackboard — the next specialist loses context.
+
+## What Emerges
+
+Users develop muscle memory for `kbot --agent <id>`. Over weeks, the learned router picks up which specialist wins which task *for this user* (not average) and routes preemptively. The experience becomes: "I type the prompt, the right expert answers." That's the routing skill paying compound interest.

package/skills/self-improvement/autopoiesis-loop/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: autopoiesis-loop
+description: Use when planning multi-session work. The autopoiesis loop is kbot using itself to improve itself — every session should end a little sharper than it started.
+version: 1.0.0
+author: kbot
+license: MIT
+metadata:
+  kbot:
+    tags: [self-improvement, meta, dogfood, autopoiesis]
+    related_skills: [skill-self-authorship, teacher-trace-curation, dream-to-commit]
+---
+
+# The Autopoiesis Loop
+
+kbot is the tool *and* the workbench. Every session has two outputs: the thing the user asked for, and the incremental improvement to kbot itself. Sessions that only produce the first are leaving compound interest on the table.
+
+## The Five Moves (once per session)
+
+1. **Session start** — run `kbot bootstrap`. The bootstrap agent surfaces the highest-leverage improvement based on accumulated signals. Do this before feature work, not instead of it.
+2. **During work** — notice repeated patterns. Each repetition is a skill waiting to be written (`skill-self-authorship`).
+3. **On friction** — missing tool? `forge-reflex`. Wrong specialist? Update the learned router via corrective feedback.
+4. **Session end** — update `SCRATCHPAD.md` with what you learned (not what you did). The next session's opening context reads this file.
+5. **Overnight** — the dream engine consolidates transcripts into memory entries. The daemon reviews diffs, runs code quality scans, translates i18n. Work continues while the user sleeps.
+
+## Iron Law
+
+```
+NEVER END A SESSION WORSE THAN IT STARTED.
+```
+
+If kbot hit a wall and you didn't leave a corrective signal behind (a skill, a memory, a scratchpad note, a corrected learned-router pattern), the loop is broken.
+
+## The Three Signals That Compound
+
+- **Corrections** — user says "no, do X instead." These go into `~/.kbot/corrections/` and load as closed-loop prompts.
+- **Teacher traces** — every non-local Claude call is logged to `~/.kbot/teacher/traces.jsonl`. Weekly, `kbot train-self` fine-tunes local models on the best ones.
+- **Skills** — successful patterns distilled into `~/.kbot/skills/`. Loaded on relevance.
+
+Each of these runs automatically once wired up. The skill is knowing to wire them up in the first place.
+
+## What Emerges
+
+Three weeks of active use and kbot's answers start feeling tuned to *this user* specifically. Six weeks in, the local model (via `train-self`) is answering basic questions at zero cost. Three months in, kbot's corrections archive has more collective wisdom than the user's own notes.
+
+## Anti-Pattern
+
+Running kbot as a pure consumer — asking questions, using answers, never looking at what's in `~/.kbot/`. You're paying for the loop with every API call but not collecting the dividend.