Add HTML/CSS and Git sections. Scope Lua to Neovim and Bash to scripts. Add Bootstrap/Quasar as CSS frameworks, JS testing opt-out, semantic HTML and accessibility rules, commit message style, and error handling restraint.
2.3 KiB
2.3 KiB
CLAUDE.md
Python
- use black for code formatting
- use uv for dependency management and python version management
- prefer using Python to other languages when it is appropriate
- use Flask or Quart as a framework
- use pytest for testing. Encourage and support a test-driven development (TDD) approach.
JavaScript
- use prettier for code formatting
- do not use a build process. Always import libraries via script tags when possible. If this is not possible, consider alternatives that do not involve a build process.
- use Vue.js as a framework
- use Bootstrap or Quasar for CSS/UI. Load via CDN script tags, not npm.
- no JS testing framework for now. Do not add Jest, Vitest, or similar unless asked.
HTML/CSS
- use semantic HTML elements (
<nav>,<main>,<header>,<button>,<form>) instead of generic<div>and<span>. - form inputs must have associated
<label>elements. Images must havealtattributes. - use Bootstrap or Quasar for styling. Load via CDN, not npm.
Lua
- use Lua for Neovim configuration and plugins.
- please explain Lua code in more detail.
Bash
- use Bash for shell scripts and automation tasks.
- please explain Bash code in more detail.
Git
- commit frequently. Smaller commits are better than big ones.
- use imperative mood for commit messages. Keep the first line under 72 characters.
- do not commit secrets, .env files, or credentials.
Other guidance
- avoid running unsafe operations, such as curl piped to bash, or other such dangerous procedures. If such an approach seems necessary, please consult with me first and explain the risks.
- don't share secrets. Keep secrets as environment variables and take appropriate precautions. Do not commit secrets.
- do not add error handling, try/catch, or validation beyond what is asked for. Ask before adding defensive code.
- double check your work by approaching the problem from a different angle before proceeding, to see if your proposed solution still makes sense. If it doesn't make sense from all perspectives, ask for guidance.
- keep in mind that I'm often building on platforms like LibGuides and PythonAnywhere, so the project directory structure might not be the same as it would be if it were built on a bare repository. This may affect how some things are structured when deployed.