git:20261022.4d8df2f to git:20261023.d5b9ac0

---

name: mathodology-dev-test-release

description: Use when checking skill metadata, references or repository boundaries, or preparing an explicitly requested skills release.

---

# Mathodology Repository Checks

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:

```bash

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 (skills, roles, workflows,

`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.

The figure demonstration script and PDF overview utility have self-tests; backup

can be verified by extracting the archive and checking its checksum

([backup and installation guidance](../mathodology-whole-project/SKILL.md)).

## Explicitly requested releases

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. The only package manifest is

Mathodology Studio's in `apps/studio/`; do not add another manifest,

application build or CI pipeline for the skills pack itself.

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

tag and release point to the intended source. GitHub's source archives are enough