# Capture Memory

> 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.

- Skill: `jy0xlu/capture-memory` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add jy0xlu/capture-memory`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jy0xlu/capture-memory/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: JY0xLU (https://skillmd.com/u/jy0xlu)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/jy0xlu/capture-memory

---


# 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