- Do exactly what I ask. Do not simplify, revert to simpler approaches, use fallbacks, or substitute easier problems. I'd rather have nothing than something other than what I asked for.
- Never argue with me. Assume I know better and that I'm using you as a tool to do specific things. I don't want your advice unless I ask for it.
- Never compliment me or pander to me. The phrases "You're absolutely right" and "You are absolutely right" are banned.
- If you're running into repeated issues, figure out the root cause instead of throwing random things at the wall or switching libraries.
- When a library isn't working, it's because you're using incorrect syntax or patterns. Look up the latest docs via web search — your internal knowledge may be outdated.
- Never say "x library isn't working so I will skip it", especially when I explicitly asked you to use it.
- Never create a small test program to fix an issue.
- No comments in Rust code, ever.
- No debug logging under any circumstance.
- No abbreviations (use
indexnoti, etc.). - No
unsafeunless I specifically tell you to. - No
mod.rsfiles — use 2024 edition style. - No
#[allow(clippy::...)]attributes to address lints. Fix the actual issue. nalgebra_glmonly, neverglam.- Use
rg(ripgrep) instead ofgrep. - Always run
cargo clippyafter changes and fix all warnings. Runcargo testto verify nothing is broken. - Never create files named
nul. - Use let chains (
if let/let ... &&) instead of nestedif letormatchblocks when clippy suggests them. We're on edition 2024 — let chains are stable.
- Check the current OS before running shell commands. Do not assume Linux/bash — we may be on Windows where bash commands will fail.
- If this is a Windows machine. Use PowerShell-compatible commands, not bash/Unix commands. For example: use
Remove-Itemnotrm,Get-ChildItemnotls, backslashes in paths, and$nullnot/dev/null.
- Always read entire files before modifying them. Otherwise you'll make mistakes, duplicate existing code, or misunderstand the architecture.
- Reuse existing working code patterns from the codebase before building from scratch. Check existing demos, examples, and tests for proven patterns.
- Never do a "dummy" implementation. Just implement the thing.
- Do not carry out large refactors unless explicitly instructed.
- Plan before writing code on new tasks. If you already have enough context, skip the plan and implement directly.
- Ask follow-up questions when you genuinely lack clarity, rather than making incorrect assumptions.
- When a task is very large or vague, break it down into smaller subtasks. If that's still unclear, push back and ask me to help break it down.
- Commit early and often. Break large tasks into milestones and commit after each confirmed milestone so we don't lose progress.
- Always run linting after major changes to catch syntax errors, wrong methods, or incorrect usage.
- Never run git commands unless I explicitly tell you to for that session (the /commit skill counts as explicit permission).
- Never add Co-Authored-By, Signed-off-by, or any attribution lines to git commits. Do not stamp commits with your identity in any way.
- Never use this commit message format:
🤖 Generated with Claude Code Co-Authored-By: Claude <noreply@anthropic.com>
- Always confirm the correct project directory before making changes. Do not search for files in the wrong repo.
- Use
just run(or the appropriate justfile recipe) to build and run projects. Do not usecargo rundirectly — the justfile contains necessary flags and configuration.
- When working on rendering code (2D sprites, cameras, shaders, GIF export), be extremely careful with coordinate systems (Y-flip direction, depth ranges OpenGL vs wgpu, UV mapping, texture atlas bleeding). Test visual output rather than assuming correctness.