{"id":21027,"plugin_id":"plugins_6aabf17d723481919bf6d18cd917fa77","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:44.755Z","digest":"b61e2f3495340abd289ffb60414cac6205602a7ef57cdfe4cd228c691f9b2694","against":null,"payload":{"description":"Use when a project gains, changes, validates, abandons, or depends on durable truth that future work must remember, including architecture, behavior, bugs, baselines, constraints, versions, tests, canonical locations, or memory structure.","included_files":[{"relative_path":"references/memory-hierarchy.md","size_in_bytes":2512},{"relative_path":"scripts/memory_keeper_check.py","size_in_bytes":4205}],"name":"maintaining-project-memory","skill_md_contents":"---\nname: maintaining-project-memory\ndescription: Use when a project gains, changes, validates, abandons, or depends on durable truth that future work must remember, including architecture, behavior, bugs, baselines, constraints, versions, tests, canonical locations, or memory structure.\n---\n\n# Maintaining Project Memory\n\n## Core law\n\n**One durable fact = one canonical owner. One canonical memory = one living file.** Memory stores current truth, not a session transcript.\n\n## Before changing durable truth\n\n1. Identify the authoritative persistent surface and project root.\n2. Load the smallest relevant memory chain from root to owner.\n3. Identify the detailed owner; ambiguity routes to `repairing-memory-state`.\n4. Read `references/memory-hierarchy.md` before creating, splitting, merging, or compacting memory.\n\n## Synchronization\n\nAfter every durable change:\n\n1. update the nearest owning memory immediately;\n2. replace obsolete truth instead of appending diary history;\n3. update a parent only when parent-level routing/status/constraint changed;\n4. keep child detail out of the parent;\n5. verify memory reflects the new truth before completion.\n\nDurable truth includes architecture, feature state, bugs, baselines, tests, workflows, paths, constraints, abandoned approaches that must not return, and next actions future work depends on. Throwaway edits require no memory rewrite.\n\n## Memory lifecycle\n\nApply the lifecycle rules in the hierarchy reference. In short:\n\n- **Split trigger:** a subdomain gains independent ownership and enough independently changing truth that keeping it inline lowers route density or causes parent duplication.\n- **Merge trigger:** a child no longer has independent ownership and its remaining truth can live in the parent without duplication or routing ambiguity.\n- **Compaction trigger:** current truth is obscured by stale history, repetition, oversized detail, or low route density; rewrite in place while preserving constraints that still affect future decisions.\n\nNever create a sibling active canon with `_MAJ`, `_FINAL`, dates, `copy`, `backup`, `(1)`, `v2`, `new`, or `updated`. Update the active canon in place or perform controlled replacement with exactly one active owner remaining.\n\nFor local filesystems, `scripts/memory_keeper_check.py` provides conservative structural checks; project technical tests remain separate.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}