maintain-project-memory

Imported from Firepanda415/research-and-scientific-lib-skills (plugins/research-skills/skills/maintain-project-memory/SKILL.md). Install upstream with npx skills add Firepanda415/research-and-scientific-lib-skills --skill maintain-project-memory. Copyright stays with the author.

Maintain Project Memory

Leave enough accurate context for a later session to make the next decision without reconstructing the whole conversation. Preserve knowledge that changes future work, rather than a transcript of activity.

Find the current owners

Read the user's request, the existing project entry and the records relevant to the requested update. Verify important current claims against live source, configuration, decisions or evidence. Follow replacement links when old paths have moved; a remembered filename is not a reason to recreate a retired file. Report a missing owner or evidence source without inventing its contents.

Distinguish user requirements, current design decisions, observed results, proposals and historical reports. Plans and successful runs cannot establish scientific truth or override current user intent. A historical action permission does not by itself authorize a new run, external message or behavior change.

Use the project's existing locations and access rules. Public contracts belong in public documentation; private coordination and project history belong in project memory; temporary reports retain the evidence needed for their claims. These are responsibilities, not a required directory structure. Keep private paths and agent instructions out of public user documentation. Read only the history needed to resolve the update, not all logs or large research outputs.

Select knowledge worth keeping

Retain confirmed, nontrivial facts that could change a future decision:

• A failure mechanism, the condition that exposed it, the prevention rule at its actual owner, and the domain where the lesson applies.
• A decision's rationale, relevant rejected alternative, consequence and the condition under which reconsideration would make sense.
• An accepted result's source/revision, workload or assumptions, evidence location and limits. Record a later unresolved finding alongside earlier acceptance when their scopes differ; neither erases the other.
• Unresolved work and user-approved deferrals, with the remaining question and the next action only when it is actually known and authorized.

Prefer a short causal note and evidence link. Do not record routine typos, repeated principles, transient progress or an unverified hypothesis as a lesson. Keep hypotheses and proposals visibly provisional when they are useful to retain. A concrete incident may illustrate a general mechanism; it does not justify a universal restriction, permanent test, new runtime check or recurring experiment.

Reconcile rather than append

Choose whether each relevant record needs an addition, correction, replacement link or historical designation. Keep one current owner for each decision and link to it from readers that need it. Preserve unique rationale and evidence before consolidating records; respect immutable history and user-owned files. Do not delete raw research evidence merely because a summary now exists.

Separate current status from durable lessons. Historical commands, environment versions and test totals describe their measured scope; direct future execution to the live environment owner. Historical plans and unresolved possibilities do not become a dispatch queue merely by appearing in memory.

Reuse the existing entry and naming conventions. Create a new record only when the topic and its reader justify it; do not require WIP/TODO/DEV_NOTE files or a fixed set of ledgers. Keep principal-only rationale separate from bounded worker instructions where the project makes that distinction.

Write only within the user's requested memory scope and the host's persistence rules. If the host requires proposed update notes instead of direct memory edits, use that mechanism and distinguish proposed updates from applied ones. This workflow does not authorize source changes, new research runs, issue publication, global memory updates or periodic maintenance outside that scope.

Verify the handoff

Check that the updated entry reaches the current owners, referenced evidence exists where claimed, superseded instructions no longer steer new work, and unresolved obligations remain visible. Do not mark a finding resolved from a worker receipt or green suite alone.

For a substantial reorganization, consider a bounded cold-start handoff check: give a fresh session the entry and a realistic next task, then inspect whether it finds the right owners, evidence limits and action boundaries. Use delegation only when available and authorized; otherwise inspect the same path locally. Do not launch the underlying experiment just to test the memory.

Report the actual records changed, important corrections, retained uncertainties and the handoff checks performed. Distinguish link/source checks from demonstrated successful use by a fresh session.