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

   • Use vocabulary.notes for the notes folder name
   • Use vocabulary.note for the note type name in output
   • Use vocabulary.rethink for rethink command name in threshold alerts
   • Use vocabulary.topic_map for MOC references

2. ops/config.yaml — thresholds

   • self_evolution.observation_threshold (default: 10) — for threshold alerts
   • self_evolution.tension_threshold (default: 5) — for threshold alerts

3. 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?

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?

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:

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