agentsclimarketplace

Memory as files

Skill Edward4226/codex-maxxing/skills/memory-as-files

Drop-in AGENTS.md / CLAUDE.md + 3 companion skills distilled from Jason Liu's《Codex-maxxing》(2026-05-10). Executable rules, not a reprint.

Install
npx -y skills add Edward4226/codex-maxxing --skill memory-as-files

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use this skill when the user wants persistent, cross-session, reviewable memory for an ongoing project, set of people, or domain knowledge. It initializes a versioned file vault (TODO.md + people/ + projects/ + notes/), defines maintenance rules so memory stays current at natural beats, and treats the vault's git diff as the periodic memory-review surface.

SKILL.md

3.8 KB, 879 tokens by cl100k_base, as published. Nobody here has run it

memory-as-files

Chat history is volatile, lossy, and hidden. A file vault is permanent, searchable, and diffable. This skill turns "things you should remember about my work" into a small, structured, git-tracked folder.

When to use this skill

Use it when:

  • The user works across many sessions on the same project or people
  • "Remember that..." / "Don't forget..." comes up repeatedly
  • The user wants the host to onboard a future session with the same context
  • A handoff to a teammate or another agent is anticipated

Do not use it for ephemeral session state — use TaskList for that.

What it produces: the vault scaffold

memory/
├── TODO.md                      # open loops; one line per item with status
├── people/
│   └── <name>.md                # what I know about each person
├── projects/
│   └── <name>.md                # context per project (goal, status, blockers)
└── notes/
    └── <topic>.md               # domain knowledge worth keeping

The vault lives at the project root (default) or ~/memory/ (cross-project). It gets committed to git so changes are reviewable.

Maintenance rules — the actual "skill"

The vault is only useful if it stays current. Update at these natural beats:

TriggerUpdate
User mentions a new person (role, ownership, contact)people/<name>.md
Project status changes (milestone, blocker, decision)projects/<name>.md
User closes an open loopstrike or move the line in TODO.md
User shares non-trivial domain knowledgeappend to notes/<topic>.md
Session end / weekly reviewcommit; review the diff

Updates are append-mostly: don't overwrite history without recording it. Past wrongness is sometimes useful context.

Procedure

  1. If memory/ doesn't exist, run the scaffold (create directories + empty stub files with one-line headers).
  2. On every meaningful learning, find the right file and update it in one place.
  3. At session end, commit with a descriptive message: memory: <what changed and why>.
  4. Suggest a weekly diff review: git log --since="1 week ago" memory/ then git diff HEAD~5 memory/.

Anti-patterns this skill blocks

  • ❌ Writing memory updates into the chat without persisting to the vault.
  • ❌ One giant memory.md — you can't grep it usefully when it's 5000 lines.
  • ❌ Storing secrets (API keys, passwords, tokens) in the vault — even private repos leak. Use a secret manager.
  • ❌ Memory the user doesn't know about — always announce updates: "I added <X> to projects/<Y>.md."

Why files (not a database, not chat history)

  • Portable — works across hosts (Claude / Codex / Cursor / a human teammate).
  • Diffable — git diff is the memory review surface.
  • Greppablerg "person-name" memory/ finds everything in one shot.
  • Boring — no service to set up, no schema to migrate, no SaaS to outlast.

Worked example (original — not lifted from any source)

Mid-session, the user says: "By the way, Sara is taking over the data pipeline from Marcus next week."

This skill triggers:

  1. Update people/sara.md: append "owns data pipeline (from 2026-06-01, succeeding Marcus)."
  2. Update people/marcus.md: append "handed data pipeline to Sara on 2026-06-01."
  3. Update projects/data-pipeline.md: change owner line.
  4. Announce in chat: "Updated people/{sara,marcus}.md and projects/data-pipeline.md with the handover."

Gives 0 of the 12 instructions most memory context skills give in 879 tokens

Counted across 674 of the 847 authors here whose files we hold, read 2026-08-06

  • inform the user when setup is completein 21 of 674, across 6 files
  • confirm the draft with the user before writingin 21 of 674, across 6 files
  • update the agent skills block in place if it existsin 21 of 674, across 6 files
  • present findings to the userin 20 of 674, across 5 files
  • write the three docs files from seed templatesin 20 of 674, across 5 files
  • ask the user about each decision one at a timein 19 of 674, across 4 files
  • edit CLAUDE.md if it existsin 18 of 674, across 3 files
  • explore current repo statein 18 of 674, across 3 files
  • do not overwrite user edits to surrounding sectionsin 18 of 674, across 3 files
  • back up the original file before overwritingin 16 of 674, across 8 files
  • keep the memory index under 200 linesin 15 of 674
  • Provide actionable steps and verificationin 13 of 674, across 2 files

Said here and by no other author read

  • create the vault scaffold if it does not exist
  • update the correct vault file on every meaningful learning
  • record updates as append-mostly entries
  • commit vault changes at session end
  • suggest a weekly git diff review
  • announce all memory updates to the user

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.