capture-memory

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