self-improvement-curator

The core invariant: NEVER auto-modify rules, skills, schema, or wiki pages based on signals. All changes flow through a human approval gate via the /evolve slash command.

Format contract and entry schema live in docs/second-brain/wiki/_SCHEMA.md Section 15. This skill file defines only the behavioral workflow.

<trigger_phrases> This skill's evolve_review_workflow MUST be triggered when the user invokes any of these (IDE-agnostic — works in Claude Code, Cursor, Copilot, or any agent that loads this skill):

Slash command (Claude Code only): /evolve

Natural language triggers (all IDEs, in any language — these are English references):

• "run evolve", "review improvements", "review pending improvements", "show the improvement queue", "let's review what you learned", or the equivalent in the user's language.

When any trigger fires, execute <evolve_review_workflow> below. The workflow definition here is the SINGLE SOURCE OF TRUTH — the Claude Code slash command at .claude/commands/evolve.md is only a thin ergonomic shortcut that delegates to this skill. </trigger_phrases>

<session_start_protocol> Pending-count surfacing at session start is performed by sumela-prompt.md (<session_bootstrap> STEP 2). Do NOT duplicate that read here.

The full set of _improvement-queue/IMP-*.md entries is scanned ONLY when /evolve is triggered (see <evolve_review_workflow>). Re-validation pulse and applied-entry loading happen inside the evolve workflow, not at session start. </session_start_protocol>

<signal_capture_workflow> During every user turn — and after you independently resolve a bug or problem — scan for these seven signal types. Capture is silent — you do NOT announce that you're capturing unless asked.

Signal types (full definitions in _SCHEMA.md Section 15.4):

1. correction — User says "no", "not like that", "don't do it this way again", "don't use that", or the equivalent in any language. Capture: what they corrected, what the correct approach is.

2. confirmation — User validates a non-obvious choice you made ("yes, exactly", "good call", "nice catch"). Only capture if the choice was contested or non-default — don't capture routine "ok" responses.

3. decision — A decision is made during brainstorming/ULTRATHINK about how the agent should work (which rule to add, which workflow to change, which skill to invoke differently). Capture: the decision, alternatives, reason.

   CRITICAL BOUNDARY — do NOT double-capture with using-second-brain DECISION CAPTURE (operation #5):

   • Project architectural decisions (which technology, which pattern, which endpoint design — answers to "would another developer on this project also follow this?") → handled by using-second-brain DECISION CAPTURE workflow → written to wiki/architecture-decisions.md as AD-XX. DO NOT capture these as decision signals.
   • Agent behavioral decisions (which rule file should change, which skill should be updated, how the agent should approach a class of tasks differently — answers to "this is about how the agent works, not about the project") → capture as decision signal in the queue.
   • Decision tree: "If a new developer joined the team without Claude, would this decision still apply to them?" → Yes = project decision (wiki) / No = agent decision (queue).
   • Edge case: if a decision has BOTH dimensions (e.g., "we'll use Redis AND the agent should always propose Redis for read-heavy patterns"), split into two entries: the project fact goes to the wiki via DECISION CAPTURE, the agent behavior goes to the queue as a decision signal.