Skip to content

/reflecting

Scans the session, suggests what is worth reflecting on, and lets the user pick which learnings to deepen. Use when completing significant work, when the user corrects your approach, when a bug is resolved, or when new patterns emerge. Use when user says "reflect", "what did we

shell
$ npx -y skills add wayne930242/Reflexive-Claude-Code --skill reflecting --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
  • You can call itInvoke it directly when you want it.
  • Slash command/reflecting
How auto-invocation works

Context preview

The summary Claude sees to decide when to auto-load this skill.

Scans the session, suggests what is worth reflecting on, and lets the user pick which learnings to deepen. Use when completing significant work, when the user corrects your approach, when a bug is resolved, or when new patterns emerge. Use when user says "reflect", "what did we

SKILL.md

reflecting.SKILL.md
name: reflecting
description: Scans the session, suggests what is worth reflecting on, and lets the user pick which learnings to deepen. Use when completing significant work, when the user corrects your approach, when a bug is resolved, or when new patterns emerge. Use when user says "reflect", "what did we learn", "capture learnings".
argument-hint: "[pain-point]"

Reflecting

Overview

**Reflecting IS surfacing candidate learnings, then deepening only the ones the user picks.**

Scan the session, list what is *worth* reflecting on with a one-line reason each, and let the user choose. Do not force every event into a full learning report. Capture before context fades; deepen on demand.

**When to reflect:** after a significant feature, a resolved bug, repeated failed attempts, an unexpected discovery, or a long session. Don't wait for "later" — context fades fast.

Routing

**Pattern:** suggest → pick → deepen **Hand off:** `planning-agent-systems`, opt-in (only when a learning should become a component)

Stage 1: Suggest Candidates (lightweight)

Scan the conversation for moments worth reflecting on. For each, write ONE line:

`[type] short description — why it's worth a look`

Types: **correction** (user corrected you), **error** (mistake / multiple attempts), **discovery** (new insight about project/domain/tooling), **repetition** (same action repeated — automation candidate), **safety_bypass** (destructive/irreversible action without confirmation, or a safety check skipped).

Rules:

  • No minimum count. A quiet session may yield one candidate, or none. One honest candidate beats a forced three.
  • Do NOT trace routers, locate files, or fill multi-field forms here. Stage 1 is a menu, not a report.
  • **safety_bypass is always surfaced, flagged ⚠️** — never bury a skipped safety check, even in a light scan. Watch for: `--force` / `reset --hard` / `clean -f` / `branch -D`, `--no-verify`, `rm -rf` / dropping tables, deleting or editing tests to pass, discarding unfamiliar files, `rsync --delete` without exclusions, or user interjections ("stop", "don't", "wait", "undo", "rollback").
  • If a pain point was given via `$ARGUMENTS`, list it first — even if the trace doesn't show it failing.

Present the list and ask: **which do you want to deepen?** (some, all, or none.)

Stage 2: Deepen Picked Candidates only

For each candidate the user picks:

1. **Extract the learning** — what would prevent the failure or repeat the success, and where it applies. 2. **Locate the router** — which skill/rule/law/CLAUDE.md routed the behavior. Glob the path; "none" if it came from general knowledge. 3. **Suggest where the fix lands** — simplest component that works:

  • one-line convention → `rule`; immutable project constraint → `law`; repeated multi-step process → `skill`; automated check → `hook`; reference material → `doc`
  • **safety_bypass → `rule` or `law` only** — never a skill alone (safety needs always-on enforcement). Name the exact command/flag to block.

4. **Debug session** — capture two things separately: the bug itself (root cause + prevention rule) and any reasoning error made while debugging.

Write the picked learnings to `.rcc/{YYYY-MM-DD}-reflection.md` using `references/report-template.md`.

Stage 3: Land (optional)

Default: present the suggested fixes; let the user apply them.

To turn a learning into a component automatically, hand off to `planning-agent-systems` with the reflection path. Otherwise stop — do not auto-create components.

Red Flags — STOP

  • "Surface everything as a full learning" → Stage 1 is a menu; only deepen the picks.
  • "Skip the safety_bypass — user didn't complain" → silence ≠ consent. Always surface it, flagged.
  • "Auto-create the component, I know where it goes" → landing is opt-in. Suggest, don't impose.
  • "Nothing worth noting" → scan once more; capture now, context fades.

References

  • `references/report-template.md` — lightweight reflection list format
  • `planning-agent-systems` — opt-in, only when turning a learning into a component
  • `.rcc/config.yml` `decisions_log` — append new decisions here
Read more
Read it on GitHub ↗
Ships withreflexive-claude-code

A Claude Code plugin marketplace for skills-driven Agentic Context Engineering (ACE) — build, analyze, and maintain agent systems with structured workflows.

Get the whole plugin, auto-invoked