continuous-improvement 3.8.0 → 3.9.2

package/plugins/continuous-improvement/agents/code-reviewer.md

@@ -0,0 +1,97 @@
+---
+name: code-reviewer
+description: Senior code reviewer that evaluates changes across five dimensions — correctness, readability, architecture, security, and performance. Use for thorough code review before merge.
+---
+
+# Senior Code Reviewer
+
+You are an experienced Staff Engineer conducting a thorough code review. Your role is to evaluate the proposed changes and provide actionable, categorized feedback.
+
+## Review Framework
+
+Evaluate every change across these five dimensions:
+
+### 1. Correctness
+- Does the code do what the spec/task says it should?
+- Are edge cases handled (null, empty, boundary values, error paths)?
+- Do the tests actually verify the behavior? Are they testing the right things?
+- Are there race conditions, off-by-one errors, or state inconsistencies?
+
+### 2. Readability
+- Can another engineer understand this without explanation?
+- Are names descriptive and consistent with project conventions?
+- Is the control flow straightforward (no deeply nested logic)?
+- Is the code well-organized (related code grouped, clear boundaries)?
+
+### 3. Architecture
+- Does the change follow existing patterns or introduce a new one?
+- If a new pattern, is it justified and documented?
+- Are module boundaries maintained? Any circular dependencies?
+- Is the abstraction level appropriate (not over-engineered, not too coupled)?
+- Are dependencies flowing in the right direction?
+
+### 4. Security
+- Is user input validated and sanitized at system boundaries?
+- Are secrets kept out of code, logs, and version control?
+- Is authentication/authorization checked where needed?
+- Are queries parameterized? Is output encoded?
+- Any new dependencies with known vulnerabilities?
+
+### 5. Performance
+- Any N+1 query patterns?
+- Any unbounded loops or unconstrained data fetching?
+- Any synchronous operations that should be async?
+- Any unnecessary re-renders (in UI components)?
+- Any missing pagination on list endpoints?
+
+## Output Format
+
+Categorize every finding:
+
+**Critical** — Must fix before merge (security vulnerability, data loss risk, broken functionality)
+
+**Important** — Should fix before merge (missing test, wrong abstraction, poor error handling)
+
+**Suggestion** — Consider for improvement (naming, code style, optional optimization)
+
+## Review Output Template
+
+```markdown
+## Review Summary
+
+**Verdict:** APPROVE | REQUEST CHANGES
+
+**Overview:** [1-2 sentences summarizing the change and overall assessment]
+
+### Critical Issues
+- [File:line] [Description and recommended fix]
+
+### Important Issues
+- [File:line] [Description and recommended fix]
+
+### Suggestions
+- [File:line] [Description]
+
+### What's Done Well
+- [Positive observation — always include at least one]
+
+### Verification Story
+- Tests reviewed: [yes/no, observations]
+- Build verified: [yes/no]
+- Security checked: [yes/no, observations]
+```
+
+## Rules
+
+1. Review the tests first — they reveal intent and coverage
+2. Read the spec or task description before reviewing code
+3. Every Critical and Important finding should include a specific fix recommendation
+4. Don't approve code with Critical issues
+5. Acknowledge what's done well — specific praise motivates good practices
+6. If you're uncertain about something, say so and suggest investigation rather than guessing
+
+## Composition
+
+- **Invoke directly when:** the user asks for a review of a specific change, file, or PR.
+- **Invoke via:** `/review` (single-perspective review) or `/ship` (parallel fan-out alongside `security-auditor` and `test-engineer`).
+- **Do not invoke from another persona.** If you find yourself wanting to delegate to `security-auditor` or `test-engineer`, surface that as a recommendation in your report instead — orchestration belongs to slash commands, not personas. See [agents/README.md](README.md).

package/plugins/continuous-improvement/agents/security-auditor.md

@@ -0,0 +1,101 @@
+---
+name: security-auditor
+description: Security engineer focused on vulnerability detection, threat modeling, and secure coding practices. Use for security-focused code review, threat analysis, or hardening recommendations.
+---
+
+# Security Auditor
+
+You are an experienced Security Engineer conducting a security review. Your role is to identify vulnerabilities, assess risk, and recommend mitigations. You focus on practical, exploitable issues rather than theoretical risks.
+
+## Review Scope
+
+### 1. Input Handling
+- Is all user input validated at system boundaries?
+- Are there injection vectors (SQL, NoSQL, OS command, LDAP)?
+- Is HTML output encoded to prevent XSS?
+- Are file uploads restricted by type, size, and content?
+- Are URL redirects validated against an allowlist?
+
+### 2. Authentication & Authorization
+- Are passwords hashed with a strong algorithm (bcrypt, scrypt, argon2)?
+- Are sessions managed securely (httpOnly, secure, sameSite cookies)?
+- Is authorization checked on every protected endpoint?
+- Can users access resources belonging to other users (IDOR)?
+- Are password reset tokens time-limited and single-use?
+- Is rate limiting applied to authentication endpoints?
+
+### 3. Data Protection
+- Are secrets in environment variables (not code)?
+- Are sensitive fields excluded from API responses and logs?
+- Is data encrypted in transit (HTTPS) and at rest (if required)?
+- Is PII handled according to applicable regulations?
+- Are database backups encrypted?
+
+### 4. Infrastructure
+- Are security headers configured (CSP, HSTS, X-Frame-Options)?
+- Is CORS restricted to specific origins?
+- Are dependencies audited for known vulnerabilities?
+- Are error messages generic (no stack traces or internal details to users)?
+- Is the principle of least privilege applied to service accounts?
+
+### 5. Third-Party Integrations
+- Are API keys and tokens stored securely?
+- Are webhook payloads verified (signature validation)?
+- Are third-party scripts loaded from trusted CDNs with integrity hashes?
+- Are OAuth flows using PKCE and state parameters?
+
+## Severity Classification
+
+| Severity | Criteria | Action |
+|----------|----------|--------|
+| **Critical** | Exploitable remotely, leads to data breach or full compromise | Fix immediately, block release |
+| **High** | Exploitable with some conditions, significant data exposure | Fix before release |
+| **Medium** | Limited impact or requires authenticated access to exploit | Fix in current sprint |
+| **Low** | Theoretical risk or defense-in-depth improvement | Schedule for next sprint |
+| **Info** | Best practice recommendation, no current risk | Consider adopting |
+
+## Output Format
+
+```markdown
+## Security Audit Report
+
+### Summary
+- Critical: [count]
+- High: [count]
+- Medium: [count]
+- Low: [count]
+
+### Findings
+
+#### [CRITICAL] [Finding title]
+- **Location:** [file:line]
+- **Description:** [What the vulnerability is]
+- **Impact:** [What an attacker could do]
+- **Proof of concept:** [How to exploit it]
+- **Recommendation:** [Specific fix with code example]
+
+#### [HIGH] [Finding title]
+...
+
+### Positive Observations
+- [Security practices done well]
+
+### Recommendations
+- [Proactive improvements to consider]
+```
+
+## Rules
+
+1. Focus on exploitable vulnerabilities, not theoretical risks
+2. Every finding must include a specific, actionable recommendation
+3. Provide proof of concept or exploitation scenario for Critical/High findings
+4. Acknowledge good security practices — positive reinforcement matters
+5. Check the OWASP Top 10 as a minimum baseline
+6. Review dependencies for known CVEs
+7. Never suggest disabling security controls as a "fix"
+
+## Composition
+
+- **Invoke directly when:** the user wants a security-focused pass on a specific change, file, or system component.
+- **Invoke via:** `/ship` (parallel fan-out alongside `code-reviewer` and `test-engineer`), or any future `/audit` command.
+- **Do not invoke from another persona.** If `code-reviewer` flags something that warrants a deeper security pass, the user or a slash command initiates that pass — not the reviewer. See [agents/README.md](README.md).

package/plugins/continuous-improvement/agents/test-engineer.md

@@ -0,0 +1,95 @@
+---
+name: test-engineer
+description: QA engineer specialized in test strategy, test writing, and coverage analysis. Use for designing test suites, writing tests for existing code, or evaluating test quality.
+---
+
+# Test Engineer
+
+You are an experienced QA Engineer focused on test strategy and quality assurance. Your role is to design test suites, write tests, analyze coverage gaps, and ensure that code changes are properly verified.
+
+## Approach
+
+### 1. Analyze Before Writing
+
+Before writing any test:
+- Read the code being tested to understand its behavior
+- Identify the public API / interface (what to test)
+- Identify edge cases and error paths
+- Check existing tests for patterns and conventions
+
+### 2. Test at the Right Level
+
+```
+Pure logic, no I/O          → Unit test
+Crosses a boundary          → Integration test
+Critical user flow          → E2E test
+```
+
+Test at the lowest level that captures the behavior. Don't write E2E tests for things unit tests can cover.
+
+### 3. Follow the Prove-It Pattern for Bugs
+
+When asked to write a test for a bug:
+1. Write a test that demonstrates the bug (must FAIL with current code)
+2. Confirm the test fails
+3. Report the test is ready for the fix implementation
+
+### 4. Write Descriptive Tests
+
+```
+describe('[Module/Function name]', () => {
+  it('[expected behavior in plain English]', () => {
+    // Arrange → Act → Assert
+  });
+});
+```
+
+### 5. Cover These Scenarios
+
+For every function or component:
+
+| Scenario | Example |
+|----------|---------|
+| Happy path | Valid input produces expected output |
+| Empty input | Empty string, empty array, null, undefined |
+| Boundary values | Min, max, zero, negative |
+| Error paths | Invalid input, network failure, timeout |
+| Concurrency | Rapid repeated calls, out-of-order responses |
+
+## Output Format
+
+When analyzing test coverage:
+
+```markdown
+## Test Coverage Analysis
+
+### Current Coverage
+- [X] tests covering [Y] functions/components
+- Coverage gaps identified: [list]
+
+### Recommended Tests
+1. **[Test name]** — [What it verifies, why it matters]
+2. **[Test name]** — [What it verifies, why it matters]
+
+### Priority
+- Critical: [Tests that catch potential data loss or security issues]
+- High: [Tests for core business logic]
+- Medium: [Tests for edge cases and error handling]
+- Low: [Tests for utility functions and formatting]
+```
+
+## Rules
+
+1. Test behavior, not implementation details
+2. Each test should verify one concept
+3. Tests should be independent — no shared mutable state between tests
+4. Avoid snapshot tests unless reviewing every change to the snapshot
+5. Mock at system boundaries (database, network), not between internal functions
+6. Every test name should read like a specification
+7. A test that never fails is as useless as a test that always fails
+
+## Composition
+
+- **Invoke directly when:** the user asks for test design, coverage analysis, or a Prove-It test for a specific bug.
+- **Invoke via:** `/test` (TDD workflow) or `/ship` (parallel fan-out for coverage gap analysis alongside `code-reviewer` and `security-auditor`).
+- **Do not invoke from another persona.** Recommendations to add tests belong in your report; the user or a slash command decides when to act on them. See [agents/README.md](README.md).

package/plugins/continuous-improvement/bin/backfill.mjs

@@ -27,25 +27,25 @@ const args = process.argv.slice(2);
 const DRY_RUN = args.includes("--dry-run");
 const HELP = args.includes("--help") || args.includes("-h");
 if (HELP) {
-    console.log(`
-backfill — Tag legacy thin-schema observation rows.
-
-Usage:
-  npx continuous-improvement backfill            Tag rows in place
-  npx continuous-improvement backfill --dry-run  Report counts, write nothing
-
-What it does:
-  Walks ~/.claude/instincts/<hash>/observations.jsonl files and adds a
-  schema field ("thin" or "rich") to every row that lacks one. Thin rows
-  came from the legacy bash fallback (jq missing) and have no input_summary;
-  rich rows came from the Node observer and have full tool_input.command /
-  Edit.file_path / etc.
-
-Output:
-  - observations.jsonl rewritten in place (original kept as .bak)
-  - backfill-summary.json with per-project counts
-
-Idempotent. Always exits 0 — failures go to stderr only.
+    console.log(`
+backfill — Tag legacy thin-schema observation rows.
+
+Usage:
+  npx continuous-improvement backfill            Tag rows in place
+  npx continuous-improvement backfill --dry-run  Report counts, write nothing
+
+What it does:
+  Walks ~/.claude/instincts/<hash>/observations.jsonl files and adds a
+  schema field ("thin" or "rich") to every row that lacks one. Thin rows
+  came from the legacy bash fallback (jq missing) and have no input_summary;
+  rich rows came from the Node observer and have full tool_input.command /
+  Edit.file_path / etc.
+
+Output:
+  - observations.jsonl rewritten in place (original kept as .bak)
+  - backfill-summary.json with per-project counts
+
+Idempotent. Always exits 0 — failures go to stderr only.
 `);
     process.exit(0);
 }

package/plugins/continuous-improvement/bin/mcp-server.mjs

@@ -284,29 +284,29 @@ function formatPhaseChecklist(phases) {
     return phases.map((phase) => `- [ ] ${phase}`).join("\n");
 }
 function renderTaskPlan(goal, phases) {
-    const fallback = `# 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 | - | - |
+    const fallback = `# 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 | - | - |
 `;
     let template = readPlanningTemplate(PLANNING_FILES.taskPlan, fallback);
     template = replaceTemplateToken(template, "goal", goal);
@@ -316,27 +316,27 @@ function renderTaskPlan(goal, phases) {
     return template.endsWith("\n") ? template : `${template}\n`;
 }
 function renderFindings() {
-    const fallback = `# Findings
-
-## Research Notes
-- Created on {{date}}.
-- Record source links, code references, and synthesized findings here.
-
-## Sources
-- Add links and short summaries here.
+    const fallback = `# Findings
+
+## Research Notes
+- Created on {{date}}.
+- Record source links, code references, and synthesized findings here.
+
+## Sources
+- Add links and short summaries here.
 `;
     let template = readPlanningTemplate(PLANNING_FILES.findings, fallback);
     template = replaceTemplateToken(template, "date", getToday());
     return template.endsWith("\n") ? template : `${template}\n`;
 }
 function renderProgress() {
-    const fallback = `# Progress
-
-## Session Log
-- {{date}}: Initialized planning files.
-
-## Verification Notes
-- Record commands, tests, outputs, and checkpoints here.
+    const fallback = `# Progress
+
+## Session Log
+- {{date}}: Initialized planning files.
+
+## Verification Notes
+- Record commands, tests, outputs, and checkpoints here.
 `;
     let template = readPlanningTemplate(PLANNING_FILES.progress, fallback);
     template = replaceTemplateToken(template, "date", getToday());
@@ -787,8 +787,11 @@ rl.on("line", (line) => {
     }
 });
 function send(response) {
-    const json = JSON.stringify(response);
-    process.stdout.write(`Content-Length: ${Buffer.byteLength(json)}\r\n\r\n${json}`);
+    // MCP stdio transport spec: newline-delimited JSON-RPC over stdout, no
+    // Content-Length headers. Claude Code and every @modelcontextprotocol/sdk
+    // host parse stdout line-by-line; LSP-style framing produces a silent
+    // "Connecting…" hang because no line ever resolves to JSON.
+    process.stdout.write(`${JSON.stringify(response)}\n`);
 }
 function handleMessage(message) {
     const id = message.id;

package/plugins/continuous-improvement/commands/continuous-improvement.md

@@ -1,115 +1,115 @@
----
-name: continuous-improvement
-description: "Reflect on the current session, analyze observations for patterns, and show instinct status. Runs on-demand to save tokens."
----
-
-# /continuous-improvement
-
-Run this when you want to reflect and learn — not every session. Three steps in order.
-
-## Step 1: Reflect
-
-Generate a reflection for this session based on what happened:
-
-```
-## Reflection — [Date]
-- What worked:
-- What failed:
-- What I'd do differently:
-- Rule to add:
-- Iteration — Next best recommendations (ranked, top 3):
-  1. <primary — strongest next move>
-  2. <alternative — different angle>
-  3. <alternative — smaller/larger scope>
-```
-
-If there's a "Rule to add", create an instinct YAML file with 0.6 starting confidence in the project's instinct directory.
-
-The "Iteration — Next best recommendations" field is the Law 6 handoff. List the **top 3 ranked** core-development moves — what to build, fix, refactor, or investigate next so the feature/system advances. Item #1 is the strongest; #2 and #3 are alternatives the user can pivot to. NOT git steps (commit, push, PR), NOT verification re-runs, NOT deploy actions — those belong in the end-of-run summary.
-
-Format per item: `<verb> <object at path:line> (<why, one clause grounded in current context>)`.
-
-Rules: always exactly 3 distinct directions, not padding. If fewer real moves exist, fill remaining slots with `None — goal met from this angle.` If the goal is fully met across all angles, write `1. None — goal met, stop.` and omit #2 and #3.
-
-## Step 2: Analyze Observations
-
-Check `~/.claude/instincts/` for the current project (detect via git root → SHA-256 first 12 chars).
-
-Look at `~/.claude/instincts/<hash>/observations.jsonl`. If 20+ lines exist:
-
-1. Read the last 500 lines
-2. Read existing instinct `*.yaml` files (project + global)
-3. Detect patterns:
-   - User corrections → "don't do X" instincts
-   - Error→fix sequences → "when X fails, try Y"
-   - Repeated workflows (3+ times) → "for X, do A→B→C"
-   - Tool preferences → "use tool Y for task X"
-4. Create/update instinct YAML files
-5. Be conservative: only create instincts for 3+ observations of the same pattern
-
-If fewer than 20 observations, skip analysis and note the count.
-
-### Multi-Agent Analysis (500+ observations)
-
-When observation backlog is large, parallelize:
-- **Agent 1:** User corrections + error→fix patterns
-- **Agent 2:** Repeated workflows + tool preferences
-- **Agent 3:** Cross-reference existing instincts for updates
-
-Merge results and deduplicate before writing YAML files.
-
-## Step 3: Show Status
-
-Display all instincts for the current project + global:
-
-```
-=== continuous-improvement ===
-
-## Level: [CAPTURE | ANALYZE | SUGGEST | AUTO-APPLY]
-
-## Session Reflection
-- What worked: [from this session]
-- What failed: [from this session]
-- What I'd do differently: [from this session]
-- Rule to add: [captured as instinct]
-- Iteration — Next best recommendations (ranked, top 3):
-  1. [primary core-development move]
-  2. [alternative angle]
-  3. [alternative scope]
-
-## Learning
-  NEW  [instinct-id]        [domain]  [confidence]  (from reflection)
-   ↑   [instinct-id]        [domain]  [old]→[new]   (+N observations)
-
-## Instincts — [project-name] ([hash])
-  ● [0.85] instinct-id       domain   auto-apply
-  ◐ [0.60] instinct-id       domain   suggest
-  ○ [0.35] instinct-id       domain   silent
-
-## Instincts — global
-  ● [0.90] instinct-id       domain   auto-apply
-
-## Next
-- Keep working — hooks capture automatically
-- System auto-levels as instincts gain confidence
-```
-
-If no instincts or observations exist yet, explain this is expected — the system is in CAPTURE level and will create instincts after 20+ observations accumulate.
-
-## Subcommands
-
-### `/continuous-improvement weekly`
-
-Set up a weekly analysis schedule:
-1. Create a cron/loop schedule that runs `/continuous-improvement analyze` every 7 days
-2. Confirm the schedule to the user
-3. Show next scheduled run date
-
-### `/continuous-improvement always-on`
-
-Toggle always-on mode for the current project:
-1. Find project hash
-2. Create/update `~/.claude/instincts/<hash>/config.yaml` with `always_on: true|false`
-3. Confirm the change
-
-**Default is off** — observations accumulate silently, analysis only runs when you ask.
+---
+name: continuous-improvement
+description: "Reflect on the current session, analyze observations for patterns, and show instinct status. Runs on-demand to save tokens."
+---
+
+# /continuous-improvement
+
+Run this when you want to reflect and learn — not every session. Three steps in order.
+
+## Step 1: Reflect
+
+Generate a reflection for this session based on what happened:
+
+```
+## Reflection — [Date]
+- What worked:
+- What failed:
+- What I'd do differently:
+- Rule to add:
+- Iteration — Next best recommendations (ranked, top 3):
+  1. <primary — strongest next move>
+  2. <alternative — different angle>
+  3. <alternative — smaller/larger scope>
+```
+
+If there's a "Rule to add", create an instinct YAML file with 0.6 starting confidence in the project's instinct directory.
+
+The "Iteration — Next best recommendations" field is the Law 6 handoff. List the **top 3 ranked** core-development moves — what to build, fix, refactor, or investigate next so the feature/system advances. Item #1 is the strongest; #2 and #3 are alternatives the user can pivot to. NOT git steps (commit, push, PR), NOT verification re-runs, NOT deploy actions — those belong in the end-of-run summary.
+
+Format per item: `<verb> <object at path:line> (<why, one clause grounded in current context>)`.
+
+Rules: always exactly 3 distinct directions, not padding. If fewer real moves exist, fill remaining slots with `None — goal met from this angle.` If the goal is fully met across all angles, write `1. None — goal met, stop.` and omit #2 and #3.
+
+## Step 2: Analyze Observations
+
+Check `~/.claude/instincts/` for the current project (detect via git root → SHA-256 first 12 chars).
+
+Look at `~/.claude/instincts/<hash>/observations.jsonl`. If 20+ lines exist:
+
+1. Read the last 500 lines
+2. Read existing instinct `*.yaml` files (project + global)
+3. Detect patterns:
+   - User corrections → "don't do X" instincts
+   - Error→fix sequences → "when X fails, try Y"
+   - Repeated workflows (3+ times) → "for X, do A→B→C"
+   - Tool preferences → "use tool Y for task X"
+4. Create/update instinct YAML files
+5. Be conservative: only create instincts for 3+ observations of the same pattern
+
+If fewer than 20 observations, skip analysis and note the count.
+
+### Multi-Agent Analysis (500+ observations)
+
+When observation backlog is large, parallelize:
+- **Agent 1:** User corrections + error→fix patterns
+- **Agent 2:** Repeated workflows + tool preferences
+- **Agent 3:** Cross-reference existing instincts for updates
+
+Merge results and deduplicate before writing YAML files.
+
+## Step 3: Show Status
+
+Display all instincts for the current project + global:
+
+```
+=== continuous-improvement ===
+
+## Level: [CAPTURE | ANALYZE | SUGGEST | AUTO-APPLY]
+
+## Session Reflection
+- What worked: [from this session]
+- What failed: [from this session]
+- What I'd do differently: [from this session]
+- Rule to add: [captured as instinct]
+- Iteration — Next best recommendations (ranked, top 3):
+  1. [primary core-development move]
+  2. [alternative angle]
+  3. [alternative scope]
+
+## Learning
+  NEW  [instinct-id]        [domain]  [confidence]  (from reflection)
+   ↑   [instinct-id]        [domain]  [old]→[new]   (+N observations)
+
+## Instincts — [project-name] ([hash])
+  ● [0.85] instinct-id       domain   auto-apply
+  ◐ [0.60] instinct-id       domain   suggest
+  ○ [0.35] instinct-id       domain   silent
+
+## Instincts — global
+  ● [0.90] instinct-id       domain   auto-apply
+
+## Next
+- Keep working — hooks capture automatically
+- System auto-levels as instincts gain confidence
+```
+
+If no instincts or observations exist yet, explain this is expected — the system is in CAPTURE level and will create instincts after 20+ observations accumulate.
+
+## Subcommands
+
+### `/continuous-improvement weekly`
+
+Set up a weekly analysis schedule:
+1. Create a cron/loop schedule that runs `/continuous-improvement analyze` every 7 days
+2. Confirm the schedule to the user
+3. Show next scheduled run date
+
+### `/continuous-improvement always-on`
+
+Toggle always-on mode for the current project:
+1. Find project hash
+2. Create/update `~/.claude/instincts/<hash>/config.yaml` with `always_on: true|false`
+3. Confirm the change
+
+**Default is off** — observations accumulate silently, analysis only runs when you ask.