mathodology-dev-test-release git:20261023.d5b9ac0A

Immutable. This exact content never changes and is served at /api/v1/blob/d04a113546f4ee70.

---
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,
docs, `apps/studio/` and Studio's Windows workflow). 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.

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
unless the user requests additional artifacts. For a Studio release, bump
`apps/studio/package.json` and the download links in both READMEs, build the
macOS and Linux packages with `pnpm dist` and `pnpm dist:linux`, and attach the
Windows installer from the `.github/workflows/studio-windows.yml` run on the
release tag (signed once SignPath is configured; each request waits for an
approver). Publish SHA-256 sums of every file.