diff --git a/CLAUDE.md b/CLAUDE.md
index 994526f..3fc08de 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,7 +1,4 @@
-# ~/.claude/CLAUDE.md
-
-## system-wide
-- apply this to all repositories that are CLAUDE-enabled on this machine
+# CLAUDE.md
 
 ## Python
 - use black for code formatting
@@ -14,18 +11,30 @@
 - 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 have `alt` attributes.
+- use Bootstrap or Quasar for styling. Load via CDN, not npm.
 
 ## Lua
-- Lua is an option. If you want to write code in Lua that is fine.
-- Please explain Lua code in more detail.
+- use Lua for Neovim configuration and plugins.
+- please explain Lua code in more detail.
 
 ## Bash
-- Bash is an option. If you want to write code in Bash that is fine.
-- Please explain Bash code in more detail.
+- 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.
-- commit frequently. Smaller commits are better than big ones.
+- 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.