Remember

Runtime Configuration (Step 0 — before any processing)

Read these files to configure domain-specific behavior:

1. arscontexta/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. arscontexta/ops/config.yaml — thresholds

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

3. arscontexta/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 arscontexta/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 arscontexta/ops/methodology/:

ls -1 arscontexta/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 arscontexta/ops/methodology/:

Rule Zero: This methodology note becomes part of the system's canonical specification. arscontexta/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 arscontexta/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]" arscontexta/ops/methodology/ 2>/dev/null | wc -l | tr -d ' '

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

This is friction capture #[N] in the "[category]" area.
3+ captures in the same area suggest a systemic pattern.
Consider running /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: arscontexta/ops/methodology/[filename].md
  Updated: arscontexta/ops/methodology.md MOC
  Category: [category]

  [If pattern threshold reached:]
  This is friction capture #[N] in the "[category]" area.
  Consider running /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

Step 4: If Multiple Corrections Detected

If the conversation contains more than one correction:

  Detected [N] corrections in this conversation:

  1. "[quoted text]" → [interpretation]
  2. "[quoted text]" → [interpretation]
  3. "[quoted text]" → [interpretation]

  Capture all as methodology notes? (all / select numbers / none)

Step 5: If No Corrections Found

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

  No recent corrections detected in this conversation.

  Options:
  - /remember "description" — capture specific friction with explicit text
  - /remember --mine-sessions — scan session transcripts for uncaptured patterns

Session Mining Mode

Flag provided: /remember --mine-sessions or /remember --mine

This mode scans stored session transcripts for friction patterns the user addressed during work but did not explicitly /remember.

Step 1: Find Unmined Sessions

# Find session files without mined: true marker
UNMINED=$(grep -rL '^mined: true' arscontexta/ops/sessions/*.md 2>/dev/null)
UNMINED_COUNT=$(echo "$UNMINED" | grep -c . 2>/dev/null || echo 0)

If no unmined sessions found:

--=={ remember — mine }==--

  No unprocessed sessions found in arscontexta/ops/sessions/.
  All sessions have been mined for friction patterns.

Step 2: Mine Each Session

For each unmined session, read the full content and search for:

Step 3: Classify Findings

For each detected pattern, classify into one of two output types:

Step 4: Deduplicate Against Existing Notes

Before creating any notes:

1. Read all existing methodology notes in arscontexta/ops/methodology/
2. Read all existing observations in arscontexta/ops/observations/
3. For each finding:
   • If an existing methodology note covers this → skip or add as evidence to existing
   • If an existing observation covers this → skip or add as evidence to existing
   • If novel → create new note

Step 5: Create Notes

For methodology findings: Follow the same creation process as explicit mode (Step 3 in Explicit Mode section), with source: session-mining and add session_source: [session filename].

For observation findings:

---
description: [what was observed and what it suggests]
category: [friction | surprise | process-gap | methodology]
status: pending
observed: YYYY-MM-DD
source: session-mining
session_source: [session filename]
---

# [the observation as a sentence]

[What happened, which session, why it matters, and what pattern it might be part of.]

---

Related: [[observations]]

Step 6: Mark Sessions as Mined

After processing each session, add mined: true to its frontmatter:

# Add mined marker to session file frontmatter

Use Edit tool to add mined: true after the existing frontmatter fields. Do not modify other frontmatter content.

Step 7: Report

--=={ remember — mine }==--

  Sessions scanned: [N]

  Methodology notes created: [count]
    - [filename] — [brief description]

  Observations created: [count]
    - [filename] — [brief description]

  Duplicates skipped: [count]
    - [existing note] — already covers [pattern]

  Sessions marked as mined: [list]

  [If pattern thresholds reached:]
  Category "[category]" now has [N] methodology notes.
  Consider running /rethink to review [category] patterns.

The Methodology Learning Loop

This is the complete cycle that /remember participates in:

Work happens
  → user corrects agent behavior (explicit or implicit)
  → /remember captures correction as methodology note
  → methodology note filed to arscontexta/ops/methodology/
  → agent reads methodology notes at session start (via context file reference)
  → agent behavior improves
  → fewer corrections needed
  → when methodology notes accumulate (3+ in same category)
  → /rethink triages and detects patterns
  → patterns elevated to context file changes
  → system methodology evolves at the architectural level
  → the cycle continues with new friction at the edges

Each layer of this loop serves a different purpose:

• /remember captures individual friction points — fast, low ceremony
• arscontexta/ops/methodology/ stores accumulated behavioral guidance — persists across sessions
• /rethink detects patterns and proposes structural changes — periodic, deliberate
• arscontexta/ops/context.md (or equivalent) embodies the system's stable methodology — changes rarely, by human approval

The loop is healthy when methodology notes accumulate slowly (friction is being addressed) and /rethink elevates patterns to context-level changes when thresholds are exceeded.

The loop is unhealthy when the same category keeps getting methodology notes without elevation (the system is capturing friction but not learning from it).

Rule Zero: Methodology as Canonical Specification

The methodology folder is more than a friction capture log. It is the system's authoritative self-model — the canonical specification from which drift is measured.

What this means for /remember:

• Every methodology note you create becomes part of the spec. Write directives, not incident reports.
• The title should be an actionable behavior ("check for semantic duplicates before creating any note") not a problem description ("duplicate creation issue").
• Future /rethink sessions will compare system behavior against what methodology notes declare. Vague notes create unmeasurable specs.

What this means for the system:

• arscontexta/ops/methodology/ is consulted by meta-skills (/ask, /architect, /rethink) as the source of truth for how the system works.
• Drift detection compares methodology note assertions against actual config.yaml and context file state.
• When methodology notes are stale (older than config changes), the system surfaces this as a maintenance condition.

The methodology folder is the spec. /remember writes the spec. /rethink enforces the spec. The loop is closed.

Methodology Note Design

Title Pattern

Methodology note titles should describe what the agent should DO, not what went wrong:

The title is what the agent reads at session start. It should be immediately actionable as a behavioral directive.

Body Quality

Methodology notes are operational guidance, not essays. They should be:

1. Specific enough for a fresh agent session — no assumed context from the session that created them
2. Scoped explicitly — when does this apply and when does it not?
3. Dual-sided — both what to do AND what to avoid
4. Evidence-grounded — reference the specific friction that triggered this learning

Category Selection

Choose the most specific applicable category:

If a friction point spans categories (e.g., "processing voice" or "capture quality"), choose the primary category and mention the secondary in the body.

Edge Cases

No arscontexta/ops/methodology/ Directory

Create it and the arscontexta/ops/methodology.md MOC:

---
description: Methodology notes capturing how this system has learned to operate
type: moc
---

# methodology

Methodology notes organized by category. Each note captures a specific behavioral learning.

## Processing

## Capture

## Connection

## Maintenance

## Voice

## Behavior

## Quality

Duplicate Friction

If a methodology note with very similar content already exists:

1. Do NOT create a duplicate
2. Link to the existing note
3. Add the new instance as evidence: update the existing note's body with the new context
4. Report: "Extended existing methodology note [[title]] with additional evidence"

Contradicting Existing Methodology

If the new friction CONTRADICTS an existing methodology note (user now wants the opposite of what was previously captured):

1. Create an observation in arscontexta/ops/observations/ documenting the contradiction
2. Update the existing methodology note's status to superseded and add superseded_by: [new note]
3. Create the new methodology note with the updated guidance
4. Report the contradiction and suggest /rethink if this is part of a broader pattern

No Sessions to Mine

Report clearly: "No unprocessed sessions found in arscontexta/ops/sessions/." Do not treat this as an error.

Very Long Sessions

For sessions longer than 2000 lines:

1. Process in chunks of ~500 lines
2. Track findings across chunks to detect patterns that span the session
3. Report chunk-level progress for transparency

Implicit vs Explicit Corrections

Some corrections are implicit — the user does it themselves rather than telling the agent to change:

• User manually edits a note the agent created (the edit reveals what was wrong)
• User chooses a different approach without explaining why
• User skips a step the agent suggested

In contextual mode, flag these as lower-confidence findings and always confirm before creating methodology notes from implicit signals.

Empty Conversation Context

In contextual mode with no conversation history (e.g., first message of a session):

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

  No conversation context available to analyze.
  Use /remember "description" to capture specific friction directly.