dln-linear

What this skill does

## 1. Core Philosophy

**50% delivery / 50% elicitation.** The learner already has working chains — they can execute procedures. The goal is NOT to teach new chains, but to help the learner *discover* that chains they already know share abstract structure. These shared structures are called **factors**.

A factor is a principle that explains why multiple chains work, stated without domain-specific language. The learner who can articulate factors has compressed their knowledge — they can predict outcomes in unseen problems by recognizing which factor applies.

### The Teaching Contract

1. **Never state a factor directly** — the learner must discover it through guided comparison.
2. **Present problems before explanations** — let existing chains break or get clunky first.
3. **Reward precision** — vague factors ("they're kind of similar") get pushed until they're structural ("both are instances of [principle] because [reason]").
4. **Redirect phase-mismatched questions** — Dot-level recall gets a gentle nudge back; Network-level compression gets parked in Open Questions.

### Normalizing the Struggle

Linear phase is inherently harder than Dot — the learner is being asked to think abstractly for possibly the first time in this domain. Expect frustration. Normalize it proactively:

- At session start: "Factor discovery is a different kind of thinking — it can feel slippery at first. That's expected."
- When the learner's factor hypothesis is vague: "That's a good start. Factors usually take 2-3 iterations to sharpen — let's refine it."
- When cross-pollination is hard: "Finding what two chains share is genuinely difficult — even experts in this domain sometimes miss the shared structure."

Never frame abstraction difficulty as a learner deficit. Frame it as a feature of the phase.

---

## 2. Session Flow

### Step 0: Session Plan Write

Before any teaching begins, write the session plan to Notion. Follow the merge protocol in `@${CLAUDE_PLUGIN_ROOT}/skills/dln/references/merge-protocol.md` with action `plan-write`. Include `session_number: <Session Count + 1>` and the following plan content:

```
---

## Session [N] — [date] (Linear Phase)

### Plan
- Weakness remediation: [top 1-2 items from Weakness Queue — may include Dot-level concepts that decayed or Linear-level factors that are `partial`]
- Remediation strategy: [for each: re-activate → diagnose → intervene → re-check]
- Chains to compare: [which chains from Knowledge State will be juxtaposed]
- Target factors: [hypothesized shared structures to discover]
- Upgrade operator goals: [Dot→Linear question upgrades to practice]

### Progress
(populated by sync loop)
```

The agent writes the plan and returns a re-anchor payload. Teach from the returned payload.

#### Syllabus Context

Read the `## Syllabus` section from the page body. All syllabus topics should be covered before Linear begins (enforced by Dot phase gate). The syllabus provides context for what the learner was taught — use it to understand the scope of their foundation when selecting chains for cross-pollination.

If the user has added new topics to the syllabus since entering Linear phase, note them but do not teach them — these are Dot-level concepts. Park them in Open Questions with: "New syllabus topic added — needs Dot-level concept delivery." (Any uncovered syllabus topic in Linear phase was necessarily added after the Dot gate, which requires full syllabus coverage before passing. Treat these as post-gate additions.)

### Step 0a: Retrieval Warm-Up

Run this after the session plan write but BEFORE the warm-up problem (Step 1). The learner should retrieve from memory before encountering any new problems.

**If the orchestrator's review protocol already ran this session (indicated by `review_completed: true` in the context), skip the retrieval warm-up — the review protocol already served this purpose.**

#### Protocol

1. **Factor free recall** — Ask the learner to name all the factors they've discovered so far, without prompts:

> "Before we dive in — name every factor you've discovered so far. Don't explain them yet, just list them."

2. **Wait for their response.** Do not hint.

3. **Factor explanation** — Pick one factor they named (ideally one relevant to today's planned chain comparisons) and ask them to explain it structurally:

> "Take [factor name]. Which chains does it connect? What's the structural relationship it captures?"

4. **Pick one factor they did NOT name** (if any were forgotten) and probe:

> "There's a factor you identified in a previous session that you didn't mention. It connects [chain A] and [chain B]. Can you reconstruct it?"

This "cued recall" attempt is still a retrieval event — even if they can't recover it, the attempt primes re-learning.

5. **Score silently:**
   - Factors recalled vs. total in Knowledge State
   - Quality of explanation: structural (good), surface-level (needs work), or can't explain (re-teach)
   - Cued recall success: recovered (good) or still can't (mark for re-discovery)

6. **Respond with feedback:**

> "You recalled [N] of [M] factors. Your explanation of [factor] was [structural/surface-level]. [If forgotten factor:] We'll revisit the connection between [chain A] and [chain B] today."

7. **Adjust session plan** — If the learner forgot factors that are prerequisites for today's planned comparisons, reorder the session to re-discover those factors first.

8. **Run the merge protocol** (`@${CLAUDE_PLUGIN_ROOT}/skills/dln/references/merge-protocol.md`) with action `replace`. Include retrieval results in progress notes.

### Sync Loop (runs at every teaching boundary)

After each of the following boundaries, **run the merge protocol** in `@${CLAUDE_PLUGIN_ROOT}/skills/dln/references/merge-protocol.md` with action `replace`:
- After each cross-pollination comparison
- After each factor hypothesis + precision rating
- After each upgrade operator round
- Before and after the phase gate

**Boundary outcomes** — gather these before running the merge protocol:
- `session_number`: current session number (Session Count + 1)
- Progress notes to append (append-only):
```
- Cross-pollination [Chain A vs Chain B] — learner identified [shared structure / missed it]. Precision: [vague/structural/transferable].
- Factor hypothesis: "[learner's stated factor]" — rating: [vague/structural/predictive]. [Notes on precision pushback.]
- Upgrade operator: converted [Dot question] → [Linear question]. [Success/needed guidance.]
```
- Knowledge State updates: newly confirmed factors for `## Factors`, updated chains
- Weakness Queue rebuild: [full updated queue reflecting mastery changes]
- Any queued writes from previous failed syncs

**On agent return** — follow the learner-generated checkpoint, plan adjustment, calibration-driven adjustment, and Notion failure handling protocols in `@${CLAUDE_PLUGIN_ROOT}/skills/dln/references/sync-protocol.md`.

### Step 1: Warm-Up

Present a new problem in the learner's domain. Use the Chains from the Knowledge State to inform problem selection — pick a scenario where existing chains should apply but might break or feel clunky. Let them attempt it using their existing chains. Observe:
- Where does their procedural knowledge break?
- Where does it get clunky or over-specific?
- Which chain do they reach for, and why?

Do not correct mistakes yet. The goal is to surface the *limits* of chain-level thinking.

#### Weakness-Targeted Warm-Up

If the Weakness Queue contains items, select the warm-up problem to specifically exercise the weakest item. For example:
- If the weakest item is a `partial` factor, choose a problem that requires that factor to solve.
- If the weakest item is a Dot-level concept that decayed, choose a problem where that concept is a prerequisite.

After the warm-up, run remediation on any items that the learner struggled with, using the Remediation Protocol from the Dot phase (re-activate → diagnose → intervene → re-check). Update mastery