bench-maintain

Maintains the nu-validator coverage benchmark by defending invariants across upstream updates and markuplint changes.

611|63|Updated Sep 26, 2017
One-click install
npx skills add https://github.com/markuplint/markuplint --skill bench-maintain
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: bench-maintain
Source: https://github.com/markuplint/markuplint/tree/main/.claude/skills/bench-maintain
Command: npx skills add https://github.com/markuplint/markuplint --skill bench-maintain

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Once the nu-validator coverage backlog reaches zero, the benchmark enters steady state where upstream submodule bumps, Docker image drift, and markuplint rule changes can silently break invariants. This Skill provides the maintenance loop that keeps nu-only entries at zero, exclusions tracked, and issue mappings green.

Core Features & Use Cases

  • Invariant Defense: Verifies after every refresh that nu-only.json is empty, excluded-ids entries cite specs and open tracking issues, xref audits pass, and nu ran clean.
  • Upstream Update Follow-up: Classifies new nu-only entries after a submodule bump or engine digest change into new fixtures, stale exclusions, or markuplint regressions, each with a defined owner action.
  • Regression Checking: Runs bench:update:ml and bench:compare after rule, spec, or parser changes to confirm no coverage was lost.
  • Use Case: After bumping the tests/external/validator submodule and running yarn bench:update, use this Skill to diff meta.json, triage any new nu-only entries, re-pin stale exclusion hashes, and commit the snapshot updates.

Quick Start

Run a full nu-validator bench refresh after the submodule update and verify all invariants before committing the snapshot changes.

Frequently Asked Questions about bench-maintain

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update the nu-validator benchmark after an upstream release?

Run git submodule update --remote tests/external/validator, then yarn bench:update to pull the current Docker engine. Diff snapshots/diff/meta.json to see which axis moved, classify any new nu-only entries, verify invariants, and commit the snapshot changes.

What should I do when new nu-only entries appear after a bench refresh?

Classify each entry into one of three causes: a new upstream fixture or check (run bench-triage), a stale per-id exclusion (re-pin the new message hash), or a markuplint regression (fix the responsible rule, never exclude). Each cause has a defined owner action.

How do I check for markuplint regressions without Docker?

Run yarn bench:update:ml followed by yarn bench:compare after a rule, spec, or parser change. nu-only.json must stay empty, and every change in the ml-only path set must be explained by the change under test before committing.

Why did a pattern-based exclusion stop matching after a nu update?

Pattern exclusions fail silently when nu changes message wording, flipping the fixture verdict without any nu-only reappearance. Check the nu-over headcount against expected counts recorded in pattern reason fields and re-verify deferred spec counts.

When should I run a full bench health check?

The xref audit runs automatically on relevant PRs and weekly cron, but upstream drift has no automation. Schedule a full nu update follow-up periodically, at the latest before each release, since the engine follows the :latest Docker tag.