Skip to content

Instantly share code, notes, and snippets.

@matthewjberger
Last active February 23, 2026 20:18
Show Gist options
  • Select an option

  • Save matthewjberger/f44da4d3df10f77aa468ce7b812f34e6 to your computer and use it in GitHub Desktop.

Select an option

Save matthewjberger/f44da4d3df10f77aa468ce7b812f34e6 to your computer and use it in GitHub Desktop.

Behavior

  • 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.

Rust

  • No comments in Rust code, ever.
  • No debug logging under any circumstance.
  • No abbreviations (use index not i, etc.).
  • No unsafe unless I specifically tell you to.
  • No mod.rs files — use 2024 edition style.
  • No #[allow(clippy::...)] attributes to address lints. Fix the actual issue.
  • nalgebra_glm only, never glam.
  • Use rg (ripgrep) instead of grep.
  • Always run cargo clippy after changes and fix all warnings. Run cargo test to verify nothing is broken.
  • Never create files named nul.
  • Use let chains (if let / let ... &&) instead of nested if let or match blocks when clippy suggests them. We're on edition 2024 — let chains are stable.

Platform

  • 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-Item not rm, Get-ChildItem not ls, backslashes in paths, and $null not /dev/null.

Code Quality

  • 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.

Workflow

  • 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.

Git

  • 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>
    

Projects

  • 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 use cargo run directly — the justfile contains necessary flags and configuration.

Rendering

  • 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment