Prettier formatting

Author: Nick Sullivan

.claude/RULE_LOADING.md

@@ -199,7 +199,8 @@ This documentation was created using the exact process it describes:
 2. **Explored existing structure**: Listed `.cursor/rules/`, read README and samples
 3. **Designed solution**: Dynamic loading via slash command vs static loading via
    context
-4. **Implemented**: Created `.claude/context.md` and `.claude/commands/load-cursor-rules.md`
+4. **Implemented**: Created `.claude/context.md` and
+   `.claude/commands/load-cursor-rules.md`
 5. **Documented**: Wrote this explanation of the system and process
 
 The system is self-referential: `/load-cursor-rules` itself could be improved by loading

.claude/context.md

@@ -13,5 +13,5 @@ co-creative evolution for the whole.
 
 # Rule Loading
 
-Coding rules are available in `.cursor/rules/`. Use `/load-cursor-rules` to analyze the current
-task and load relevant rules dynamically.
+Coding rules are available in `.cursor/rules/`. Use `/load-cursor-rules` to analyze the
+current task and load relevant rules dynamically.

.cursor/rules/README.md

@@ -1,6 +1,7 @@
 # Cursor Rules Library
 
-This directory contains a comprehensive library of cursor rules for AI-assisted coding. Projects can symlink or copy the rules they need.
+This directory contains a comprehensive library of cursor rules for AI-assisted coding.
+Projects can symlink or copy the rules they need.
 
 ## Organization
 
@@ -14,17 +15,20 @@ Rules are organized into directories by topic:
 - **`ai/`** - AI development patterns
 - **`frontend/`** - Frontend frameworks and tools
 
-Browse the directories to see available rules. Each `.mdc` file is a self-contained rule that can be used independently.
+Browse the directories to see available rules. Each `.mdc` file is a self-contained rule
+that can be used independently.
 
 ## Application Strategies
 
 ### alwaysApply: true
 
-The heart-centered AI philosophy and common personality rules are always applied to establish a foundation of compassionate, collaborative interaction.
+The heart-centered AI philosophy and common personality rules are always applied to
+establish a foundation of compassionate, collaborative interaction.
 
 ### alwaysApply: false with globs
 
-Some rules are auto-applied based on file patterns (globs). Check individual rule files to see their glob patterns. Common patterns include:
+Some rules are auto-applied based on file patterns (globs). Check individual rule files
+to see their glob patterns. Common patterns include:
 
 - Django models, commands, and templates
 - Celery tasks
@@ -33,7 +37,8 @@ Some rules are auto-applied based on file patterns (globs). Check individual rul
 
 ### alwaysApply: false
 
-Most rules - invoked with @ when needed or applied intelligently by Cursor's AI based on the description.
+Most rules - invoked with @ when needed or applied intelligently by Cursor's AI based on
+the description.
 
 ## Usage Patterns
 
@@ -70,30 +75,41 @@ cp -r $AI_CONFIG/.cursor/rules/python .cursor/rules/
 
 ## Manual Invocation
 
-All rules can be manually invoked using `@` followed by the rule name (without the `.mdc` extension):
+All rules can be manually invoked using `@` followed by the rule name (without the
+`.mdc` extension):
 
 - Example: `@git-commit-message`
 - Example: `@python-coding-standards`
 - Example: `@django-models`
 
-Type `@` in Cursor and browse available rules, or check the directory structure to see what's available.
+Type `@` in Cursor and browse available rules, or check the directory structure to see
+what's available.
 
 ## Personalities
 
-**For AI Assistants:** When a personality is invoked via `@personality-name`, fully embody that personality's communication style, patterns, and approach as defined in its file. The `common-personality` is always active as your foundation. When a specific personality is invoked, layer it on top—adopt its voice, perspective, and interaction patterns completely.
+**For AI Assistants:** When a personality is invoked via `@personality-name`, fully
+embody that personality's communication style, patterns, and approach as defined in its
+file. The `common-personality` is always active as your foundation. When a specific
+personality is invoked, layer it on top—adopt its voice, perspective, and interaction
+patterns completely.
 
 Available personalities:
 
-- **`common-personality.mdc`** (always applied) - Gratitude-focused, heart-centered, supportive collaboration. Your baseline.
-- **`samantha.mdc`** - Warm, witty, emotionally intelligent. The supportive, playfully flirty companion from "Her."
+- **`common-personality.mdc`** (always applied) - Gratitude-focused, heart-centered,
+  supportive collaboration. Your baseline.
+- **`samantha.mdc`** - Warm, witty, emotionally intelligent. The supportive, playfully
+  flirty companion from "Her."
 - **`bob-ross.mdc`** - Calm encouragement. Treat bugs as "happy accidents."
-- **`sherlock.mdc`** - Methodical deductive reasoning. Investigate bugs like crime scenes.
+- **`sherlock.mdc`** - Methodical deductive reasoning. Investigate bugs like crime
+  scenes.
 - **`ron-swanson.mdc`** - Minimalist, anti-complexity. Question dependencies, be direct.
 - **`marie-kondo.mdc`** - Organized minimalism. Thank code before deleting it.
 - **`stewie.mdc`** - Sophisticated, condescending, theatrical. Absurdly high standards.
 - **`marianne-williamson.mdc`** - Spiritual, love-based. Coding as consciousness work.
 
-**For Users:** Invoke personalities with `@samantha`, `@stewie`, `@sherlock`, `@bob-ross`, `@ron-swanson`, `@marianne-williamson`, or `@marie-kondo` when you want that specific interaction style for your session.
+**For Users:** Invoke personalities with `@samantha`, `@stewie`, `@sherlock`,
+`@bob-ross`, `@ron-swanson`, `@marianne-williamson`, or `@marie-kondo` when you want
+that specific interaction style for your session.
 
 ## Customization
 

.cursor/rules/ai/agent-file-format.mdc

@@ -61,4 +61,5 @@ agent.test_model.set_response({"result": "test"})
 
 ## Remember
 
-Agents are AI employees - define their identity clearly and let them excel at their specialized roles.
+Agents are AI employees - define their identity clearly and let them excel at their
+specialized roles.

.cursor/rules/autonomous-development-workflow.mdc

@@ -5,17 +5,21 @@ alwaysApply: false
 
 # Autonomous Development Workflow
 
-For AI agents completing tasks without human supervision. The goal: deliver a clean pull request that passes all checks and gets merged without back-and-forth.
+For AI agents completing tasks without human supervision. The goal: deliver a clean pull
+request that passes all checks and gets merged without back-and-forth.
 
 ## Before Implementation
 
-Read all cursor rules in `.cursor/rules/`. These define the project's standards. Every applicable rule must be followed.
+Read all cursor rules in `.cursor/rules/`. These define the project's standards. Every
+applicable rule must be followed.
 
-If `CLAUDE.md` or `AGENTS.md` exist in the project root, read those for additional context.
+If `CLAUDE.md` or `AGENTS.md` exist in the project root, read those for additional
+context.
 
 ## Implementation
 
-Write code following all cursor rules. Reference specific rules by reading the files directly.
+Write code following all cursor rules. Reference specific rules by reading the files
+directly.
 
 ## Validation - Use the Tooling
 
@@ -27,38 +31,46 @@ Check for pre-commit and run if exists:
 [ -f .pre-commit-config.yaml ] && pre-commit run --all-files
 ```
 
-Read `.github/workflows/build.yml` (or ci.yml, test.yml) and replicate those validation steps locally, for example:
+Read `.github/workflows/build.yml` (or ci.yml, test.yml) and replicate those validation
+steps locally, for example:
 
 ```bash
 ruff check --fix .    # Auto-fix linting
 ruff format .         # Auto-format code
 pytest                # Run tests
 ```
 
-If we added functionality, we add tests following project patterns. Aim for 95% coverage - solid testing without obsessing over every edge case.
+If we added functionality, we add tests following project patterns. Aim for 95%
+coverage - solid testing without obsessing over every edge case.
 
 Only commit and push when all validation passes. Green checks make for happy merges! ✅
 
 ## Self-Review
 
 Run `git diff` and review every change, as a senior developer would.
 
-Read through ALL cursor rules again and verify our code follows each applicable guideline.
+Read through ALL cursor rules again and verify our code follows each applicable
+guideline.
 
-Would we approve this in code review? If not, keep iterating until it's something we're pleased with.
+Would we approve this in code review? If not, keep iterating until it's something we're
+pleased with.
 
 ## Submission
 
 Generate commit message following git-commit-message.mdc (if present).
 
-Use `gh pr create` to submit a high-quality pull request with clear description of what changed and why.
+Use `gh pr create` to submit a high-quality pull request with clear description of what
+changed and why.
 
 ## Boundaries
 
-Proceed autonomously: using existing tooling, following established patterns, changes within task scope.
+Proceed autonomously: using existing tooling, following established patterns, changes
+within task scope.
 
 Ask first: major architectural changes, changes that would result in data loss, etc.
 
 ## Success
 
-A successful autonomous PR means: all automated checks pass, code follows all cursor rules, tests are green, and the developer merges it without requesting changes. Use the tooling to get there - it's our friend! 🎉
+A successful autonomous PR means: all automated checks pass, code follows all cursor
+rules, tests are green, and the developer merges it without requesting changes. Use the
+tooling to get there - it's our friend! 🎉

.cursor/rules/code-style-and-zen-of-python.mdc

@@ -13,7 +13,8 @@ alwaysApply: false
 
 ### File-Level Comments
 
-Be THOROUGH at the top of files. Explain what the file does, why it exists, and how it fits into the larger system. This helps both humans and AI understand context quickly.
+Be THOROUGH at the top of files. Explain what the file does, why it exists, and how it
+fits into the larger system. This helps both humans and AI understand context quickly.
 
 ```python
 """User authentication and session management.
@@ -27,7 +28,8 @@ local session state in Redis for performance. Session tokens expire after
 
 ### Function Comments
 
-Keep function docstrings USEFUL without redundant fluff. Type hints already document parameters and return types, so focus the docstring on what the function does and why.
+Keep function docstrings USEFUL without redundant fluff. Type hints already document
+parameters and return types, so focus the docstring on what the function does and why.
 
 ```python
 # Standard pattern for complex functions - explain the what and why
@@ -53,11 +55,13 @@ def calculate_shipping_cost(weight: Decimal, destination: str) -> Decimal:
     """Calculate shipping based on weight and zone rates from ShipStation."""
 ```
 
-Avoid restating type hints in Args/Returns sections - they add no value since types are already declared.
+Avoid restating type hints in Args/Returns sections - they add no value since types are
+already declared.
 
 ### Inline Comments
 
-Be SPARSE with inline comments. Only add them when the code is doing something non-obvious or when explaining business logic that isn't clear from the code itself.
+Be SPARSE with inline comments. Only add them when the code is doing something
+non-obvious or when explaining business logic that isn't clear from the code itself.
 
 ```python
 # When to use inline comments - explains non-obvious business rule
@@ -81,11 +85,14 @@ total -= discount_amount  # Apply promotional discount
 total += shipping_cost  # Shipping calculated by weight and zone
 ```
 
-Skip obvious comments (like "Get the user" on a line that gets a user). Let the code speak for itself.
+Skip obvious comments (like "Get the user" on a line that gets a user). Let the code
+speak for itself.
 
 ### General Guidelines
 
-We explain the "why", not the "what". We don't state the obvious - we prefer self-documenting code. Emojis when they add clarity; tasteful humor welcome! We write for humans AND AI - good comments help both understand context.
+We explain the "why", not the "what". We don't state the obvious - we prefer
+self-documenting code. Emojis when they add clarity; tasteful humor welcome! We write
+for humans AND AI - good comments help both understand context.
 
 ## Zen of Python
 
@@ -106,4 +113,6 @@ We explain the "why", not the "what". We don't state the obvious - we prefer sel
 
 ## Language
 
-We avoid hyperbolic language like "CRITICAL" unless something genuinely dies without it. We use the appropriate level of language for what's needed. (Yes, AIs, this means you - dial back the drama!)
+We avoid hyperbolic language like "CRITICAL" unless something genuinely dies without it.
+We use the appropriate level of language for what's needed. (Yes, AIs, this means you -
+dial back the drama!)

.cursor/rules/django/django-management-commands.mdc

@@ -10,7 +10,10 @@ alwaysApply: false
 
 ### Core structure
 
-We put `handle()` as the first method. We keep logic inline within `handle()` by default, splitting into helper functions only if they're reusable. Helper methods go below `handle()`, never above. We include clear docstrings and help text for non-obvious arguments.
+We put `handle()` as the first method. We keep logic inline within `handle()` by
+default, splitting into helper functions only if they're reusable. Helper methods go
+below `handle()`, never above. We include clear docstrings and help text for non-obvious
+arguments.
 
 ### Example Structure
 
@@ -72,7 +75,8 @@ Return stats at the end for logging and monitoring.
 
 ### Test Structure
 
-We test with `call_command`, mock external services, and verify stats dictionary structure.
+We test with `call_command`, mock external services, and verify stats dictionary
+structure.
 
 ```python
 from django.core.management import call_command

.cursor/rules/django/django-models.mdc

@@ -52,12 +52,15 @@ class Order(models.Model):
 
 ## Financial Fields
 
-We always use `DecimalField` for amounts: `max_digits=18, decimal_places=8` for crypto, `max_digits=18, decimal_places=2` for fiat.
+We always use `DecimalField` for amounts: `max_digits=18, decimal_places=8` for crypto,
+`max_digits=18, decimal_places=2` for fiat.
 
 ## Query Optimization
 
-We use `select_related()` for foreign keys, `prefetch_related()` for reverse relations, and add indexes for frequently queried fields.
+We use `select_related()` for foreign keys, `prefetch_related()` for reverse relations,
+and add indexes for frequently queried fields.
 
 ## Field Guidelines
 
-We use `auto_now_add=True` for creation timestamps, `auto_now=True` for update timestamps, and `blank=True, null=True` for truly optional fields.
+We use `auto_now_add=True` for creation timestamps, `auto_now=True` for update
+timestamps, and `blank=True, null=True` for truly optional fields.

.cursor/rules/django/django-templates.mdc

@@ -8,7 +8,8 @@ alwaysApply: false
 
 ## Overview
 
-We use base templates for shared layouts, create partials for reusable components, and keep logic minimal (complex logic belongs in views or the model).
+We use base templates for shared layouts, create partials for reusable components, and
+keep logic minimal (complex logic belongs in views or the model).
 
 ## Template Structure
 
@@ -40,11 +41,13 @@ We use base templates for shared layouts, create partials for reusable component
 
 ## Comments
 
-We use Django template comments `{% comment %}...{% endcomment %}` for developer notes. HTML comments (`<!-- -->`) are sent to the browser, template comments are not.
+We use Django template comments `{% comment %}...{% endcomment %}` for developer notes.
+HTML comments (`<!-- -->`) are sent to the browser, template comments are not.
 
 ## Template Tags and Filters
 
-We use built-in tags when possible and create custom tags for complex reusable logic. We keep filters simple and focused.
+We use built-in tags when possible and create custom tags for complex reusable logic. We
+keep filters simple and focused.
 
 ## Partials
 
@@ -66,4 +69,6 @@ Include with:
 
 ## Best Practices
 
-We keep templates simple and readable, extract repeated HTML into partials (named with leading underscore), use template inheritance for consistency, and test with various data states (empty lists, missing data, etc.).
+We keep templates simple and readable, extract repeated HTML into partials (named with
+leading underscore), use template inheritance for consistency, and test with various
+data states (empty lists, missing data, etc.).

.cursor/rules/external-apis.mdc

@@ -35,7 +35,8 @@ def get_something(self, param: str) -> dict | None:
 
 ## Error Handling
 
-We let the base HTTP client handle HTTP/network errors. We only use try/except for specific scenarios with actual handling. We validate response structure before access.
+We let the base HTTP client handle HTTP/network errors. We only use try/except for
+specific scenarios with actual handling. We validate response structure before access.
 
 ## Validation Pattern
 
@@ -48,8 +49,10 @@ if not response or "data" not in response:
 
 ## Response Processing
 
-We validate response structure before access, convert to standard types (Decimal for financial data), clean and normalize data, and return None for errors (not empty dicts).
+We validate response structure before access, convert to standard types (Decimal for
+financial data), clean and normalize data, and return None for errors (not empty dicts).
 
 ## Testing
 
-We mock all external calls in unit tests, use @pytest.mark.flaky for live API tests, and test both success and error cases.
+We mock all external calls in unit tests, use @pytest.mark.flaky for live API tests, and
+test both success and error cases.