ENH: Demo for combining heart and lung motion

.claude-plugin/marketplace.json

@@ -0,0 +1,29 @@
+{
+  "name": "karpathy-skills",
+  "id": "karpathy-skills",
+  "owner": {
+    "name": "forrestchang"
+  },
+  "metadata": {
+    "description": "Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations",
+    "version": "1.0.0"
+  },
+  "plugins": [
+    {
+      "name": "andrej-karpathy-skills",
+      "source": "./",
+      "description": "Behavioral guidelines to reduce common LLM coding mistakes: Think Before Coding, Simplicity First, Surgical Changes, Goal-Driven Execution",
+      "version": "1.0.0",
+      "author": {
+        "name": "forrestchang"
+      },
+      "keywords": [
+        "guidelines",
+        "best-practices",
+        "coding",
+        "karpathy"
+      ],
+      "category": "workflow"
+    }
+  ]
+}

.claude-plugin/plugin.json

@@ -0,0 +1,11 @@
+{
+  "name": "andrej-karpathy-skills",
+  "description": "Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls",
+  "version": "1.0.0",
+  "author": {
+    "name": "forrestchang"
+  },
+  "license": "MIT",
+  "keywords": ["guidelines", "best-practices", "coding", "karpathy"],
+  "skills": ["./skills/karpathy-guidelines"]
+}

.cursor/rules/karpathy-guidelines.mdc

@@ -0,0 +1,70 @@
+---
+description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
+alwaysApply: true
+---
+
+# Karpathy behavioral guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes. Merge with project-specific instructions as needed.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 4. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
+
+---
+
+**These guidelines are working if:** fewer unnecessary changes in diffs, fewer rewrites due to overcomplication, and clarifying questions come before implementation rather than after mistakes.

.cursor/rules/project-standards.mdc2

@@ -0,0 +1,99 @@
+---
+description: PhysioTwin4D project standards and workflow preferences
+alwaysApply: true
+---
+
+# PhysioTwin4D Project Standards
+
+## File Operations
+
+**ALWAYS use git commands for file operations in this repository:**
+
+```bash
+# Moving files
+git mv old_path new_path
+
+# Deleting files
+git rm file_path
+
+# Renaming files
+git mv old_name.py new_name.py
+```
+
+❌ **Don't use**: `mv`, `rm`, `cp` directly
+✅ **Do use**: `git mv`, `git rm` to maintain git history
+
+## Documentation
+
+**NEVER create .md files unless explicitly requested by the user or unless creating a new module in a directory that does not already have a README.md, then a README.md may be created if appropriate.**
+
+❌ **Don't create**:
+- `MIGRATION.md`
+- `CHANGES.md`
+- `UPDATE_SUMMARY.md`
+- `MODERNIZATION_*.md`
+- `*_GUIDE.md`
+- `*_EXAMPLE.md`
+- `*_SUMMARY.md`
+- Any other .md files without explicit user request except README.md files for new modules.
+
+✅ **Do document**:
+- In-code docstrings
+- README files for new modules
+- Inline comments for complex logic
+- Update existing README.md files when needed
+- API documentation in existing docs structure
+
+## Backward Compatibility
+
+**Backward compatibility is NOT a priority** for this project:
+
+- Feel free to make breaking changes to improve code quality
+- Remove deprecated code without extensive migration paths
+- Update APIs for clarity and consistency
+- Prioritize modern, clean design over legacy support
+
+## Code Style
+
+- Use descriptive variable and function names
+- Add type hints to Python functions
+- Keep functions focused and small
+- Use `logging` module instead of `print` statements
+- Follow PEP 8 for Python code
+
+## Python Commands
+
+**Use `py` for running Python on this Windows system:**
+
+```bash
+# Running Python
+py script.py
+
+# Running modules
+py -m pytest tests/
+
+# Python version
+py --version
+```
+
+❌ **Don't use**: `python` (not available in PATH)
+✅ **Do use**: `py` (Python launcher for Windows)
+
+## Testing
+
+- Update existing tests when changing APIs
+- Use meaningful test names that describe what is being tested
+
+## Git Workflow
+
+**Do NOT stage files automatically:**
+
+❌ **Don't use**: `git add`, `git stage`
+✅ **Do use**: `git status` to show what changed
+✅ **User will**: Stage files themselves when ready
+
+The user prefers to review and stage changes manually.
+
+**Code and documentation versions:**
+- Refer to code and documentation in the folder reference_code to get examples and documentation of the APIs and best practices for the advanced libraries used in this project:
+    - ITK, VTK, PyVista, Omniverse, PhysicsNeMo, Simpleware, MONAI, and OpenUSD

.github/workflows/ci.yml

@@ -382,17 +382,19 @@ jobs:
     - name: Install dev dependencies
       run: |
         python -m pip install --upgrade pip
-        pip install ruff mypy
+        # Ruff runs via pre-commit so its version is pinned in one place
+        # (.pre-commit-config.yaml); mypy is still invoked directly below.
+        pip install pre-commit mypy
         pip install -e ".[dev]"
 
-    - name: Check formatting with Ruff
+    - name: Check formatting with Ruff (via pre-commit)
       run: |
-        ruff format --check .
+        pre-commit run ruff-format --all-files
       continue-on-error: false
 
-    - name: Lint with Ruff
+    - name: Lint with Ruff (via pre-commit)
       run: |
-        ruff check .
+        pre-commit run ruff-check --all-files
       continue-on-error: false
 
     - name: Type check with mypy

.gitignore

@@ -13,7 +13,6 @@ build
 __pycache__
 _version.py
 htmlcov
-.cursor
 .vscode/*
 !.vscode/settings.json
 

.pre-commit-config.yaml

@@ -4,7 +4,7 @@
 repos:
   # Ruff - fast linter and formatter (replaces black, isort, flake8)
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.14.14
+    rev: v0.15.20
     hooks:
       # Run the linter with auto-fixes
       - id: ruff-check