Identifies improvement targets from accumulated session learnings and proposes concrete skill/agent modifications. General-purpose pipeline for any Claude Code project.
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.
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:
research)brainstorm)code-review)issue-debugging)| 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:
/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 directoryStage 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)
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}?" |
When --sources is NOT provided, use these defaults:
sessions/*.md — Session handoff files (windowed by --since, default: last 10).claude/agent-memory/*/MEMORY.md — Agent memory files when availableStage 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
├── 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
├── 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
├── 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
├── Write diagnostic YAML to logs/diagnostics/continuous-feedback-{YYYYMMDD-HHMMSS}.yaml
│ └── Use templates/diagnostic-output.yaml schema
└── Verify completion checklist
// 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
| 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."
| 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. |
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.
IMPORTANT: Before returning to the user, verify ALL items are complete:
logs/continuous-feedback/{run-slug}/logs/continuous-feedback/{run-slug}/04-validation.mdlogs/diagnostics/Do NOT return to user until all checkboxes can be marked complete.
npx skills add ashaykubal/continuous-feedback下载完整 Skill 目录，包含 SKILL.md 及所有相关文件
Search for places (restaurants, cafes, etc.) via Google Places API proxy on localhost.
Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
Start voice calls via the OpenClaw voice-call plugin.
Notion API for creating and managing pages, databases, and blocks.
Gemini CLI for one-shot Q&A, summaries, and generation.
Category:developer