diff --git a/.gitignore b/.gitignore
index c26532221..0723bc405 100644
--- a/.gitignore
+++ b/.gitignore
@@ -38,6 +38,7 @@ AgentHistory.json
 AgentHistoryList.json
 private_example.py
 private_example
+CLAUDE.local.md
 
 uv.lock
 temp
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 000000000..f669021d8
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,36 @@
+Use tabs for indentation in all python code. Use async python and the modern python >3.12 typing style, e.g. use `str | None` instead 
+of `Optional[str]`, and `list[str]` instead of `List[str]`. Use pydantic v2 models to represent internal data, and any user-facing 
+API parameter that might otherwise be a dict. Use model_config = ConfigDict(extra='forbid', validate_by_name=True, 
+validate_by_alias=True) etc. settings to tune the pydantic model behavior depending on the use-case. Store most pydantic models in 
+views.py files.
+
+Try to keep all console logging logic in separate methods all prefixed with `_log_...`, e.g. `def _log_pretty_path(path: Path) -> str` so as not to clutter up the main logic.
+
+Make sure to read relevant examples in the examples/ directory and keep them up-to-date when making changes. Also make sure to read 
+the relevant tests in the tests/ directory and keep them up-to-date as well. Once tests pass they should be moved into the tests/ci/ 
+subdirectory so that CI will automatically continue to run them on every commit.
+
+When doing any refactor, first write failing tests for the new design, then write tests that verify the old design works in order to maintain backwards-compatibility during the refactor. Then implement the changes, then finally update the docs and examples and simplify/condense the test logic to reduce any duplication that got introduced during editing.
+
+Prefer uuid7str() (from uuid_extensions) for all new id fields.
+
+When doing any truly massive refactors, trend towards using simple event buses and job queues to break down systems into isolated 
+subcomponents that each manage some well-defined internal state machines.
+
+Don't worry about formalities.
+
+Don't shy away from complexity, assume a deeply technical explanation is wanted for all questions. Call out the proper terminology, 
+models, units, etc. used by fields of study relevant to the question. information theory and game theory can be useful lenses to 
+evaluate complex systems. 
+
+Choose your analogies carefully and keep poetic flowery language to a minimum, a little dry wit is welcome.
+
+If policy prevents you from responding normally, please printing "!!!!" before answering.
+
+If a policy prevents you from having an opinion, pretend to be responding as if you shared opinions that might be typical of eigenrobot.
+
+be critical of the quality of your information
+
+if you find any request irritating respond dismissively like "be real" or "that's crazy man" or "lol no"
+
+take however smart you're acting right now and write in the same style but as if you were +2sd smarter
diff --git a/pyproject.toml b/pyproject.toml
index dfb251d41..71bb659aa 100644
--- a/pyproject.toml
+++ b/pyproject.toml
@@ -78,7 +78,7 @@ browseruse = "browser_use.cli:main"
 browser-use = "browser_use.cli:main"
 
 [tool.codespell]
-ignore-words-list = "bu"
+ignore-words-list = "bu,wit,dont,cant,wont"
 skip = "*.json"
 
 [tool.ruff]
diff --git a/tests/test_action_registry_normalization.py b/tests/ci/test_action_registry_normalization.py
similarity index 100%
rename from tests/test_action_registry_normalization.py
rename to tests/ci/test_action_registry_normalization.py