Agent memory file

Skill tanveerriaz/Skillz/skills/agent-memory-file

Use when setting up or maintaining a project's AI-agent memory file (CLAUDE.md, AGENTS.md, .cursorrules, or copilot-instructions). Captures the durable project context an agent needs every session — stack, structure, conventions, guardrails — in one place, kept concise and free of secrets.From its SKILL.md

Install

npx -y skills add tanveerriaz/Skillz --skill agent-memory-file

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

1 stars1 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

3.4 KB, as published. Nobody here has run it

Purpose

Give AI agents reliable, durable project context. Without a memory file, every session re-derives the stack, conventions, and rules — inconsistently. This skill defines what belongs in an agent memory file (and what doesn't) so any compatible tool loads the same ground truth.

When to Use

Use when starting a project that AI agents will work on, when conventions keep getting violated across sessions, or when consolidating scattered rules into one canonical file. Applies to CLAUDE.md, AGENTS.md, .cursor/rules/*.mdc, and copilot-instructions.md.

Inputs

The project's tech stack and runtime.
Folder structure and where things belong.
Coding conventions, branch policy, and test commands.
Non-negotiable guardrails (security, branches, scope).

Outputs

A concise memory file an agent reads at session start, covering: project overview, stack (with "do not deviate" items), structure, conventions, workflow rules, and guardrails.

Procedure

Lead with a one-paragraph overview: what the project is and its core constraint (e.g. local-only, no build step, regulated domain).
Pin the stack explicitly, marking anything that must not change.
Map the structure: where routes, services, components, tests, and docs live, and any single-responsibility rules.
State conventions: code style, naming, commit format, and the test/lint command.
State workflow rules: branch policy, approval gates, and the change process to follow.
List guardrails as short imperatives the agent must always honor.
Keep it lean. Memory files are read every session — prune anything stale or low-signal. Link to deeper docs rather than inlining them.
Point editors at the canonical copy if multiple tools are used, so they share one source.

Quality Checklist

One-paragraph project overview present
Stack pinned, with non-negotiables marked
Structure and "where things go" rules included
Conventions and test command documented
Guardrails written as short imperatives
File is concise (signal over completeness)
No secrets, private URLs, or org-specific confidential data

Edge Cases

Multiple tools in use: keep one canonical file and have others reference it to avoid drift.
Monorepo: consider a root memory file plus scoped per-package notes.
Rules conflict: state precedence explicitly (e.g. "security rules override all others").
File growing large: split deep material into /docs and keep the memory file as an index.

Safety Rules

Never put secrets, tokens, or credentials in a memory file — it is committed.
Never include client/employer confidential details in a public repo's memory file.
Keep guardrails explicit; an unstated rule is an unenforced rule.

Examples

Good: A 60-line AGENTS.md with overview, pinned stack, structure map, commit convention, "work on dev only", and a guardrails list ("never merge without approval", "never commit .env").

Bad: A 600-line file mixing the full API reference, changelog, and meeting notes that no agent will read in full.