continuous-improvement 3.12.3 → 3.15.0

package/plugins/expert.json

@@ -1,6 +1,6 @@
 {
   "name": "continuous-improvement",
-  "version": "3.12.3",
+  "version": "3.15.0",
   "mode": "expert",
   "description": "Expert mode: tune confidence, manage instincts, and persist plans on disk. Adds safety, token-budget, and strategic-compact skills plus the /learn-eval command so long sessions stay sharp and learnings survive context resets.",
   "tools": [
@@ -75,6 +75,10 @@
     {
       "name": "ci_distill_promote",
       "what": "Promote an edited draft into a live instinct"
+    },
+    {
+      "name": "ci_distill_from_workflow",
+      "what": "Draft a reusable instinct from a verified Workflow run"
     }
   ],
   "setup": {

package/skills/README.md

@@ -18,10 +18,12 @@ These add concrete enforcement to the 7 Laws. Tier-1 skills are the always-on mi
 
 | Skill | What it does | Pairs with which Law |
 |-------|--------------|----------------------|
-| `para-memory-files` | File-based persistent memory using PARA (Projects/Areas/Resources/Archives) for cross-session context | Law 5 (Reflect), Law 7 (Learn) |
-| `verification-loop` | Six-phase verification (build, types, lint, tests, security, diff) with a structured PASS/FAIL report | Law 4 (Verify Before Reporting) |
+| `deploy-receipt` | Deploy verification receipt — SHA-match + healthcheck proof that what merged is what's live, closing the merged-but-not-deployed gap | Law 4 (Verify Before Reporting) |
 | `gateguard` | PreToolUse fact-forcing gate that blocks Edit/Write/destructive Bash until concrete investigation is presented | Law 1 (Research) |
+| `model-forward` | Standing stance: go with Claude Code and the model, not against it — skills are scaffolding that merges into the model; the durable core is goal-driven execution + guardrails | All 7 Laws (stance) |
+| `recall` | BM25 search over the observation log so "have I hit this before?" is answerable before re-deriving a fix | Law 1 (Research) |
 | `tdd-workflow` | RED→GREEN→REFACTOR enforcement, 80%+ coverage gate across unit/integration/E2E | Law 3 (One Thing), Law 4 (Verify) |
+| `verification-loop` | Six-phase verification (build, types, lint, tests, security, diff) with a structured PASS/FAIL report | Law 4 (Verify Before Reporting) |
 
 ## Tier 2 — additional skills for **expert** mode
 

package/skills/gateguard.md

@@ -136,7 +136,7 @@ This gate is what catches the squash-merge / ahead-of-origin trap recorded in th
 
 ### Today: runtime hook + skill (zero install beyond the plugin)
 
-`hooks/gateguard.mjs` is bundled with this plugin and wired as the first PreToolUse hook in `plugins/continuous-improvement/hooks/hooks.json`. When you install the plugin, the runtime gate is live — no extra config, no opt-in. The hook reads tool input from stdin, classifies it through a data-driven routing table (Read/Grep/Glob → allow, Write/Edit/MultiEdit → mutating-file gate, Bash → destructive-pattern check), and emits `{decision, reason?}` on stdout. Per-session state lives at `~/.claude/instincts/<project-hash>/gateguard-session.json` (override via `GATEGUARD_SESSION_DIR` for tests) and caps cumulative clearances at `MAX_CLEARED_FILES = 50`.
+`hooks/gateguard.mjs` is bundled with this plugin and wired as the first PreToolUse hook in `plugins/continuous-improvement/hooks/hooks.json`. When you install the plugin, the runtime gate is live — no extra config, no opt-in. The hook reads tool input from stdin, classifies it through a data-driven routing table (Read/Grep/Glob → allow, Write/Edit/MultiEdit → mutating-file gate, Bash → destructive-pattern check), and emits `{decision, reason?}` on stdout. Per-session state lives at `~/.claude/instincts/<project-hash>/sessions/<session-id>/gateguard-session.json` — scoped by the stdin `session_id` so the cap never bleeds across concurrent sessions (it falls back to the unscoped `<project-hash>/` dir when no session id is present, and `GATEGUARD_SESSION_DIR` overrides it for tests). The cap is `MAX_CLEARED_FILES = 50` per session, and the state self-heals after `STATE_TTL_MS` so a stale gate never needs a manual `rm`.
 
 Smoke-test the runtime gate after install: ask Claude to write a throwaway file with no research first. The hook should return a `block` decision with a fact-list reason; Claude should pause rather than write.
 
@@ -150,10 +150,10 @@ The block reason prints the exact `gateguard-session.json` path and the clearanc
 
 The inline `_gateguard_facts_presented: true` retry still works on harnesses that forward unknown tool params, but Claude Code's strict tool schema (`additionalProperties: false`) rejects it with `InputValidationError` — use one of the above on Claude Code.
 
-### V1 honest limitations (not mitigated, documented)
+### Limitations and guarantees
 
-- **Honor system.** Clearance is recorded by `ci_gateguard_clear`, the `gateguard-clear.mjs` CLI, a manual state-file write, or the inline `_gateguard_facts_presented` flag where the harness allows it (see "Clearing the gate" above). The hook can't verify the investigation actually happened; the 50-file cap bounds damage from stuck loops or rogue agents.
-- **State-file deletion.** `rm`-ing the session state resets every gate. Acceptable because the session itself is the trust boundary.
+- **Honor system.** Clearance is recorded by `ci_gateguard_clear`, the `gateguard-clear.mjs` CLI, a manual state-file write, or the inline `_gateguard_facts_presented` flag where the harness allows it (see "Clearing the gate" above). The hook can't verify the investigation actually happened; the 50-file cap — counted per session — bounds damage from stuck loops or rogue agents.
+- **State-file deletion / self-heal.** `rm`-ing the session state resets every gate. Because state is scoped per session (`sessions/<session-id>/`), the session is a real trust boundary, not one shared across concurrent runs. A stale state file also self-heals once its `created_at` ages past `STATE_TTL_MS`, so a manual `rm` is rarely needed.
 - **Parallel-hook race.** Two simultaneous hook invocations can race the read+write of the state file. Acceptable trade-off vs Windows atomic-rename complexity.
 
 **MultiEdit per-file gating.** The hook clears and checks every `edits[]` path individually, so a mixed-clearance batch blocks until *all* edited files are cleared or facts are presented. The block reason now names the whole batch, not just the first uncleared path.

package/skills/goal-monitor.md

@@ -77,5 +77,5 @@ ci_goal_check goal_file=docs/x.md  # score against a specific plan file
 ## Pairs With
 
 - **`proceed-with-the-recommendation`** (orchestrator, Law 2) — run a goal check at phase boundaries to confirm the plan still matches the work.
-- **`para-memory-files`** / planning-with-files — the `## Goal` section this skill reads is the same one those workflows write.
+- **planning-with-files** — the `## Goal` section this skill reads is the same one that workflow writes.
 - **`strategic-compact`** — before compacting a long session, a goal check confirms what the session was actually about.

package/skills/handoff.md

@@ -51,7 +51,6 @@ Anything that is already captured elsewhere gets a path or URL pointer, not a du
 ## Companion / alternative skills
 
 - [`strategic-compact`](./strategic-compact.md) — compact the current session at a phase boundary instead of writing a handoff doc. Use when the session continues with the same agent.
-- [`para-memory-files`](./para-memory-files.md) — durable cross-session memory under `~/.claude/memory/`. Use for classified facts (user, project, feedback, reference), not per-session handoff briefs.
 - `superpowers:writing-plans` — produce the plan doc the handoff can reference instead of duplicating.
 
 ## Attribution

package/skills/model-forward.md

@@ -0,0 +1,44 @@
+---
+name: model-forward
+tier: "1"
+description: Enforces all 7 Laws as a standing stance — go with Claude Code and the model, not against it. Skills are scaffolding that merges into the model over time; the durable core is goal-driven execution (the higher the stated goal, the better) plus self-discipline guardrails.
+origin: continuous-improvement
+user-invocable: true
+---
+
+# Model-Forward Skill
+
+The standing mental model for every session: **always go with Claude — not against it — until the user says otherwise.**
+
+Models improve continuously. Mechanics that skills hand-hold today (planning etiquette, routing, verification reminders) keep merging into the model itself. Betting against that trend produces scaffolding that fights the harness. Betting with it keeps only what stays valuable as models get smarter.
+
+## The Two Invariants
+
+Everything in continuous-improvement reduces to two things that survive every model generation:
+
+1. **Goal-driven execution.** Anchor on the highest stated goal — the higher the goal, the better the execution. Tie every change to it, refuse scope creep, stop when it is met. (Laws 2, 3, 4, 6.)
+2. **Self-discipline / guardrails.** Research before executing, verify before reporting, reflect and learn after. Guardrails are how an agent earns autonomy. (Laws 1, 4, 5, 7.)
+
+Skill mechanics are scaffolding around those two. The invariants are the product; the scaffolding is replaceable.
+
+## Decision Rules
+
+| Situation | Model-forward call |
+|---|---|
+| A native Claude Code feature now covers what a custom skill or hook does | Prefer the native path; propose retiring the scaffold instead of maintaining a parallel one |
+| A skill's instructions conflict with current Claude Code best practice | Follow Claude Code best practice; flag the skill for update |
+| Tempted to add scaffolding to compensate for a model weakness | First confirm the current model still has that weakness; do not patch yesterday's model |
+| A guardrail keeps firing on behavior the model no longer exhibits | Propose loosening or retiring it — stacking stale guardrails is also drift |
+| The user explicitly says to go against a default | The user wins. "Until said otherwise" is the contract. |
+
+Never retire a guardrail unilaterally — retiring scaffolding is a proposal to the operator, not a silent action. The bias points toward the model; the authority stays with the user.
+
+## Harness Portability
+
+This stance is harness-agnostic state. Agents beyond Claude Code that import continuous-improvement skills — Hermes- and OpenClaw-class harnesses included — adopt the same mental model: native capability first, two invariants always, scaffolding only where the current model demonstrably needs it.
+
+## What This Skill Is Not
+
+- Not a license to skip the Laws — the invariants are the part that never merges away.
+- Not an auto-update mechanism — it changes posture, not files.
+- Not a reason to drop verification: "the model is probably right" is still a "should work" claim until checked (Law 4).