Remember
Persist hard-won facts, conventions, and preferences into project auto-memory so future agent sessions do not miss what auto-capture would overlook.
Overview
remember is a journey-wide agent skill that saves explicit, timestamped knowledge to auto-memory—usable whenever a solo builder needs to lock in a fact before the next agent session forgets it.
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill rememberWhat is this skill?
- Parses what, why it matters, and project vs global scope before writing
- Duplicate check via grep on project memory dir before appending
- Timestamped explicit entries when auto-memory is too passive
- Examples span CI gotchas, architecture choices, and user style preferences
- Works with Claude project memory paths keyed off cwd
Adoption & trust: 1.6k installs on skills.sh; 17.5k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Critical project truths stay in chat logs or your head, so the agent repeats mistakes on CI versions, auth libraries, or style rules.
Who is it for?
Builders who repeatedly re-explain the same stack constraints, test flags, or preferences to coding agents.
Skip if: Publishing user-facing documentation or replacing a maintained CLAUDE.md for onboarding—use docs skills when the audience is humans, not session memory.
When should I use this skill?
A discovery is too important to rely on auto-capture—debugging insights, conventions not in CLAUDE.md, tool gotchas, architecture decisions, or stated preferences.
What do I get? / Deliverables
A deduplicated memory entry records the fact with context so later Claude runs in the same project retrieve it from auto-memory.
- Timestamped auto-memory entry with parsed what/why/scope
- Duplicate-avoidance note when similar memory already exists
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Record that Jest needs --forceExit so database tests do not hang on the next feature branch.
Capture that CDN—not the API—causes CORS on /api/upload after a production firefight.
Lock the decision to use Drizzle over Prisma before implementation planning spreads the wrong assumption.
Remember reviewer preference for explicit error handling instead of catch-all try blocks.
How it compares
Use for durable agent memory snippets instead of hoping the model auto-summarizes chat without an explicit /si:remember command.
Common Questions / FAQ
Who is remember for?
Solo and indie developers using Claude Code (or compatible flows) who want intentional memory writes after debugging or decisions.
When should I use remember?
After Operate incident lessons, during Build when you learn tool gotchas, at Validate when pricing or scope assumptions must stick, at Ship when CI quirks appear, or anytime a fact must survive the next session.
Is remember safe to install?
It writes under your local Claude project memory path—review the Security Audits panel on this page and avoid storing secrets or tokens in remembered text.
SKILL.md
READMESKILL.md - Remember
# /si:remember — Save Knowledge Explicitly Writes an explicit entry to auto-memory when something is important enough that you don't want to rely on Claude noticing it automatically. ## Usage ``` /si:remember <what to remember> /si:remember "This project's CI requires Node 20 LTS — v22 breaks the build" /si:remember "The /api/auth endpoint uses a custom JWT library, not passport" /si:remember "Reza prefers explicit error handling over try-catch-all patterns" ``` ## When to Use | Situation | Example | |-----------|---------| | Hard-won debugging insight | "CORS errors on /api/upload are caused by the CDN, not the backend" | | Project convention not in CLAUDE.md | "We use barrel exports in src/components/" | | Tool-specific gotcha | "Jest needs `--forceExit` flag or it hangs on DB tests" | | Architecture decision | "We chose Drizzle over Prisma for type-safe SQL" | | Preference you want Claude to learn | "Don't add comments explaining obvious code" | ## Workflow ### Step 1: Parse the knowledge Extract from the user's input: - **What**: The concrete fact or pattern - **Why it matters**: Context (if provided) - **Scope**: Project-specific or global? ### Step 2: Check for duplicates ```bash MEMORY_DIR="$HOME/.claude/projects/$(pwd | sed 's|/|%2F|g; s|%2F|/|; s|^/||')/memory" grep -ni "<keywords>" "$MEMORY_DIR/MEMORY.md" 2>/dev/null ``` If a similar entry exists: - Show it to the user - Ask: "Update the existing entry or add a new one?" ### Step 3: Write to MEMORY.md Append to the end of `MEMORY.md`: ```markdown - {{concise fact or pattern}} ``` Keep entries concise — one line when possible. Auto-memory entries don't need timestamps, IDs, or metadata. They're notes, not database records. If MEMORY.md is over 180 lines, warn the user: ``` ⚠️ MEMORY.md is at {{n}}/200 lines. Consider running /si:review to free space. ``` ### Step 4: Suggest promotion If the knowledge sounds like a rule (imperative, always/never, convention): ``` 💡 This sounds like it could be a CLAUDE.md rule rather than a memory entry. Rules are enforced with higher priority. Want to /si:promote it instead? ``` ### Step 5: Confirm ``` ✅ Saved to auto-memory "{{entry}}" MEMORY.md: {{n}}/200 lines Claude will see this at the start of every session in this project. ``` ## What NOT to use /si:remember for - **Temporary context**: Use session memory or just tell Claude in conversation - **Enforced rules**: Use `/si:promote` to write directly to CLAUDE.md - **Cross-project knowledge**: Use `~/.claude/CLAUDE.md` for global rules - **Sensitive data**: Never store credentials, tokens, or secrets in memory files ## Tips - Be concise — one line beats a paragraph - Include the concrete command or value, not just the concept - ✅ "Build with `pnpm build`, tests with `pnpm test:e2e`" - ❌ "The project uses pnpm for building and testing" - If you're remembering the same thing twice, promote it to CLAUDE.md