agentsclimarketplace

Memory keeping

Skill matejformanek/postgres-claude/.claude/skills/memory-keeping

Turn Claude Code into a long-term collaborator on PostgreSQL internals — cited knowledge corpus, agent skills, slash commands, and task-shaped scenarios for backend hacking.

Install
npx -y skills add matejformanek/postgres-claude --skill memory-keeping

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

Close out a pg-claude session — sync progress/STATE.md, progress/coverage.md, progress/files-examined.md, and append a sessions/ log entry whenever a session produced durable output (a new knowledge/idioms or knowledge/subsystems doc, a [verified-by-code] fact, a discovered gotcha, a file-by-file deep read, or a locked decision from pg-claude-plan.md §14). Use proactively when the user says "wrap up", "close out the session", "sync memory files", "record this gotcha", "we're done for the day", or "log this for next time" — and whenever durable output was just produced. Skip for PG MemoryContext / palloc / pfree internals questions (use memory-contexts), LangChain / LangGraph / LlamaIndex agent memory and vector stores, application memory leaks / valgrind / heaptrack, conversational chat history persistence, finding old Claude sessions (use find-session), and ChatGPT / Claude.ai conversation export.

SKILL.md

5.7 KB, ~1.2k tokens by cl100k_base, as published. Nobody here has run it

memory-keeping

The pg-claude system is only as useful as its memory. STATE.md, coverage.md, and the sessions/ log are how a future Claude (or future you) picks up cold without re-reading the whole repo.

Invariants

  1. STATE.md is the front page. It must answer in under a minute: what phase are we in, what's the last thing that got finished, what's the next concrete step. Keep it short — link to detail elsewhere.
  2. coverage.md is a table. One row per documented artifact (subsystem, idiom, data-structure). Columns: name | path | last-verified-commit | confidence-summary | open-questions.
  3. sessions/ is append-only. One file per significant session, YYYY-MM-DD-<topic>.md (use today's date, the day you're writing — not the date of the work if it spanned multiple days). Never edit old session logs; if a later session invalidates a claim, write a new session log that supersedes it and update STATE.md to point at the newer one.
  4. files-examined.md is the per-file ledger. Append-only. One row per source file read in non-trivial depth, columns: path | depth (skim/read/deep-read) | date | last-verified-commit | produced-doc. Append whenever a file becomes load-bearing for any claim in knowledge/, including pure file-by-file deep reads that don't yet have a synthesis doc. (See CLAUDE.md rule 6: "Track what you read.")

When to update what

TriggerSTATE.mdcoverage.mdfiles-examined.mdsessions/
New subsystem doc landedyes (move forward)new rowappend one row per file citednew file
Existing doc re-verified at a newer commitbump phase if relevantupdate last-verified-commitappend re-verify rows for re-read filesnew file
Decision from pg-claude-plan.md §14 lockedrecord decision + datenew file noting rationale
Discovered a wrong claim in an existing docnote correction in STATEadjust confidence-summaryappend re-verify row for the file you re-readnew file describing the discovery
File-by-file deep read with no new synthesisappend rowsoptional
Pure exploration with no durable outputoptional, only if worth re-finding

When you discover a wrong claim, fix the claim in the knowledge/ doc itself (the artifact) in the same session. The session log records the discovery; the coverage.md row gets its confidence-summary adjusted; STATE.md gets a one-line note pointing at the new session log. The old session log is never touched.

How to write a session log

≤ 50 lines is the target. Headings:

# <date> — <topic>

## What I did
Bullets, terse.

## What I learned
The 2–5 non-obvious things. Cite source files where applicable.

## What I'm unsure about
Honest list. Future sessions can pick these up.

## Pointers left for next time
Concrete next steps, in priority order.

How to update STATE.md

Edit, don't append. STATE.md has a fixed shape:

# pg-claude — current state

**Phase:** <Phase 0 / 0.5 / 1a / …>
**Last activity:** <date> — <one-line summary>
**Source commit at last verification:** <sha>

## Done
- bullets

## In progress
- bullets (usually one)

## Next
- 1–3 concrete next steps, in order

## Recent session logs
- `sessions/<file>` — one-line tag
- (keep ~5 most recent; older ones live only in the dir)

How to extend coverage.md

It is a markdown table. New rows go at the bottom unless you're reordering by priority. Don't delete rows — if a doc is retired, mark its row with status: retired and link to the replacement.

Things you must not do

  • Don't write into STATE.md decisions that aren't actually decided (don't speculate forward).
  • Don't conflate sessions/ entries with knowledge/ docs. sessions/ records the act of producing; knowledge/ is the produced artifact.
  • Don't try to compact session logs by deleting old ones — they are the audit trail.

Cross-references

  • .claude/skills/pg-claude/SKILL.md — master index; this skill keeps its progress/ pointers honest.
  • .claude/skills/meta-commit-style/SKILL.md — STATE.md / coverage.md updates land via this commit style.
  • .claude/skills/pg-implement/SKILL.md — R12 (end-of-implementation gate) explicitly invokes this skill.
  • progress/STATE.md — the front page this skill maintains.
  • progress/coverage.md, progress/files-examined.md — the per-artifact / per-file ledgers this skill appends to.
  • Top-level CLAUDE.md — Rule 6 ("Track what you read") is the reason files-examined.md exists.

Gives 0 of the 12 instructions most memory context skills give in ~1.2k 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 a session log for durable outputs
  • keep state file short and link to detail
  • use today's date for new session logs
  • append new rows to the coverage table
  • append rows for files cited in new docs
  • fix wrong claims in the doc itself

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.