continuous-feedback

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 research)
• Brainstorming new features (use 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:

- 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 your project typecheck, lint, and test commands 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)

// 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.