ashaykubal/continuous-feedback

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.