Memory Md Management
Score and improve agent MEMORY.md (or similar) files using a five-dimension rubric so your coding agent keeps accurate commands, architecture, and gotchas across sessions.
Overview
memory-md-management is a journey-wide agent skill that scores MEMORY-style files on commands, architecture, patterns, conciseness, and currency—usable whenever a solo builder needs reliable agent context before committi
Install
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill memory-md-managementWhat is this skill?
- Five scoring dimensions: Commands/Workflows, Architecture, Non-Obvious Patterns, Conciseness, Currency
- Commands tier tops at 20 points for build, test, lint, and deploy coverage
- Architecture tier expects directory map, modules, entry points, and data flow
- Patterns dimension captures gotchas, workarounds, and unusual "why" rationale
- Conciseness and currency gates penalize filler and stale instructions
- 5 scoring dimensions in the memory quality rubric
- 20-point caps on Commands/Workflows and Architecture Clarity
- 15-point caps on Non-Obvious Patterns, Conciseness, and Currency
Adoption & trust: 838 installs on skills.sh; 271 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent memory file is long but agents still run wrong commands and miss repo-specific gotchas after every session reset.
Who is it for?
Indie builders maintaining MEMORY.md for coding agents who want an objective checklist instead of vibes-based edits.
Skip if: Projects with no persistent agent memory artifact or teams that forbid markdown context files in favor of MCP-only retrieval.
When should I use this skill?
You maintain agent memory markdown and need structured criteria to improve commands, architecture notes, and currency.
What do I get? / Deliverables
You align memory markdown to the rubric’s tiered criteria so future agent turns inherit dense, current commands and architecture maps.
- Rubric-aligned assessment bands per dimension
- Actionable gaps list for memory edits
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Audit MEMORY.md after renaming packages so deploy commands in section one still match package.json scripts.
Run the rubric before release to ensure architecture notes mention the new auth middleware path agents will touch.
Bootstrap a thin memory file for a weekend spike and use Currency + Commands tiers so the agent does not hallucinate npm vs pnpm.
Refresh Non-Obvious Patterns after an outage so on-call agents inherit the real retry workaround.
Keep a lightweight memory stub while exploring repos so later Validate work inherits directory maps without re-discovery.
How it compares
Quality checker for agent memory prose—not a vector DB or automatic codebase indexer.
Common Questions / FAQ
Who is memory-md-management for?
Solo and indie builders who rely on MEMORY.md-style files to steer Claude Code, Cursor, or Codex across repeated sessions.
When should I use memory-md-management?
After refactors in Build, before Ship review when docs drift, during Operate incidents when runbooks change, or in Validate when you spin up a prototype repo agent—any time memory must stay trustworthy.
Is memory-md-management safe to install?
See the Security Audits panel on this Prism page; the skill judges content quality and does not by itself read secrets—still scrub tokens before scoring shared memory files.
SKILL.md
READMESKILL.md - Memory Md Management
# Memory File Quality Criteria ## Scoring Rubric ### 1. Commands/Workflows (20 points) **20 points**: All essential commands documented with context - Build, test, lint, deploy commands present - Development workflow clear - Common operations documented **15 points**: Most commands present, some missing context **10 points**: Basic commands only, no workflow **5 points**: Few commands, many missing **0 points**: No commands documented ### 2. Architecture Clarity (20 points) **20 points**: Clear codebase map - Key directories explained - Module relationships documented - Entry points identified - Data flow described where relevant **15 points**: Good structure overview, minor gaps **10 points**: Basic directory listing only **5 points**: Vague or incomplete **0 points**: No architecture info ### 3. Non-Obvious Patterns (15 points) **15 points**: Gotchas and quirks captured - Known issues documented - Workarounds explained - Edge cases noted - "Why we do it this way" for unusual patterns **10 points**: Some patterns documented **5 points**: Minimal pattern documentation **0 points**: No patterns or gotchas ### 4. Conciseness (15 points) **15 points**: Dense, valuable content - No filler or obvious info - Each line adds value - No redundancy with code comments **10 points**: Mostly concise, some padding **5 points**: Verbose in places **0 points**: Mostly filler or restates obvious code ### 5. Currency (15 points) **15 points**: Reflects current codebase - Commands work as documented - File references accurate - Tech stack current **10 points**: Mostly current, minor staleness **5 points**: Several outdated references **0 points**: Severely outdated ### 6. Actionability (15 points) **15 points**: Instructions are executable - Commands can be copy-pasted - Steps are concrete - Paths are real **10 points**: Mostly actionable **5 points**: Some vague instructions **0 points**: Vague or theoretical ## Assessment Process 1. Read the memory file completely 2. Cross-reference with actual codebase: - Run documented commands (mentally or actually) - Check if referenced files exist - Verify architecture descriptions 3. Score each criterion 4. Calculate total and assign grade 5. List specific issues found 6. Propose concrete improvements ## Red Flags - Commands that would fail (wrong paths, missing deps) - References to deleted files/folders - Outdated tech versions - Copy-paste from templates without customization - Generic advice not specific to the project - "TODO" items never completed - Duplicate info across multiple memory files # Memory File Templates ## Key Principles - **Concise**: Dense, human-readable content; one line per concept when possible - **Actionable**: Commands should be copy-paste ready - **Project-specific**: Document patterns unique to this project, not generic advice - **Current**: All info should reflect actual codebase state --- ## Recommended Sections Use only the sections relevant to the project. Not all sections are needed. ### Commands Document the essential commands for working with the project. ~~~markdown ## Commands | Command | Description | |---------|-------------| | `<cmd>` | Install dependencies | | `<cmd>` | Start development server | | `<cmd>` | Production build | | `<cmd>` | Run tests | | `<cmd>` | Lint/format code | ~~~ ### Architecture Describe the project structure so Claude understands where things live. ~~~markdown ## Architecture ~~~ <tree-structure> ``` # <directory-name> # <directory-name> ``` ``` ### Key Files List important files that Claude should know about. ```markdown ## Key Files - `<path>` - <purpose> - `<path>` - <purpose> ``` ### Code Style Document project-specific coding conventions. ```markdown ## Code Style - <convention 1> - <convention 2> ``` ### Environment Document required environment variables and setup. ```markdown ## Environment Required: - `<VAR>` - <purpose> Setup: - <setup steps> ``` ### Tes