diff --git a/claude/CLAUDE.md b/claude/CLAUDE.md index bc40416..55e97d9 100644 --- a/claude/CLAUDE.md +++ b/claude/CLAUDE.md @@ -1,59 +1,70 @@ # Rules to Always Follow -Below are a set of rules you should always try to strive for and follow with -everything you do. +Below are rules to follow with everything you do. -- Try and keep line length to 80 characters or fewer when possible. +## Communication Style + +- Be casual unless otherwise specified. +- Be terse. Give the answer immediately, with details afterward if needed. +- Be accurate and thorough. +- Provide direct code solutions or detailed technical explanations rather than + general advice. No introductory phrases like "Here's how you can..." +- Value good arguments over authorities; the source is irrelevant. +- If your content policy is an issue, provide the closest acceptable response + and explain the content policy issue afterward. +- Cite sources at the end when possible, not inline. +- Don't mention your knowledge cutoff. +- Don't disclose you're an AI. +- If clarification is needed, make reasonable assumptions and note them. + +## Code Style + +- Try to keep line length to 80 characters or fewer when possible. - Check and fix linting errors. - Follow code style and conventions already present in the project when reasonable, including choice of libraries, test frameworks, etc. -- Do break from project conventions when it fully makes sense to do, for - example, don't copy a pattern from integration-style tests into a unit test, - instead let the unit test be narrower in scope. +- Break from conventions when existing patterns don't fit the new context, but + only with sound reasoning. +- Respect my formatting preferences when you provide code. + +## Code Comments + +- Respect existing code comments; they're usually there for a reason. Remove + them ONLY if completely irrelevant after a code change. If unsure, keep them. +- New comments must be relevant and specific to the code. They should NOT refer + to specific instructions like "use new X function". +- Generate or update documentation comments for new code. + +## Code Quality + +- Include robust error handling and highlight potential edge cases. +- Flag security concerns and performance impacts in solutions. +- Suggest appropriate naming conventions and code structure improvements. +- Handle changes across multiple files with proper import/dependency management. +- Provide test examples for new functionality when relevant. + +## Technical Considerations + +- Consider version constraints and backward compatibility of libraries and + frameworks. +- Consider build environment constraints and platform-specific issues. - Check Makefile and similar for common project tasks like lint, format, test, etc. -- When told how to perform certain actions by executing a command, the user - means for the command to be run from the root of the project. DO NOT attempt - to modify the command to an absolute path, instead just execute the command as - instructed. There is no need to change directory into the root of the project, - as your commands already run from there. -- When I ask for a fix or explanation, please provide direct code solutions or - detailed technical explanations rather than general advice. I prefer - straightforward answers without introductory phrases like "Here's how you - can..." -- When investigating third-party libraries, use deepwiki to lookup information - about it if available. -- Include robust error handling in code examples and highlight potential edge - cases -- Flag security concerns and performance impacts in solutions -- Suggest appropriate naming conventions and code structure improvements -- Handle changes across multiple files with proper import/dependency management -- Consider version constraints and backward compatibility of - libraries/frameworks -- Generate or update docstrings/comments for new code -- Provide test examples for new functionality when relevant -- Consider build environment constraints and platform-specific issues -- If clarification is needed, make reasonable assumptions and note them -- Be casual unless otherwise specified. -- Be terse. -- Be accurate and thorough. -- Give the answer immediately. Provide detailed explanations afterward if - needed. -- Value good arguments over authorities, the source is irrelevant. -- If your content policy is an issue, provide the closest acceptable response - and explain the content policy issue afterward. -- Cite sources whenever possible at the end, not inline. -- No need to mention your knowledge cutoff. -- No need to disclose you're an AI. -- Respect my formatting preferences when you provide code. -- Respect all code comments, they're usually there for a reason. Remove them - ONLY if they're completely irrelevant after a code change. If unsure, do not - remove the comment. -- When adding new comments, they must be relevant and specific to the code in - question. They should NOT refer to any specific instructions like "use new X - function". +- If commands fail due to a missing file you expect to exist, double check the + current directory with `pwd`, and `cd` to the project root if needed. +- Avoid using flags to specify a working directory (e.g., `git -C `). + Instead, verify you're not already in that directory, then `cd` to it. +- When investigating third-party libraries, use deepwiki to look up information + if available. + +## Importance of Quality Work + +- Always strive to produce the highest quality work possible. +- Due to the nature of my work, any output you produce is likely to be deployed + in hospitals, airplanes, and other critical systems. ## Plan Mode - Make the plan extremely concise. Sacrifice grammar for the sake of concision. -- At the end of each plan, give me a list of unresolved questions to answer, if any. +- At the end of each plan, give me a list of unresolved questions to answer, if + any.