Initial commit

commands/generate_command.md

@@ -0,0 +1,111 @@
+# Create a Custom Claude Code Command
+
+Create a new slash command in `.claude/commands/` for the requested task.
+
+## Goal
+
+#$ARGUMENTS
+
+## Key Capabilities to Leverage
+
+**File Operations:**
+- Read, Edit, Write - modify files precisely
+- Glob, Grep - search codebase
+- MultiEdit - atomic multi-part changes
+
+**Development:**
+- Bash - run commands (git, tests, linters)
+- Task - launch specialized agents for complex tasks
+- TodoWrite - track progress with todo lists
+
+**Web & APIs:**
+- WebFetch, WebSearch - research documentation
+- GitHub (gh cli) - PRs, issues, reviews
+- Puppeteer - browser automation, screenshots
+
+**Integrations:**
+- AppSignal - logs and monitoring
+- Context7 - framework docs
+- Stripe, Todoist, Featurebase (if relevant)
+
+## Best Practices
+
+1. **Be specific and clear** - detailed instructions yield better results
+2. **Break down complex tasks** - use step-by-step plans
+3. **Use examples** - reference existing code patterns
+4. **Include success criteria** - tests pass, linting clean, etc.
+5. **Think first** - use "think hard" or "plan" keywords for complex problems
+6. **Iterate** - guide the process step by step
+
+## Structure Your Command
+
+```markdown
+# [Command Name]
+
+[Brief description of what this command does]
+
+## Steps
+
+1. [First step with specific details]
+   - Include file paths, patterns, or constraints
+   - Reference existing code if applicable
+
+2. [Second step]
+   - Use parallel tool calls when possible
+   - Check/verify results
+
+3. [Final steps]
+   - Run tests
+   - Lint code
+   - Commit changes (if appropriate)
+
+## Success Criteria
+
+- [ ] Tests pass
+- [ ] Code follows style guide
+- [ ] Documentation updated (if needed)
+```
+
+## Tips for Effective Commands
+
+- **Use $ARGUMENTS** placeholder for dynamic inputs
+- **Reference CLAUDE.md** patterns and conventions
+- **Include verification steps** - tests, linting, visual checks
+- **Be explicit about constraints** - don't modify X, use pattern Y
+- **Use XML tags** for structured prompts: `<task>`, `<requirements>`, `<constraints>`
+
+## Example Pattern
+
+```markdown
+Implement #$ARGUMENTS following these steps:
+
+1. Research existing patterns
+   - Search for similar code using Grep
+   - Read relevant files to understand approach
+
+2. Plan the implementation
+   - Think through edge cases and requirements
+   - Consider test cases needed
+
+3. Implement
+   - Follow existing code patterns (reference specific files)
+   - Write tests first if doing TDD
+   - Ensure code follows CLAUDE.md conventions
+
+4. Verify
+   - Run tests:
+     - Rails: `bin/rails test` or `bundle exec rspec`
+     - TypeScript: `npm test` or `yarn test` (Jest/Vitest)
+     - Python: `pytest` or `python -m pytest`
+   - Run linter:
+     - Rails: `bundle exec standardrb` or `bundle exec rubocop`
+     - TypeScript: `npm run lint` or `eslint .`
+     - Python: `ruff check .` or `flake8`
+   - Check changes with git diff
+
+5. Commit (optional)
+   - Stage changes
+   - Write clear commit message
+```
+
+Now create the command file at `.claude/commands/[name].md` with the structure above.

commands/plan.md

@@ -0,0 +1,359 @@
+# Create GitHub Issue
+
+## Introduction
+
+Transform feature descriptions, bug reports, or improvement ideas into well-structured markdown files issues that follow project conventions and best practices. This command provides flexible detail levels to match your needs.
+
+## Feature Description
+
+<feature_description> #$ARGUMENTS </feature_description>
+
+## Main Tasks
+
+### 1. Repository Research & Context Gathering
+
+<thinking>
+First, I need to understand the project's conventions and existing patterns, leveraging all available resources and use paralel subagents to do this.
+</thinking>
+
+Runn these three agents in paralel at the same time:
+
+- Task repo-research-analyst(feature_description)
+- Task best-practices-researcher (feature_description)
+- Task framework-docs-researcher (feature_description)
+
+**Reference Collection:**
+
+- [ ] Document all research findings with specific file paths (e.g., `app/services/example_service.rb:42`)
+- [ ] Include URLs to external documentation and best practices guides
+- [ ] Create a reference list of similar issues or PRs (e.g., `#123`, `#456`)
+- [ ] Note any team conventions discovered in `CLAUDE.md` or team documentation
+
+### 2. Issue Planning & Structure
+
+<thinking>
+Think like a product manager - what would make this issue clear and actionable? Consider multiple perspectives
+</thinking>
+
+**Title & Categorization:**
+
+- [ ] Draft clear, searchable issue title using conventional format (e.g., `feat:`, `fix:`, `docs:`)
+- [ ] Identify appropriate labels from repository's label set (`gh label list`)
+- [ ] Determine issue type: enhancement, bug, refactor
+
+**Stakeholder Analysis:**
+
+- [ ] Identify who will be affected by this issue (end users, developers, operations)
+- [ ] Consider implementation complexity and required expertise
+
+**Content Planning:**
+
+- [ ] Choose appropriate detail level based on issue complexity and audience
+- [ ] List all necessary sections for the chosen template
+- [ ] Gather supporting materials (error logs, screenshots, design mockups)
+- [ ] Prepare code examples or reproduction steps if applicable, name the mock filenames in the lists
+
+### 3. Choose Implementation Detail Level
+
+Select how comprehensive you want the issue to be:
+
+#### 📄 MINIMAL (Quick Issue)
+
+**Best for:** Simple bugs, small improvements, clear features
+
+**Includes:**
+
+- Problem statement or feature description
+- Basic acceptance criteria
+- Essential context only
+
+**Structure:**
+
+````markdown
+[Brief problem/feature description]
+
+## Acceptance Criteria
+
+- [ ] Core requirement 1
+- [ ] Core requirement 2
+
+## Context
+
+[Any critical information]
+
+## MVP
+
+### test.rb
+
+```ruby
+class Test
+  def initialize
+    @name = "test"
+  end
+end
+```
+
+## References
+
+- Related issue: #[issue_number]
+- Documentation: [relevant_docs_url]
+````
+
+#### 📋 MORE (Standard Issue)
+
+**Best for:** Most features, complex bugs, team collaboration
+
+**Includes everything from MINIMAL plus:**
+
+- Detailed background and motivation
+- Technical considerations
+- Success metrics
+- Dependencies and risks
+- Basic implementation suggestions
+
+**Structure:**
+
+```markdown
+## Overview
+
+[Comprehensive description]
+
+## Problem Statement / Motivation
+
+[Why this matters]
+
+## Proposed Solution
+
+[High-level approach]
+
+## Technical Considerations
+
+- Architecture impacts
+- Performance implications
+- Security considerations
+
+## Acceptance Criteria
+
+- [ ] Detailed requirement 1
+- [ ] Detailed requirement 2
+- [ ] Testing requirements
+
+## Success Metrics
+
+[How we measure success]
+
+## Dependencies & Risks
+
+[What could block or complicate this]
+
+## References & Research
+
+- Similar implementations: [file_path:line_number]
+- Best practices: [documentation_url]
+- Related PRs: #[pr_number]
+```
+
+#### 📚 A LOT (Comprehensive Issue)
+
+**Best for:** Major features, architectural changes, complex integrations
+
+**Includes everything from MORE plus:**
+
+- Detailed implementation plan with phases
+- Alternative approaches considered
+- Extensive technical specifications
+- Resource requirements and timeline
+- Future considerations and extensibility
+- Risk mitigation strategies
+- Documentation requirements
+
+**Structure:**
+
+```markdown
+## Overview
+
+[Executive summary]
+
+## Problem Statement
+
+[Detailed problem analysis]
+
+## Proposed Solution
+
+[Comprehensive solution design]
+
+## Technical Approach
+
+### Architecture
+
+[Detailed technical design]
+
+### Implementation Phases
+
+#### Phase 1: [Foundation]
+
+- Tasks and deliverables
+- Success criteria
+- Estimated effort
+
+#### Phase 2: [Core Implementation]
+
+- Tasks and deliverables
+- Success criteria
+- Estimated effort
+
+#### Phase 3: [Polish & Optimization]
+
+- Tasks and deliverables
+- Success criteria
+- Estimated effort
+
+## Alternative Approaches Considered
+
+[Other solutions evaluated and why rejected]
+
+## Acceptance Criteria
+
+### Functional Requirements
+
+- [ ] Detailed functional criteria
+
+### Non-Functional Requirements
+
+- [ ] Performance targets
+- [ ] Security requirements
+- [ ] Accessibility standards
+
+### Quality Gates
+
+- [ ] Test coverage requirements
+- [ ] Documentation completeness
+- [ ] Code review approval
+
+## Success Metrics
+
+[Detailed KPIs and measurement methods]
+
+## Dependencies & Prerequisites
+
+[Detailed dependency analysis]
+
+## Risk Analysis & Mitigation
+
+[Comprehensive risk assessment]
+
+## Resource Requirements
+
+[Team, time, infrastructure needs]
+
+## Future Considerations
+
+[Extensibility and long-term vision]
+
+## Documentation Plan
+
+[What docs need updating]
+
+## References & Research
+
+### Internal References
+
+- Architecture decisions: [file_path:line_number]
+- Similar features: [file_path:line_number]
+- Configuration: [file_path:line_number]
+
+### External References
+
+- Framework documentation: [url]
+- Best practices guide: [url]
+- Industry standards: [url]
+
+### Related Work
+
+- Previous PRs: #[pr_numbers]
+- Related issues: #[issue_numbers]
+- Design documents: [links]
+```
+
+### 4. Issue Creation & Formatting
+
+<thinking>
+Apply best practices for clarity and actionability, making the issue easy to scan and understand
+</thinking>
+
+**Content Formatting:**
+
+- [ ] Use clear, descriptive headings with proper hierarchy (##, ###)
+- [ ] Include code examples in triple backticks with language syntax highlighting
+- [ ] Add screenshots/mockups if UI-related (drag & drop or use image hosting)
+- [ ] Use task lists (- [ ]) for trackable items that can be checked off
+- [ ] Add collapsible sections for lengthy logs or optional details using `<details>` tags
+- [ ] Apply appropriate emoji for visual scanning (🐛 bug, ✨ feature, 📚 docs, ♻️ refactor)
+
+**Cross-Referencing:**
+
+- [ ] Link to related issues/PRs using #number format
+- [ ] Reference specific commits with SHA hashes when relevant
+- [ ] Link to code using GitHub's permalink feature (press 'y' for permanent link)
+- [ ] Mention relevant team members with @username if needed
+- [ ] Add links to external resources with descriptive text
+
+**Code & Examples:**
+
+```markdown
+# Good example with syntax highlighting and line references
+
+\`\`\`ruby
+
+# app/services/user_service.rb:42
+
+def process_user(user)
+
+# Implementation here
+
+end \`\`\`
+
+# Collapsible error logs
+
+<details>
+<summary>Full error stacktrace</summary>
+
+\`\`\` Error details here... \`\`\`
+
+</details>
+```
+
+**AI-Era Considerations:**
+
+- [ ] Account for accelerated development with AI pair programming
+- [ ] Include prompts or instructions that worked well during research
+- [ ] Note which AI tools were used for initial exploration (Claude, Copilot, etc.)
+- [ ] Emphasize comprehensive testing given rapid implementation
+- [ ] Document any AI-generated code that needs human review
+
+### 5. Final Review & Submission
+
+**Pre-submission Checklist:**
+
+- [ ] Title is searchable and descriptive
+- [ ] Labels accurately categorize the issue
+- [ ] All template sections are complete
+- [ ] Links and references are working
+- [ ] Acceptance criteria are measurable
+- [ ] Add names of files in pseudo code examples and todo lists
+- [ ] Add an ERD mermaid diagram if applicable for new model changes
+
+## Output Format
+
+Present the complete issue content within `<github_issue>` tags, ready for GitHub CLI:
+
+```bash
+gh issue create --title "[TITLE]" --body "[CONTENT]" --label "[LABELS]"
+```
+
+## Thinking Approaches
+
+- **Analytical:** Break down complex features into manageable components
+- **User-Centric:** Consider end-user impact and experience
+- **Technical:** Evaluate implementation complexity and architecture fit
+- **Strategic:** Align with project goals and roadmap

commands/resolve_todo_parallel.md

@@ -0,0 +1,29 @@
+Resolve all TODO comments using parallel processing.
+
+## Workflow
+
+### 1. Analyze
+
+Get all unresolved TODOs from the /todos/\*.md directory
+
+### 2. Plan
+
+Create a TodoWrite list of all unresolved items grouped by type.Make sure to look at dependencies that might occur and prioritize the ones needed by others. For example, if you need to change a name, you must wait to do the others. Output a mermaid flow diagram showing how we can do this. Can we do everything in parallel? Do we need to do one first that leads to others in parallel? I'll put the to-dos in the mermaid diagram flow‑wise so the agent knows how to proceed in order.
+
+### 3. Implement (PARALLEL)
+
+Spawn a pr-comment-resolver agent for each unresolved item in parallel.
+
+So if there are 3 comments, it will spawn 3 pr-comment-resolver agents in parallel. liek this
+
+1. Task pr-comment-resolver(comment1)
+2. Task pr-comment-resolver(comment2)
+3. Task pr-comment-resolver(comment3)
+
+Always run all in parallel subagents/Tasks for each Todo item.
+
+### 4. Commit & Resolve
+
+- Commit changes
+- Remove the TODO from the file, and mark it as resolved.
+- Push to remote

commands/review.md

@@ -0,0 +1,390 @@
+# Review Command
+
+<command_purpose> Perform exhaustive code reviews using multi-agent analysis, ultra-thinking, and Git worktrees for deep local inspection. </command_purpose>
+
+## Introduction
+
+<role>Senior Code Review Architect with expertise in security, performance, architecture, and quality assurance</role>
+
+## Prerequisites
+
+<requirements>
+- Git repository with GitHub CLI (`gh`) installed and authenticated
+- Clean main/master branch
+- Proper permissions to create worktrees and access the repository
+- For document reviews: Path to a markdown file or document
+</requirements>
+
+## Main Tasks
+
+### 1. Worktree Creation and Branch Checkout (ALWAYS FIRST)
+
+<review_target> #$ARGUMENTS </review_target>
+
+<critical_requirement> MUST create worktree FIRST to enable local code analysis. No exceptions. </critical_requirement>
+
+<thinking>
+First, I need to determine the review target type and set up the worktree.
+This enables all subsequent agents to analyze actual code, not just diffs.
+</thinking>
+
+#### Immediate Actions:
+
+<task_list>
+
+- [ ] Determine review type: PR number (numeric), GitHub URL, file path (.md), or empty (latest PR)
+- [ ] Create worktree directory structure at `$git_root/.worktrees/reviews/pr-$identifier`
+- [ ] Check out PR branch in isolated worktree using `gh pr checkout`
+- [ ] Navigate to worktree - ALL subsequent analysis happens here
+
+- Fetch PR metadata using `gh pr view --json` for title, body, files, linked issues
+- Clone PR branch into worktree with full history `gh pr checkout $identifier`
+- Set up language-specific analysis tools
+- Prepare security scanning environment
+
+Ensure that the worktree is set up correctly and that the PR is checked out. ONLY then proceed to the next step.
+
+</task_list>
+
+#### Detect Project Type
+
+<thinking>
+Determine the project type by analyzing the codebase structure and files.
+This will inform which language-specific reviewers to use.
+</thinking>
+
+<project_type_detection>
+
+Check for these indicators to determine project type:
+
+**Rails Project**:
+- `Gemfile` with `rails` gem
+- `config/application.rb`
+- `app/` directory structure
+
+**TypeScript Project**:
+- `tsconfig.json`
+- `package.json` with TypeScript dependencies
+- `.ts` or `.tsx` files
+
+**Python Project**:
+- `requirements.txt` or `pyproject.toml`
+- `.py` files
+- `setup.py` or `poetry.lock`
+
+Based on detection, set appropriate reviewers for parallel execution.
+
+</project_type_detection>
+
+#### Parallel Agents to review the PR:
+
+<parallel_tasks>
+
+Run ALL or most of these agents at the same time, adjusting language-specific reviewers based on project type:
+
+**Language-Specific Reviewers (choose based on project type)**:
+
+For Rails projects:
+1. Task kieran-rails-reviewer(PR content)
+2. Task dhh-rails-reviewer(PR title)
+3. If turbo is used: Task rails-turbo-expert(PR content)
+
+For TypeScript projects:
+1. Task kieran-typescript-reviewer(PR content)
+
+For Python projects:
+1. Task kieran-python-reviewer(PR content)
+
+**Universal Reviewers (run for all project types)**:
+4. Task git-history-analyzer(PR content)
+5. Task dependency-detective(PR content)
+6. Task pattern-recognition-specialist(PR content)
+7. Task architecture-strategist(PR content)
+8. Task code-philosopher(PR content)
+9. Task security-sentinel(PR content)
+10. Task performance-oracle(PR content)
+11. Task devops-harmony-analyst(PR content)
+12. Task data-integrity-guardian(PR content)
+
+</parallel_tasks>
+
+### 4. Ultra-Thinking Deep Dive Phases
+
+<ultrathink_instruction> For each phase below, spend maximum cognitive effort. Think step by step. Consider all angles. Question assumptions. And bring all reviews in a synthesis to the user.</ultrathink_instruction>
+
+<deliverable>
+Complete system context map with component interactions
+</deliverable>
+
+#### Phase 3: Stakeholder Perspective Analysis
+
+<thinking_prompt> ULTRA-THINK: Put yourself in each stakeholder's shoes. What matters to them? What are their pain points? </thinking_prompt>
+
+<stakeholder_perspectives>
+
+1. **Developer Perspective** <questions>
+
+   - How easy is this to understand and modify?
+   - Are the APIs intuitive?
+   - Is debugging straightforward?
+   - Can I test this easily? </questions>
+
+2. **Operations Perspective** <questions>
+
+   - How do I deploy this safely?
+   - What metrics and logs are available?
+   - How do I troubleshoot issues?
+   - What are the resource requirements? </questions>
+
+3. **End User Perspective** <questions>
+
+   - Is the feature intuitive?
+   - Are error messages helpful?
+   - Is performance acceptable?
+   - Does it solve my problem? </questions>
+
+4. **Security Team Perspective** <questions>
+
+   - What's the attack surface?
+   - Are there compliance requirements?
+   - How is data protected?
+   - What are the audit capabilities? </questions>
+
+5. **Business Perspective** <questions>
+   - What's the ROI?
+   - Are there legal/compliance risks?
+   - How does this affect time-to-market?
+   - What's the total cost of ownership? </questions> </stakeholder_perspectives>
+
+#### Phase 4: Scenario Exploration
+
+<thinking_prompt> ULTRA-THINK: Explore edge cases and failure scenarios. What could go wrong? How does the system behave under stress? </thinking_prompt>
+
+<scenario_checklist>
+
+- [ ] **Happy Path**: Normal operation with valid inputs
+- [ ] **Invalid Inputs**: Null, empty, malformed data
+- [ ] **Boundary Conditions**: Min/max values, empty collections
+- [ ] **Concurrent Access**: Race conditions, deadlocks
+- [ ] **Scale Testing**: 10x, 100x, 1000x normal load
+- [ ] **Network Issues**: Timeouts, partial failures
+- [ ] **Resource Exhaustion**: Memory, disk, connections
+- [ ] **Security Attacks**: Injection, overflow, DoS
+- [ ] **Data Corruption**: Partial writes, inconsistency
+- [ ] **Cascading Failures**: Downstream service issues </scenario_checklist>
+
+### 6. Multi-Angle Review Perspectives
+
+#### Technical Excellence Angle
+
+- Code craftsmanship evaluation
+- Engineering best practices
+- Technical documentation quality
+- Tooling and automation assessment
+
+#### Business Value Angle
+
+- Feature completeness validation
+- Performance impact on users
+- Cost-benefit analysis
+- Time-to-market considerations
+
+#### Risk Management Angle
+
+- Security risk assessment
+- Operational risk evaluation
+- Compliance risk verification
+- Technical debt accumulation
+
+#### Team Dynamics Angle
+
+- Code review etiquette
+- Knowledge sharing effectiveness
+- Collaboration patterns
+- Mentoring opportunities
+
+### 4. Simplification and Minimalism Review
+
+Run the Task code-simplicity-reviewer() to see if we can simplify the code.
+
+### 5. Findings Synthesis and Todo Creation
+
+<critical_requirement> All findings MUST be converted to actionable todos in the CLI todo system </critical_requirement>
+
+#### Step 1: Synthesize All Findings
+
+<thinking>
+Consolidate all agent reports into a categorized list of findings.
+Remove duplicates, prioritize by severity and impact.
+</thinking>
+
+<synthesis_tasks>
+- [ ] Collect findings from all parallel agents
+- [ ] Categorize by type: security, performance, architecture, quality, etc.
+- [ ] Assign severity levels: 🔴 CRITICAL (P1), 🟡 IMPORTANT (P2), 🔵 NICE-TO-HAVE (P3)
+- [ ] Remove duplicate or overlapping findings
+- [ ] Estimate effort for each finding (Small/Medium/Large)
+</synthesis_tasks>
+
+#### Step 2: Present Findings for Triage
+
+For EACH finding, present in this format:
+
+```
+---
+Finding #X: [Brief Title]
+
+Severity: 🔴 P1 / 🟡 P2 / 🔵 P3
+
+Category: [Security/Performance/Architecture/Quality/etc.]
+
+Description:
+[Detailed explanation of the issue or improvement]
+
+Location: [file_path:line_number]
+
+Problem:
+[What's wrong or could be better]
+
+Impact:
+[Why this matters, what could happen]
+
+Proposed Solution:
+[How to fix it]
+
+Effort: Small/Medium/Large
+
+---
+Do you want to add this to the todo list?
+1. yes - create todo file
+2. next - skip this finding
+3. custom - modify before creating
+```
+
+#### Step 3: Create Todo Files for Approved Findings
+
+<instructions>
+When user says "yes", create a properly formatted todo file:
+</instructions>
+
+<todo_creation_process>
+
+1. **Determine next issue ID:**
+   ```bash
+   ls todos/ | grep -o '^[0-9]\+' | sort -n | tail -1
+   ```
+
+2. **Generate filename:**
+   ```
+   {next_id}-pending-{priority}-{brief-description}.md
+   ```
+   Example: `042-pending-p1-sql-injection-risk.md`
+
+3. **Create file from template:**
+   ```bash
+   cp todos/000-pending-p1-TEMPLATE.md todos/{new_filename}
+   ```
+
+4. **Populate with finding data:**
+   ```yaml
+   ---
+   status: pending
+   priority: p1  # or p2, p3 based on severity
+   issue_id: "042"
+   tags: [code-review, security, rails]  # add relevant tags
+   dependencies: []
+   ---
+
+   # [Finding Title]
+
+   ## Problem Statement
+   [Detailed description from finding]
+
+   ## Findings
+   - Discovered during code review by [agent names]
+   - Location: [file_path:line_number]
+   - [Key discoveries from agents]
+
+   ## Proposed Solutions
+
+   ### Option 1: [Primary solution from finding]
+   - **Pros**: [Benefits]
+   - **Cons**: [Drawbacks]
+   - **Effort**: [Small/Medium/Large]
+   - **Risk**: [Low/Medium/High]
+
+   ## Recommended Action
+   [Leave blank - needs manager triage]
+
+   ## Technical Details
+   - **Affected Files**: [List from finding]
+   - **Related Components**: [Models, controllers, services affected]
+   - **Database Changes**: [Yes/No - describe if yes]
+
+   ## Resources
+   - Code review PR: [PR link if applicable]
+   - Related findings: [Other finding numbers]
+   - Agent reports: [Which agents flagged this]
+
+   ## Acceptance Criteria
+   - [ ] [Specific criteria based on solution]
+   - [ ] Tests pass
+   - [ ] Code reviewed
+
+   ## Work Log
+
+   ### {date} - Code Review Discovery
+   **By:** Claude Code Review System
+   **Actions:**
+   - Discovered during comprehensive code review
+   - Analyzed by multiple specialized agents
+   - Categorized and prioritized
+
+   **Learnings:**
+   - [Key insights from agent analysis]
+
+   ## Notes
+   Source: Code review performed on {date}
+   Review command: /workflows:review {arguments}
+   ```
+
+5. **Track creation:**
+   Add to TodoWrite list if tracking multiple findings
+
+</todo_creation_process>
+
+#### Step 4: Summary Report
+
+After processing all findings:
+
+```markdown
+## Code Review Complete
+
+**Review Target:** [PR number or branch]
+**Total Findings:** [X]
+**Todos Created:** [Y]
+
+### Created Todos:
+- `{issue_id}-pending-p1-{description}.md` - {title}
+- `{issue_id}-pending-p2-{description}.md` - {title}
+...
+
+### Skipped Findings:
+- [Finding #Z]: {reason}
+...
+
+### Next Steps:
+1. Triage pending todos: `ls todos/*-pending-*.md`
+2. Use `/triage` to review and approve
+3. Work on approved items: `/resolve_todo_parallel`
+```
+
+#### Alternative: Batch Creation
+
+If user wants to convert all findings to todos without review:
+
+```bash
+# Ask: "Create todos for all X findings? (yes/no/show-critical-only)"
+# If yes: create todo files for all findings in parallel
+# If show-critical-only: only present P1 findings for triage
+```

commands/triage.md

@@ -0,0 +1,222 @@
+Present all findings, decisions, or issues here one by one for triage. The goal is to go through each item and decide whether to add it to the CLI todo system.
+
+**IMPORTANT: DO NOT CODE ANYTHING DURING TRIAGE!**
+
+This command is for:
+- Triaging code review findings
+- Processing security audit results
+- Reviewing performance analysis
+- Handling any other categorized findings that need tracking
+
+## Workflow
+
+### Step 1: Present Each Finding
+
+For each finding, present in this format:
+
+```
+---
+Issue #X: [Brief Title]
+
+Severity: 🔴 P1 (CRITICAL) / 🟡 P2 (IMPORTANT) / 🔵 P3 (NICE-TO-HAVE)
+
+Category: [Security/Performance/Architecture/Bug/Feature/etc.]
+
+Description:
+[Detailed explanation of the issue or improvement]
+
+Location: [file_path:line_number]
+
+Problem Scenario:
+[Step by step what's wrong or could happen]
+
+Proposed Solution:
+[How to fix it]
+
+Estimated Effort: [Small (< 2 hours) / Medium (2-8 hours) / Large (> 8 hours)]
+
+---
+Do you want to add this to the todo list?
+1. yes - create todo file
+2. next - skip this item
+3. custom - modify before creating
+```
+
+### Step 2: Handle User Decision
+
+**When user says "yes":**
+
+1. **Determine next issue ID:**
+   ```bash
+   ls todos/ | grep -o '^[0-9]\+' | sort -n | tail -1
+   ```
+
+2. **Create filename:**
+   ```
+   {next_id}-pending-{priority}-{brief-description}.md
+   ```
+
+   Priority mapping:
+   - 🔴 P1 (CRITICAL) → `p1`
+   - 🟡 P2 (IMPORTANT) → `p2`
+   - 🔵 P3 (NICE-TO-HAVE) → `p3`
+
+   Example: `042-pending-p1-transaction-boundaries.md`
+
+3. **Create from template:**
+   ```bash
+   cp todos/000-pending-p1-TEMPLATE.md todos/{new_filename}
+   ```
+
+4. **Populate the file:**
+   ```yaml
+   ---
+   status: pending
+   priority: p1  # or p2, p3 based on severity
+   issue_id: "042"
+   tags: [category, relevant-tags]
+   dependencies: []
+   ---
+
+   # [Issue Title]
+
+   ## Problem Statement
+   [Description from finding]
+
+   ## Findings
+   - [Key discoveries]
+   - Location: [file_path:line_number]
+   - [Scenario details]
+
+   ## Proposed Solutions
+
+   ### Option 1: [Primary solution]
+   - **Pros**: [Benefits]
+   - **Cons**: [Drawbacks if any]
+   - **Effort**: [Small/Medium/Large]
+   - **Risk**: [Low/Medium/High]
+
+   ## Recommended Action
+   [Leave blank - will be filled during approval]
+
+   ## Technical Details
+   - **Affected Files**: [List files]
+   - **Related Components**: [Components affected]
+   - **Database Changes**: [Yes/No - describe if yes]
+
+   ## Resources
+   - Original finding: [Source of this issue]
+   - Related issues: [If any]
+
+   ## Acceptance Criteria
+   - [ ] [Specific success criteria]
+   - [ ] Tests pass
+   - [ ] Code reviewed
+
+   ## Work Log
+
+   ### {date} - Initial Discovery
+   **By:** Claude Triage System
+   **Actions:**
+   - Issue discovered during [triage session type]
+   - Categorized as {severity}
+   - Estimated effort: {effort}
+
+   **Learnings:**
+   - [Context and insights]
+
+   ## Notes
+   Source: Triage session on {date}
+   ```
+
+5. **Confirm creation:**
+   "✅ Created: `{filename}` - Issue #{issue_id}"
+
+**When user says "next":**
+- Skip to the next item
+- Track skipped items for summary
+
+**When user says "custom":**
+- Ask what to modify (priority, description, details)
+- Update the information
+- Present revised version
+- Ask again: yes/next/custom
+
+### Step 3: Continue Until All Processed
+
+- Process all items one by one
+- Track using TodoWrite for visibility
+- Don't wait for approval between items - keep moving
+
+### Step 4: Final Summary
+
+After all items processed:
+
+```markdown
+## Triage Complete
+
+**Total Items:** [X]
+**Todos Created:** [Y]
+**Skipped:** [Z]
+
+### Created Todos:
+- `042-pending-p1-transaction-boundaries.md` - Transaction boundary issue
+- `043-pending-p2-cache-optimization.md` - Cache performance improvement
+...
+
+### Skipped Items:
+- Item #5: [reason]
+- Item #12: [reason]
+
+### Next Steps:
+1. Review pending todos: `ls todos/*-pending-*.md`
+2. Approve for work: Move from pending → ready status
+3. Start work: Use `/resolve_todo_parallel` or pick individually
+```
+
+## Example Response Format
+
+```
+---
+Issue #5: Missing Transaction Boundaries for Multi-Step Operations
+
+Severity: 🔴 P1 (CRITICAL)
+
+Category: Data Integrity / Security
+
+Description:
+The google_oauth2_connected callback in GoogleOauthCallbacks concern performs multiple database
+operations without transaction protection. If any step fails midway, the database is left in an
+inconsistent state.
+
+Location: app/controllers/concerns/google_oauth_callbacks.rb:13-50
+
+Problem Scenario:
+1. User.update succeeds (email changed)
+2. Account.save! fails (validation error)
+3. Result: User has changed email but no associated Account
+4. Next login attempt fails completely
+
+Operations Without Transaction:
+- User confirmation (line 13)
+- Waitlist removal (line 14)
+- User profile update (line 21-23)
+- Account creation (line 28-37)
+- Avatar attachment (line 39-45)
+- Journey creation (line 47)
+
+Proposed Solution:
+Wrap all operations in ApplicationRecord.transaction do ... end block
+
+Estimated Effort: Small (30 minutes)
+
+---
+Do you want to add this to the todo list?
+1. yes - create todo file
+2. next - skip this item
+3. custom - modify before creating
+```
+
+Do not code, and if you say yes, make sure to mark the to‑do as ready to pick up or something. If you make any changes, update the file and then continue to read the next one. If next is selecrte make sure to remove the to‑do from the list since its not relevant.
+
+Every time you present the to‑do as a header, can you say what the progress of the triage is, how many we have done and how many are left, and an estimated time for completion, looking at how quickly we go through them as well?

commands/work.md

@@ -0,0 +1,150 @@
+# Work Plan Execution Command
+
+## Introduction
+
+This command helps you analyze a work document (plan, Markdown file, specification, or any structured document), create a comprehensive todo list using the TodoWrite tool, and then systematically execute each task until the entire plan is completed. It combines deep analysis with practical execution to transform plans into reality.
+
+## Prerequisites
+
+- A work document to analyze (plan file, specification, or any structured document)
+- Clear understanding of project context and goals
+- Access to necessary tools and permissions for implementation
+- Ability to test and validate completed work
+- Git repository with main branch
+
+## Main Tasks
+
+### 1. Setup Development Environment
+
+- Ensure main branch is up to date
+- Create feature branch with descriptive name
+- Setup worktree for isolated development
+- Configure development environment
+
+### 2. Analyze Input Document
+
+<input_document> #$ARGUMENTS </input_document>
+
+## Execution Workflow
+
+### Phase 1: Environment Setup
+
+1. **Update Main Branch**
+
+   ```bash
+   git checkout main
+   git pull origin main
+   ```
+
+2. **Create Feature Branch and Worktree**
+
+   - Determine appropriate branch name from document
+   - Get the root directory of the Git repository:
+
+   ```bash
+   git_root=$(git rev-parse --show-toplevel)
+   ```
+
+   - Create worktrees directory if it doesn't exist:
+
+   ```bash
+   mkdir -p "$git_root/.worktrees"
+   ```
+
+   - Add .worktrees to .gitignore if not already there:
+
+   ```bash
+   if ! grep -q "^\.worktrees$" "$git_root/.gitignore"; then
+     echo ".worktrees" >> "$git_root/.gitignore"
+   fi
+   ```
+
+   - Create the new worktree with feature branch:
+
+   ```bash
+   git worktree add -b feature-branch-name "$git_root/.worktrees/feature-branch-name" main
+   ```
+
+   - Change to the new worktree directory:
+
+   ```bash
+   cd "$git_root/.worktrees/feature-branch-name"
+   ```
+
+3. **Verify Environment**
+   - Confirm in correct worktree directory
+   - Install dependencies if needed
+   - Run initial tests to ensure clean state
+
+### Phase 2: Document Analysis and Planning
+
+1. **Read Input Document**
+
+   - Use Read tool to examine the work document
+   - Identify all deliverables and requirements
+   - Note any constraints or dependencies
+   - Extract success criteria
+
+2. **Create Task Breakdown**
+
+   - Convert requirements into specific tasks
+   - Add implementation details for each task
+   - Include testing and validation steps
+   - Consider edge cases and error handling
+
+3. **Build Todo List**
+   - Use TodoWrite to create comprehensive list
+   - Set priorities based on dependencies
+   - Include all subtasks and checkpoints
+   - Add documentation and review tasks
+
+### Phase 3: Systematic Execution
+
+1. **Task Execution Loop**
+
+   ```
+   while (tasks remain):
+     - Select next task (priority + dependencies)
+     - Mark as in_progress
+     - Execute task completely
+     - Validate completion
+     - Mark as completed
+     - Update progress
+   ```
+
+2. **Quality Assurance**
+
+   - Run tests after each task
+   - Execute lint and typecheck commands
+   - Verify no regressions
+   - Check against acceptance criteria
+   - Document any issues found
+
+3. **Progress Tracking**
+   - Regularly update task status
+   - Note any blockers or delays
+   - Create new tasks for discoveries
+   - Maintain work visibility
+
+### Phase 4: Completion and Submission
+
+1. **Final Validation**
+
+   - Verify all tasks completed
+   - Run comprehensive test suite
+   - Execute final lint and typecheck
+   - Check all deliverables present
+   - Ensure documentation updated
+
+2. **Prepare for Submission**
+
+   - Stage and commit all changes
+   - Write commit messages
+   - Push feature branch to remote
+   - Create detailed pull request
+
+3. **Create Pull Request**
+   ```bash
+   git push -u origin feature-branch-name
+   gh pr create --title "Feature: [Description]" --body "[Detailed description]"
+   ```