agentleFS
cobibeancobibean/project-memory-skill/SKILL.md

project-memory

Skill7 starsChanged 5 months agoMITView on GitHub

Use this skill when starting or finishing substantial project work that would benefit from durable continuity across Codex, Claude, or other agent sessions. It teaches agents to read recent project memory before work and write concise Markdown session memory after meaningful work under docs/memory/YYYY-MM-DD/descriptive-slug-memory-YYYY-MM-DD.md, including what happened, what was learned, decisions made, gotchas, changed files, verification, constraints, open decisions, and useful next context while avoiding secrets and sensitive details.

24 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 19 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 19

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use project memory to preserve durable project context for humans and future agents.

    line 16
  2. Distinctive:

    Only include handoff or resume instructions when work is incomplete, interrupted, or the user explicitly asks for a handoff.

    line 21
  3. Distinctive:

    Do not overwrite, delete, or rewrite prior memory unless the user explicitly asks.

    line 31
  4. Very specific:

    Check whether docs/memory/ exists.

    line 39
  5. Distinctive:

    If it exists, list recent memory files:

    line 40
  6. Distinctive:

    Read the most recent relevant memory files.

    line 46
  7. Distinctive:

    Read any source-of-truth docs referenced by those files when they matter for the task.

    line 47
  8. Distinctive:

    If no memory exists, continue normally.

    line 51
  9. Distinctive:

    Do not create memory at the start unless the user asks.

    line 52
  10. Distinctive:

    Create a new memory file when the session produced context that future humans or agents would be annoyed to rediscover.

    line 56
  11. Distinctive:

    Use today's local date and create the dated folder if needed:

    line 59
  12. Distinctive:

    Use a lowercase descriptive slug:

    line 65
  13. Distinctive:

    Do not write memory for tiny edits, quick answers, routine formatting, or work that leaves no durable decisions, constraints, verification, …

    line 71
  14. Distinctive:

    Use only the sections that matter:

    line 106
  15. Distinctive:

    Write Markdown a human or agent can skim in under two minutes.

    line 136
  16. Distinctive:

    Follow stricter local repo instructions first.

    line 157
  17. Distinctive:

    Never overwrite prior memory unless explicitly asked.

    line 158
  18. Distinctive:

    If existing memory must be amended, preserve prior content and add a dated note.

    line 159
  19. Distinctive:

    If old memory conflicts with current source-of-truth docs, trust the newer source of truth and mention the conflict.

    line 162
  20. Distinctive:

    If work is interrupted, write current status, exact resume instructions, and known verification state.

    line 164

“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Project Memory

Use project memory to preserve durable project context for humans and future agents.

Project memory is a record of what happened, what was learned, what decisions were made, and what still needs judgment. It is not primarily an agent handoff. Only include handoff or resume instructions when work is incomplete, interrupted, or the user explicitly asks for a handoff.

Project memory lives at:

docs/memory/YYYY-MM-DD/descriptive-slug-memory-YYYY-MM-DD.md

Memory is append-only by default. Create a new file for new work. Do not overwrite, delete, or rewrite prior memory unless the user explicitly asks.

Before Work

For substantial work:

  1. Find the project root.
  2. Check whether docs/memory/ exists.
  3. If it exists, list recent memory files:
find docs/memory -type f -name '*.md' | sort | tail -10
  1. Read the most recent relevant memory files.
  2. Read any source-of-truth docs referenced by those files when they matter for the task.
  3. Briefly summarize the relevant context before acting.

If no memory exists, continue normally. Do not create memory at the start unless the user asks.

After Meaningful Work

Create a new memory file when the session produced context that future humans or agents would be annoyed to rediscover.

Use today's local date and create the dated folder if needed:

docs/memory/YYYY-MM-DD/

Use a lowercase descriptive slug:

docs/memory/2026-05-18/auth-flow-memory-2026-05-18.md

Do not write memory for tiny edits, quick answers, routine formatting, or work that leaves no durable decisions, constraints, verification, or next actions.

What To Capture

Capture durable context, not a transcript:

  • session summary
  • what was learned
  • decisions made
  • open decisions that still need judgment
  • files created or changed
  • source-of-truth docs
  • commands, tests, builds, screenshots, or checks run
  • known constraints, gotchas, and failure modes
  • open questions
  • recommended next work, when useful
  • handoff or resume notes, only when work is incomplete or explicitly handed off

What Not To Capture

Do not store:

  • secrets, API keys, tokens, passwords, or private credentials
  • PHI, unnecessary personal data, or sensitive client details
  • raw logs containing secrets or private data
  • verbose transcripts
  • every routine command
  • speculation that will not help future work

Mention that a secret was configured or verified without recording the secret value.

Memory Template

Use only the sections that matter:

# <Project or Task> Memory - YYYY-MM-DD

## Session summary

## What we learned

## Decisions made

## Open decisions

## Files created or changed

## Source-of-truth docs

## Commands and verification

## Gotchas and constraints

## Open questions

## Recommended next work

## Handoff or resume notes

Writing Style

Write Markdown a human or agent can skim in under two minutes.

Prefer:

  • short sections
  • bullets for concrete facts
  • exact file paths
  • exact commands when verification matters
  • clear next actions when there are real next actions
  • the reason behind decisions when that reason would be easy to lose

Avoid:

  • long narrative
  • generic handoff framing when the work is already complete
  • duplicated repo docs
  • vague claims like "fixed stuff"
  • rewriting history from older memory files

Safety Rules

  • Follow stricter local repo instructions first.
  • Never overwrite prior memory unless explicitly asked.
  • If existing memory must be amended, preserve prior content and add a dated note.
  • Redact sensitive values.
  • If old memory conflicts with current source-of-truth docs, trust the newer source of truth and mention the conflict.
  • If work is interrupted, write current status, exact resume instructions, and known verification state.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.