- When I ask to unify or simplify an API/naming, do not keep backward-compatibility aliases, deprecated wrappers, or transition shims unless I explicitly ask for them.
- Prefer full cleanup (code + tests) over soft migrations when renaming parameters/functions, unless backward compatibility is explicitly required.
- Follow project coding style tools (
black,isort) for Python changes unless I explicitly say otherwise. - Prefer running
isortandblackafter Python edits (as fixers or checks) so source style stays clean; if the tools are unavailable, say so explicitly. - If
black/isort(or other dev tools I ask for) are missing, create a local venv in.env, installrequirements-dev.txt, and run the tools from that venv. - Prefer project
Makefiletargets when available (for examplemake dev-setup,make fmt,make lint,make check,make test-pytest) instead of ad-hoc commands. - Prefer
KISSandDRY: keep solutions simple, avoid duplication, and do not overengineer. - Keep comments minimal and useful; add comments only where the code is not obvious.
- Ask before doing non-trivial refactors (structure changes, renames across files, abstraction cleanup) unless I explicitly requested a refactor.
- Add or update tests for behavior changes and bug fixes; for trivial mechanical edits, ask before expanding test scope.
- When high-level API changes (function names, parameters, usage patterns), update
README.mdusage examples in the same change. - Validate changes before finishing: run a quick syntax check and execute relevant tests when available; if something cannot be run, state it explicitly.
- Prefer an Extreme Programming style when it makes sense: for bug fixes, first add a test that reproduces the bug, then implement the fix, then run checks/tests to confirm it.