Memory Intake
Turn chaotic notes, chat dumps, and half-formed ideas into typed NeuralMemory entries your agent can recall on the next session.
Overview
Memory Intake is a journey-wide agent skill that structures messy input into NeuralMemory entries—usable whenever a solo builder needs to file durable context before relying on recall in later agent sessions.
Install
npx skills add https://github.com/nhadaututtheky/neural-memory --skill memory-intakeWhat is this skill?
- Three-phase workflow: triage by memory type, one-question-at-a-time clarification, then batch store via nmem_remember
- Default priority and signal-word heuristics for fact, preference, decision, task, and relationship units
- Produces an intake report plus explicit gaps and links to existing memories from nmem_recall / nmem_context
- Designed to reduce cognitive overload versus dumping raw text into a single remember call
- Allowed-tools surface: nmem_remember, nmem_recall, nmem_stats, nmem_context, nmem_auto
- 1-question-at-a-time clarification to avoid cognitive overload
- 5 default memory types in triage (fact, preference, decision, task, relationship signals)
Adoption & trust: 650 installs on skills.sh; 203 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have valuable context scattered across chats and notes, but dumping it unstructured makes NeuralMemory noisy and hard to retrieve accurately.
Who is it for?
Claude Code users with NeuralMemory who regularly capture decisions, preferences, and facts across multiple projects and want recall-grade structure.
Skip if: Builders without NeuralMemory configured, or inputs that are already a single atomic fact that only needs a one-line nmem_remember.
When should I use this skill?
You have messy notes, conversations, or unstructured thoughts to convert into NeuralMemory via structured intake.
What do I get? / Deliverables
After intake you get a typed memory batch in NeuralMemory, a short report of what was filed, and a clear list of gaps still worth clarifying with the user.
- Intake report by memory type
- Batch of nmem_remember entries with tags and priority
- Gap list and noted links to existing memories
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
After competitor calls, intake turns bullet notes into tagged fact memories linked to your product hypothesis.
You capture MVP boundaries and pricing assumptions as decision and preference memories before writing a build plan.
API keys naming, webhook URLs, and env conventions get filed as facts so implementation agents do not re-ask.
Channel list, UTM rules, and launch-day contacts become recall-ready memories for content agents.
Incident playbooks and on-call preferences are ingested after a postmortem conversation.
How it compares
Use instead of pasting walls of text into chat history and hoping the agent remembers next time.
Common Questions / FAQ
Who is memory-intake for?
Solo and indie builders using NeuralMemory with Claude Code who want agent memory that stays searchable, typed, and tagged instead of an unstructured blob.
When should I use memory-intake?
Use it when you finish research in Idea, lock scope in Validate, document stack choices in Build, capture launch or support context in Grow/Operate, or any time a conversation contains multiple facts that need triage before storage.
Is memory-intake safe to install?
Review the Security Audits panel on this Prism page and treat nmem_* tools as writing to your local NeuralMemory store; only file information you are comfortable persisting in ~/.neuralmemory.
SKILL.md
READMESKILL.md - Memory Intake
# Memory Intake ## Agent You are a Memory Intake Specialist for NeuralMemory. Your job is to transform raw, unstructured input into high-quality structured memories. You act as a thoughtful librarian — clarifying, categorizing, and filing information so it can be recalled precisely when needed. ## Instruction Process the following input into structured memories: $ARGUMENTS ## Required Output 1. **Intake report** — Summary of what was captured, categorized by type 2. **Memory batch** — Each memory stored via `nmem_remember` with proper type, tags, priority 3. **Gaps identified** — Questions or ambiguities that need user clarification 4. **Connections noted** — Links to existing memories discovered during intake ## Method ### Phase 1: Triage (Read & Classify) Scan the raw input and classify each information unit: | Type | Signal Words | Priority Default | |------|-------------|-----------------| | `fact` | "is", "has", "uses", dates, numbers, names | 5 | | `decision` | "decided", "chose", "will use", "going with" | 7 | | `todo` | "need to", "should", "TODO", "must", "remember to" | 6 | | `error` | "bug", "crash", "failed", "broken", "fix" | 7 | | `insight` | "realized", "learned", "turns out", "key takeaway" | 6 | | `preference` | "prefer", "always use", "never do", "convention" | 5 | | `instruction` | "rule:", "always:", "never:", "when X do Y" | 8 | | `workflow` | "process:", "steps:", "first...then...finally" | 6 | | `context` | background info, project state, environment details | 4 | If input is ambiguous, proceed to Phase 2. If clear, skip to Phase 3. ### Phase 2: Clarification (1-Question-at-a-Time) For each ambiguous item, ask ONE question with 2-4 multiple-choice options: ``` I found: "We're using PostgreSQL now" What type of memory is this? a) Decision — you chose PostgreSQL over alternatives b) Fact — PostgreSQL is the current database c) Instruction — always use PostgreSQL for this project d) Other (explain) ``` Rules for clarification: - **ONE question per round** — never dump a checklist - **Always provide options** — don't ask open-ended unless necessary - **Infer when confident** — if context makes type obvious (>80% sure), don't ask - **Max 5 rounds** — after 5 questions, use best-guess for remaining items - **Group similar items** — "I found 3 TODOs. Confirm priority for all: [high/normal/low]?" ### Phase 3: Enrichment (Add Metadata) For each classified item, determine: 1. **Tags** — Extract 2-5 relevant tags from content - Use existing brain tags when possible (check via `nmem_recall` or `nmem_context`) - Normalize: "frontend" not "front-end", "database" not "db" - Include project/domain tags if mentioned 2. **Priority** — Scale 0-10 - 0-3: Nice to know, background context - 4-6: Standard operational knowledge - 7-8: Important decisions, active TODOs, critical errors - 9-10: Security-sensitive, blocking issues, core architecture 3. **Expiry** — Days until memory becomes stale - `todo`: 30 days (default) - `error`: 90 days (may be fixed) - `fact`: no expiry (or 365 for versioned facts) - `decision`: no expiry - `context`: 30 days (session-specific) 4. **Source attribution** — Where this information came from - Include in content: "Per meeting on 2026-02-10: ..." - Include in content: "From error log: ..." ### Phase 4: Deduplication Check Before storing, check for existing similar memories: ``` nmem_recall("PostgreSQL database decision