continuous-improvement 3.0.0 → 3.8.0

package/plugins/continuous-improvement/skills/verification-loop/SKILL.md

@@ -0,0 +1,192 @@
+---
+name: verification-loop
+tier: "1"
+description: "Enforces Law 4 (Verify Before Reporting) of the 7 Laws of AI Agent Discipline. A comprehensive verification system for agent coding sessions covering build, types, lint, tests, security, and diff with a PASS/FAIL report."
+origin: continuous-improvement
+---
+
+# Verification Loop Skill
+
+A comprehensive verification system for agent coding sessions.
+
+## When to Use
+
+Invoke this skill:
+- After completing a feature or significant code change
+- Before creating a PR
+- When you want to ensure quality gates pass
+- After refactoring
+
+## Verification Phases
+
+### Phase 0: Resolve the Ladder
+
+Every project has its own actual invocation for build / typecheck / lint / test / security / deploy-receipt. Hardcoding `npm run build` and `npm run test` works when the project happens to use those exact scripts; for everything else (pnpm, yarn, cargo, go, mise, just, custom scripts, monorepos with workspace-scoped commands) it returns "deps not installed" or "config not found" misreads from the wrong invocation. Phase 0 runs first so Phases 1–6 never have to guess.
+
+**Resolution priority** (first match wins):
+
+1. **`.claude/verify-ladder.json` manifest** at the repo root. Schema:
+   ```json
+   {
+     "build":          "npm run build",
+     "typecheck":      "tsc -p tsconfig.json --noEmit",
+     "lint":           "npm run lint",
+     "test":           "npm test",
+     "security":       "npm audit --audit-level=high",
+     "deploy_receipt": "npx wrangler deployments list --json"
+   }
+   ```
+   Any field omitted falls through to step 2 for that field only. A field set to the literal string `null` means "skip this phase for this project."
+2. **Sniff `package.json` `scripts`** for `build`, `typecheck` or `tsc`, `lint`, `test`, `audit` or `security`. Tie-breaker when multiple scripts could match a phase: prefer `verify:<phase>` over `<phase>` over `<phase>:*`. Do NOT pick `test` when `verify:test` exists; the operator's explicit verification surface always wins over the convenience alias.
+3. **Sniff per-language toolchain files** if `package.json` is absent: `Cargo.toml` → `cargo build` / `cargo test`, `go.mod` → `go build ./...` / `go test ./...`, `pyproject.toml` → `pytest` / `ruff check`, `Gemfile` → `bundle exec rspec`, etc.
+4. **Ask the operator** if none of the above resolves the field. Do not invent.
+
+**Output the resolved ladder** as a single fenced block before running any phase, so the operator can spot a wrong resolution before it costs a misread:
+
+```
+verify-ladder (resolved):
+  build:           npm run build
+  typecheck:       npx tsc --noEmit  (sniff: package.json scripts.typecheck)
+  lint:            npm run lint
+  test:            npm test
+  security:        (skipped — no script defined)
+  deploy_receipt:  npx wrangler deployments list --json  (manifest)
+```
+
+Each row shows the resolved command + its source (manifest, sniff, or skipped). The fenced block is the contract surface — every later phase reads from this resolved ladder, never from a hardcoded fallback.
+
+A starter manifest is provided at `templates/verify-ladder.example.json`; copy it to `.claude/verify-ladder.json` and trim per project.
+
+### Phase 1: Build Verification
+Run the `build` command from the resolved ladder. Example for a default Node project:
+```bash
+# Resolved from package.json scripts.build:
+npm run build 2>&1 | tail -20
+```
+
+If build fails, STOP and fix before continuing.
+
+### Phase 2: Type Check
+```bash
+# TypeScript projects
+npx tsc --noEmit 2>&1 | head -30
+
+# Python projects
+pyright . 2>&1 | head -30
+```
+
+Report all type errors. Fix critical ones before continuing.
+
+### Phase 3: Lint Check
+```bash
+# JavaScript/TypeScript
+npm run lint 2>&1 | head -30
+
+# Python
+ruff check . 2>&1 | head -30
+```
+
+### Phase 4: Test Suite
+```bash
+# Run tests with coverage
+npm run test -- --coverage 2>&1 | tail -50
+
+# Check coverage threshold
+# Target: 80% minimum
+```
+
+Report:
+- Total tests: X
+- Passed: X
+- Failed: X
+- Coverage: X%
+
+### Phase 5: Security Scan
+```bash
+# Check for secrets
+grep -rn "sk-" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
+grep -rn "api_key" --include="*.ts" --include="*.js" . 2>/dev/null | head -10
+
+# Check for console.log
+grep -rn "console.log" --include="*.ts" --include="*.tsx" src/ 2>/dev/null | head -10
+```
+
+### Phase 6: Diff Review
+```bash
+# Show what changed
+git diff --stat
+git diff HEAD~1 --name-only
+```
+
+Review each changed file for:
+- Unintended changes
+- Missing error handling
+- Potential edge cases
+
+### Phase 7: Result + Completeness Gate
+
+Phases 1–6 verify mechanism — build green, types clean, tests pass, no secrets, diff intentional. Phase 7 verifies outcome: did the work the operator actually asked for actually land? Mechanism passing while outcome is missing is the most expensive failure mode in this loop, because the green report invites a merge that doesn't deliver.
+
+Two questions, both required to be `Yes`:
+
+**1. Did the stated goal land? Yes/No + evidence.**
+
+The stated goal is the goal as named at task start, not the goal as remembered now. If the operator asked "fix the bug where X happens", evidence is the bug no longer happening (failing test now passes, repro screenshot, manual verification). If they asked "add an admin button", evidence is the button visible and functional in the running UI. Build-green is not evidence of result — it is evidence of mechanism. Don't conflate.
+
+**2. Did every promised step finish? Yes/No + list.**
+
+Enumerate every step you said you would do — the recommendation list, the plan doc, the TodoWrite items, the commit-by-commit roadmap. Mark each Done or Skipped. If any are Skipped, name them and the reason. A "complete" verification with silently skipped promises is a trust violation, not a deliverable.
+
+Both gates are independent: `Yes` on goal alone means a half-complete checklist that may break later; `Yes` on completeness alone means busywork that didn't deliver. Both must be `Yes` — even if the previous six phases all pass — or the work isn't done.
+
+If either is `No`, the verification report goes back to the operator with the explicit gap, not on to PR. The operator decides whether the gap is acceptable to ship as-is or whether more work is required first. Never silently downgrade to "ready" because the mechanism phases looked good.
+
+### Phase 8: Deploy Receipt (auto-deploy projects only)
+
+For repos whose `verify-ladder.json` declares a `deploy_receipt` field — or whose sniff path detects an auto-deploy target (Railway, Cloudflare Workers, Vercel, Netlify, Fly.io) — the verify is not complete until the deployed SHA matches the merge SHA and a healthcheck returns 200. Hand off to the `deploy-receipt` skill (Law 4 deploy-seam companion landed in PR #83) and treat its `Receipt status: COMPLETE` as the gate.
+
+INCOMPLETE receipts move to "Immediate operator action" in the close, never to "ready". Library-only / package-published repos skip this phase entirely (no deploy seam exists).
+
+## Output Format
+
+After running all phases, produce a verification report:
+
+```
+VERIFICATION REPORT
+==================
+
+Build:        [PASS/FAIL]
+Types:        [PASS/FAIL] (X errors)
+Lint:         [PASS/FAIL] (X warnings)
+Tests:        [PASS/FAIL] (X/Y passed, Z% coverage)
+Security:     [PASS/FAIL] (X issues)
+Diff:         [X files changed]
+Goal landed:  [YES/NO] — <one-line evidence or gap>
+All promised: [YES/NO] — <X of Y steps Done; list any Skipped>
+
+Overall:   [READY/NOT READY] for PR
+
+Issues to Fix:
+1. ...
+2. ...
+```
+
+`Overall: READY` requires every line above to pass, including both Phase 7 gates. Mechanism-green plus outcome-`No` is `NOT READY` — surface the gap, do not ship.
+
+## Continuous Mode
+
+For long sessions, run verification every 15 minutes or after major changes:
+
+```markdown
+Set a mental checkpoint:
+- After completing each function
+- After finishing a component
+- Before moving to next task
+
+Run: /verify
+```
+
+## Integration with Hooks
+
+This skill complements PostToolUse hooks but provides deeper verification.
+Hooks catch issues immediately; this skill provides comprehensive review.

package/plugins/continuous-improvement/skills/wild-risa-balance/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: wild-risa-balance
+tier: "2"
+description: Enforces Law 2 (Plan Is Sacred) of the 7 Laws of AI Agent Discipline. Decision-framing lens that pairs WILD generation with RISA execution when emitting recommendation lists. Not a runtime hook.
+origin: continuous-improvement
+---
+
+# WILD / RISA Balance
+
+## When to Use
+
+- Emitting a multi-item recommendation block (≥3 items)
+- Choosing between a safe option and a bold option
+- Reviewing your own plan for over-cautiousness or over-fantasy
+- Pairing with `proceed-with-the-recommendation` to decide which items belong above and below the cut
+
+## The Two Modes
+
+### RISA (Execution)
+
+- **R**ealistic — fits the constraints in front of you
+- **I**mportant — moves a stated goal, not a vanity metric
+- **S**pecific — names files, commands, or owners
+- **A**greeable — the operator can approve it without a meeting
+
+If you only stay in RISA, you ship safe, average results.
+
+### WILD (Creation)
+
+- **W**ild — breaks the default frame
+- **I**maginative — invents an option that did not exist a minute ago
+- **L**imitless — ignores current budget, headcount, or stack
+- **D**isruptive — replaces a workflow rather than tuning it
+
+If you only stay in WILD, you generate cool ideas that never ship.
+
+## The Trap
+
+RISA alone produces a backlog of incremental fixes that never compound. WILD alone produces a graveyard of demos that never reach production. The bigger failure is unconscious switching: drifting into WILD during execution, or drifting into RISA during brainstorming, without naming the switch. Name the mode you are in before you write the next line.
+
+## Switching Deliberately
+
+| Phase                   | Mode  | Why                                                |
+|-------------------------|-------|----------------------------------------------------|
+| Brainstorm              | WILD  | Quantity and range beat early filtering            |
+| Roadmap framing         | WILD  | Frame the bigger bet before scoping it down        |
+| Per-item recommendation | Mixed | Top items can be WILD, baseline items must be RISA |
+| Per-item execution      | RISA  | One thing, verified, shipped                       |
+| Verification            | RISA  | Reality check, no new invention                    |
+| Reflection              | WILD  | Counterfactuals, "what would have been bolder"     |
+
+WILD owns generation phases. RISA owns execution phases. The switch is intentional, not accidental.
+
+## How to Apply in a Recommendation List
+
+When this skill is in play, every recommendation block ships **at least 7 items**, split as:
+
+1. **Top block — WILD pilots: exactly 2 bold items.** Present both; the operator picks at most one to actually run. If you cannot find a second genuinely bold option, stretch — do not pad with a safe item dressed up as wild.
+2. **Bottom block — RISA baseline: at least 5 safe items.** These ship now regardless of the WILD bet. If you cannot reach 5, the surface is under-explored — expand scope before emitting the list.
+3. Within each block, rank descending by impact.
+4. Once the list is composed, wait for the operator's "proceed" signal before invoking `proceed-with-the-recommendation`. Never auto-trigger it. This skill only changes how the list is composed.
+
+Total floor: **2 WILD + 5 RISA = 7 items minimum.** Going above is fine; going below means the skill was not applied.
+
+The point: the operator gets a real WILD/RISA contrast (2 bold bets weighed against a 5-deep trusted baseline), not a flat list where the bold option silently competes with safe ones and loses by default.
+
+## Audience Tiers (beginner vs expert)
+
+Recommendation blocks ship in **two tiers** depending on the operator's signaled level. The 2 WILD + ≥5 RISA floor described above is the **expert** tier. Beginners get a different, lighter shape. The point: under-load for experts and overload for beginners are both failure modes — splitting the format prevents both.
+
+### Tier selection
+
+**Default = expert.** Switch to beginner only when one of these triggers fires:
+
+- **Explicit flag** — the operator types `/beginner` or refers to themselves as a beginner ("for beginner", "as a beginner", "I'm new to this").
+- **Explicit lite framing** — "simple list", "just the top 3", "small list", "short version", "no need for surgical".
+- **Auto-detect heuristic** — the **first message of the thread** contains any of: `beginner`, `new to (this|claude|the system)`, `simple`, `explain like`, `first time`, `i'm just starting`, `i'm learning`. Single-message false positives are acceptable — the operator flips with `/expert` if mismatched.
+
+The operator can override mid-thread: `/expert` switches back to WILD+RISA, `/beginner` switches back to the lite tier. Apply the most recently named tier.
+
+### Beginner tier (lite shape)
+
+When in beginner tier:
+
+- **3 minimum, 5 maximum** items. No padding past 5. Below 3 means there is no recommendation — write `Recommendation: no`.
+- **Goal-driven** — each item names the outcome, not the mechanism. Format: `<verb> <thing> → <observable result>`.
+- **Execution-first** — each item is a concrete next action, not a tradeoff to weigh.
+- **One-shot, iterate from there** — no "surgical change" framing, no phased sequencing, no commit-size gates. Get to a working pass, then improve.
+- **Optimized for the latest Opus model (Opus 4.7 at time of writing)** — assume the model holds the full task in one shot. Do not pre-decompose into micro-steps that fight the model's reasoning depth. Lean on broader, outcome-shaped instructions over fine-grained scripts.
+- Order: descending impact.
+- No WILD/RISA labels. No counts annotation. No tiered tables.
+
+### Expert tier (default for Naim, default in this repo)
+
+The full WILD+RISA structure documented above: ≥7 items, exactly 2 WILD + ≥5 RISA, WILD on top descending, RISA below descending, counts annotated inline.
+
+Each item still leads with the outcome inside both WILD and RISA: `<verb> <thing> → <observable result>`.
+
+### Tier signal in the 3-section close
+
+When Phase 7's three-section close lands, the `## Recommendation` header carries an explicit tier suffix:
+
+- Expert: `## Recommendation (expert)`
+- Beginner: `## Recommendation (beginner)`
+
+The Stop hook regex (`^#+ +Recommendation(?:\s|$)`) already accepts both forms — the suffix is documentation, not a gate. The point is a self-describing audit trail: a future reader (or an instinct scan) can tell which tier was applied without re-deriving it from item count or label presence.
+
+### The "no" escape valve (both tiers)
+
+If neither tier can produce a real recommendation — every candidate item would be padding, or you cannot reach the tier's floor (3 for beginner, 7 for expert) without inventing busywork — write `Recommendation: no` and stop. This applies to **both tiers equally**.
+
+`no` is not absence. It is an explicit signal that the current session or perspective is exhausted on this surface and the operator should switch context: a fresh session (cold prompt cache, no carryover bias), a different specialist agent (different perspective on the same problem), a different framing (re-scoping the goal), or sleep on it. Padding to hit the floor is the failure mode this escape exists to prevent — a flat 3-item beginner list of "review the README, run the tests, commit your changes" is worse than `Recommendation: no` because it disguises an empty thought as work.
+
+When `no` ships, the Phase 7 close header still carries the tier suffix (`## Recommendation (expert)` or `## Recommendation (beginner)`) so the audit trail records which tier exhausted itself, and the body is just the literal `no` on its own line. No tiered tables, no WILD/RISA blocks, no "Want me to: A or B?" closer.
+
+## Proactive Roadmap Surfacing (surface, do not execute)
+
+A "wait for instructions" agent fails by silence — sitting on a known next step (visible roadmap, deferred item from a prior session) until told. A "proactive" agent fails by running that step without being asked. Both lose. Surface bridges them: raise the next step as a recommendation item, never as a fait accompli.
+
+### Trigger conditions
+
+Surface a next step when any of these are true:
+
+- A persistent roadmap names an undone step — MemoryCore `current-session.md`, `docs/plans/*`, `⚠️ Deferred` entries in a project `CLAUDE.md`, or pending operator actions logged in MemoryCore.
+- The current task is finished and a stated session goal implies the next one.
+- The session has drifted from a stated roadmap (asked to do A, but B is now blocked by A's choice).
+- An instinct or memory record predicts a near-term action the operator typically forgets (e.g., "rotate keys before next deploy", "push branch after N commits").
+
+### Hard boundary — surface, do not execute
+
+Surfacing emits the next step as a recommendation item. It does **not** mean running the command, editing the file, or shipping the change. Execution still requires explicit "proceed", "go", "run it", or equivalent. The boundary is non-negotiable:
+
+- Global CLAUDE.md: "If instructions conflict or information is missing, stop and ask."
+- Auto Mode: even in autonomous execution, "anything that deletes data or modifies shared or production systems still needs explicit user confirmation."
+- Trust is asymmetric — one unauthorized "helpful" action costs more than a hundred missed surfacings. Recovery is one-way.
+
+### Format
+
+A surfaced item lives inside the normal RISA block. Mark it inline as `(surfaced — <source>)` so the operator can tell which items came from the roadmap vs. the current request:
+
+```
+RISA baseline — ship regardless (5 of ≥5)
+1. Run remote D1 migration before next deploy → unblocks Close/Cancel admin button. (surfaced — pending operator action since 2026-05-04)
+2. ...
+```
+
+A WILD-tier reframe of the roadmap itself (not a single deferred step, but a re-shape of the whole next phase) goes in the WILD block instead, with the same `(surfaced — <source>)` marker.
+
+### Anti-patterns
+
+- Re-surfacing an item the operator explicitly deferred — once is a reminder, three times is nagging. After one repeat, log the defer reason to memory and stop.
+- Surfacing speculative steps with no source in any roadmap or memory ("you should also consider…" without a citation).
+- Bundling a surface with execution ("I went ahead and started X"). Surface, wait, execute on go.
+- Treating absence of a roadmap as license to invent one — if no roadmap exists and none was requested, ask before drafting.
+
+The point: the operator never has to remember a deferred item, and never has to forgive an unauthorized one. Both at once.
+
+## Integration with the 7 Laws
+
+| Mode | Reinforces                                              | Tempered by              |
+|------|---------------------------------------------------------|--------------------------|
+| RISA | Law 2 (Plan), Law 3 (One Thing), Law 4 (Verify)         | Law 6 (Iterate One Thing) |
+| WILD | Law 1 (Research — broader exploration), Law 5 (Reflect) | Law 6 (Iterate One Thing) |
+
+Both modes pass through Law 6 before execution. WILD without Law 6 is a wishlist. RISA without Law 6 ships safe fixes while the real bottleneck waits.
+
+## Example
+
+```
+Recommendations (descending impact within each block)
+
+WILD pilots — pick at most one (2 of 2)
+1. Replace the current review workflow with a single adversarial pair.
+2. Drop the staging environment in favor of feature-flagged production.
+
+RISA baseline — ship regardless (5 of ≥5)
+1. Add the missing test for the failure path noted in verification.
+2. Rename the ambiguous flag to match its actual behavior.
+3. Backfill the type on the public export that currently widens to `any`.
+4. Wire the existing Stop hook into the new skill's checklist gate.
+5. Update the README mirror so the bundled plugin matches the source skill. (surfaced — verify:skill-mirror gate flagged drift in last CI run)
+```
+
+Total: 7 items (2 WILD + 5 RISA). That is the floor — emit more on either side if the surface warrants it. The fifth RISA item is marked `(surfaced — <source>)` to demonstrate the convention from the Proactive Roadmap Surfacing section: items lifted from a roadmap or memory carry an inline source attribution so the operator can tell roadmap-driven items apart from current-request items.
+
+## Related
+
+- `continuous-improvement` — the 7 Laws card (core skill)
+- `proceed-with-the-recommendation` — execution arm; carries surfaced items across the surface → execute boundary defined in the Proactive Roadmap Surfacing section above
+- `superpowers:brainstorming` — upstream WILD generator
+- `verification-loop` — downstream RISA verifier

package/plugins/continuous-improvement/skills/workspace-surface-audit/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: workspace-surface-audit
+tier: companion
+description: "Enforces Law 1 (Research Before Executing) of the 7 Laws of AI Agent Discipline. Audits the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommends the highest-value continuous-improvement-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment."
+origin: continuous-improvement
+---
+
+# Workspace Surface Audit
+
+Read-only audit skill for answering the question "what can this workspace and machine actually do right now, and what should we add or enable next?"
+
+This is the continuous-improvement answer to setup-audit plugins. It does not modify files unless the user explicitly asks for follow-up implementation.
+
+## When to Use
+
+- User says "set up Claude Code", "recommend automations", "what plugins or MCPs should I use?", or "what am I missing?"
+- Auditing a machine or repo before installing more skills, hooks, or connectors
+- Comparing official marketplace plugins against continuous-improvement coverage
+- Reviewing `.env`, `.mcp.json`, plugin settings, or connected-app surfaces to find missing workflow layers
+- Deciding whether a capability should be a skill, hook, agent, MCP, or external connector
+
+## Non-Negotiable Rules
+
+- Never print secret values. Surface only provider names, capability names, file paths, and whether a key or config exists.
+- Prefer continuous-improvement workflows over generic "install another plugin" advice when continuous-improvement can reasonably own the surface.
+- Treat external plugins as benchmarks and inspiration, not authoritative product boundaries.
+- Separate three things clearly:
+  - already available now
+  - available but not wrapped well in continuous-improvement
+  - not available and would require a new integration
+
+## Audit Inputs
+
+Inspect only the files and settings needed to answer the question well:
+
+1. **Repo surface**
+   - `package.json`, lockfiles, language markers, framework config, `README.md`
+   - `.mcp.json`, `.lsp.json`, `.claude/settings*.json`, `.codex/*`
+   - `AGENTS.md`, `CLAUDE.md`, install manifests, hook configs
+2. **Environment surface**
+   - `.env*` files in the active repo and obvious adjacent continuous-improvement workspaces
+   - Surface only key names such as `STRIPE_API_KEY`, `TWILIO_AUTH_TOKEN`, `FAL_KEY`
+3. **Connected tool surface**
+   - Installed plugins, enabled connectors, MCP servers, LSPs, and app integrations
+4. **continuous-improvement surface**
+   - Existing skills, commands, hooks, agents, and install modules that already cover the need
+
+## Audit Process
+
+### Phase 1: Inventory What Exists
+
+Produce a compact inventory:
+
+- active harness targets
+- installed plugins and connected apps
+- configured MCP servers
+- configured LSP servers
+- env-backed services implied by key names
+- existing continuous-improvement skills already relevant to the workspace
+
+If a surface exists only as a primitive, call that out. Example:
+
+- "Stripe is available via connected app, but continuous-improvement lacks a billing-operator skill"
+- "Google Drive is connected, but there is no continuous-improvement-native Google Workspace operator workflow"
+
+#### Environment Grain
+
+Before any tool-class advice, capture the per-host facts that make commands either run or fail. The 28-day usage report's recurring "command failed / wrong approach" friction class roots almost entirely in this grain being unrecorded at session start — the agent reaches for `jq`, finds it missing, retries; reaches for bash chaining, hits PowerShell parser errors, retries; trusts a stale `pwd` after `tsc`, runs verification from the wrong directory, retries.
+
+Probe and record (no destructive commands; quote results inline):
+
+- **Shell flavor.** `echo $SHELL` on POSIX or `$PSVersionTable.PSEdition` on Windows; detect `bash`, `zsh`, `pwsh`, or `cmd`. PowerShell on Windows treats `&&`, `2>&1`, and quoting differently from bash; Git Bash on Windows is bash-shaped but lacks several POSIX utilities by default.
+- **OS family + line endings.** `uname -s` (or PowerShell `$IsWindows`) plus `git config --get core.autocrlf`. On Windows with `core.autocrlf=true`, `git status` reports phantom modifications on every checked-out file — `git diff --stat` is the reliable change-set view.
+- **jq availability.** `command -v jq` (or `Get-Command jq`). When jq is missing, observation-pipeline hooks fall back to a thin schema and curl/JSON one-liners need a node/python rewrite.
+- **Case-sensitive filesystem.** Test by creating two paths differing only in case in a tempdir. NTFS (Windows) and APFS (macOS default) are case-insensitive; Linux ext4 and case-sensitive APFS are case-sensitive. Affects `CLAUDE.md` vs `claude.md` resolution and import paths.
+- **CWD baseline.** `pwd` (or `Get-Location`) recorded at session start. `tsc`, build scripts, and some test runners change CWD as a side effect; subsequent commands run from the wrong directory return "deps not installed" or "config not found" misreads.
+- **Parallel-actor expectation.** Document whether a second Claude / Codex / Maulana session may operate on the same working tree. If yes, the `gateguard` Parallel-Actor Gate must baseline `git rev-parse HEAD` + `git status --porcelain` + upstream before the first mutation, and re-check on every subsequent mutation.
+
+Output the recorded grain as a single fenced block so it survives context compaction and any later phase can reference it without re-probing:
+
+```
+shell-flavor:    pwsh
+os:              windows-11 / autocrlf=true
+jq:              missing
+case-sensitive:  false
+cwd-baseline:    D:/Ai/continuous-improvement
+parallel-actor:  yes
+```
+
+The fenced block is the contract surface — keep the field names stable so downstream skills (`gateguard`, `verification-loop`, future autonomous-release-train) can parse it without per-host special-casing.
+
+### Phase 2: Benchmark Against Official and Installed Surfaces
+
+Compare the workspace against:
+
+- official Claude plugins that overlap with setup, review, docs, design, or workflow quality
+- locally installed plugins in Claude or Codex
+- the user's currently connected app surfaces
+
+Do not just list names. For each comparison, answer:
+
+1. what they actually do
+2. whether continuous-improvement already has parity
+3. whether continuous-improvement only has primitives
+4. whether continuous-improvement is missing the workflow entirely
+
+### Phase 3: Turn Gaps Into continuous-improvement Decisions
+
+For every real gap, recommend the correct continuous-improvement-native shape:
+
+| Gap Type | Preferred continuous-improvement Shape |
+|----------|---------------------|
+| Repeatable operator workflow | Skill |
+| Automatic enforcement or side-effect | Hook |
+| Specialized delegated role | Agent |
+| External tool bridge | MCP server or connector |
+| Install/bootstrap guidance | Setup or audit skill |
+
+Default to user-facing skills that orchestrate existing tools when the need is operational rather than infrastructural.
+
+## Output Format
+
+Return five sections in this order:
+
+1. **Current surface** — what is already usable right now
+2. **Parity** — where continuous-improvement already matches or exceeds the benchmark
+3. **Primitive-only gaps** — tools exist, but continuous-improvement lacks a clean operator skill
+4. **Missing integrations** — capability not available yet
+5. **Top 3-5 next moves** — concrete continuous-improvement-native additions, ordered by impact
+
+## Recommendation Rules
+
+- Recommend at most 1-2 highest-value ideas per category.
+- Favor skills with obvious user intent and business value:
+  - setup audit
+  - billing/customer ops
+  - issue/program ops
+  - Google Workspace ops
+  - deployment/ops control
+- If a connector is company-specific, recommend it only when it is genuinely available or clearly useful to the user's workflow.
+- If continuous-improvement already has a strong primitive, propose a wrapper skill instead of inventing a brand-new subsystem.
+
+## Good Outcomes
+
+- The user can immediately see what is connected, what is missing, and what continuous-improvement should own next.
+- Recommendations are specific enough to implement in the repo without another discovery pass.
+- The final answer is organized around workflows, not API brands.

package/plugins/continuous-improvement/templates/planning-with-files/findings.md

@@ -0,0 +1,8 @@
+# Findings
+
+## Research Notes
+- Created on {{date}}.
+- Record source links, code references, and synthesized findings here.
+
+## Sources
+- Add links and short summaries here.

package/plugins/continuous-improvement/templates/planning-with-files/progress.md

@@ -0,0 +1,7 @@
+# Progress
+
+## Session Log
+- {{date}}: Initialized planning files.
+
+## Verification Notes
+- Record commands, tests, outputs, and checkpoints here.

package/plugins/continuous-improvement/templates/planning-with-files/task_plan.md

@@ -0,0 +1,23 @@
+# Task Plan
+
+## Goal
+{{goal}}
+
+## Status
+{{status}}
+
+## Phases
+{{phases}}
+
+## Key Questions
+- [ ] What existing implementation or context should be reviewed first?
+- [ ] What constraints or risks need validation before execution?
+- [ ] What verification proves the task is complete?
+
+## Decisions Made
+- None yet.
+
+## Errors Encountered
+| Error | Attempt | Resolution |
+| --- | --- | --- |
+| None yet | - | - |

package/plugins/expert.json

@@ -1,8 +1,8 @@
 {
   "name": "continuous-improvement",
-  "version": "3.0.0",
+  "version": "3.8.0",
   "mode": "expert",
-  "description": "Full plugin: 8 tools including instinct management, import/export, observation viewer, and manual instinct creation.",
+  "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 disciplined and learnings survive context resets.",
   "tools": [
     {
       "name": "ci_status",
@@ -35,6 +35,22 @@
     {
       "name": "ci_import",
       "what": "Import instincts from JSON (skip duplicates)"
+    },
+    {
+      "name": "ci_plan_init",
+      "what": "Create project-root planning files for persistent task memory"
+    },
+    {
+      "name": "ci_plan_status",
+      "what": "Summarize task_plan.md, findings.md, and progress.md status"
+    },
+    {
+      "name": "ci_dashboard",
+      "what": "Visual dashboard showing instinct health, confidence distribution, and learning progress"
+    },
+    {
+      "name": "ci_load_pack",
+      "what": "Load starter instinct packs (react, python, go) into the current project"
     }
   ],
   "setup": {
@@ -42,7 +58,11 @@
       "mcpServers": {
         "continuous-improvement": {
           "command": "node",
-          "args": ["<install-path>/bin/mcp-server.mjs", "--mode", "expert"]
+          "args": [
+            "<install-path>/bin/mcp-server.mjs",
+            "--mode",
+            "expert"
+          ]
         }
       }
     },
@@ -50,13 +70,22 @@
       "mcpServers": {
         "continuous-improvement": {
           "command": "node",
-          "args": ["<install-path>/bin/mcp-server.mjs", "--mode", "expert"]
+          "args": [
+            "<install-path>/bin/mcp-server.mjs",
+            "--mode",
+            "expert"
+          ]
         }
       }
     }
   },
   "hooks": {
-    "included": ["PreToolUse", "PostToolUse", "SessionStart", "SessionEnd"],
+    "included": [
+      "PreToolUse",
+      "PostToolUse",
+      "SessionStart",
+      "SessionEnd"
+    ],
     "description": "Full hook suite: observation capture + session-level instinct loading and auto-reflection."
   }
 }