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.
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.
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.
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.
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.
Working with MADSci manager services (Event, Experiment, Resource, Data, Workcell, Location, Lab). Use when creating, modifying, debugging, or configuring manager servers.
Working with MADSci node modules for laboratory instrument integration. Use when creating, modifying, debugging, or testing node modules that interface with scientific instruments.
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.