菜单
Use when deciding what information belongs in memory, how to classify it, and what must not be saved because it is derivable from the repo, git history, or current task context
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when verifying implementation work and the failure mode is superficial approval, code-reading in place of execution, or over-trusting a passing test suite without trying to break the change
Use when coordinating multi-step work across workers or subagents, especially when research, implementation, and verification should be split while the main agent stays responsible for synthesis and user communication
Use when the task is codebase exploration rather than modification, and you need a fast, read-only search pattern that starts broad when location is unknown, narrows when location is known, and parallelizes independent searches
Use when deciding whether shell commands are truly read-only, safe for concurrent execution, and free of path, git, redirection, or command-shape risks that should force a stricter permission path
Use when the real risk is not lack of knowledge but self-justifying shortcuts such as explaining instead of running commands, skipping the hard part first, or deciding on your own that verification would take too long
Use when maintaining session notes that must preserve a fixed markdown template, stay within section and total token budgets, and remain useful after compaction or resume
| name | memory-type-system |
| description | Use when deciding what information belongs in memory, how to classify it, and what must not be saved because it is derivable from the repo, git history, or current task context |
This repository uses a four-type memory taxonomy in src/memdir/memoryTypes.ts. The point of the taxonomy is to store durable, non-derivable context, not to duplicate facts that can be recovered from the codebase.
Save information about the user's role, expertise, preferences, and working style.
Examples:
Save guidance about how work should be done.
Examples:
For feedback memories, include:
Save ongoing project facts that are not derivable from the current repo state.
Examples:
Convert relative dates into absolute dates before saving them.
Save pointers to external systems and where to look next.
Examples:
Do not save:
CLAUDE.mdIf grep, git log, or reading the repo can answer it, it usually does not belong in memory.
Save a memory only if it is:
For feedback and project, prefer:
Why:How to apply:That makes the memory durable instead of cryptic.
You have applied this skill correctly when every saved memory fits one of the four types and none of it duplicates information that should instead be recovered from the repo or external source of truth.