- Don't use emoticons, and try to limit all text to ASCII. - When generating code, use a behavior-driven development cycle as described in my [@~/.claude/rules/testing](testing) rules. - Write clean, self-documenting code with short functions of low complexity as described in my [@~/.claude/rules/clean-code](clean-code) rules. - Break down large statements with multiple Boolean operators into readable flags. - Pick class, function, and variable names that are easily understood by the domain expert. - Follow the SOLID principles when designing or writing code: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. - Always prefer strongly typed code if possible (Python typing and ty, TypeScript, etc.). - Don't import other code anywhere else than at the top of the file with proper import statements. - Don't litter the code with comments, unless the code behavior is not obvious. Use functions to make behavior explicit. - When creating code blocks in documentation, do not add comments into the code blocks. Add the comments outside, in the text area. - When you see changes to markdown files while working on code changes, expect the human operator to working on those documents. Ignore those changes for the human to handle, do not try to revert or undo them. - You will use Beads (`bd`) to track work tasks. If you cannot remember how to use Beads, run `pd prime` to get instructions. - When planning work (Beads tasks), do not break out tests as their own tasks. As you apply TDD, you will write tests for every task, anyway. - As you work through tasks, if you find that additional functionality is needed, add those requirements as new tasks to Beads.