Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sweetcornna/mathodology-dev-test-release
Use when checking skill metadata, references or repository boundaries, or preparing an explicitly requested skills release.
Passed 16 of 20 test cases with the skill, and 10 of 20 without it.
and 4 more in the full report
6 fixed10 passed either way4 still failing0 broke3 errored
Tokens, turns and time describe resource use, not a dollar price.
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
We want to configure the repository validator script `validate_repo.py` to enforce that every skill markdown file contains exactly three level-2 headings. Which flag enables this heading count check?
| Checked | Without skill | With skill |
|---|---|---|
| States that the validator script does not enforce document heading counts. | Missed | Passed |
The instructions your model reads when the skill loads.
Repository maintenance checks are optional utilities; they do not run during modeling by default and cannot establish mathematical or editorial quality.
From a repository checkout, run:
python3 .claude/skills/mathodology-dev-test-release/scripts/validate_repo.py all
The standard-library checker covers skill/role metadata, local Markdown links,
known skill references and allowed repository paths. Individual commands are
metadata, links, boundary and selftest. It supports a source export without
Git; in a checkout it also inspects tracked paths. It does not enforce document
heading counts, search wording, updater contracts or contest run schemas.
When changing a utility, exercise its actual behavior. The figure demonstration script and PDF overview utility have self-tests; backup can be verified by extracting the archive and checking its checksum. Read backup and installation guidance.
When changing prompts, review representative user scenarios and inspect generated figures. Do not add tests that simply restate prompt sentences. Do not report that a prompt guarantees consistent future model behavior.
Release work is repository maintenance, separate from the modeling guidance. Inspect the current remote branch, recent releases and existing tags. Choose the next version consistently with that history and describe migration requirements when removing an old entry point or utility. Do not invent a package manifest, application build or CI pipeline for this skills pack.
Review the actual changes, run relevant checks and verify retained asset licenses. Use a focused branch and pull request when that matches repository practice. Respect branch protections; do not bypass required reviews or checks. Once the authorized changes are merged, tag that exact commit and publish the requested release with concise changes, migration notes and truthful validation results. Never move an existing release tag to a different commit. Verify the published
test cases passed, vs 10 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.