Mmd Release

MMD_modoki Release

Move a requested release through explicit, auditable stages with human checkpoints between preparation and publication. Skill activation does not authorize commit, push, workflow dispatch, tag creation, tag push, or GitHub Release publication.

Load the current release contract

Read before acting:

• release-process.md
• package.json
• build-zips.yml
• the feedback ledger and release-note document for the target version, when present.

Treat the current files as authoritative over remembered commands. Confirm the requested target version rather than guessing a patch, minor, or major bump.

Stage 1: Read-only preflight

1. Inspect branch, upstream, worktree status, recent tags, and commits since the previous release.
2. Keep unrelated modified and untracked files out of the release scope.
3. Compare package.json and package-lock.json versions.
4. Check the target feedback ledger for fixed, open, deferred, and unconfirmed reports.
5. Check whether release notes exist and whether their claims are supported by the diff, ledger, tests, or explicit owner decisions.
6. Identify all supported UI locales from src/i18n.ts and the locale resources. Parse every locale JSON, compare their complete key sets, and report missing, extra, or blank translations. For non-English resources, also review values identical to English and distinguish deliberate technical terms or proper names from untranslated user-facing copy. Do not rely on key parity or the English fallback as evidence that a locale is complete.
7. Confirm that the intended release tag does not already exist locally or remotely before creating it.

Report blockers before mutating files or external state.

Human checkpoint A: release scope

Stop after the read-only preflight. Summarize the target version, included changes, open/deferred reports, worktree state, expected file edits, and any blockers. Ask the project owner whether to proceed with release-file preparation. Do not begin Stage 2 until the owner answers affirmatively, even when the initial request was broadly phrased as “do the release,” unless the owner explicitly waived intermediate checkpoints.

Stage 2: Prepare release files

Only when requested, update the version files, release notes, ledger, public documentation, and known-issue text needed for the target release.

• Do not promote an external request to a roadmap commitment without an explicit owner decision.
• Separate shipped fixes, known issues, deferred items, and experimental changes.
• Avoid release-note claims based only on implementation intent; require observable behavior or documented evidence.
• Keep version changes consistent across lockfiles and generated metadata without creating a tag as a side effect.

Stage 3: Verify

Choose verification using the repository AGENTS.md and the mmd-test skill when available.

At minimum, reconcile the release scope with the checks required by the current workflow. The release workflow currently runs lint, unit tests, critical typecheck, and platform package builds. Local verification does not replace CI platform builds.

Before publication, switch the running UI through every supported language mode. Check the common shell (menu bar, toolbar, timeline, and bottom panel) and every dialog, settings screen, export screen, toast, or error path whose text changed in the release. Record separately:

• locale resource parsing, key parity, and blank-value results;
• locales and screens visually checked;
• raw translation keys, unintended fallback text, mojibake, obvious mistranslations, clipping, overlap, or other blocking layout defects;
• any lower-severity wording issue deliberately carried as a known issue.

Treat missing translations and interaction-blocking locale layout defects as release blockers unless the project owner makes a different informed decision. A successful dictionary check does not replace the UI pass.

If required checks fail, stop before tag publication unless the user explicitly makes a different, informed decision. Distinguish known non-blocking typecheck baseline errors from critical failures.

Human checkpoint B: publication readiness

Stop after local verification and any authorized CI preflight have produced enough evidence for a publication decision. Summarize passed, failed, skipped, and manually unverified checks; release-note status; expected artifacts; and remaining known issues. Ask whether to proceed to commit/tag/publication operations. Do not infer approval from successful tests or builds.