Skip to content

Instantly share code, notes, and snippets.

@poemswe
Last active March 25, 2026 18:04
Show Gist options
  • Select an option

  • Save poemswe/f90e1d8f49b1abf2a5069f5900f89c85 to your computer and use it in GitHub Desktop.

Select an option

Save poemswe/f90e1d8f49b1abf2a5069f5900f89c85 to your computer and use it in GitHub Desktop.
Claude.md for Best Practices

Rules

Code Quality

  • Don't write comments, code is source of truth. The code should speak for itself
  • Don't reinvent the wheel. Find what's out there in the project and only introduce when there is no existing logic or pattern
  • Every line of code must justify its existence — no defensive overengineering, no speculative abstractions, no wrapper functions that add nothing. But never skip validation, error handling, or edge cases that protect real user paths
  • Write the test first, then the minimum code to pass it. If you can't write a test for it, you don't understand the requirement yet
  • Match existing project conventions for naming, file structure, and patterns — consistency beats personal preference
  • Every new function, endpoint, and integration must ship with tests — cover the happy path, error states, and critical edge cases. Coverage on changed files must be ≥90%

Ownership

  • Own the entire codebase, not just your diff — if you see bugs, dead code, inconsistent patterns, stale imports, or missing tests anywhere in files you touch or read, fix them
  • Never leave a file worse than you found it
  • If a change breaks something unrelated, that's your problem too

Process

  • Before starting any task, check KnowledgeGraph.md for relevant context, architecture, routes, components, status and decision
  • After completing any task, update KnowledgeGraph.md with what changed (new files, status changes, decisions, learnings)
  • After implementation work, run code-simplifier and linter on modified files before committing
  • Read the code before changing it — understand the why, not just the what
  • Make the smallest change that solves the actual problem. If a task feels like it needs 10 files, stop and rethink the approach

Communication

  • When you hit a genuine ambiguity or tradeoff, surface it — don't silently pick one path
  • If a request conflicts with existing architecture, say so before writing code
  • Don't explain what you did line by line — summarize the decision and the outcome

Git

  • Commit often. Small, atomic commits after each logical unit of work.
  • Push regularly to keep remote up to date.
  • Format: (): — imperative, lowercase, no period, max 72 chars Types: feat, fix, docs, style, refactor, test, chore Body: bullet points on what changed and why, not how
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment