memory-usage

Read and write persistent project memory across sessions using topic-based naming conventions.

Updated Jul 11, 2026
One-click install
npx skills add https://github.com/danielsuguimoto/skills --skill memory-usage-danielsuguimoto
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: memory-usage
Source: https://github.com/danielsuguimoto/skills/tree/main/skills/memory-usage
Command: npx skills add https://github.com/danielsuguimoto/skills --skill memory-usage-danielsuguimoto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Important project knowledge like architectural decisions, conventions, and pitfalls gets lost between sessions, forcing repeated re-investigation. This Skill defines when and how to read and write persistent project memory so durable knowledge survives across sessions. ## Core Features & Use Cases - Read-before-acting triggers: Lists and reads relevant memories before non-trivial tasks, unfamiliar errors, or questions about project conventions. - Write-after-learning rules: Captures non-obvious invariants, pitfalls, and architectural decisions under stable slash-separated topic paths like pitfalls/ and decisions/. - Generic memory operations: Covers list, read, write, edit, delete, rename, and project activation across any memory driver configured in docs/memory-providers.md. - Use Case: After debugging a tricky module lifecycle issue, write the findings under pitfalls/placements-lifecycle so the next session reads it before touching that code instead of re-investigating from scratch. ## Quick Start Read the project memory providers spec, list existing memories relevant to my current task, and write a new memory under decisions/ documenting the architectural choice we just made.

Frequently Asked Questions about memory-usage

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I persist project knowledge across AI sessions?▼

Write non-obvious knowledge like architectural decisions, conventions, and pitfalls to a persistent memory store under stable slash-separated topic paths. Read relevant memories before starting non-trivial work so prior findings are reused instead of re-derived.

What should I write to project memory versus leave in code?▼

Write only knowledge that is expensive to re-derive: architectural decisions with rationale, non-obvious pitfalls, and lasting conventions. Never store facts trivially recoverable from code, tests, or docs, nor transient state like current branches or ticket IDs.

How should project memory entries be named and organized?▼

Use specific slash-separated topic paths such as modules/<name>, pitfalls/<topic>, and decisions/<topic> rather than generic names. Keep entries structured with headings and bullets, split entries past roughly 100 lines, and cross-reference with mem:<name>.

What happens if the memory providers spec file is missing?▼

The Skill falls back to native tools and notes the gap rather than inventing the spec contents. It reads <project-root>/docs/memory-providers.md via shell commands since the file may be gitignored and invisible to built-in search.

When should I not write something to persistent memory?▼

Do not write conversation state, task progress, session scratchpads, or transient data like in-flight PR numbers. Also avoid duplicating existing memories; edit the existing entry instead of creating a new one.