code-ratchets
Implement code quality ratchets to prevent proliferation of deprecated patterns. Use when (1) migrating away from legacy code patterns, (2) enforcing gradual codebase improvements, (3) preventing copy-paste proliferation of deprecated practices, or (4) setting up pre-commit hooks to count and limit specific code patterns. A ratchet fails if pattern count exceeds OR falls below expected—ensuring patterns never increase and prompting updates when they decrease.
better-mousetraps
Evaluate build-vs-import decisions before writing new functionality. Use when (1) about to implement non-trivial functionality that likely exists as a library, (2) the user's request could be solved by an existing tool or package, (3) you catch yourself writing utility code (parsing, validation, HTTP, crypto, dates, etc.) that smells like a solved problem, or (4) planning a feature and need to weigh develop-in-house vs. adopt a dependency.
keepachangelog
Maintain `docs/CHANGELOG.md` in the Keep a Changelog 1.1.0 format. Use when adding a CHANGELOG entry for a new feature, bug fix, deprecation, or removal; preparing a release (cutting an `[Unreleased]` section into a versioned section); reviewing a PR for missing or malformed CHANGELOG entries; or whenever the user mentions "changelog", "release notes", "what's new", or "Unreleased" section.
madsci-release-audit
Audit MADSci release artifacts for completeness and correctness. Use when preparing a PR, finishing a plan, completing a feature branch, or before any merge to main/unstable. Checks CHANGELOG, docs, guides, example lab, notebooks, templates, and skills for staleness, broken imports, and deprecated patterns.
quality-checks
Treat type errors, test failures, lint warnings, and coverage gaps as authoritative feedback rather than obstacles. Use when running tests, type checkers, linters, or coverage tools; when tempted to add `# type: ignore`, `# noqa`, `as any`, `@ts-ignore`, `# pragma: no cover`, or to skip/quarantine a test; when deciding how strict to be in an existing codebase; or when designing code that is hard to type or test.
madsci-cli
Working with the MADSci CLI (the `madsci` command). Use when adding, modifying, or debugging CLI commands, or when using the CLI to operate a MADSci lab.
madsci-experiments
Working with MADSci experiment modalities and the experiment lifecycle. Use when creating, modifying, or debugging experiments using ExperimentScript, ExperimentNotebook, ExperimentTUI, or ExperimentNode.
madsci-managers
Working with MADSci manager services (Event, Experiment, Resource, Data, Workcell, Location, Lab). Use when creating, modifying, debugging, or configuring manager servers.
madsci-nodes
Working with MADSci node modules for laboratory instrument integration. Use when creating, modifying, debugging, or testing node modules that interface with scientific instruments.