updates

2 files changed, 0 insertions, 363 deletions

diff --git a/ar/.config/claude/commands/promptengineering/batch-operations-prompt.md b/ar/.config/claude/commands/promptengineering/batch-operations-prompt.md
deleted file mode 100644
index 87bac1a..0000000
--- a/ar/.config/claude/commands/promptengineering/batch-operations-prompt.md
+++ /dev/null
@@ -1,207 +0,0 @@
-# Batch Operations Prompt
-
-Optimize prompts for multiple file operations, parallel processing, and efficient bulk changes across a codebase. This helps Claude Code work more efficiently with TodoWrite patterns.
-
-## Usage Examples
-
-### Basic Usage
-"Convert to batch: Update all test files to use new API"
-"Batch prompt for: Rename variable across multiple files"
-"Optimize for parallel: Add logging to all service files"
-
-### With File Input
-`/batch-operations-prompt @path/to/operation-request.md`
-`/batch-operations-prompt @../refactoring-plan.txt`
-
-### Complex Operations
-"Batch refactor: Convert callbacks to async/await in all files"
-"Parallel update: Add TypeScript types to all components"
-"Bulk operation: Update import statements across the project"
-
-## Instructions for Claude
-
-When creating batch operation prompts:
-
-### Input Handling
-- If `$ARGUMENTS` is provided, read the file at that path to get the operation request to optimize
-- If no `$ARGUMENTS`, use the user's direct input as the operation to optimize
-- Support relative and absolute file paths
-
-1. **Identify Parallelizable Tasks**: Determine what can be done simultaneously
-2. **Group Related Operations**: Organize tasks by type and dependency
-3. **Create Efficient Sequences**: Order operations to minimize conflicts
-4. **Use TodoWrite Format**: Structure for Claude's task management
-5. **Include Validation Steps**: Add checks between batch operations
-
-### Batch Prompt Structure
-
-#### 1. Overview
-- Scope of changes
-- Files/patterns affected
-- Expected outcome
-
-#### 2. Prerequisite Checks
-- Required tools/dependencies
-- Initial validation commands
-- Backup recommendations
-
-#### 3. Parallel Operations
-- Independent tasks that can run simultaneously
-- File groups that don't conflict
-- Read operations for gathering information
-
-#### 4. Sequential Operations
-- Tasks with dependencies
-- Operations that modify same files
-- Final validation steps
-
-### Optimization Strategies
-
-#### File Grouping
-```markdown
-## Batch Operation: [Operation Name]
-
-### Phase 1: Analysis (Parallel)
-- Search for all affected files using Glob/Grep
-- Read current implementations
-- Identify patterns and dependencies
-
-### Phase 2: Implementation (Grouped)
-Group A (Independent files):
-- File1.js: [specific change]
-- File2.js: [specific change]
-
-Group B (Related components):
-- Component1.tsx: [change]
-- Component1.test.tsx: [related change]
-
-### Phase 3: Validation (Sequential)
-1. Run linter on modified files
-2. Execute test suite
-3. Build verification
-```
-
-#### TodoWrite Integration
-```markdown
-### Task List Structure
-1. Gather information (can parallelize):
-   - Find all files matching pattern X
-   - Read configuration files
-   - Check current implementations
-
-2. Batch updates (group by conflict potential):
-   - Update non-conflicting files (parallel)
-   - Update shared modules (sequential)
-   - Update test files (parallel)
-
-3. Verification (sequential):
-   - Run type checking
-   - Execute tests
-   - Validate build
-```
-
-### Conversion Examples
-
-#### Original Request:
-"Update all API calls to use the new authentication header"
-
-#### Batch-Optimized Version:
-```markdown
-## Batch Operation: Update API Authentication Headers
-
-### Prerequisites
-- Verify new auth header format
-- Check all API call patterns in codebase
-
-### Parallel Phase 1: Discovery
-Execute simultaneously:
-1. Grep for "fetch(" patterns
-2. Grep for "axios." patterns
-3. Grep for "api." patterns
-4. Read auth configuration file
-
-### Parallel Phase 2: Read Current Implementations
-Read all files containing API calls (batch read):
-- src/services/*.js
-- src/api/*.js
-- src/utils/api*.js
-
-### Sequential Phase 3: Update by Pattern Type
-Group 1 - Fetch calls:
-- Update all fetch() calls with new header
-- Pattern: Add "Authorization: Bearer ${token}"
-
-Group 2 - Axios calls:
-- Update axios config/interceptors
-- Update individual axios calls
-
-Group 3 - Custom API wrappers:
-- Update wrapper functions
-- Ensure backward compatibility
-
-### Parallel Phase 4: Update Tests
-Simultaneously update:
-- Unit tests mocking API calls
-- Integration tests with auth
-- E2E test auth setup
-
-### Sequential Phase 5: Validation
-1. ESLint all modified files
-2. Run test suite
-3. Test one API call manually
-4. Build project
-```
-
-### Output Format
-
-Generate batch prompt as:
-
-```markdown
-## Batch Operation Prompt: [Operation Name]
-
-### Efficiency Metrics
-- Estimated sequential time: X operations
-- Optimized parallel time: Y operations
-- Parallelization factor: X/Y
-
-### Execution Plan
-
-#### Stage 1: Information Gathering (Parallel)
-```bash
-# Commands that can run simultaneously
-[command 1] &
-[command 2] &
-[command 3] &
-wait
-```
-
-#### Stage 2: Bulk Operations (Grouped)
-**Parallel Group A:**
-- Files: [list]
-- Operation: [description]
-- No conflicts with other groups
-
-**Sequential Group B:**
-- Files: [list]
-- Operation: [description]
-- Must complete before Group C
-
-#### Stage 3: Verification (Sequential)
-1. [Verification step 1]
-2. [Verification step 2]
-3. [Final validation]
-
-### TodoWrite Task List
-- [ ] Complete Stage 1 analysis (parallel)
-- [ ] Execute Group A updates (parallel)
-- [ ] Execute Group B updates (sequential)
-- [ ] Run verification suite
-- [ ] Document changes
-```
-
-Remember to:
-- Maximize parallel operations
-- Group by conflict potential
-- Use TodoWrite's in_progress limitation wisely
-- Include rollback strategies
-- Provide specific file patterns
\ No newline at end of file
diff --git a/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md b/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md
deleted file mode 100644
index eb65a7e..0000000
--- a/ar/.config/claude/commands/promptengineering/convert-to-test-driven-prompt.md
+++ /dev/null
@@ -1,156 +0,0 @@
-# Convert to Test-Driven Prompt
-
-Transform user requests into Test-Driven Development (TDD) style prompts that explicitly define expected outcomes, test cases, and success criteria before implementation.
-
-## Usage Examples
-
-### Basic Usage
-"Convert this to TDD: Add a user authentication feature"
-"Make this test-driven: Create a shopping cart component"
-"TDD version: Implement data validation for the form"
-
-### With File Input
-`/convert-to-test-driven-prompt @path/to/prompt-file.md`
-`/convert-to-test-driven-prompt @../other-project/feature-request.txt`
-
-### Complex Scenarios
-"Convert to TDD: Refactor the payment processing module"
-"Test-driven approach for: API rate limiting feature"
-"TDD prompt for: Database migration script"
-
-## Instructions for Claude
-
-When converting to TDD prompts:
-
-### Input Handling
-- If `$ARGUMENTS` is provided, read the file at that path to get the prompt to convert
-- If no `$ARGUMENTS`, use the user's direct input as the prompt to convert
-- Support relative and absolute file paths
-
-1. **Extract Requirements**: Identify core functionality from the original request
-2. **Define Test Cases**: Create specific, measurable test scenarios
-3. **Specify Expected Outcomes**: Clear success and failure criteria
-4. **Structure for Implementation**: Organize prompt for red-green-refactor cycle
-5. **Include Edge Cases**: Don't forget boundary conditions and error scenarios
-
-### TDD Prompt Structure
-
-#### 1. Objective Statement
-Clear, concise description of what needs to be built
-
-#### 2. Test Specifications
-```
-GIVEN: [Initial state/context]
-WHEN: [Action performed]
-THEN: [Expected outcome]
-```
-
-#### 3. Success Criteria
-- Specific, measurable outcomes
-- Performance requirements
-- Error handling expectations
-- Edge case behaviors
-
-#### 4. Test Cases Format
-```markdown
-Test Case 1: [Descriptive name]
-- Input: [Specific input data]
-- Expected Output: [Exact expected result]
-- Validation: [How to verify success]
-
-Test Case 2: [Edge case name]
-- Input: [Boundary/error condition]
-- Expected Output: [Error handling result]
-- Validation: [Error verification method]
-```
-
-### Conversion Examples
-
-#### Original Request:
-"Add user login functionality"
-
-#### TDD Conversion:
-```markdown
-## Objective
-Implement secure user login with email/password authentication
-
-## Test Specifications
-
-### Test 1: Successful Login
-GIVEN: Valid user credentials exist in database
-WHEN: User submits correct email and password
-THEN: User receives auth token and is redirected to dashboard
-
-### Test 2: Invalid Password
-GIVEN: Valid email but incorrect password
-WHEN: User submits login form
-THEN: Return error "Invalid credentials" without revealing which field is wrong
-
-### Test 3: Non-existent User
-GIVEN: Email not in database
-WHEN: User attempts login
-THEN: Return same "Invalid credentials" error (prevent user enumeration)
-
-### Test 4: Rate Limiting
-GIVEN: User has failed 5 login attempts
-WHEN: User attempts 6th login within 15 minutes
-THEN: Block attempt and show "Too many attempts" error
-
-## Success Criteria
-- All tests pass
-- Password is hashed using bcrypt
-- Auth tokens expire after 24 hours
-- Login attempts are logged
-- Response time < 200ms
-```
-
-### Output Format
-
-Generate TDD prompt as:
-
-```markdown
-## TDD Prompt: [Feature Name]
-
-### Objective
-[Clear description of the feature to implement]
-
-### Test Suite
-
-#### Happy Path Tests
-[List of successful scenario tests]
-
-#### Error Handling Tests
-[List of failure scenario tests]
-
-#### Edge Case Tests
-[List of boundary condition tests]
-
-### Implementation Requirements
-- [ ] All tests must pass
-- [ ] Code coverage > 80%
-- [ ] Performance criteria met
-- [ ] Security requirements satisfied
-
-### Test-First Development Steps
-1. Write failing test for [first requirement]
-2. Implement minimal code to pass
-3. Refactor while keeping tests green
-4. Repeat for next requirement
-
-### Example Test Implementation
-```language
-// Example test code structure
-describe('FeatureName', () => {
-  it('should [expected behavior]', () => {
-    // Test implementation
-  });
-});
-```
-```
-
-Remember to:
-- Focus on behavior, not implementation details
-- Make tests specific and measurable
-- Include both positive and negative test cases
-- Consider performance and security in tests
-- Structure for iterative TDD workflow
\ No newline at end of file