Give Claude a Memory of Your Project
Write the CLAUDE.md that stops you re-explaining your codebase daily.
Most of your prompt budget goes on context you have supplied a hundred times. A project memory file spends it once.
That is the gap this drop closes. It is a automation skill built for Claude, and it takes about ten minutes to set up the first time. After that it runs in under a minute.
Who should use it
Developers and technical teams using Claude Code or Projects.
How it works
The skill file does five things, in this order.
1. Map the repository. Directory purposes, not a file listing.
2. Record the conventions. Naming, error handling, test style, the things reviewers always flag.
3. Write the commands. Build, test, lint, deploy. Exact strings, not descriptions.
4. List the traps. The migration that must run first, the service that fails silently.
5. Add the boundaries. Files never to touch, and what always needs a human review.
What comes back
A CLAUDE.md that makes every future session start with full context.
The mistake to avoid
Keep it under 300 lines and prune it monthly. A memory file that grows forever becomes noise, and noise is worse than no file.
Running it
Save this as SKILL.md inside a folder named after the skill, then drop the folder into your Claude Code skills directory or upload it to a Claude Project. Claude reads the frontmatter to decide when the skill applies, so keep the description line intact. For a one-off run, paste the prompt block directly.
Where this fits
On its own, one skill saves an hour a week. The compounding happens when three or four of them run in sequence on the same input, the same transcript that produces a scope of work also produces the follow-up email and the project brief. That is the point at which it stops being a prompt and starts being an internal tool. If you want that wired into the systems your team already uses, that is the work 67 Digital does.
In the file
Read this repository and write a CLAUDE.md project memory file.
Sections, in this order:
1. WHAT THIS IS, the product in two sentences, and who uses it.
2. ARCHITECTURE, directory purposes and how data flows between them.
Not a file listing.
3. COMMANDS, exact strings for install, dev, test, lint, build, deploy.
4. CONVENTIONS, naming, error handling, test style, commit format. Derive
these from the actual code, not from general best practice.
5. TRAPS, non-obvious failures. Migrations that must run first, services
that fail silently, environment variables with no defaults.
6. BOUNDARIES, files never to edit without asking, and changes that always
need human review.
Maximum 300 lines. Every claim must come from the code. Mark guesses [VERIFY].