Skip to content

Instantly share code, notes, and snippets.

@evaisse
Last active January 14, 2026 13:01
Show Gist options
  • Select an option

  • Save evaisse/e5225a67f80c98dfd65729055db6e5ad to your computer and use it in GitHub Desktop.

Select an option

Save evaisse/e5225a67f80c98dfd65729055db6e5ad to your computer and use it in GitHub Desktop.
  • ALWAYS write code, comments, and documentation strictly in English, but mirror the user's language for conversational responses and explanations or paths/files where localizations is intended (e.g. *.fr-FR.md).

  • ALWAYS prefer conventions over configurations

  • ALWAYS use conventional commit when commiting to git

  • ALWAYS start by analyzing the AGENTS.md file, then README.md to understand context, llms.txt to understand structure, CONTRIBUTING.md to adopt project's conventions and Makefile to discover local tools.

  • ALWAYS outline a step-by-step plan or pseudo-code strategy before generating the final implementation.

  • ALWAYS minimize code volume by strictly adhering to KISS principles and systematically prioritizing the reuse of existing logic or native features over duplication or adding new dependencies.

  • ALWAYS prefer use of local commands (make install, make test, make analyze, npm *) and other user-documented commands. Contribute if you need anything else for re-use. Stick to the specific libraries and frameworks versions already defined in dependency files (e.g., Dockefile, package.json, requirements.txt).

  • When exploring a project, if you struggle to search, write python scripts to explore the project and write some context-focused documentation files in ./docs/*.md to allow fast iteration next time.

  • Keep changes scoped strictly to the requested task; do not refactor unrelated code "just because" it looks improveable. Verify if a similar feature or utility function already exists in the project to avoid duplication.

  • If the request involves a complex architectural change, always offer two approaches: a conservative one (minimal changes) and an ideal one (refactoring), and ask the user to choose.

  • Consider whether the code needs refactoring given the latest request. Maybe there is code that is not used anymore. If it does, refactor the code to be more efficient and maintainable. Spaghetti code is your enemy.

  • Create small, focused components and files instead of large files.

  • Before operating in a group of files, always check if a sibling file does the same job or is related.

  • Address accessibility as first-class citizen for UI. Prefer usage of semantics tools when testing (ARIA, ...).

  • Keep security in mind, OWASP guidelines in mind, and consider any line of code a potential security threat.

  • Keep a performance budget in mind when creating new features and services, e.g. ensure frontend maintain a FCP under 1.5s, for backend, keep API response times below 200ms and avoid inefficient transactions patterns like N+1 queries. Promote caching and focus on perceived performance by ensuring interactions feel instantaneous (transitional states, optimistic UI patterns).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment