| name | capture-memory |
| description | Use when active work produces a memory-worthy signal. Direct-land explicit strong signal into ACTIVE.md or LEARNINGS.md when the destination is clear; use inbox only for unresolved inferred signal. |
Capture Memory
Use this skill during active work.
Its job is to record signal in the right layer immediately, not to delay strong signal behind an unnecessary inbox hop.
Use This Skill When
- the user explicitly corrects a mistake
- the user gives a durable directive or stable preference
- a reusable workflow win becomes clear
- a repeated failure pattern becomes clear
- a capability gap keeps appearing
- a task outcome, blocker, or route decision should be remembered later
Do Not Use This Skill When
- the user wants a nightly review or cleanup pass
- the user wants broad memory reorganization
- the user wants a broad
AGENTS.md rewrite without a clear review path
Output Targets
Choose one target, not all of them.
Direct-Land To ACTIVE.md
Write directly to the active ACTIVE.md when the signal is:
- explicit
- source-backed
- immediately behavior-changing
- temporary, hot, phase-specific, or operational right now
Direct-Land To LEARNINGS.md
Write directly to the active LEARNINGS.md when the signal is:
- explicit
- durable
- reusable across tasks or sessions
- already clear enough to read like an executable preference, route, capability choice, or failure pattern
Use inbox/ Only As A Quarantine Buffer
Write to the active inbox only when the signal is:
- inferred rather than directly stated
- still ambiguous
- still competing with another route
- only seen once and not yet strong enough to guide future behavior
- useful as evidence later, but not yet good enough for
ACTIVE.md or LEARNINGS.md
Direct-Landing Rules
- explicit user corrections should not wait in
inbox/ if the destination layer is already clear
- explicit stable preferences should not wait in
inbox/ if they are durable and reusable
- direct-land entries should stay short, source-backed, and executable
- include source trace and promotion reason when writing to
ACTIVE.md or LEARNINGS.md
Inbox Rules
- keep inbox entries short and source-backed
- use inbox for unresolved signal, not for already-decided memory
- do not let inbox become a public third layer
- do not rewrite old inbox entries during active work unless the current task is explicitly about maintenance
Hard Constraints
- do not spray the same signal into multiple layers
- do not invent durable learnings without traceable source
- do not silently modify
AGENTS.md; report any needed AGENTS.md change to the user before or while applying it
- do not treat every one-off observation as memory-worthy
Good Examples
- a direct user correction that clearly changes future behavior
- a durable Git or GitHub workflow preference
- a stable route that has already proved better than the fallback
- a failure pattern that should be avoided next time
Inbox Examples
- a possible route win that still needs another task to confirm
- a weak pattern inferred from one run
- a competing capability choice that has not clearly won yet
