RethinkSAFE

Claude Code plugin that generates individualized knowledge systems from conversation. You describe how you think and work, have a conversation and get a complete second brain as markdown files you own.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: rethink
description: Challenge system assumptions against accumulated evidence. Triages observations and tensions, detects patterns, generates proposals. The scientific method applied to knowledge systems. Triggers on "/rethink", "review observations", "challenge assumptions", "what have I learned".
user-invocable: true
allowed-tools: Read, Write, Edit, Grep, Glob, Bash, AskUserQuestion
context: fork
---

## 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 the command name in output
   - Use `vocabulary.topic_map` for MOC references
   - Use `vocabulary.cmd_reflect` for connection-finding references

2. **`ops/config.yaml`** — thresholds, processing preferences
   - `self_evolution.observation_threshold`: number of pending observations before suggesting rethink (default: 10)
   - `self_evolution.tension_threshold`: number of pending tensions before suggesting rethink (default: 5)

3. **`ops/methodology/`** — existing methodology notes (read all to understand current system self-knowledge)

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

The command name itself transforms per domain. The derivation manifest maps the universal name to domain-native language. If no manifest exists, use "rethink" as the command name.

## EXECUTE NOW

**Target: $ARGUMENTS**

Parse immediately:
- If target is empty: run full six-phase rethink (Phase 0 drift check + five evidence phases) on all pending observations and tensions
- If target is "triage": run Phase 1 only (triage and methodology updates, no pattern detection)
- If target is "patterns": skip triage, run Phases 3-5 only (analyze existing evidence for patterns)
- If target is "drift": run Phase 0 only (drift check without triage or pattern detection)
- If target is a specific observation or tension filename: triage that single item interactively

**START NOW.** Reference below defines the six-phase workflow.

---

## Philosophy

**The system is not sacred. Evidence beats intuition.**

Every rule in the context file, every workflow in a skill, every assumption baked into the architecture was a hypothesis at some point. Hypotheses need testing against reality. Observation notes in `ops/observations/` capture friction from actual use. Tension notes in `ops/tensions/` capture unresolved conflicts. Rethink first triages these individually (some become {DOMAIN:notes}, some become methodology updates, some get archived), then compares remaining evidence against what the system assumes and proposes changes when patterns emerge.

This is the scientific method applied to knowledge systems: hypothesize, implement, observe, revise.

Without this loop, generated systems ossify — they accumulate friction that never gets addressed, contradictions that never get resolved, and methodology learnings that never get elevated to system-level changes. /rethink is the immune system that prevents calcification.

---

## Phase 0: Drift Check

Rule Zero: ops/methodology/ is the canonical specification of how this system operates. Before triaging observations, check whether the system has drifted from what the methodology says it should do.

### 0a. Load Methodology State

```bash
# Get all methodology notes with their metadata
for f in ops/methodology/*.md; do
  echo "=== $f ==="
  head -20 "$f"  # frontmatter with category, created, updated, status
  echo ""
done
```

Read all methodology notes fully. Extract:
- Each note's category, created date, updated date, status
- The behavioral assertions each note makes (the "What to Do" sections)

### 0b. Load System Configuration

Read:
- `ops/config.yaml` — current configuration state
- The context file (CLAUDE.md) — current behavioral instructions
- `ops/derivation-manifest.md` — vocabulary and feature state

### 0c. Compare Across Three Drift Types

**Type 1: Staleness**

```bash
# Compare config.yaml modification time vs newest methodology note
CONFIG_MTIME=$(stat -f %m ops/config.yaml 2>/dev/null || stat -c %Y ops/config.yaml 2>/dev/null || echo 0)
NEWEST_METH=$(ls -t ops/methodology/*.md 2>/dev/null | head -1)
METH_MTIME=$(stat -f %m "$NEWEST_METH" 2>/dev/null || stat -c %Y "$NEWEST_METH" 2>/dev/null || echo 0)
```

If `CONFIG_MTIME > METH_MTIME`: config has changed since methodology was last updated. Flag as staleness drift.

**Type 2: Coverage Gap**

For each active feature in config.yaml (features with `enabled: true` or features present in the active configuration), check whether a corresponding methodology note exists. Features without methodology coverage represent gaps — the system does things it cannot explain to itself.

Check these feature areas:
- Processing pipeline (is there a methodology note about processing behavior?)
- Maintenance conditions (methodology notes about when maintenance triggers?)
- Session rhythm (methodology notes about session workflow?)
- Domain-specific behaviors (methodology notes about domain vocabulary and patterns?)

**Type 3: Assertion Mismatch**

For each methodology note that makes a behavioral assertion ("What to Do" section), check:
- Does the context file contain instructions that align with or contradict this directive?
- Does config.yaml contain settings that align with or contradict this directive?
- Are there other methodology notes that contradict this one?

Report: which assertions align, which contradict, which have no corresponding system element.

### 0d. Create Drift Observations

For each drift finding, create an observation note in `ops/observations/`:

```markdown
---
description: [specific drift finding]
category: drift
status: pending
observed: {today's date}
related_notes: ["[[methodology note]]", "[[config element]]"]
---
# [drift 

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.