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 skills/melodic-software/claude-code-plugins/methodologynpx skills add melodic-software/claude-code-plugins --skill methodologygit clone --depth 1 https://github.com/melodic-software/claude-code-pluginsWrote 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/melodic-software/claude-code-plugins/methodology)<a href="https://agentmods.dev/skills/melodic-software/claude-code-plugins/methodology"><img src="https://agentmods.dev/badge/skills/melodic-software/claude-code-plugins/methodology.svg" alt="Measured on agentmods" 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.00144 | $0.01105 |
| Opus 5 | $0.00072 | $0.00553 |
| Sonnet 5 | $0.00029 | $0.00221 |
| Haiku 4.5 | $0.00014 | $0.00111 |
Grade A, and why
methodology 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 2d 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.
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 — 69 lines — stays where its author put it; the contents beside it link to each section on GitHub.
LLM evaluation methodology
Distilled from a cover-to-cover reading of Anthropic's "Define success criteria and build
evaluations" (https://platform.claude.com/docs/en/test-and-evaluate/develop-tests) and its linked
evals cookbook (anthropics/claude-cookbooks misc/building_evals.ipynb), fetched 2026-08-08.
Reference files carry per-file source stamps; re-fetch the source page for runnable code or when a
specific must be current.
Routing table
| Query about... | Load |
|---|---|
| Success criteria: specific/measurable/achievable/relevant, quantifying hazy qualities (safety, empathy), metric menu (F1, BLEU, accuracy, latency, price), criteria dimensions, multidimensional targets | success-criteria.md |
| Eval anatomy (input/output/golden answer/score), golden-answer-as-rubric, design principles, edge-case taxonomy, real-distribution mirroring, volume over polish, authoring vs grading cost asymmetry, generating cases with Claude | eval-design.md |
| Grading ladder (code > LLM > human), LLM-grader rubrics, constrained verdicts, reasoning-then-discard, grader-output validation, different-model grading, testing the grader first | grading.md |
| Concrete recipes: exact match, cosine similarity/consistency, ROUGE-L/summarization, Likert/tone, binary/privacy-leak, ordinal/context utilization | recipes.md |
Load the most relevant file first; a second only if the first doesn't fully answer.
Quick decision guide (no file load needed):
- "Where do I start?" → Define measurable success criteria first; evals test against them; only then iterate on prompts.
- "Is this criterion good?" → It names a specific quality, a number or defined scale, a realistic target, and ties to a user need. "Good performance" fails all four.
- "Which grading method?" → The fastest, most reliable, most scalable that fits: code-based if the output can be constrained to allow it; LLM-graded for judgment; human only as a last resort.
- "Can I automate this seemingly subjective eval?" → Usually — constrain the output format, reformat to multiple choice, or use an LLM grader with a tight rubric and constrained verdict.
- "How many cases?" → Prefer volume with automated grading over a few hand-graded showpieces; generate more from a baseline set with Claude, human-reviewed.
- "Can I trust my LLM grader?" → Only after reading samples of its verdicts against your own judgment; and grade with a different model than the one that generated the output.
- "One metric or several?" → Several — most use cases need multidimensional criteria (fidelity + safety + latency + cost); a single headline metric hides regressions.
What ships with it
4 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 2d ago First seen · 69 lines · 144 tokens per session scan A 2ef7118889b9
methodology is a skill published in the GitHub repository melodic-software/claude-code-plugins (15 stars, last pushed today), licensed MIT. It adds 144 tokens to every session and 1,105 once invoked, about $0.0007 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-09-03.
Other skills, from other repositories
llm-evaluation
LLM evaluation and testing patterns including prompt testing, hallucination detection, benchmark creation, and quality metrics. Use when testing LLM applications, validating prompt quality, implementing systematic evaluation, or measuring LLM performance.
benchmark-before-optimize
For performance work: measure before changing, profile to find bottlenecks, compare before and after.
parse-extract-input
For text processing: extract numbers, words, structured data from messy text using regex patterns, parsing utilities.
test-structural-invariants
For data structure validation: test lengths, relationships, constraints that must hold, verify setup is correct.
test-with-examples
For example-driven development: test cases as specifications, input/output pairs, documentation through examples.
verify-solution-properties
For solution checking: independent verification that result is correct, separate from how it was computed.