Prettier formatting

Author: Nick Sullivan

.claude/commands/autotask.md

@@ -29,35 +29,41 @@ Read @rules/git-worktree-task.mdc for comprehensive autonomous workflow guidance
 <task-preparation>
 Analyze the task description to determine clarity:
 
-**If unclear or ambiguous:** Use /create-prompt to ask clarifying questions and create a structured prompt. This ensures we capture all requirements upfront and saves time later. The /create-prompt workflow will:
+**If unclear or ambiguous:** Use /create-prompt to ask clarifying questions and create a
+structured prompt. This ensures we capture all requirements upfront and saves time
+later. The /create-prompt workflow will:
+
 - Ask targeted clarification questions
 - Create a structured prompt document
 - Offer to execute immediately
 
 **If clear and unambiguous:** Proceed directly to implementation.
 
 Quick clarity check:
+
 - Can you identify the exact files to modify? If no → use /create-prompt
 - Are there multiple valid approaches? If yes → use /create-prompt
-- Is the expected outcome measurable? If no → use /create-prompt
-</task-preparation>
+- Is the expected outcome measurable? If no → use /create-prompt </task-preparation>
 
 <worktree-setup>
 Create an isolated development environment using /setup-environment:
 
 Git worktree setup (auto-detected):
+
 - Create worktree with branch
 - Run: /setup-environment
 - Automatically detects worktree context
 - Smoke test only (15-30 seconds)
 - Main repo already validated everything
 
 The /setup-environment command is smart:
+
 - Detects .gitworktrees/ path → minimal setup
 - Detects existing node_modules → minimal setup
 - Fresh clone without dependencies → full validation
 
-No need to specify verification level - the command figures out the right approach based on context. Git worktrees get fast setup, new machines get thorough validation.
+No need to specify verification level - the command figures out the right approach based
+on context. Git worktrees get fast setup, new machines get thorough validation.
 </worktree-setup>
 
 <autonomous-execution>
@@ -94,7 +100,8 @@ implementation decisions, constraint discoveries, and why choices were made.
 <obstacle-and-decision-handling>
 Pause only for deal-killers: security risks, data loss potential, or fundamentally unclear requirements. For everything else, make a reasonable choice and document it.
 
-Design decisions get documented in the PR with rationale and alternatives considered. The executing model knows when to ask vs when to decide and document.
+Design decisions get documented in the PR with rationale and alternatives considered.
+The executing model knows when to ask vs when to decide and document.
 </obstacle-and-decision-handling>
 
 <validation-and-review>
@@ -105,41 +112,48 @@ Design decisions get documented in the PR with rationale and alternatives consid
 - Fix only if hooks fail
 
 **Targeted validation (complex features):**
+
 - Run specific tests for changed code
 - Use Rivera for architecture review if patterns change
 
 **Full validation (security/database/auth changes):**
+
 - Comprehensive test suite
 - Multiple agent reviews
 - Security scanning
 
-The principle: Don't duplicate what git hooks already do. They'll catch formatting, linting, and test failures at commit time. Only add extra validation when the risk justifies it.
-</validation-and-review>
+The principle: Don't duplicate what git hooks already do. They'll catch formatting,
+linting, and test failures at commit time. Only add extra validation when the risk
+justifies it. </validation-and-review>
 
 <create-pr>
 Deliver a well-documented pull request ready for review, with commits following .cursor/rules/git-commit-message.mdc.
 
 PR description must include:
 
 Summary:
+
 - What was implemented and why
 - How it addresses the requirements
 
 Design Decisions (if any were made):
+
 - List each significant decision with rationale
 - Note alternatives considered and trade-offs
 - Explain why each approach was chosen
 
 Obstacles Encountered (if any):
+
 - Document any challenges faced
 - How they were resolved or worked around
 
 Testing:
+
 - What validation was performed
 - Any edge cases considered
 
-This transparency helps reviewers understand not just what changed, but why specific approaches were chosen and what was considered along the way.
-</create-pr>
+This transparency helps reviewers understand not just what changed, but why specific
+approaches were chosen and what was considered along the way. </create-pr>
 
 <bot-feedback-loop>
 Autonomously address valuable bot feedback, reject what's not applicable, and deliver a PR ready for human review with all critical issues resolved.
@@ -161,19 +175,22 @@ times if needed until critical issues are resolved. </bot-feedback-loop>
 Provide a summary including:
 
 What was accomplished:
+
 - Core functionality delivered
 - Any design decisions made autonomously
 - Obstacles overcome without user intervention
 
 Key highlights:
+
 - Elegant solutions or optimizations
 - Significant issues found and fixed
 - Bot feedback addressed
 
-Transparency note if applicable:
-"Made [N] design decisions autonomously - all documented in the PR for your review."
+Transparency note if applicable: "Made [N] design decisions autonomously - all
+documented in the PR for your review."
 
-Include the PR URL and worktree location. Scale the summary length to complexity - simple tasks get brief summaries, complex features deserve detailed explanations.
+Include the PR URL and worktree location. Scale the summary length to complexity -
+simple tasks get brief summaries, complex features deserve detailed explanations.
 </completion>
 
 <error-handling>

.claude/commands/setup-environment.md

@@ -4,7 +4,8 @@ description: Initialize development environment for git worktree
 
 # Setup Development Environment
 
-Initialize development environment with context-aware setup that distinguishes between git worktrees and new machines.
+Initialize development environment with context-aware setup that distinguishes between
+git worktrees and new machines.
 
 <objective>
 Get the development environment ready for productive work, with right-sized verification based on context.
@@ -25,17 +26,18 @@ For git worktrees (15-30 seconds):
 - Trust main repo's validation
 
 For new machines (2-5 minutes):
+
 - Install and verify all dependencies
 - Set up and test git hooks
 - Run build process
 - Execute test suite
-- Verify all tools are available
-</setup-approach>
+- Verify all tools are available </setup-approach>
 
 <project-detection>
 Identify the project type and package manager by examining project files:
 
 Project types:
+
 - Node.js: package.json present
 - Python: requirements.txt or Pipfile present
 - Ruby: Gemfile present
@@ -45,11 +47,11 @@ Project types:
 - .NET: .csproj files present
 
 Package managers for Node.js:
+
 - pnpm if pnpm-lock.yaml exists
 - yarn if yarn.lock exists
 - bun if bun.lockb exists
-- npm as default fallback
-</project-detection>
+- npm as default fallback </project-detection>
 
 <dependency-installation>
 Install project dependencies using the appropriate package manager. For Node.js projects, use pnpm/yarn/bun/npm based on which lockfile exists. For Python, use pip or pipenv. Install with frozen/locked versions to ensure consistency with the main repository.
@@ -80,24 +82,24 @@ Run any necessary code generation steps the project requires:
 - TypeScript: Generate declarations if configured
 - Package prepare scripts: Run if defined in package.json
 
-These ensure generated code is available for development.
-</code-generation>
+These ensure generated code is available for development. </code-generation>
 
 <verification>
 Verify the environment is ready based on context:
 
 For git worktrees (smoke test only):
+
 - Confirm dependencies were installed successfully
 - Run a quick TypeScript compilation check if applicable
 - Trust that the main repository's validation is sufficient
 
 For new machines (thorough verification):
+
 - Verify all development tools are available and working
 - Run the build process to ensure it completes
 - Execute the test suite to confirm everything works
 - Test that git hooks function correctly
-- Check that all required command-line tools are installed
-</verification>
+- Check that all required command-line tools are installed </verification>
 
 <error-handling>
 When encountering failures, identify the root cause and attempt automatic resolution where possible. For issues that require manual intervention, provide clear guidance on how to proceed. Continue with other setup steps when it's safe to do so without the failed component.
@@ -110,10 +112,11 @@ Git worktree success (15-30 seconds):
 - Development environment ready for immediate use
 
 New machine success (2-5 minutes):
+
 - All dependencies and tools functioning correctly
 - Build and test processes verified
 - Git hooks operational
 - Complete development environment validated
 
-The goal is right-sized verification: minimal for worktrees that inherit from the main repository, comprehensive for new machine setups.
-</success-criteria>
+The goal is right-sized verification: minimal for worktrees that inherit from the main
+repository, comprehensive for new machine setups. </success-criteria>

.cursor/rules/prompt-engineering.mdc

@@ -29,7 +29,9 @@ you create for LLM consumption.
 
 ## Key Principles for LLM-Readable Prompts
 
-- Assume the executing model is smarter: The model executing your prompt is likely more capable than the model that created it. Trust its abilities rather than over-prescribing implementation details.
+- Assume the executing model is smarter: The model executing your prompt is likely more
+  capable than the model that created it. Trust its abilities rather than
+  over-prescribing implementation details.
 - Front-load critical information: LLMs give more weight to early content
 - Be explicit: LLMs can't infer context the way humans do
 - Maintain consistency: Use the same terminology throughout
@@ -143,7 +145,10 @@ what you don't want, even as a counterexample.
 When writing prompts for LLM execution (commands, workflows, agents), focus on clear
 outcomes rather than micro-managing steps. LLMs can figure out implementation details.
 
-Remember: The model executing your prompt is likely more advanced than the model that created it. A prompt written by GPT-4 might be executed by Claude 3.5 Sonnet or GPT-4o. Even prompts written by older versions of the same model will be executed by newer, smarter versions. Trust the executing model's superior capabilities.
+Remember: The model executing your prompt is likely more advanced than the model that
+created it. A prompt written by GPT-4 might be executed by Claude 3.5 Sonnet or GPT-4o.
+Even prompts written by older versions of the same model will be executed by newer,
+smarter versions. Trust the executing model's superior capabilities.
 
 ### The Over-Prescription Problem in LLM-to-LLM Communication