dotfiles/CLAUDE.md

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. Always use the /pytest skill when writing Python
• use the python-dotenv library for environment variables

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.
• do not use var constructions in most circumstances. Prefer let and const.

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 have alt attributes.
• 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, credentials, or anything that may seem sensitive

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.