agentsclimarketplace
Sign in

Serena refresh

Skill 1stvamp/agent-skills/serena-refresh

Refresh and re-sync Serena's project memories after a codebase has moved on, so the agent's orientation notes match current reality instead of quietly misleading it. Use whenever you return to a Serena-onboarded repo after time away, after a merge, refactor, rename, or dependency bump, or when the memories look stale or describe structure that no longer exists. Trigger on phrases like "refresh serena", "update serena memories", "sync serena", "the architecture notes are out of date", or "we just merged the queue rewrite, update the memory". This is for projects ALREADY set up with Serena; for first-time setup use the serena-onboard skill instead. The refresh is surgical and git-scoped: it only rewrites memories whose subject matter actually changed, never a blanket re-onboard.From its SKILL.md

Install
npx -y skills add 1stvamp/agent-skills --skill serena-refresh

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.

SKILL.md

5.4 KB, ~1.1k tokens by cl100k_base, as published. Nobody here has run it

Serena Refresh

Keep Serena's memory layer honest. The symbol index does not need refreshing: find_symbol and find_referencing_symbols read current files through the language server, so navigation already reflects new code. What goes stale is the human/agent-authored markdown under .serena/memories/ — the execution_path note still describing the old flow after a refactor, the structure note that never heard about a new package. Because the activate hook reloads those into every session, a stale memory is worse than a missing one: it is confidently wrong, every session, until corrected. This skill finds the drift and rewrites only the affected memories.

The engine is git. Scope the work to what changed since the last refresh, rather than re-reading the whole repo (which would just be onboarding again).

Step 0: Preconditions

  1. Serena loaded? Confirm mcp__serena__* tools exist this session. If not, Serena isn't connected — point the user at setup (serena-onboard).
  2. Onboarded? check_onboarding_performed, or confirm .serena/memories/ has .md files. If the project was never onboarded, this is the wrong skill — hand off to serena-onboard for a first pass.

Step 1: Scope the refresh against git

Run from the repo root:

bash scripts/refresh_scope.sh

It resolves a baseline ref (the .serena/last_refresh marker if present, else it asks you to pass one), diffs it against HEAD ignoring .serena/ itself, and prints: changed files, changed top-level areas, manifest/dependency changes, the current memory list, and a heuristic shortlist of memories that mention a changed area.

If there's no marker, pass a sensible baseline explicitly — the last release tag, the onboarding commit, or a date ref:

bash scripts/refresh_scope.sh <sha-or-tag>
bash scripts/refresh_scope.sh 'HEAD@{2 weeks ago}'

If the script reports no commits since the baseline, the memories are current; stop and say so (don't invent work).

Step 2: Confirm and rewrite only what drifted

The shortlist is a heuristic, not a verdict. For each candidate, and for the always-worth-checking execution_path and structure memories:

  1. Read the current memory (read_memory).
  2. Check current reality for the changed area using Serena symbol tools (get_symbols_overview, find_symbol, find_referencing_symbols), not grep. For dependency/manifest changes, read the manifest to update tech_stack.
  3. If the memory is now inaccurate, rewrite it (write_memory overwrites). Keep it tight; don't pad. If it's still accurate, leave it untouched — needless churn erodes trust in the layer.

See references/refresh-playbook.md for the path-to-memory mapping and the handling of the trickier cases below.

Step 3: Handle new, removed, and renamed subsystems

  • New subsystem (a new package/service/module that no memory covers): add a focused memory for it and add a one-line pointer from core and structure.
  • Removed code: if a memory describes something now deleted, fix the memory or remove it (delete_memory). A memory pointing at code that no longer exists is a trap.
  • Renamed/moved: update names and paths in every memory that referenced the old location. The diff's R/D/A status lines flag these.

Step 4: Advance the marker

Once the affected memories are correct, move the baseline forward so the next refresh is scoped from here:

git rev-parse HEAD > .serena/last_refresh

Step 5: Optional — restart the language server

Rarely needed, but after a branch switch or a dependency bump the language server can serve stale or empty symbol results. If navigation looks plainly wrong (known symbols not found, references missing), call Serena's restart_language_server tool, then re-verify. Don't do this routinely; it costs a cold re-index.

Step 6: Report

Summarise: the baseline and HEAD you compared, which memories you changed and why, any added/removed, and confirmation the marker advanced. Be explicit about what you deliberately left unchanged so the user can sanity-check your scoping.

Notes

  • Surgical by design. If you find yourself rewriting most memories, either the baseline was too old (huge diff) or the codebase genuinely turned over — say so, rather than silently doing a full re-onboard under a refresh label.
  • The marker may be gitignored. .serena/ is usually untracked, so the marker is local state. That's fine; it only needs to persist on this machine.
  • No marker and no obvious baseline? Ask the user when they last onboarded or which release to compare against, rather than guessing a ref.

What ships with it: 2 files

7.2 KB alongside SKILL.md, 1 of them executable

references/

scripts/

Gives 0 of the 12 instructions most architecture codebase skills give in ~1.1k tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

  • scope the refresh against git diff
  • stop if no commits exist since baseline
  • read each candidate memory file
  • check current reality with symbol tools
  • rewrite only inaccurate memory files
  • update paths for renamed or moved code

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 326,852. 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.