@qball-inc/the-bulwark 1.0.0

package/skills/component-patterns/references/pattern-process-spawner.md

@@ -0,0 +1,133 @@
+# Pattern 4: Process Spawner Verification
+
+## Strategy
+
+Spawn process, verify it's running (check port/pid), verify behavior, cleanup.
+
+---
+
+## Template (Bash)
+
+```bash
+#!/bin/bash
+# Process Spawner Verification: {component_name}
+set -e
+
+echo "=== Process Spawner Verification: {component_name} ==="
+
+# Spawn process
+{spawn_command} &
+PROC_PID=$!
+echo "Spawned process (PID: $PROC_PID)"
+
+# Cleanup trap
+cleanup() {
+  echo "Cleaning up..."
+  kill $PROC_PID 2>/dev/null || true
+  wait $PROC_PID 2>/dev/null || true
+}
+trap cleanup EXIT
+
+sleep 2  # Wait for startup
+
+# Test 1: Process is running
+echo -n "Test 1: Process running... "
+if kill -0 $PROC_PID 2>/dev/null; then
+  echo "PASS (PID $PROC_PID alive)"
+else
+  echo "FAIL (process not running)"
+  exit 1
+fi
+
+# Test 2: Port is open (if applicable)
+echo -n "Test 2: Port {port} open... "
+if nc -z localhost {port} 2>/dev/null; then
+  echo "PASS"
+else
+  echo "FAIL"
+  exit 1
+fi
+
+# Test 3: Process responds correctly
+echo -n "Test 3: Process responds... "
+RESPONSE=$({verification_command})
+if echo "$RESPONSE" | grep -q "{expected_pattern}"; then
+  echo "PASS"
+else
+  echo "FAIL (expected pattern: {expected_pattern}, got: $RESPONSE)"
+  exit 1
+fi
+
+echo "=== All tests passed ==="
+```
+
+---
+
+## Template (Node/Jest)
+
+```javascript
+const { spawn, execSync } = require('child_process');
+const net = require('net');
+
+function waitForPort(port, timeout = 5000) {
+  return new Promise((resolve, reject) => {
+    const start = Date.now();
+    const check = () => {
+      const socket = new net.Socket();
+      socket.setTimeout(100);
+      socket.on('connect', () => {
+        socket.destroy();
+        resolve(true);
+      });
+      socket.on('error', () => {
+        socket.destroy();
+        if (Date.now() - start > timeout) reject(new Error('Timeout'));
+        else setTimeout(check, 100);
+      });
+      socket.connect(port, 'localhost');
+    };
+    check();
+  });
+}
+
+describe('{component_name} Process', () => {
+  let proc;
+
+  beforeAll(async () => {
+    proc = spawn('{spawn_command}', [], { detached: true });
+    await waitForPort({port});
+  });
+
+  afterAll(() => {
+    if (proc) {
+      process.kill(-proc.pid);
+    }
+  });
+
+  test('process is running', () => {
+    expect(proc.pid).toBeDefined();
+    expect(() => process.kill(proc.pid, 0)).not.toThrow();
+  });
+
+  test('port is open', async () => {
+    await expect(waitForPort({port}, 1000)).resolves.toBe(true);
+  });
+
+  test('responds correctly', () => {
+    const output = execSync('{verification_command}', { encoding: 'utf8' });
+    expect(output).toContain('{expected_pattern}');
+  });
+});
+```
+
+---
+
+## Placeholders
+
+| Placeholder | Description |
+|-------------|-------------|
+| `{component_name}` | Name of the process spawner component |
+| `{spawn_command}` | Command to spawn the process |
+| `{port}` | Port the process listens on (if applicable) |
+| `{verification_command}` | Command to verify process behavior |
+| `{expected_pattern}` | Expected pattern in response |

package/skills/continuous-feedback/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: continuous-feedback
+description: Identifies improvement targets from accumulated session learnings and proposes concrete skill/agent modifications. General-purpose pipeline for any Claude Code project.
+user-invocable: true
+argument-hint: "<target-skill-or-path> [--sources <paths>] [--since <session-N>]"
+skills:
+  - subagent-prompting
+---
+
+# Continuous Feedback
+
+Analyzes accumulated session handoffs, memory files, and other learning sources to identify concrete improvement opportunities for skills and agents. Spawns a Collector, 1-3 specialized Analyzers (parallel), and a Proposer — then validates and annotates proposals for user review.
+
+---
+
+## When to Use This Skill
+
+**Load this skill when the user request matches ANY of these patterns:**
+
+| Trigger Pattern | Example User Request |
+|-----------------|---------------------|
+| Skill improvement | "What improvements can we make to test-audit?", "Evolve code-review" |
+| Session learning harvest | "What have we learned across sessions?", "Harvest learnings" |
+| Feedback loop | "Run continuous feedback on X", "Analyze our session learnings" |
+| Retrospective | "What patterns have emerged?", "Review accumulated experience" |
+
+**DO NOT use for:**
+- Initial topic research (use `bulwark-research`)
+- Brainstorming new features (use `bulwark-brainstorm`)
+- Code review (use `code-review`)
+- Debugging (use `issue-debugging`)
+
+---
+
+## Dependencies
+
+| Category | Files | Requirement | When to Load |
+|----------|-------|-------------|--------------|
+| **Collect instructions** | `references/collect-instructions.md` | **REQUIRED** | Include in Collector prompt |
+| **Specialization references** | `references/specialize-*.md` | **REQUIRED** | Load matching specializations for Analyzers |
+| **Collect output template** | `templates/collect-output.md` | **REQUIRED** | Include in Collector prompt |
+| **Proposal output template** | `templates/proposal-output.md` | **REQUIRED** | Include in Proposer prompt |
+| **Diagnostic template** | `templates/diagnostic-output.yaml` | **REQUIRED** | Use when writing diagnostics |
+| **Subagent prompting** | `subagent-prompting` skill | **REQUIRED** | Load at Stage 0 for 4-part prompt template |
+
+**Fallback behavior:**
+- If a specialization reference is missing: Skip that specialization, always run general Analyzer, note in diagnostics
+- If output template is missing: Use the schemas from this SKILL.md directly
+
+---
+
+## Usage
+
+```
+/continuous-feedback <target-skill-or-path> [--sources <paths>] [--since <session-N>]
+```
+
+**Arguments:**
+- `<target-skill-or-path>` — Target skill name (e.g., `test-audit`) or path to a skill directory. If a directory containing multiple skills, analyze all detected skill types.
+- `--sources <paths>` — Custom input source paths (files or directories). Overrides default input sources.
+- `--since <session-N>` — Only collect learnings from session N onwards. Default: last 10 sessions.
+
+**Examples:**
+- `/continuous-feedback test-audit` — Analyze learnings for the test-audit skill
+- `/continuous-feedback test-audit --since session-50` — Only learnings from session 50 onwards
+- `/continuous-feedback skills/code-review/ --sources logs/research/` — Custom input sources
+- `/continuous-feedback .claude/skills/` — Analyze all skills in the directory
+
+---
+
+## Stages
+
+### Stage 0: Pre-Flight (Orchestrator)
+
+```
+Stage 0: Pre-Flight
+├── Parse arguments (target, --sources, --since)
+├── Resolve target: skill name → skill directory path
+│   ├── Check skills/{name}/ first
+│   ├── Then .claude/skills/{name}/
+│   └── If raw path provided, use directly
+├── Verify Pre-Flight Gate (see below)
+├── Resolve input sources (default or custom)
+├── Determine specializations: read target's SKILL.md to detect skill type
+├── Slugify target for output directory
+├── Create output directory: logs/continuous-feedback/{run-slug}/
+├── Load subagent-prompting skill
+├── Load references/collect-instructions.md
+├── Load matching references/specialize-*.md files
+├── AskUserQuestion if target is ambiguous or inputs are unclear
+└── Token budget check (warn if >30% consumed)
+```
+
+#### Pre-Flight Gate
+
+**MANDATORY** — These checks MUST pass before proceeding. Do NOT skip.
+
+| Check | Condition | Failure Action |
+|-------|-----------|----------------|
+| Session handoff threshold | ≥5 session handoffs exist in the input scope | STOP: "Insufficient input data. Need at least 5 session handoffs. Found {N}." |
+| Target path exists | Target path exists and contains readable files | STOP: "Target path does not exist: {path}" |
+| Target is identifiable | Can determine what kind of skill/asset the target is | AskUserQuestion: "Could not determine target type. What kind of skill is {target}?" |
+
+#### Default Input Sources
+
+When `--sources` is NOT provided, use these defaults:
+
+1. `sessions/*.md` — Session handoff files (windowed by `--since`, default: last 10)
+2. Project MEMORY.md — Always read in full (curated summary, not windowed)
+3. `.claude/agent-memory/*/MEMORY.md` — Agent memory files when available
+
+### Stage 1: Collect (Sonnet sub-agent, sequential)
+
+```
+Stage 1: Collect
+├── Construct prompt using 4-part template (GOAL/CONSTRAINTS/CONTEXT/OUTPUT)
+│   ├── GOAL: Parse input sources and extract learning items with source
+│   │   attribution and LLM-classified skill_relevance tags
+│   ├── CONSTRAINTS:
+│   │   ├── Use Grep to locate section headers, Read with offsets for targeted extraction
+│   │   ├── Preserve full learning content (pass-through, no lossy compression)
+│   │   ├── Assign skill_relevance via LLM classification (NOT keyword matching)
+│   │   ├── Each item MUST have: id, source, section, category, skill_relevance, content
+│   │   └── Target 1000-2000 words depending on input volume
+│   ├── CONTEXT:
+│   │   ├── Input file paths (resolved session handoffs, memory files, custom paths)
+│   │   ├── Parsing rules from references/collect-instructions.md
+│   │   └── Collect output template from templates/collect-output.md
+│   └── OUTPUT: logs/continuous-feedback/{run-slug}/01-collect.md
+├── Spawn general-purpose Sonnet agent
+├── Read Collector output
+├── Verify output is non-empty (see Error Handling)
+├── Extract skill_types_detected from Collector YAML header
+└── Token budget check
+```
+
+**Pass-through schema**: The Collector groups and tags learning items but preserves near-raw content. Each item includes:
+
+```yaml
+- id: L001
+  source: "session_45_20260208.md"
+  section: "Learnings"
+  category: "defect-pattern"  # defect-pattern | architecture-decision | framework-observation | workflow-improvement | tool-behavior
+  skill_relevance: ["test-audit", "code-review"]  # LLM-classified
+  content: |
+    Full learning text preserved with surrounding context.
+    No lossy compression — Analyzers handle interpretation.
+```
+
+### Stage 2: Analyze (1-3 Sonnet sub-agents, parallel)
+
+```
+Stage 2: Analyze
+├── Read Collector output (01-collect.md)
+├── Determine Analyzer count from skill_types_detected:
+│   ├── If "test-audit" in detected types → load specialize-test-audit.md
+│   ├── If "code-review" in detected types → load specialize-code-review.md
+│   └── ALWAYS spawn general Analyzer with specialize-general.md
+├── For each Analyzer, construct prompt using 4-part template:
+│   ├── GOAL: Analyze collected learnings through {specialization} lens and
+│   │   identify concrete improvements for the target skill
+│   ├── CONSTRAINTS:
+│   │   ├── Only analyze items matching your specialization (filtered by skill_relevance)
+│   │   ├── General Analyzer: also process items not fully covered by other Analyzers
+│   │   ├── Read the target skill's current files to avoid proposing existing content
+│   │   ├── For each improvement: what was learned, what it affects, proposed change, priority, evidence
+│   │   └── Target 800-1200 words
+│   ├── CONTEXT:
+│   │   ├── Collector output (01-collect.md)
+│   │   ├── Specialization reference (references/specialize-{type}.md)
+│   │   └── Target skill path for autonomous exploration
+│   └── OUTPUT: logs/continuous-feedback/{run-slug}/02-analyze-{specialization}.md
+├── Spawn all Analyzers in parallel (single message, multiple Task calls)
+├── Read all Analyzer outputs
+└── Token budget check (checkpoint if >55%)
+```
+
+**CRITICAL**: Spawn all Analyzers in a single message with N Task tool calls. Do NOT spawn sequentially.
+
+**Dynamic spawning**: The number of Analyzers is data-driven (1-3). If collected learnings only match test-audit and general, only 2 Analyzers spawn. The general Analyzer ALWAYS runs.
+
+### Stage 3: Act/Propose (Sonnet sub-agent, sequential)
+
+```
+Stage 3: Act
+├── Construct prompt using 4-part template:
+│   ├── GOAL: Synthesize all analyses into concrete, copy-paste-ready change
+│   │   proposals for the target skill
+│   ├── CONSTRAINTS:
+│   │   ├── Every proposal MUST have all mandatory fields (see proposal template)
+│   │   ├── Proposed content MUST be copy-paste ready — specific enough to apply
+│   │   │   without interpretation
+│   │   ├── "Improve X" is a FAILURE. "Add the following pattern to {file} under
+│   │   │   {section}: [specific content]" is SUCCESS
+│   │   ├── Read target skill's current files to avoid stale proposals
+│   │   ├── Skip proposals for content that already exists in the target
+│   │   ├── Deduplicate across analyses — merge overlapping improvements
+│   │   └── Target 1500-2500 words
+│   ├── CONTEXT:
+│   │   ├── All Analyzer outputs (02-analyze-*.md files)
+│   │   ├── Proposal output template from templates/proposal-output.md
+│   │   └── Target skill path for autonomous exploration
+│   └── OUTPUT: logs/continuous-feedback/{run-slug}/03-proposal.md
+├── Spawn general-purpose Sonnet agent
+├── Read Proposer output
+├── Verify proposals have mandatory fields (see Error Handling)
+└── Token budget check
+```
+
+**Proposal mandatory fields** (each proposed change):
+
+| Field | Required | Description |
+|-------|----------|-------------|
+| Target | YES | Exact file path |
+| Change type | YES | Add / Modify / Remove |
+| Section | YES | Target section within file, or "New section" |
+| Priority | YES | High / Medium / Low |
+| Source learnings | YES | L-IDs and session/memory references |
+| Proposed content | YES | Copy-paste ready text |
+| Rationale | YES | Why this improves the skill, traced to learning items |
+| Validation | YES | How to verify the change works |
+
+### Stage 4: Validate (Orchestrator, no sub-agent)
+
+```
+Stage 4: Validate
+├── Read proposal document (03-proposal.md)
+├── For each proposed change:
+│   ├── If targeting a skill asset (.md in skills/ or .claude/skills/):
+│   │   └── Annotate: "Run /anthropic-validator on {target} after applying"
+│   ├── If targeting a code file (.ts, .js, .sh, etc.):
+│   │   └── Annotate: "Run just typecheck && just lint && just test after applying"
+│   └── If targeting configuration:
+│       └── Annotate: "Verify configuration is valid and reload"
+├── Write validation notes to logs/continuous-feedback/{run-slug}/04-validation.md
+└── Present proposals to user with validation annotations
+```
+
+**Design note**: Stage 4 does NOT run validators on proposals (proposals are not applied yet). It annotates each proposal with the appropriate validation steps the user should run after applying.
+
+### Stage 5: Diagnostics (REQUIRED)
+
+```
+Stage 5: Diagnostics
+├── Write diagnostic YAML to logs/diagnostics/continuous-feedback-{YYYYMMDD-HHMMSS}.yaml
+│   └── Use templates/diagnostic-output.yaml schema
+└── Verify completion checklist
+```
+
+---
+
+## Execution Flow (F# Pipeline)
+
+```fsharp
+// continuous-feedback pipeline
+PreFlight(args, inputs)                    // Stage 0: Orchestrator
+|> Collector(sessions, memory, custom)     // Stage 1: Sonnet, sequential
+|> [Analyzer(test-audit), Analyzer(code-review), Analyzer(general)]  // Stage 2: Sonnet, parallel (dynamic 1-3)
+|> Proposer(all_analyses, target_skills)   // Stage 3: Sonnet, sequential
+|> Validate(proposal)                      // Stage 4: Orchestrator, no sub-agent
+```
+
+---
+
+## Token Budget Management
+
+| Checkpoint | Threshold | Action |
+|------------|-----------|--------|
+| After Pre-Flight | >30% consumed | Warn user: "Pipeline agents will consume significant context" |
+| After Collector output read | Running tally | If approaching 45%, checkpoint with user |
+| After all Analyzers complete | Running tally | If approaching 55%, checkpoint with user |
+| After Proposer output read | Must be <65% | Leave room for validation + diagnostics |
+| Pipeline complete at >65% | Immediate | Write diagnostics, do not start additional work |
+
+If token budget is insufficient to complete the full pipeline, inform the user and suggest: "Collector + Analyzers this session, Proposer + validation next session."
+
+---
+
+## Error Handling
+
+| Scenario | Action |
+|----------|--------|
+| Collector returns empty output | Re-spawn once with reinforced extraction instructions. If still empty, STOP — cannot proceed without collected learnings. |
+| Collector returns truncated output | Accept as-is, note in diagnostics. |
+| Analyzer returns empty output | Re-spawn once. If still empty, skip that specialization, document gap. |
+| Proposer returns empty/vague output | Re-spawn once with reinforced specificity instructions. If still vague, document in diagnostics. |
+| Proposer proposals missing mandatory fields | Re-spawn once with explicit field checklist. If still incomplete, document in diagnostics. |
+| Token budget exceeded mid-pipeline | Stop spawning, write partial results, note incomplete in diagnostics. |
+| No learnings match a specialization | Do not spawn that Analyzer. Document in diagnostics. |
+| Fewer than 5 session handoffs | Pre-Flight Gate blocks. Inform user. |
+| Target path does not exist | Pre-Flight Gate blocks. Inform user. |
+
+---
+
+## Diagnostic Output (REQUIRED)
+
+**MANDATORY**: You MUST write diagnostic output after every invocation. This is Stage 5 and cannot be skipped.
+
+Write to: `logs/diagnostics/continuous-feedback-{YYYYMMDD-HHMMSS}.yaml`
+
+**Template**: Use `templates/diagnostic-output.yaml` for the schema. Fill in actual values from the session.
+
+---
+
+## Completion Checklist
+
+**IMPORTANT**: Before returning to the user, verify ALL items are complete:
+
+- [ ] Stage 0: Pre-Flight Gate passed (≥5 session handoffs, target exists)
+- [ ] Stage 0: Arguments parsed (target, --since, --sources)
+- [ ] Stage 0: Output directory created at `logs/continuous-feedback/{run-slug}/`
+- [ ] Stage 0: subagent-prompting skill loaded
+- [ ] Stage 0: AskUserQuestion used if target was ambiguous
+- [ ] Stage 1: Collector spawned (Sonnet) and output read
+- [ ] Stage 1: Collector output is non-empty with learning items
+- [ ] Stage 2: Correct number of Analyzers spawned (1-3, based on detected skill types)
+- [ ] Stage 2: All Analyzers spawned in parallel (single message)
+- [ ] Stage 2: General Analyzer always included
+- [ ] Stage 2: All Analyzer outputs read
+- [ ] Stage 3: Proposer spawned (Sonnet) and output read
+- [ ] Stage 3: All proposals have mandatory fields (target, change_type, section, proposed_content, rationale, validation)
+- [ ] Stage 3: Proposals are copy-paste ready (not vague recommendations)
+- [ ] Stage 4: Validation annotations written to `logs/continuous-feedback/{run-slug}/04-validation.md`
+- [ ] Stage 4: Proposals presented to user with validation steps
+- [ ] Stage 5: Diagnostic YAML written to `logs/diagnostics/`
+
+**Do NOT return to user until all checkboxes can be marked complete.**

package/skills/continuous-feedback/references/collect-instructions.md

@@ -0,0 +1,81 @@
+# Collection Instructions
+
+These instructions guide the Collector sub-agent on how to parse input sources and extract learning items.
+
+## Input Sources
+
+### Session Handoffs (`sessions/*.md`)
+
+Session handoff files follow a consistent structure. Extract learning items from these sections:
+
+| Section Header | What to Extract | Category Mapping |
+|----------------|-----------------|------------------|
+| `## Learnings` | Bullet points describing what was learned | defect-pattern, workflow-improvement, tool-behavior |
+| `## Technical Decisions` | Design choices with rationale | architecture-decision |
+| `## Blockers / Issues` | Problems encountered and resolutions | defect-pattern, framework-observation |
+| `## What Was Accomplished` | Completed work items (extract patterns, not status) | workflow-improvement |
+| `## Verification Status` | Test/validation outcomes revealing gaps | defect-pattern |
+
+**Parsing approach:**
+1. Use Grep to locate section headers (`^## Learnings`, `^## Technical Decisions`, etc.)
+2. Use Read with offsets to extract content between section headers
+3. Each bullet point or decision block becomes one learning item
+4. Preserve the full text of each item including surrounding context sentences
+
+**Session windowing:** When `--since` is specified, only process session files with session number >= N. Session number is extracted from filename: `session_{N}_*.md`.
+
+### Project MEMORY.md
+
+MEMORY.md is a curated summary that persists across sessions. Extract from these sections:
+
+| Section Header | What to Extract | Category Mapping |
+|----------------|-----------------|------------------|
+| `## Defects & Lessons Learned` | Defect patterns and their fixes | defect-pattern |
+| `## Architecture Decisions` | Design choices | architecture-decision |
+| `## Framework Observations` | Platform behaviors | framework-observation |
+| `## Critical Findings` | Cross-cutting discoveries | defect-pattern, tool-behavior |
+| `## Hook Behavior` | Hook system behaviors | framework-observation, tool-behavior |
+| `## Key Patterns` | Workflow conventions | workflow-improvement |
+
+**Parsing approach:**
+1. Read MEMORY.md in full (it's curated and concise)
+2. Each bold-prefixed bullet (e.g., `**DEF-P4-005**:`) is one learning item
+3. Preserve the full text including any sub-bullets
+
+### Agent Memory Files (`.claude/agent-memory/*/MEMORY.md`)
+
+When available, these contain agent-specific learnings. Parse using the same approach as project MEMORY.md.
+
+### Custom Paths (`--sources`)
+
+When custom paths are provided:
+1. If path is a file: read and extract any structured learning content
+2. If path is a directory: scan for `.md` files and apply session handoff parsing rules
+3. Look for the same section headers as session handoffs
+4. If no recognized headers found, treat entire file content as a single learning item with category "workflow-improvement"
+
+## Skill Relevance Classification
+
+After extracting each learning item, classify which skills it could improve. This is an LLM judgment task, not keyword matching.
+
+### Classification Guidelines
+
+| Skill Type | Indicators in Content |
+|------------|----------------------|
+| test-audit | Mock detection, test classification, assertion patterns, AST analysis, T1-T4 rules, test mode selection, verification line counting |
+| code-review | Security patterns, review lenses, pipeline stages, coding standards, OWASP, type safety, framework conventions |
+| general | Skill authoring, prompt engineering, sub-agent behavior, workflow patterns, hook behavior, configuration, frontmatter, token management |
+
+**Multi-tag rule**: A learning item may be relevant to multiple skills. Assign all applicable tags. When uncertain, include "general" as a fallback.
+
+**Do NOT use keyword matching.** The sentence "Mock return values used as literal inputs violate T3" is relevant to `test-audit` even though it doesn't contain the word "test-audit". Classify based on what the learning would improve, not which words appear in it.
+
+## Output Requirements
+
+1. Write output to the path specified in the GOAL
+2. Use the collect-output template structure
+3. Assign sequential IDs (L001, L002, ...) to each item
+4. Group items by source file for readability
+5. Include the YAML header with counts and detected skill types
+6. If a source file has no extractable learnings, skip it silently
+7. If total items extracted is 0, write an output file stating "No learning items found in scanned sources" — the orchestrator will handle the empty result

package/skills/continuous-feedback/references/specialize-code-review.md

@@ -0,0 +1,82 @@
+# Specialization: Code Review
+
+This reference guides the code-review Analyzer on what improvement patterns to look for in collected learnings.
+
+## Target Skill Structure
+
+The code-review skill (`skills/code-review/` or `.claude/skills/code-review/`) typically contains:
+
+| Component | Purpose |
+|-----------|---------|
+| `SKILL.md` | Main skill document with 3-phase pipeline (static tools, LLM judgment, diagnostic log) |
+| `references/security-patterns.md` | Security vulnerability detection patterns (OWASP, injection, etc.) |
+| `references/type-safety-patterns.md` | Type safety review patterns |
+| `references/coding-standards.md` | Coding standards enforcement patterns |
+| `references/framework-patterns.md` | Framework-specific review patterns |
+
+## What to Look For
+
+### Security Pattern Gaps
+
+Learnings that reveal security patterns not currently covered:
+
+- New vulnerability types encountered during code review or debugging
+- OWASP patterns missing from security references
+- Framework-specific security concerns (e.g., WSL path traversal, CRLF injection)
+- Supply chain or dependency vulnerabilities discovered
+
+**Action**: Propose additions to `references/security-patterns.md` with specific vulnerability descriptions and detection heuristics.
+
+### Framework Pattern Updates
+
+Learnings about framework behaviors that affect code review:
+
+- New framework conventions or anti-patterns discovered
+- Hook system behaviors that the review should check for
+- Configuration patterns that indicate quality issues
+- Build system quirks (e.g., CRLF on WSL, executable bit issues)
+
+**Action**: Propose additions to `references/framework-patterns.md` with concrete examples.
+
+### Review Lens Improvements
+
+Learnings about the review process itself:
+
+- Cases where the review missed an issue that was later found in testing
+- Patterns where reviewer bias led to false positives or negatives
+- New review dimensions not covered by current lenses
+- Effectiveness of static tools vs LLM judgment for specific pattern types
+
+**Action**: Propose review lens updates or new review categories in `SKILL.md`.
+
+### Type Safety Enhancements
+
+Learnings about type safety patterns:
+
+- New TypeScript patterns that indicate type unsafety
+- Cases where `any` or type assertions masked real issues
+- Generics patterns that improve or degrade type safety
+- Runtime type validation patterns at system boundaries
+
+**Action**: Propose additions to `references/type-safety-patterns.md` with violation and fix examples.
+
+### Instruction Hardening
+
+Learnings about LLM compliance with code-review instructions:
+
+- Cases where the reviewer skipped steps or produced incomplete output
+- Missing BINDING language that allowed instruction drift
+- Stage sequencing issues (e.g., LLM judgment running before static tools)
+- Output format compliance gaps
+
+**Action**: Propose instruction strengthening with specific MUST/MUST NOT language.
+
+## Analysis Output Structure
+
+For each improvement identified, produce:
+
+1. **What was learned** — the specific learning item(s) driving this
+2. **What it affects** — which code-review component (reference file, SKILL.md section)
+3. **Proposed improvement** — specific enough for the Proposer to create a copy-paste-ready change
+4. **Priority** — High (current misses cause real failures), Medium (improves coverage), Low (nice to have)
+5. **Evidence** — reference the source learning item IDs (L-NNN)