remember

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md — vocabulary mapping, domain context
2. Use vocabulary.notes for the notes folder name
3. Use vocabulary.note for the note type name in output
4. Use vocabulary.rethink for rethink command name in threshold alerts
5. Use vocabulary.topic_map for MOC references

1. ops/config.yaml — thresholds
2. self_evolution.observation_threshold (default: 10) — for threshold alerts
3. self_evolution.tension_threshold (default: 5) — for threshold alerts

1. ops/methodology/ — read existing methodology notes before creating new ones (prevents duplicates)

If these files don't exist (pre-init invocation or standalone use), use universal defaults.

EXECUTE NOW

Target: $ARGUMENTS

Parse immediately:

• If target contains a quoted description or unquoted text: explicit mode — user describes friction directly
• If target is empty: contextual mode — review recent conversation for corrections
• If target contains --mine-sessions or --mine: session mining mode — scan ops/sessions/ for patterns

START NOW. Reference below defines the three modes.

Explicit Mode

User provides a description: /remember "don't process personal notes like research" or /remember always check for duplicates before creating

Step 1: Parse the Friction

Analyze the user's description to extract:

• What the agent did wrong (or what the user wants to prevent)
• What the user wants instead (the correct behavior)
• The scope — when does this apply? Always? Only for specific content types? Only in certain phases?
• The category — which area of agent behavior does this affect?

| Category | Applies When | |----------|-------------| | processing | How to extract, reduce, or handle content | | capture | How to record, file, or organize incoming material | | connection | How to find, evaluate, or add links between notes | | maintenance | How to handle health checks, reweaving, cleanup | | voice | How to write, what tone or style to use | | behavior | General agent conduct, interaction patterns | | quality | Standards for notes, descriptions, titles |

Step 2: Check for Existing Methodology Notes

Before creating a new note, read all files in ops/methodology/:

ls -1 ops/methodology/*.md 2>/dev/null

For each existing note, check if it covers the same behavioral area. Specifically:

• Does an existing note address the same friction?
• Would the new learning extend an existing note rather than warrant a new one?

| Check Result | Action | |-------------|--------| | No existing notes in this area | Create new methodology note | | Existing note covers different aspect of same area | Create new note, link to existing | | Existing note covers same friction | Extend existing note with new evidence instead of creating duplicate | | Existing note contradicts new friction | Create both a new methodology note AND an observation about the contradiction |

Step 3: Create Methodology Note

Write to ops/methodology/:

Rule Zero: This methodology note becomes part of the system's canonical specification. ops/methodology/ is not a log of what happened — it is the authoritative declaration of how the system should behave. Write this note as a directive: what the agent SHOULD do, not what went wrong. Future sessions, /rethink drift checks, and meta-skills will consult this note as ground truth for system behavior.

Filename: Convert the prose title to kebab-case. Example: "don't process personal notes like research" becomes dont-process-personal-notes-like-research.md.

---
description: [what this methodology note teaches — specific enough to be actionable]
type: methodology
category: [processing | capture | connection | maintenance | voice | behavior | quality]
source: explicit
created: YYYY-MM-DD
status: active
---

# [prose-as-title describing the learned behavior]

## What to Do

[Clear, specific guidance. Not "be careful" but "when encountering X, do Y instead of Z."]

## What to Avoid

[The specific anti-pattern this note prevents. What was the agent doing wrong?]

## Why This Matters

[What goes wrong without this guidance. Connect to the user's actual friction — what broke, what was confusing, what wasted time.]

## Scope

[When does this apply? Always? Only for certain content types? Only during specific phases? Be explicit about boundaries.]

---

Related: [[methodology]]

Writing quality for methodology notes:

• Be specific enough that a fresh agent session could follow this guidance without additional context
• Use concrete examples where possible — "when processing therapy notes" not "when processing certain types of content"
• State both the DO and the DON'T — methodology notes that only say what to do miss the anti-pattern that triggered them
• Keep scope explicit — unbounded methodology notes get applied where they should not be

Step 4: Update Methodology MOC

Edit ops/methodology.md (create if missing):

1. Find the section for the note's category
2. Add the note with a context phrase: - [[note title]] — [what this teaches]
3. If no section exists for this category, create one

## [Category]

- [[existing note]] — what it teaches
- [[new note]] — what this teaches

Step 5: Check Pattern Threshold

Count methodology notes in the same category:

grep -rl "^category: [CATEGORY]" ops/methodology/ 2>/dev/null | wc -l | tr -d ' '

If 3+ notes exist in the same category, this is a signal for /{DOMAIN:rethink}:

This is friction capture #[N] in the "[category]" area.
3+ captures in the same area suggest a systemic pattern.
Consider running /{DOMAIN:rethink} to review [category] methodology patterns
and potentially elevate them to context file changes.

Step 6: Output

--=={ remember }==--

  Captured: [brief description of the learning]
  Filed to: ops/methodology/[filename].md
  Updated: ops/methodology.md MOC
  Category: [category]

  [If pattern threshold reached:]
  This is friction capture #[N] in the "[category]" area.
  Consider running /{DOMAIN:rethink} to review [category] methodology patterns.

Contextual Mode

No argument provided: /remember

The agent reviews the current conversation to find corrections the user made that should become methodology notes.

Step 1: Review Recent Context

Scan the current conversation for correction signals. Look for:

| Signal Type | Detection Patterns | Example | |------------|-------------------|---------| | Direct correction | "no", "that's wrong", "not like that", "incorrect" | "No, don't split that into separate notes" | | Redirection | "actually", "instead", "let's do X not Y", "stop" | "Actually, keep the original phrasing" | | Preference statement | "I prefer", "always do X", "never do Y", "from now on" | "Always check for duplicates first" | | Frustration signal | "again?", "I already said", "why did you", "that's the third time" | "Why did you create a duplicate again?" | | Quality correction | "too vague", "not specific enough", "that's not what I meant" | "That description is too vague — add the mechanism" |

Step 2: Identify the Most Recent Correction

From the detected corrections, identify the most recent one. Present it to the user for confirmation:

--=={ remember — contextual }==--

  Detected correction:
    "[quoted user text]"

  Interpreted as:
    [What the agent should learn from this — specific behavioral change]

  Category: [category]

  Capture this as a methodology note? (yes / no / modify)

Wait for user confirmation. Do not create notes from inferred corrections without approval — the agent might misinterpret what the user meant.

Step 3: Handle Response

| Response | Action | |----------|--------| | "yes" | Create methodology note (same process as explic