pybasin

Write and review Python documentation using Sphinx/rST style docstrings for mkdocstrings. Use when writing docstrings, documenting classes, methods, or reviewing documentation for proper formatting.

Apply clean-code heuristics when reviewing or writing code. Use when: spotting duplicate branches, fixing API contracts that push work onto callers, simplifying conditionals, or identifying structural smells that make code hard to extend.

Design or review pybasin experiments and benchmarks where measurement structure matters. Use when creating or fixing notebooks or scripts for solver, trajectory, or feature-extraction comparisons and you need to choose `JaxSolver` save semantics (`t_span`, `t_steps`, `t_eval`), decide what should be integrated once and reused versus reintegrated per batch size, keep hot paths batched, reuse expensive benchmark artifacts across notebook cells, or report results in one decision-focused table without duplicated summaries.

Write and revise documentation (Markdown, prose sections) so that the text reads naturally and avoids patterns commonly flagged as AI-generated. Use when creating or editing .md files, case study pages, README sections, or any prose-heavy documentation.

Rework a tstorch calculator domain as one coherent migration - make every feature in that domain faster than tsfresh's CPU implementation, keep numerical output identical, confirm torch.compile(fullgraph=True)/torch.export safety, lock all of that in with regression tests and Google-style docs, and wire the domain into TorchFeatureExtractor's SUPPORTED_FEATURES in a clean way. Use when fixing a calculator file under packages/tstorch/src/tstorch/calculators/, adding a new domain, or working through batched-migration-wip.md's 'Not started' list.