Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add instructions/earino/resumasher/claude-mdgit clone --depth 1 https://github.com/earino/resumasherWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.01157 | $0.01157 |
| Opus 5 | $0.00579 | $0.00579 |
| Sonnet 5 | $0.00231 | $0.00231 |
| Haiku 4.5 | $0.00116 | $0.00116 |
Grade A, and why
resumasher CLAUDE.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 112 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Project guidance for Claude Code agents
This file is loaded automatically when an agent starts work in this repo. It documents conventions specific to working on resumasher as Claude.
Sandbox vs host venv coordination
This repo's .venv/ is a per-platform artifact owned by whoever installed
the project on the host (typically macOS or Windows native, via
install.sh). It contains platform-specific Python binaries (Linux ELF,
macOS Mach-O, or Windows PE) baked-in paths in pyvenv.cfg, etc.
If you are a sandbox / Docker / remote-container agent sharing the host's
filesystem: do NOT write to .venv/. Doing so will either silently
break the host's installation (you'll overwrite their venv with one whose
binaries can't execute on their platform) or your own builds will silently
break (you'll inherit a venv whose binaries can't execute in your sandbox).
What to do instead
Use a sandbox-local venv at $HOME/.venv-resumasher-sandbox/. $HOME is
typically container-local in Docker (not part of the shared mount), so
the two venvs never collide.
If the sandbox venv doesn't exist yet, bootstrap it with:
bash tools/bootstrap-sandbox-venv.sh
This is idempotent (no-op if it exists), takes ~30s on a fresh container.
How tools find the right venv
bin/resumasher-exec searches in this order:
$RESUMASHER_VENV/bin/python— explicit override (CI, custom setups)$HOME/.venv-resumasher-sandbox/bin/python— sandbox convention$SKILL_ROOT/.venv/bin/python— POSIX host install$SKILL_ROOT/.venv/Scripts/python.exe— Windows host install
So once tools/bootstrap-sandbox-venv.sh has run, all wrapper invocations
do the right thing automatically. Hosts whose .venv/ works keep using it
unchanged.
When to use which
- Running tests for development iteration in a sandbox: invoke
~/.venv-resumasher-sandbox/bin/python -m pytest -qdirectly. Faster than going through the wrapper. - Anything that involves cross-process invocation of project scripts
(subprocess from a test, SKILL.md
$RScalls, etc.): always go throughbin/resumasher-exec. It picks the right venv per the search order.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 112 lines · 1,157 tokens per session scan A 393833b3e2c3
resumasher CLAUDE.md is an instructions file published in the GitHub repository earino/resumasher (7 stars, last pushed 3mo ago), licensed MIT. It adds 1,157 tokens to every session, about $0.0058 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other instructions, from other repositories
Resume-Builder CLAUDE.md
Instructions for jananthan30/Resume-Builder, covering resume builder - project context, quick start, option 1: claude code custom commands (recommended), resume only - dual optimized and cover letter only.
Resume-Builder AGENTS.md
Instructions for jananthan30/Resume-Builder, covering resume builder - codex context, codex plugin surface, native four-role resume team and operating rules.
dear-hiring-manager CLAUDE.md
Instructions for extrasmall0/dear-hiring-manager, covering claude.md — dear-hiring-manager, what this is, architecture principle, layout and user data (never in repo).
resume-tailor-plugin CLAUDE.md
Instructions for olegvg/resume-tailor-plugin, covering claude.md, project overview, architecture, key concepts and external dependency.
resume-tailor-plugin AGENTS.md
Instructions for olegvg/resume-tailor-plugin, covering agents.md, project overview, repo layout and verification.
ats-resume-agent CLAUDE.md
Claude Code instructions for NullSpace-BitCradle/ats-resume-agent, covering resume & cover letter workflow, standard process, output naming convention, hard constraints and usage.