Moonbit Agent Skills Maintainer

MoonBit Agent Skills maintainer

Use this skill in three modes:

• Audit: compare a MoonBit release with the repository and report gaps without changing version pins.
• Update: close every release item with evidence, update the product skills, run tests and evals, then re-pin and prepare PR data.
• Surface audit: compare the complete official language and toolchain documentation surfaces with the two product skills, close missing routes, and test high-value gaps without changing a release pin unless the compiler changed.

This workflow exists because testing only written claims cannot detect omitted knowledge, and a reference file can contain correct knowledge that agents cannot find from the main skill. Source completeness, semantic verification, and discoverability are separate checks.

Required workflow

1. Read the repository's AGENTS.md, references/release-maintenance.md, references/language-surface-maintenance.md, and references/toolchain-surface-maintenance.md completely. When a change is expected to alter activation, retrieval, or task outcomes, also read references/evaluation.md and evals/CLIENTS.md before selecting tasks or a client.
2. Start from the single official latest state: read https://cli.moonbitlang.com/version.json, re-pin the exact installed latest toolchain, resolve the current moonbitlang/moonbit-docs main commit, and run both vp run snapshot-language-surface and vp run snapshot-toolchain-surface. If a matching moonbitlang/website release article exists, also run vp run snapshot-release; an absent article never delays the product update. Never hand-author or filter a source inventory.
3. Read every generated source item. Close each exactly once in the matching coverage.json. Release decisions use verified/documented/out-of-scope/not-actionable claims and evidence; language- and toolchain-surface items use routed/out-of-scope because those inventories prove topic handling, not semantic truth.
4. For every user-visible item, search both product skills and existing evidence before classifying it. Assign one product owner and make the route explicit in that skill's Feature index, with the reference path and exact feature/diagnostic terms on one physical line.
5. Treat official documentation as a discovery source, not a compiler oracle. Inspect upstream warning configuration and run an isolated minimal POC with warnings enabled; the official local-type example is a known case that passes only because its package suppresses deprecated_syntax.
6. Add checked documentation or fixtures for language behavior, command-manifest entries or fixtures for project behavior, and explicit Documented, not executed text plus a direct source for facts the environment cannot execute.
7. Treat deprecations as migrations: remove the old recommendation, enable the warning, add --deny-warn, prove the old form is caught, and prove the replacement passes under the same settings. A documented-only deprecation still needs separate old-form and replacement evidence and the reason execution is unavailable.
8. Add a deterministic content eval for each change that materially alters agent behavior. Follow references/evaluation.md: prove the grader with correct and wrong solutions, prefer silent-semantic risks over compiler-self-correcting tasks, and start with one paired AB/BA pass on DeepSeek Pro. Add at most one second repetition, only when the current-skill cell fails or the pair is unstable; use one Kimi fallback pair only if the current-skill cell fails again. Never run a third repetition or repeat unaffected tasks. When evaluating discoverability, use a clean task that does not expose the answer through compiler diagnostics and compare the current skill with a byte-identical purpose-built ablation of the route under test; use a historical tree only when the whole historical skill is the intended variable. Report the result in two layers: a short user-facing comparison first and the complete technical evidence second.
9. Treat each skill's version as its installed content identity. Whenever files inside a skill directory change, increment metadata.skill-version using SemVer and set metadata.updated-date to the change date: patch for corrections or metadata, minor for new compatible coverage, and major for an incompatible rename or scope change. Change metadata.verified-date only after rerunning the pinned verification. Keep the public README status in sync; validate-skills checks the metadata format and README projection.
10. Run vp run verify-latest-upstream, both source-verification gates, both surface-coverage gates, and vp run check-release-coverage. In update mode, close the current language and toolchain surfaces and every published release inventory before changing fixture stamps, skill pins, or README status. When the latest compiler has no website article, the exact toolchain and documentation-surface pins remain authoritative.
11. Run the full repository check sequence from AGENTS.md, all relevant pinned targets, targeted model evals, and the required independent reviews.

Completion output

Report findings and user value, not a diary of commands. PR descriptions must contain:

• an eval summary that gives every distinct user task its own concrete row, states the number of distinct tasks, identifies the observed model, compares percentages under explicitly named conditions, and says the primary finding in one sentence; always show final task success, while activation and reference reads remain secondary evidence;
• a release coverage table with counts for verified, documented, out of scope, and not actionable;
• language- and toolchain-surface tables with official documents, headings, routed topics, and explicit boundaries when those inventories changed;
• a test table with the exact suites, cases, targets, and results;
• a short list of corrected wrong recommendations and newly prevented failure modes.

Detailed eval evidence may follow the summary, but exact counts, internal task IDs, claim IDs, condition names, repetitions, cells, grader details, token breakdowns, and statistics must not replace the user-facing result. Never label a comparison only as Baseline, count cells as tasks, or hide a task-success tie or regression behind a process metric.

An audit is complete when every relevant upstream source item has a decision and every claimed gap points to exact repository evidence. An update is complete only when the release, language-surface, and toolchain-surface completeness gates, repository tests, targeted content evals, and both reviews are finished.