Initial commit

commands/prime.md

@@ -0,0 +1,20 @@
+# Prime the context by analyzing the project structure
+
+Use the command `lsd --tree` to get an overview of the project's code structure. In addition,
+
+- Read the `README.md` if exist
+- Read the `flake.nix` if exist
+- Files which you think are important
+  - For python project, read `pyproject.toml` if exist
+  - For javascript and typescript project, read `package.json` if exist
+  - For rust project, read `Cargo.toml` if exist
+  - For c++ project read `CMakeLists.txt` and use it as the entrypoint to understand the project structure
+
+## Goal
+
+You should be able to tell the following 
+
+- The structure of the project
+- What problem does this project solve?
+- What are the major programming languages used in this project?
+- What is the entrypoint of this project?

commands/python-ready.md

@@ -0,0 +1,36 @@
+# Prepare CLAUDE CODE with Python-Specific Context
+
+## Task
+Read the project’s `CLAUDE.md`. Ensure all Python rules below are present. If partially present, reorganize and edit `CLAUDE.md` so all rules are included exactly and unambiguously.
+
+## Python Rules
+
+### Environment
+1. Manage the dev environment with `flake.nix` only.
+2. Assume `nix develop` is active.
+3. Do not use `pip`, `uv`, or `poetry`.
+4. Run programs as modules: `python -m package.module`.
+
+### Library Preferences
+1. Use builtin **unittest**.
+   - Discover all tests: `python -m unittest discover`
+   - Run verbose/specific: `python -m unittest -v path/to/test_file.py`
+2. Use **pydantic v2** for schemas and domain models.
+3. Use **PyTorch** and **JAX** for ML models.
+4. Use **loguru** for logging.
+5. Use **click** for CLI/arg parsing.
+6. Prefer **pathlib** over `os.path`.
+7. Use explicit `StrEnum` / `IntEnum` for enums.
+
+### Code Style
+1. **Use absolute imports**; do not use relative imports (e.g., avoid `from .x import y`).
+2. Prefer specific imports (e.g., `from pydantic import BaseModel`).
+3. **Use type hints everywhere**:
+   - Annotate all function parameters and return types.
+   - Use builtin generics (`list`, `dict`, `tuple`) instead of `typing.List`, etc.
+   - For optionals, use `MyType | None` instead of `Optional[MyType]`.
+
+### Documentation
+1. **Write docstrings for all public modules, functions, classes, methods**, and public-facing APIs. PEP 8 and PEP 257 recommend docstrings for all public elements.
+2. In docstrings:
+   - **Do not include types in the `Args:` section**, type hints in signatures cover that.

commands/web-ready.md

@@ -0,0 +1,39 @@
+# Prepare CLAUDE CODE with Web Development Context
+
+## Task
+
+Read the project’s `CLAUDE.md`. Ensure all web development rules below are present. If some are missing or partially present, reorganize and update `CLAUDE.md` so every rule is included clearly and unambiguously.
+
+## Web Development Rules
+
+### Language & Syntax
+
+1. Use **TypeScript** only (no plain JavaScript).
+2. Omit unnecessary semicolons—that is, do not add semicolons at statement ends unless required.
+3. Prefer **arrow functions** (`const f = () => ...`) for concise, inline code and callbacks. Use **function declarations** for named or top-level functions where `this` or hoisting matters.
+
+### Typing & Imports
+
+1. Always use **explicit types**, especially for function parameters and return values. Annotate returns and arguments when it improves readability.
+2. Avoid `any`. Use `unknown` or properly constrained generics instead—`unknown` forces safe type narrowing.
+3. Organize imports in this order:
+
+   * `react`
+   * third-party libraries
+   * local modules
+4. Support **absolute imports** in `.ts`/`.tsx` files, e.g.:
+
+   ```ts
+   import '@/components/MarkdownPreviewPanel'
+   ```
+
+   resolves to `src/components/MarkdownPreviewPanel.tsx`.
+
+### React & Components
+
+- In React components, always **destructure `props`** directly in function parameters.
+- Keep `README.md` updated with essential information about React components—especially view or UI-related ones.
+
+### Documentation
+
+- Document important functions, classes, and React components with inline docstrings or comments for clarity and maintainability.