Learn

---
name: learn
description: Turn a session's owner input into system updates — classify each thing he said, then route only what earns persistence to its one home. TRIGGER before updating any skill, agent, or record from the owner's session input, or after a session rich in his feedback. DO NOT TRIGGER to write a known ruling to its home (record-decision), to file research knowledge (journal), or during the session's live work — classification is a persistence-time act, never a listening-time one.
---

# Learn from a session

One Process: read back what the owner said this session, classify each item by how much it should persist, and route only what earns a home. Classification happens now, at persistence time — never while listening, when everything still looks like it might matter.

The owner's input spans a gradient. The same sentence can be a passing idea or a standing law depending on how he meant it, and only the whole session tells you which. Default DOWN the gradient when unsure. His standing laws:

- "a preference is not a ban"
- "a lean is not a decision"

## 1. Collect his words verbatim

### Pull every candidate item as he said it
Walk the session and lift each thing the owner said that could touch the system — verbatim, never paraphrased. A paraphrase has already classified the item by softening or hardening it before you meant to. Keep his exact words as the unit you classify and later route.

## 2. Classify each item on the gradient

### Sort each item into exactly one class
The gradient has four classes, weakest to strongest:

- **idea / debate** — thinking aloud, exploring, arguing a point. Nothing persists.
- **session-only** — direction that governs this job and stops when it ends. Nothing persists past the session.
- **correction** — a fix to something already done or standing. May amend one standing rule, or be local to this job.
- **rule** — a standing law he means to hold across future work.

### Default down when the class is unclear
When an item sits between two classes, take the weaker one. A preference is not a ban; a lean is not a decision. A thing said once, in passing, with no "always" or "never" behind it, is an idea or session-only — not a rule. Hardening his input into a law he did not set is the failure this Rule exists to stop.

### Ask whether a strategic review would catch it before anything becomes a rule
Before any item classifies as a rule, ask the deciding question: would a good strategic review catch this? If yes, it is NOT a rule — it is evidence the strategy gate needs sharpening, and it routes there (the check-strategy gate, handed to a context-engineer via /cc). Rules are reserved for mechanical, recurring, non-strategic corrections. A taste failure a strategic review should have caught is a gate problem, never a new micro-rule.
Evidence (owner, verbatim): "We need to fix our STRATEGY (AS I LITERALLY SAID) so those don't fundamentally happen, NOT ADD RULES FOR EVERY LITTLE THING"

### Fold a session into few changes, strategy first
A feedback session folds into FEW changes, strategy first — never a shotgun of micro-fixes. When many items point at the same failure, the fix is one sharper strategic gate, not one rule per item. An agent carrying hundreds of discrepant fixes cannot think strategically.
Evidence (owner, verbatim): "we can't launch an agent with 300 discrepant fixes because it CAN'T THINK STRATEGICALLY"

IF an item is a correction:
### Name the standing rule it amends, or mark it local
A correction either changes a specific standing rule — name which one — or it applies only to this job. If no standing rule is named and none fits, it is local and does not persist.

## 3. Confirm only genuine correction-or-rule uncertainty

IF an item's correction-or-rule classification is still uncertain after step 2:
### Batch one confirmation set to the owner
Gather every uncertain item and ask them as one set, once. Never interrogate one at a time, and never re-litigate an item whose class is already clear. Items that classified cleanly as idea or session-only are not in this set — only the ones whose standing-vs-local status changes where they land.

## 4. Route each kept item to its one home

### Send rulings through record-decision
Every kept correction or rule is an owner ruling. Route it through /record-decision, which writes his words verbatim into the one home its scope owns — product Voice.md, the deliverable's folder, or a craft skill. Never write the home yourself here.

IF a kept item is a generic craft law, not tied to this product:
### Hand it to a context-engineer via /cc
A general law of the craft belongs in the skill or agent Prompt that owns that craft. Dispatch a context-engineer to fold it in via /cc. Never edit the Prompt yourself, and never leave it as a loose note.

### Drop the classes that do not persist
Idea, debate, and session-only items are not routed anywhere. Dropping them is the correct outcome, not a gap.

## 5. Report kept and dropped

### Report both what persisted and what did not
Show the owner each kept item, its class, and the home it went to — and each item you deliberately did NOT keep, with its class. Naming the drops is what lets him catch a rule you defaulted down too far, so nothing persists silently and nothing drops silently.

Verification: every item classified into one of the four gradient classes; default-down applied with his verbatim lines where a class was unclear; uncertain correction-or-rule items batched into one confirmation set; kept items routed through /record-decision or a context-engineer via /cc; the report names both what was kept and what was dropped.