memory-dump

Accept freeform input from $ARGUMENTS (or conversation context if $ARGUMENTS is empty) and route each distinct piece of information into the correct vault location with full curated-tier structure.

Step 1: Check Nexus Availability

Call mcp__nexus-personal__toolManager_getTools with:

• request: [{ "agent": "searchManager", "tools": ["searchContent"] }, { "agent": "contentManager", "tools": ["write"] }]

If unavailable: operate in degraded mode (Write tool for captures, Grep for search). Inform the user: "Nexus unavailable — degraded mode. Search is text-only; commits tagged vault: (degraded)."

Step 2: Parse and Classify

Parse $ARGUMENTS into distinct items. Each item is a separable fact, decision, solution, observation, reference, or idea. Classify each:

Class	Criteria	Target folder
solution	A problem was solved, a workaround was found, a method confirmed	02-solutions/
decision	A non-obvious choice was made, rationale matters	03-decisions/
issue	A problem exists but is unresolved	00-inbox/
reference	Constants, specs, papers, URLs, tool docs	04-resources/references/
project	Status update, milestone, scope change for an active project	01-projects/
work-note	Session observation, log entry, intermediate result	05-journal/
(ambiguous)	Low-confidence, needs triage — use capture-tier frontmatter only	00-inbox/

When classification is ambiguous, flag it in the final report (do not silently discard or guess).

Step 3: Search Before Creating

For each classified item, search the vault before writing:

• Nexus: call searchContent with 2–3 keywords from the item
• Degraded: Grep across ${CLAUDE_PROJECT_DIR}/ for the same keywords

Decision rule:

• If a closely related note exists and the new item is a small update → update the existing note, do not create a new file
• If the existing note conflicts with the new item → flag the contradiction; do not overwrite silently
• If no related note exists → create a new note

Step 4: Write Notes

For each item approved for capture:

Frontmatter schema (all fields required except source-url):

---
title: <concise title>
date: <YYYY-MM-DD>
description: <auto-generated ~150-char summary>
type: <solution | decision | issue | reference | project | work-note>
tags: [<2-4 relevant tags>]
confidence: <verified | tested | observed | speculation>
related:
  - "[[<existing-note-slug>]]"
source: <URL | DOI | session | user-provided | instrument>
source-type: <paper | session | calculation | user-provided | instrument>
---

Rules:

• related must contain at least one [[wikilink]] to an existing vault note. If no obvious match exists, link to the closest project note or brain/index.md.
• confidence must reflect actual evidence: do not upgrade speculation to verified without justification.
• Naming: YYYY-MM-DD-descriptive-slug.md where slug uses lowercase hyphens, no stop words.
• Place in the folder matching the type column in the classification table above.

For project type: read the existing project note first. Append the update in a dated ## YYYY-MM-DD section rather than replacing the whole file.

Step 5: Update brain/ Accumulators

After writing each note, check whether it belongs in a brain/ accumulator:

• decision type → append to brain/decisions.md
• solution that reveals a reusable pattern → append to brain/patterns.md
• solution or issue that reveals a pitfall → append to brain/gotchas.md
• Lessons-style gotcha (correction, wrong assumption, debugging trap) → also append to ~/.claude/lessons.md using format: what happened | what should have happened | why

Format for brain/ entries:

- **YYYY-MM-DD**: <one-line description>. [[<note-slug>]] (confidence: <level>)

Step 6: Update brain/index.md

If any capture is a significant decision, new project milestone, or high-confidence solution, append a one-liner to the Recent Context section of brain/index.md:

- **YYYY-MM-DD**: <summary>. [[<note-slug>]]

Skip this step for low-signal items (inbox, speculative work-notes).

Step 7: Commit

Stage and commit captured notes and brain/ updates:

git add <specific files only>
git commit -m "vault: capture — <brief summary of what was captured>"

Use separate commits if captures span multiple unrelated topics. Never git add -A.

Step 8: Report

Output a concise summary:

• Captured (list each: type, title, path, action taken — created or updated)
• brain/ updated (which files, what was appended)
• Uncertain / needs review (items that were ambiguous, contradicted existing notes, or could not be classified — ask the user to clarify)
• Degraded mode notice (if Nexus was unavailable)

Do not output the full note content in the report. Paths and one-line summaries only.