---
name: netsi-claude-memory
description: 'Explore what Claude Code has actually saved in its memory about a project. Lists project folders under ~/.claude/projects/ with readable paths, waits for the user to pick one, reads MEMORY.md and all memory files, and delivers a Danish summary plus fun facts, need-to-know points and a metadata analysis (oldest memory, weekday/month distribution, count per type). Use when the user writes /netsi-claude-memory or asks "hvad ved du om mig" / "what do you remember about me", "hvad har du husket", "hvad står der i din memory", "vis mine Claude memories", "memory explorer", "hvilke projekter har du hukommelse om", or wants to review or clean up saved memories, or bring a new collaborator up to speed. Always show the project list and wait for the choice; never guess the project or invent content.'
metadata:
  teaser: 'Claude has been quietly taking notes about you and your projects. Ever wondered what it wrote down? This skill lists every project, lets you pick one and reads the memory files back to you. You get a summary, fun facts, what a newcomer needs to know and when each memory was saved. Only what is actually in the files, nothing invented.'
  tags:
    - memory
    - claude-code
    - introspektion
    - onboarding
    - analyse
  version: 1.1.0
---
# netsi-claude-memory — "What has Claude actually remembered?"

Respond in Danish unless the user writes in another language (see the Language section below: all output is in Danish).

Claude Code automatically saves memories per project under
`~/.claude/projects/<slugified-absolute-path>/memory/`. The folder contains a
`MEMORY.md` with one-line pointers plus one markdown file per memory with
YAML frontmatter (`name`, `description`, `metadata.type` — `user`, `feedback`,
`project` or `reference`) and a free-form body.

This skill opens that box and explains in **clear Danish** what is actually
in it — not a raw dump, but something a person can act on.

## Language

**All output is in Danish.** Even if the user writes in English, and even if
the memory files are written in English. Quotes from the files are kept in
their original language, but the framing around them is Danish.

## The inviolable rule

Every single statement in the report must be traceable to concrete content in
a concrete memory file. No filler, no qualified guesses, no
"probably". If there are fewer than 5 genuine fun facts or fewer than 5 genuine
need-to-know points, then **say so explicitly** ("Der er kun materiale til 3
fun facts i dette projekt") instead of padding the list.

---

## Step 1 — list the projects, un-slugified

Run the helper script:

```bash
python3 scripts/memory_scan.py list
```

(If the script is not in the working directory, use the full path to the skill folder,
e.g. `~/.claude/skills/netsi-claude-memory/scripts/memory_scan.py`.)

It lists every folder under `~/.claude/projects/` and translates the slug back
into a readable absolute path:

```
-Users-stenhougaard-Documents-GitHub-frh  →  /Users/stenhougaard/Documents/GitHub/frh
```

Be aware that un-slugifying is **ambiguous**: a `-` can be either a directory
separator or a hyphen in a real directory name (`sveltekit-netsi-dk` is one
segment, not three). The script solves this by walking the path on the filesystem
and choosing the longest match that actually exists. If the path cannot be found again
(the project has been deleted, or the folder comes from another machine), it is marked
`⚠ gættet sti` — pass that marker on to the user, do not hide it.

Present the result as a **plain numbered list** — path first, slug and
memory count as secondary information. E.g.:

```
1. /Users/stenhougaard/Documents/GitHub/frh — 12 memories
2. /Users/stenhougaard/Documents/GitHub/netsi-dk — 4 memories (⚠ gættet sti)
3. /Users/stenhougaard/projekter/kunde-x — ingen memory-mappe
```

## Step 2 — stop and ask

**Ask the question and wait.** Use `AskUserQuestion` if there are few enough
projects for them to be options; otherwise ask in plain text: "Hvilket
projekt vil du have gennemgået? Skriv nummeret."

Never proceed on your own — not even if there is only one obvious project,
and not even if the user is standing in a project that matches one of the folders.
The choice is the user's.

Exception: if the user has already named the project in their message
("gennemgå memories for frh"), still show the list, mark the match you
found, and ask for confirmation of the number.

## Step 3 — read everything

Once the number is chosen:

```bash
python3 scripts/memory_scan.py scan <nummer>
```

The script prints frontmatter, dates with source attribution, statistics and
warnings — but **not** the body by default. Then read each memory file
with the `Read` tool, so the summary is based on the actual content and not just on
the `description` field. (Alternatively `scan <nummer> --bodies`, if you would rather
have everything in one go.)

Handle these cases explicitly in the report rather than letting them disappear:

| Situation                                 | How to report it                                                                    |
| ----------------------------------------- | ----------------------------------------------------------------------------------- |
| No `memory/` folder                       | "Projektet har ingen memory-mappe — Claude har intet gemt her." Stop.               |
| Empty `memory/` folder                    | "Memory-mappen findes, men er tom." Stop.                                           |
| File mentioned in `MEMORY.md` but missing | Mention it under "Sprunget over" with the filename.                                 |
| File cannot be parsed (invalid frontmatter) | Mention it under "Sprunget over" — and use the body anyway, if it is readable.    |
| File on disk but not mentioned in `MEMORY.md` | Include it, and mark it as not indexed.                                         |

If there are no memories to analyse, say so plainly and **do not produce** the
four sections below. An empty report is a valid result.

## Step 4 — write the report

Four sections, in this order, with these headings:

### "Om dette projekt"

A short summary in plain language of what each memory is about. Explain the
**meaning in context** — not a repetition of the `description` field. Bad:
"deploy.md: hvordan der deployes". Good: "Claude har lært, at sitet kører på
Netlify med serverless-funktioner, og at `adapter-static` ligger i package.json
uden at blive brugt — så en 'det er jo et statisk site'-antagelse vil være
forkert."

One short bullet or one paragraph per memory file. Mention the filename so the summary
can be verified.

### "Fun facts"

**At least 5 bullets.** Specific, surprising or amusing details taken
directly from the content. Each bullet must end with a source reference: `(kilde:
brugerprofil.md)`.

What counts as a fun fact: an unusual preference, an opinion the user has
expressed sharply, a technical curiosity, a name or detail that surprises,
a pattern in what Claude has been corrected on.

What does **not** count: generic project info ("projektet bruger TypeScript"),
something you infer rather than read, or a rewording of a need-to-know.

### "Need-to-know"

**At least 5 bullets.** The operationally most important things a new collaborator —
or a future Claude session — must know _before_ touching the project.
Prioritise by what does harm if you don't know it: traps, inviolable
conventions, things that have been corrected before, commands that must be run in a
particular way. Here too: `(kilde: <filnavn>)` on each bullet.

### "Metadata-analyse"

About the files themselves, not their content. Must contain:

- **Ældste memory** — date + filename.
- **Antal pr. type** (`user` / `feedback` / `project` / `reference`, plus
  any files without a type).
- **Fordeling pr. ugedag** and **pr. måned** — table or bullets.
- **Mønstre der er værd at nævne**: a cluster around one week, one type that
  dominates, a long stagnation, memories that were never indexed.

**State the date source.** The script reports per file whether the date came from a field in
frontmatter (e.g. `frontmatter.metadata.created`) or from the file's `mtime`, and
summarises the distribution. Write that source next to each figure, e.g.: "Ældste memory: 2. marts 2026 (`brugerprofil.md`, kilde: `metadata.created`)" and "Ugedags‑
fordelingen bygger på mtime for 2 af 4 filer, da de mangler datofelt."

Note to the user if many dates come from `mtime`: mtime changes
when a file is edited or copied, so the distribution then says more about
_last modified_ than about _when the memory came into being_.

All dates are converted to the **machine's local time** before being distributed by weekday
and month. A frontmatter field may carry a time zone (`2026-03-02T23:30:00+02:00`),
while `mtime` is always local — without the conversion the two would sit on different
timelines, and a time close to midnight would land on the wrong weekday.

---

## Helper script

`scripts/memory_scan.py` (Python 3.9+, no required dependencies — uses
PyYAML if it is installed, otherwise a built-in minimal parser).

```bash
python3 scripts/memory_scan.py list                    # nummereret projektliste
python3 scripts/memory_scan.py scan 3                  # læs projekt nr. 3
python3 scripts/memory_scan.py scan 3 --bodies         # tag brødteksten med
python3 scripts/memory_scan.py --json scan 3           # rå JSON
python3 scripts/memory_scan.py --root /sti/til/rod list  # anden rod-mappe
```

A directory name can be used directly instead of the number
(`scan -Users-navn-projekt`) — the script itself handles the name starting with
`-`.

`scripts/test_memory_scan.py` is a regression test for the script (run
`python3 scripts/test_memory_scan.py`; exit 0 = everything passed). Among other things it covers the date
conversion across time zones and the extraction of pointers from
`MEMORY.md` — update it too if you change those parts.

If you do not have the script at hand, the steps can also be run by hand with `Glob`,
`Bash` (`ls ~/.claude/projects/`) and `Read` — but then the un-slugifying, the
date sources and the statistics must be done manually and with the same care.