菜单
Use to store durable context (decisions, facts, preferences, todos, summaries) and to recall or reply from it across sessions. Load when something worth remembering appears, or when the user asks what you were doing, what was decided, or to continue prior work.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | memory-keeper |
| description | Use to store durable context (decisions, facts, preferences, todos, summaries) and to recall or reply from it across sessions. Load when something worth remembering appears, or when the user asks what you were doing, what was decided, or to continue prior work. |
| model | inherit |
| effort | low |
| allowed-tools | ["Bash","Read"] |
| triggers | ["remember","what were we doing","what did we decide","continue where we left off","as I mentioned","keep this in mind"] |
| tags | ["memory","persistence","context"] |
A persistent, per-project memory store so context survives across sessions. It
stores structured JSONL plus a human-readable memory.md mirror, scoped by git
remote (or repo path) so one project's memory never leaks into another.
The store CLI lives at ${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs (in Cursor:
plugins/happy/hooks/memory.mjs). All commands are run with Bash.
At session start the store's contents are injected into your context. When the user asks "what were we doing", "what did we decide", "continue", or references something from before:
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" reply "auth flow"
Never ask the user to repeat something the store already knows.
When a durable item appears, store it immediately. Pick the right kind:
| kind | For |
|---|---|
decision | A choice made and why ("Chose JSONL over SQLite — zero deps"). |
fact | A stable truth about the project ("API base is /api/v2"). |
preference | How the user likes things ("Functional style, no classes"). |
todo | An open follow-up ("Add rate-limit to /login"). |
summary | A short state-of-play at the end of a work chunk. |
note | Anything else worth recalling. |
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep \
"Chose JSONL over SQLite for the store — zero deps, easy to diff" \
--kind decision --tags memory,arch
Guidelines:
# ranked search across all memory
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" recall "database schema" --limit 8
# only one kind
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" recall "" --kind todo
# JSON for programmatic use
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" recall "auth" --json
Before a session ends or context compacts, store a one-line summary and any new todos so the next session resumes cleanly:
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" keep \
"Built memory store + hooks; skills next" --kind summary
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" list # all entries with ids
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" forget <id> # remove one
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" forget --all # wipe this project
node "${CLAUDE_PLUGIN_ROOT}/hooks/memory.mjs" path # where the store lives
$HAPPY_MEMORY_DIR, else $XDG_DATA_HOME/happy-memory, else
~/.local/share/happy-memory, under projects/<project-hash>/.memory.jsonl (source of truth), memory.md (readable mirror),
project.json (id/name/root).keep/forget are the only writers.Run a bounded change → verify → fix cycle until an objective check passes (tests green, lint clean, build/type-check ok) or a hard iteration cap is hit. Use for any task that needs repeated attempts against a verifiable signal instead of a single one-shot edit.
Review code for behavior-preserving simplification — collapse duplication, remove dead code and over-engineering, cut verbose patterns down to idiomatic ones. Use when code is longer or more complex than it needs to be, or the user asks to simplify, shorten, refactor, or clean up.
Implement a planned ticket on its own branch using test-first development, updating docs as part of the change, looping change→verify→fix until the suite is green. Use when a ticket has a plan and is ready to build, or the user says "implement X" / "build the ticket" / "make it pass".
Choose the right model and effort per task phase and apply it when dispatching subagents — strong model + high effort for planning and review, a cheaper model + lower effort for mechanical execution. Use when a task splits into plan / execute / review phases or you're spawning subagents.
Push a reviewed ticket branch and open a pull request with a structured title and body, after review-changes has passed. Use when a ticket is reviewed and ready to ship, or the user says "open a PR" / "create the pull request". Stops at opening the PR — never merges.
Turn a feature request into a concrete plan — scope, approach, affected files, a test plan mapped to acceptance criteria, and out-of-scope — before any code is written. Use when the user describes new work, asks to design or spec something, or says "plan this" / "how would you build X".