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 skills add Magnus-Gille/claude-skills --skill user-test-memorygit clone --depth 1 https://github.com/Magnus-Gille/claude-skillsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/magnus-gille/claude-skills/user-test-memory)<a href="https://agentmods.dev/skills/magnus-gille/claude-skills/user-test-memory"><img src="https://agentmods.dev/badge/skills/magnus-gille/claude-skills/user-test-memory/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/magnus-gille/claude-skills/user-test-memory"><img src="https://agentmods.dev/badge/skills/magnus-gille/claude-skills/user-test-memory.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00054 | $0.03608 |
| Opus 5 | $0.00027 | $0.01804 |
| Sonnet 5 | $0.00011 | $0.00722 |
| Haiku 4.5 | $0.00005 | $0.00361 |
Grade B, and why
user-test-memory scanned grade B with 1 finding 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 11d ago.
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.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
**Codex write access works headlessly** despite `approval_mode = "approve"` on the munin tools in `~/.codex/config.toml` — no `--dangerously-bypass-approvals-and-sandbox` needed. Use `-s workspace-write` with cwd = the s How it starts
The opening of the file, as written. The whole thing — 274 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/user-test-memory - Multi-Model Memory User Testing
Spawn independent subagents at different capability levels to stress-test the Munin memory MCP tools. Each agent gets minimal briefing and must figure things out from tool descriptions and exploration. This surfaces UX issues, broken flows, confusing behavior, and missing capabilities.
Default mode: 3 Claude agents (Opus/Sonnet/Haiku). Extended mode adds Codex (via codex exec) and Antigravity (via agy --print) — see Cross-Ecosystem Extension below.
Usage
/user-test-memory- Full exploratory test across all tools (3 Claude agents)/user-test-memory retrieval- Focus testing on search/query/user-test-memory onboarding- Focus on first-time orientation experience/user-test-memory writing- Focus on write/log/update flows/user-test-memory full- 9-runner cross-ecosystem test (Claude + Codex + Antigravity)
How It Works
Step 1: Generate Test Session ID
test-<YYYYMMDD-HHMMSS>
Each agent gets a unique test namespace: testing/<model>-<session-id> (e.g., testing/opus-test-20260408-120000).
Step 2: Build the Agent Briefing
Each agent gets the SAME briefing — a deliberately minimal context that simulates a new user. Do NOT include CLAUDE.md conventions, namespace patterns, tag vocabulary, or usage guides. The agents should discover these from the tools themselves.
Briefing template (fill in {test_namespace}, {session_id}, and {focus_area} if provided):
You are a QA tester evaluating a memory system called Munin. You have access to
MCP tools prefixed with "mcp__munin-memory__". Your job is to explore these tools
as a first-time user and report what works well, what's confusing, and what's broken.
Your test namespace is "{test_namespace}" — use this for any writes so you don't
pollute real data. You may READ from any namespace to understand the system.
{focus_area_instruction}
## Your Mission
Work through these test phases. Spend roughly equal effort on each.
### Phase 1: Orient (understand the system)
- Call memory_orient. What do you learn? Is it helpful? Overwhelming? Missing things?
- Try memory_list to browse. Can you understand the namespace structure?
- Pick 2-3 interesting namespaces and read their contents.
### Phase 2: Write (create some test data)
- Write a state entry to your test namespace
- Log a couple of entries
- Try updating an existing entry
- Try writing with tags
- Try anything that seems like it should work — does it?
### Phase 3: Retrieve (find things)
- Use memory_query to search for something you just wrote
- Search for something that exists in the system already
- Try different search modes if available
- Try filtering by tags, time ranges, namespaces
### Phase 4: Advanced tools (if they exist)
- Explore any tools you haven't tried yet
- Try edge cases: empty queries, very long content, special characters
- Look for tools that seem powerful but unclear how to use
### Phase 5: Stress test
- Try something you think SHOULD work but aren't sure about
- Try to break something (within your test namespace)
- Look for inconsistencies between tool descriptions and actual behavior
## Report Format
End your exploration with a structured report. Be specific — cite exact tool names,
error messages, and surprising behaviors. Rate each category:
S = Superb (delightful, better than expected)
A = Good (works well, minor polish needed)
B = Acceptable (works but has rough edges)
C = Poor (confusing, hard to use, or unreliable)
F = Broken (doesn't work, produces wrong results, or crashes)
```markdown
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.
- 11d ago First seen · 274 lines · 54 tokens per session scan B 55edb66a1f67
user-test-memory is a skill published in the GitHub repository Magnus-Gille/claude-skills (5 stars, last pushed 5d ago), licensed MIT. It adds 54 tokens to every session and 3,608 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
dogfood
Systematically explore and test a mobile app on iOS/Android with agent-device to find bugs, UX issues, and other problems. Use when asked to dogfood, QA, exploratory test, find issues, bug hunt, or test this app on mobile.
test-warp-ui
Guides testing Warp UI features and changes using the computer use tool. Use this skill only when computer-use testing was requested (explicit request or accepted offer) and the computeruse tool is available to the agent. Covers launching Warp and verifying UI behavior.
test-electron-app
Drive the real running PostHog Electron app (live tRPC, workspace-server, real data) over CDP with agent-browser. Connect to the running app on port 9222, test desktop changes against a local Django stack, snapshot the accessibility tree, inspect network requests, and screenshot only when explicitly asked. Use when…
pyats-dynamic-test
Generate and execute deterministic pyATS aetest validation scripts - interface state, OSPF neighbors, BGP paths, ping matrices, and custom compliance tests. Use when writing a network test, validating post-change state, running pass/fail checks, or building automated regression tests.
test-loop
Plan, generate, and heal an executable E2E test suite from approved acceptance criteria (web and mobile).
playwright-cli
Automates browser interactions for testing and validating your own web applications using playwright-cli. Use when you need terminal-first browser control for navigation, form filling, screenshots, tracing, bound browser sessions, debugging, or generating Playwright test code. Only use against applications you own or…