The reflecting Skill — Lessons Wired Into Every Archive
How Datarim's reflecting skill turns the end of a task into structured review, evolution proposals, and a health check — automatically, every time.
Most development processes end when the last line is committed. Datarim adds a mandatory step before closing any task: reflection. The reflecting skill runs as Step 0.5 of /dr-archive — not optionally, not on request, but every time a task is archived.
Before Datarim v1.10.0, reflection existed as a standalone command called /dr-reflect. It was optional. The pattern failed in practice: reflection was expected on every task yet trivially skippable. The command was retired and the logic was moved inside /dr-archive as a hard step. Archive cannot proceed until reflection completes.
What the skill produces
The skill creates a reflection document at datarim/reflection/reflection-{task-id}.md. That document captures what worked, what was inefficient, and any missing patterns the task exposed. It also records a health check: a count of total skills, agents, and commands in the active scope, checked against defined thresholds. If a threshold is exceeded, the skill surfaces a suggestion to run /dr-optimize — but does not run it automatically.
The out-of-scope drift detector is one of the more practical pieces. During implementation, notes sometimes appear about things that were spotted but not fixed: stale configs, parallel drift, deferred cleanup. The skill scans for these signals in the implementation notes and auto-suggests follow-up backlog entries. This replaces the informal habit of mentally noting "I should file something about that" and then not doing it.
Evolution proposals
After reviewing the task, the skill generates evolution proposals: changes to skills, agents, command definitions, or templates that would make future work faster or safer. Each proposal is classified as Class A or Class B.
Class A covers content changes — updates to rule text, new examples, wording improvements — and can be presented to the operator for approval in the same archive cycle. Class B covers operating-model changes: pipeline routing, core contracts, command semantics. These require a PRD update before they can be applied. A Class B proposal surfaced during archive is held until that PRD is drafted; it cannot be applied the same day.
Before any approved Class A proposal is written to the framework runtime, it passes a stack-agnostic gate. The gate checks whether the proposed change names a specific technology stack. If it does, the proposal is rejected from the framework and redirected to the project's own CLAUDE.md. Framework skills stay stack-neutral. After any approved write, the full test suite runs; a failing test reopens the proposal as rejected.
Where it fits
The skill runs as mandatory Step 0.5 inside /dr-archive. It is invoked internally — operators interact with it through the archive command, not directly. The reflection document it produces feeds back into /dr-archive Step 4, where follow-up tasks are written to the backlog.
See what Datarim is for the broader pipeline, or read about the research-workflow skill that feeds the planning phase at the other end of the cycle.