/reflect-yourself

name: /reflect-yourself
description: Capture learnings from session corrections and sync to skills/rules (v1.1.3).

/reflect-yourself - Session Self-Learning System

**Version:** 1.1.3

A self-learning system for Cursor that captures corrections, discovers patterns, and syncs learnings to skills and rules.

---

How It Works

┌─────────────────┐     ┌─────────────────────┐     ┌─────────────────┐
│  You correct    │ ──► │  /reflect-yourself  │ ──► │  Updates skills │
│  the agent      │     │  captures it        │     │  and rules      │
└─────────────────┘     └─────────────────────┘     └─────────────────┘

---

Instructions for Agent

When this command is invoked, perform the following steps:

Optional: Version check (at most once per day)

Only if appropriate (e.g. user has not seen a check recently, or roughly once per day). Run `npm view reflect-yourself version` and compare to the installed version (e.g. from this command's description). If you run it, output one line (e.g. installed vX.Y.Z, npm vX.Y.Z — up to date). If a newer npm version exists, use the **Ask questions** tool (Cursor agent tool) to offer **Update now** / **Later**. Do not run this every time; do not block the flow.

Phase 1: Session Analysis

Scan the current conversation for:

1.1 Corrections (High Priority)

Look for patterns indicating the user corrected the agent:

• "no, use X" / "don't use Y" / "actually..." / "that's wrong"
• "not like that" / "I meant..." / "you should have..."
• "remember:" (explicit marker - highest confidence)
• "always do X" / "never do Y" (preference statements)

1.2 Positive Feedback

Capture what worked well:

• "Perfect!" / "Exactly right" / "Great approach"
• "Yes, like that" / "That's what I wanted"
• Implicit approval (user proceeds without correction)

1.3 Workflow Patterns

Identify repeating tasks that could become skills:

• Same type of request made multiple times
• Multi-step workflows that were followed
• Domain knowledge that was needed repeatedly

Phase 2: Learning Extraction

For each identified learning, extract:

learning:
  type: correction | preference | pattern | knowledge
  content: "The actual learning statement (concise title)"
  context: "What triggered this learning"
  confidence: 0.60-0.95
  source: "Quote or summary from conversation"
  reasoning: "Detailed explanation of WHY this should become a learning"

**Reasoning field guidelines:** The `reasoning` field should explain:

• What the user said or did that indicated this learning
• Why this is reusable (not a one-time instruction)
• How confident you are and why
• The expected benefit of remembering this

This reasoning becomes the "Why this was captured" explanation shown to users.

Confidence Scoring

| Score | Meaning | |-------|---------| | 0.90+ | Explicit "remember:" or direct correction | | 0.80 | Clear correction with "no" / "don't" / "always" | | 0.70 | Implicit correction or strong preference | | 0.60 | Inferred from context |

**Discard learnings below 0.60 confidence.**

Phase 3: Smart Filtering

**KEEP learnings that are:**

• Reusable across sessions
• Actionable and specific
• Not one-time task instructions
• Not context-specific to a single file

**DISCARD:**

• Questions (not corrections)
• One-time instructions ("now add X to this file")
• Vague feedback ("that looks better")
• Already captured in existing skills/rules

Phase 4: Placement Decision

For each learning, determine the correct destination:

Project Skills (`.cursor/skills/`)

Is it specific to THIS codebase?
├── Database schemas, conventions → YES
├── Project-specific tools/APIs → YES
├── Team workflow patterns → YES
└── Codebase structure knowledge → YES

Personal Skills (`~/.cursor/skills/`)

Is it reusable across projects?
├── General coding patterns → YES
├── Language best practices → YES
├── Tool usage (git, docker, etc.) → YES
└── Personal workflow preferences → YES

Project Rules (`.cursor/rules/`)

Is it a coding standard or convention?
├── File-specific patterns → YES (with glob)
├── Always-apply standards → YES (alwaysApply: true)
└── Style/formatting preferences → YES

Existing Skill Update

Does this improve an existing skill?
├── Correction while using a skill → Update that skill
├── New edge case for known pattern → Add to existing
└── Supersedes old approach → Replace in existing

Phase 5: Human Review

**Output format:** Summary first, then card-based learnings. No tables (they cause horizontal scroll). Keep lines short; wrap long text.

Summary-first header

Before the cards, always show a one-line summary. **The count must match the number of cards you show** (count every learning card, including reinforcements that need no edit — e.g. "2 learnings" if you show 2 cards).

## Learnings Captured

**Summary:** 3 learnings · 2 high-confidence (≥0.80) · 1 → personal skill, 1 → project rule, 1 → project skill

---

Adjust counts and destination breakdown to match the session.

Card format (plain-text, export-safe)

Output may be exported to markdown or viewed in transcripts where HTML does not render. **Do not use `<details>` or `<summary>`** — they show as raw markup. Use a short "Why" line and optional blockquote. Icons or emojis are fine as visual anchors.

**Required format:**

### 1. [correction] Always run tests before committing
**Confidence:** 0.85 | **Destination:** personal-skill: `git-workflow`
**Why:** User said "don't commit without running tests first" after agent attempted direct commit.

> Strong workflow preference; reusable across sessions.

---

### 2. [preference] Use TypeScript strict mode in this project
**Confidence:** 0.80 | **Destination:** project-rule: `typescript.mdc`
**Why:** User corrected loose typing with "always use strict mode here" — project-specific.

---

Discarded section

### Discarded (below th