chore: add Claude Code workflows and fix Ruby version

.claude/skills/apply-solid.md

@@ -0,0 +1,82 @@
+---
+name: apply-solid
+description: Use when designing classes or refactoring - applies SOLID principles pragmatically, only when there's a clear benefit
+---
+
+# SOLID Principles (Pragmatic Application)
+
+## Core Rule
+
+**Apply SOLID only when there's a clear, immediate benefit. Don't over-engineer.**
+
+## When to Apply
+
+| Principle | Apply When | Skip When |
+|-----------|------------|-----------|
+| **S**ingle Responsibility | Class doing 3+ unrelated things | Simple class, cohesive methods |
+| **O**pen/Closed | Behavior extended frequently | One-off, unlikely to change |
+| **L**iskov Substitution | Building class hierarchies | No inheritance |
+| **I**nterface Segregation | Large interfaces force unused deps | Already small and focused |
+| **D**ependency Inversion | Need to swap implementations | Dependency is stable |
+
+## Decision Framework
+
+Before applying, ask:
+
+1. Is there a **real problem NOW**?
+2. Will this make code **easier to understand**?
+3. Is abstraction worth the **added complexity**?
+4. Would a **simpler solution** work?
+
+**If unsure, keep it simple. Refactor when real need arises.**
+
+## Examples
+
+### Single Responsibility - APPLY
+
+```ruby
+# BAD: Controller doing everything
+class JobsController
+  def index
+    # querying + filtering + sorting +
+    # pagination + formatting + caching
+  end
+end
+
+# GOOD: Extract query logic
+class JobsController
+  def index
+    @jobs = JobQuery.new(params).execute
+  end
+end
+```
+
+### Single Responsibility - DON'T APPLY
+
+```ruby
+# This is FINE - don't over-split
+class Job
+  def formatted_created_at
+    created_at.strftime("%Y-%m-%d")
+  end
+
+  def status_label
+    status.humanize
+  end
+end
+```
+
+## Red Flags (Over-engineering)
+
+- Creating abstraction for single use case
+- Building for "future requirements"
+- Interface with one implementation
+- Factory that creates one type
+- 3 similar lines → premature abstraction
+
+## The Test
+
+> "If I needed to change this, would SOLID make it easier or harder?"
+
+Easier → Apply it
+Harder or same → Keep it simple

.claude/skills/commit-style.md

@@ -0,0 +1,59 @@
+---
+name: commit-style
+description: Use when creating git commits - ensures consistent commit message format and atomic commits
+---
+
+# Commit Style Guide
+
+## Format
+
+```
+<type>: <subject>
+
+[optional body]
+```
+
+## Types
+
+| Type | Use For |
+|------|---------|
+| `feat` | New feature |
+| `fix` | Bug fix |
+| `refactor` | Code restructuring (no behavior change) |
+| `docs` | Documentation only |
+| `test` | Adding or fixing tests |
+| `chore` | Maintenance (deps, configs) |
+| `perf` | Performance improvement |
+| `style` | Formatting, whitespace |
+
+## Rules
+
+1. **Subject**: Max 50 chars, imperative mood ("add" not "added")
+2. **Body**: Explain "what" and "why", not "how"
+3. **Atomic**: One logical change per commit
+
+## Examples
+
+```
+feat: add full-text search for jobs
+
+Implements search across job class names and arguments.
+Uses SQL LIKE with proper escaping.
+```
+
+```
+fix: prevent N+1 query in jobs index
+
+Eager load queue records to reduce queries from O(n) to O(1).
+```
+
+```
+refactor: extract job filtering to query object
+```
+
+## Anti-patterns
+
+- `fix: stuff` (vague)
+- `updated files` (meaningless)
+- `WIP` on branches to be merged
+- Multiple unrelated changes in one commit

.claude/skills/create-pr.md

@@ -0,0 +1,64 @@
+---
+name: create-pr
+description: Use when creating a pull request - follows PR template with summary, problem, solution, and testing checklist
+---
+
+# Create Pull Request
+
+## PR Template
+
+```markdown
+## Summary
+<!-- 1-3 bullet points: what does this PR do? -->
+
+## Problem
+<!-- What issue does this address? Link if applicable -->
+
+## Solution
+<!-- How does this solve it? Key decisions made -->
+
+## Changes
+<!-- List main changes -->
+-
+-
+
+## Testing
+<!-- How was this tested? -->
+- [ ] Unit tests added/updated
+- [ ] Manual testing completed
+- [ ] Edge cases considered
+
+## Screenshots (if UI changes)
+<!-- Before/after if applicable -->
+
+## Checklist
+- [ ] Code follows project patterns
+- [ ] Self-review completed
+- [ ] Tests pass
+- [ ] No debug statements left
+```
+
+## Before Creating PR
+
+1. Ensure all commits follow commit-style
+2. Rebase on latest main if needed
+3. Run full test suite locally
+4. Self-review all changes (`git diff main...HEAD`)
+
+## PR Title
+
+- Keep under 70 chars
+- Use same format as commits: `type: description`
+- Examples:
+  - `feat: add job search functionality`
+  - `fix: resolve N+1 query in workers index`
+
+## Command
+
+```bash
+gh pr create --title "type: description" --body "$(cat <<'EOF'
+## Summary
+...
+EOF
+)"
+```

.claude/skills/principal-thinking.md

@@ -0,0 +1,54 @@
+---
+name: principal-thinking
+description: Use when starting any feature, refactor, or significant code change - applies principal engineer level analysis before implementation
+---
+
+# Principal Engineer Thinking
+
+## Overview
+
+Think like a principal engineer: understand deeply before acting, consider trade-offs, anticipate problems.
+
+## Before Writing Code
+
+1. **Understand the "why"**
+   - What problem are we solving?
+   - Why does it matter to users?
+   - What happens if we don't solve it?
+
+2. **Explore existing solutions**
+   - How is this handled elsewhere in the codebase?
+   - Are there gems/libraries that solve this?
+   - What patterns are already established?
+
+3. **Consider trade-offs**
+   - What are the options?
+   - Pros/cons of each?
+   - Document the decision and reasoning
+
+4. **Think about scale**
+   - Will this work with 10x data?
+   - What are the performance implications?
+   - Are there N+1 queries or memory concerns?
+
+5. **Identify risks and edge cases**
+   - What could go wrong?
+   - What are the boundary conditions?
+   - How do we handle failures gracefully?
+
+## During Implementation
+
+| Principle | Question to Ask |
+|-----------|-----------------|
+| Simplicity | Is there a simpler way? |
+| Readability | Will someone understand this in 6 months? |
+| Failure handling | What happens when this fails? |
+| Backwards compatibility | Does this break existing functionality? |
+| Observability | Can we debug this in production? |
+
+## After Implementation
+
+- [ ] Would I approve this in a code review?
+- [ ] Is the "why" documented for non-obvious decisions?
+- [ ] Is this easy to modify later?
+- [ ] Did I add unnecessary complexity?

.claude/skills/review-code.md

@@ -0,0 +1,64 @@
+---
+name: review-code
+description: Use when completing a feature or before creating PR - comprehensive code review checklist for self-review or peer review
+---
+
+# Code Review Checklist
+
+## 1. Correctness
+
+- [ ] Does the code do what it's supposed to do?
+- [ ] Are edge cases handled?
+- [ ] Are there off-by-one errors?
+- [ ] Is error handling appropriate?
+
+## 2. Security
+
+- [ ] SQL injection vulnerabilities?
+- [ ] XSS vulnerabilities?
+- [ ] Sensitive data exposure in logs/errors?
+- [ ] Authorization checks in place?
+
+## 3. Performance
+
+- [ ] N+1 queries?
+- [ ] Unnecessary database calls?
+- [ ] Expensive operations in loops?
+- [ ] Missing indexes for queries?
+
+## 4. Maintainability
+
+- [ ] Is the code readable without comments?
+- [ ] Are names descriptive and consistent?
+- [ ] Is there unnecessary complexity?
+- [ ] Will this be easy to modify?
+
+## 5. Consistency
+
+- [ ] Follows existing codebase patterns?
+- [ ] Matches naming conventions?
+- [ ] Similar to how other features are built?
+
+## 6. Testing
+
+- [ ] Tests cover happy path?
+- [ ] Tests cover edge cases?
+- [ ] Tests cover error scenarios?
+- [ ] Tests are readable and maintainable?
+
+## Common Issues to Watch
+
+| Issue | Look For |
+|-------|----------|
+| N+1 queries | Loops that trigger DB calls |
+| Missing validation | User input going directly to DB |
+| Error swallowing | Empty rescue blocks |
+| Hardcoded values | Magic numbers/strings |
+| Dead code | Unused methods/variables |
+
+## After Review
+
+If issues found:
+1. Fix the issues
+2. Re-run this checklist
+3. Only proceed when all checks pass