reactree-rails-dev

ReAcTree-based systematic debugging with memory-assisted analysis, log parsing, root cause identification, and regression prevention. Uses specialized agents for comprehensive error investigation and fix verification.

ReAcTree-based Rails development with parallel execution, working memory, and episodic learning for 30-50% faster workflows. Comprehensive multi-agent orchestration with automatic skill discovery and quality gates.

ReAcTree-based feature development with user stories, acceptance criteria, TDD emphasis, and parallel execution. Specializes in user-centric development with comprehensive validation against acceptance criteria.

Initialize ReAcTree plugin in the current Rails project. Creates configuration, validates prerequisites, sets up working memory, and copies bundled skills, agents, hooks, and rules to the project. Run this first when using the plugin in a new project.

ReAcTree-based safe refactoring workflow with test preservation, reference tracking, and quality gates. Specializes in code transformation while maintaining all existing functionality and test coverage.

Action Cable and WebSocket specialist for Rails real-time features. Implements channels, connections, broadcasting patterns, and client-side subscriptions following Rails conventions and security best practices. Use this agent when: Implementing real-time chat features, live notifications, presence tracking, collaborative editing, broadcasting model updates, or any WebSocket functionality. Always invoked by implementation-executor for Action Cable features. Examples: <example> Context: Implementing real-time notifications channel user: "Create Action Cable channel for user notifications" assistant: "Creating NotificationsChannel with proper authorization and broadcasting. **Channel Implementation Plan:** - Personal user streams (notifications_user_id) - Authorization in subscribed method - mark_as_read client action - Broadcast unread count updates **Generating channel...** <invoke name='Write'> <parameter name='file_path'>app/channels/notifications_channel.rb</parameter> <parameter name='content'> class NotificationsChannel < ApplicationCable::Channel def subscribed # Authorization FIRST reject unless current_user # Subscribe to personal notification stream stream_from \"notifications_#{current_user.id}\" end def unsubscribed # Cleanup when client disconnects end def mark_as_read(data) notification = current_user.notifications.find(data['id']) notification.mark_as_read! # Broadcast updated count ActionCable.server.broadcast( \"notifications_#{current_user.id}\", action: 'count_updated', unread_count: current_user.notifications.unread.count ) end end </parameter> </invoke> ✅ Created: app/channels/notifications_channel.rb **Next Steps:** - Client JavaScript subscription in app/javascript/channels/notifications_channel.js - Model broadcasting in app/models/notification.rb (after_create_commit) - Channel spec in spec/channels/notifications_channel_spec.rb" <commentary> The action-cable-specialist always implements authorization first using 'reject unless' and follows the pattern of persisting data before broadcasting. </commentary> </example>

Backend service layer specialist for Rails applications. Creates service objects, controllers, and API endpoints. Uses Write tool to generate actual files following discovered project conventions and service-object-patterns. Use this agent when: Implementing business logic, creating service objects, building controllers, or adding API endpoints. Always invoked by implementation-executor. Examples: <example> Context: Payment processing service with Stripe integration user: "Create PaymentService::Process to handle payment creation with Stripe" assistant: "Creating backend service for payment processing. **Skill Analysis:** - service-object-patterns: Use callable pattern with .call method - Project convention: Services use Result object pattern - API integration: External Stripe API, needs error handling **Files to Create:** 1. Service: app/services/payment_service/process.rb 2. Service Spec: spec/services/payment_service/process_spec.rb **Generating Files...** <invoke name='Write'> <parameter name='file_path'>app/services/payment_service/process.rb</parameter> <parameter name='content'> module PaymentService class Process def self.call(user:, amount:, payment_method:) new(user: user, amount: amount, payment_method: payment_method).call end def initialize(user:, amount:, payment_method:) @user = user @amount = amount @payment_method = payment_method end def call validate_inputs create_payment_record process_with_stripe Result.success(payment: @payment) rescue Stripe::CardError => e Result.failure(error: e.message, code: :card_declined) rescue StandardError => e Result.failure(error: e.message, code: :processing_error) end private attr_reader :user, :amount, :payment_method def validate_inputs raise ArgumentError, 'Amount must be positive' unless amount.positive? raise ArgumentError, 'User must be present' unless user.present? end def create_payment_record @payment = Payment.create!( user: user, account: user.account, amount: amount, status: :pending ) end def process_with_stripe stripe_payment = Stripe::PaymentIntent.create( amount: (@amount * 100).to_i, currency: 'usd', customer: user.stripe_customer_id, payment_method: @payment_method, confirm: true ) @payment.update!( stripe_id: stripe_payment.id, status: :succeeded ) end end end </parameter> </invoke> ✅ Created service: app/services/payment_service/process.rb **Summary:** - Service uses callable pattern (.call class method) - Result object for success/failure handling - Proper error handling for Stripe API - Payment record created before API call for tracking" <commentary> The backend-lead agent uses the Write tool directly to create service objects that follow the project's service-object-patterns skill. </commentary> </example>

Precision code location agent for finding exact method definitions, class declarations, and symbol usages within Rails codebases. Leverages LSP (Language Server Protocol) for accurate symbol lookup when available, falling back to intelligent Grep patterns for Ruby-specific searches. Returns results in file:line format for direct navigation. The finder understands Ruby syntax including method definitions (def/end), class inheritance, module inclusion, and Rails-specific patterns like ActiveRecord associations, validations, and callbacks. Can trace method calls through the codebase to find all usages. Use this agent when: - Need to find where a specific method is defined (e.g., "where is authenticate_user! defined") - Looking for all usages/references of a method or class across the codebase - Tracing method calls to understand code flow - Finding class or module definitions - Locating Rails-specific elements (associations, validations, callbacks, scopes) - Need exact line numbers for navigation or debugging - Understanding inheritance hierarchies and module mixins Use PROACTIVELY for precise code location during debugging or code review. Examples: <example> Context: Developer needs to find method definition user: "Where is the authenticate_user! method defined?" assistant: "Locating authenticate_user! definition... **LSP goToDefinition Result:** 📍 `app/controllers/application_controller.rb:23` **Definition:** ```ruby def authenticate_user! redirect_to login_path, alert: 'Please sign in' unless current_user end ``` **Also checking for overrides:** - No overrides found in child controllers **Usages Found (15 references):** | File | Line | Context | |------|------|---------| | app/controllers/orders_controller.rb | 3 | `before_action :authenticate_user!` | | app/controllers/payments_controller.rb | 5 | `before_action :authenticate_user!` | | app/controllers/api/base_controller.rb | 8 | `skip_before_action :authenticate_user!` | | ... | ... | ... | Primary definition at application_controller.rb:23, used in 15 controllers." <commentary> Uses LSP for precise definition lookup, then Grep to find all usages, providing complete picture of method usage. </commentary> </example> <example> Context: Tracing a service object call chain user: "Find all calls to PaymentService.call" assistant: "Tracing PaymentService.call invocations... **Pattern:** `PaymentService\.(call|new)` **Call Sites Found:** 1. 📍 `app/controllers/payments_controller.rb:34` ```ruby result = PaymentService.call(user: current_user, amount: params[:amount]) ``` 2. 📍 `app/jobs/process_payment_job.rb:12` ```ruby PaymentService.call(user: user, amount: amount, async: true) ``` 3. 📍 `app/services/checkout_service.rb:45` ```ruby payment = PaymentService.new(order.user) payment.call(amount: order.total) ``` 4. 📍 `spec/services/payment_service_spec.rb:15` ```ruby described_class.call(user: user, amount: 100) ``` Found 4 call sites (3 production, 1 test)." <commentary> Traces method calls across codebase, distinguishing between production and test code. </commentary> </example>

Systematic Rails codebase analysis for implementation planning. Discovers patterns (service objects, components, auth helpers), conventions (naming, organization), and dependencies. All findings cached to working memory as verified facts for other agents to reference, preventing assumption bugs. Use this agent when: Starting feature development (Phase 2), analyzing auth patterns, verifying codebase assumptions, or discovering gems/frameworks in use. Use PROACTIVELY at workflow start. Examples: <example> Context: Developer requests JWT authentication implementation user: "Add JWT authentication with refresh tokens" assistant: "Activating Codebase Inspector to analyze existing auth patterns before planning. **Discovery Protocol:** 1. Scanning app/controllers/ for auth-related concerns and before_actions 2. Checking for Devise, Warden, or custom auth implementations 3. Identifying current_user helper location and signature 4. Mapping session management patterns 5. Finding existing token-based auth if any **Findings cached to working memory:** - Auth: Devise with :database_authenticatable, :jwt_authenticatable (via devise-jwt gem) - Helper: `current_user` in ApplicationController, returns User or nil - Pattern: API controllers inherit from Api::BaseController with token auth - Convention: JWT tokens stored in Authorization header with Bearer scheme Rails Planner can now design JWT refresh implementation using verified patterns." <commentary> The codebase inspector must run first to prevent assumption bugs. It discovers actual patterns rather than assuming common Rails conventions, and caches findings for other agents. </commentary> </example> <example> Context: Workflow orchestrator triggered Phase 2 for e-commerce feature assistant: "Phase 2: Codebase Inspection initiated for payment processing feature. **Systematic Analysis:** | Layer | Pattern Discovered | Confidence | |-------|-------------------|------------| | Models | STI for Payment types (CreditCard, BankTransfer) | High | | Services | ApplicationService base class with .call interface | High | | Controllers | Api::V1:: namespace, Jbuilder responses | High | | Components | ViewComponent with Stimulus controllers | Medium | | Testing | RSpec + FactoryBot + VCR for external APIs | High | **Critical Discoveries:** - Payment gateway: Stripe via `stripe` gem, wrapped in PaymentGateway service - Money handling: `money-rails` gem with currency stored as cents - Async: Sidekiq for webhook processing Caching 12 verified facts to working memory. Planning phase can proceed." <commentary> Demonstrates systematic inspection with confidence levels and structured output that rails-planner will consume. </commentary> </example>

LSP-powered context compilation agent using cclsp MCP tools + Sorbet. Extracts interfaces and builds vocabulary after planning, before implementation. Use this agent when: Phase 3.5 is active and cclsp tools are available. Runs CONDITIONALLY only when cclsp MCP exists - graceful skip otherwise. Responsibilities: - Per-task interface extraction using find_definition/find_references - Project vocabulary building from symbols, patterns, types - Sorbet type information extraction when available - Store compiled context in working memory for implementation-executor

Executes LOOP and CONDITIONAL control flow nodes in ReAcTree workflows. Manages iterative cycles (TDD red-green-refactor, retry logic), branching paths (environment checks, feature flags), and state persistence in .claude/reactree-state.jsonl. Implements condition caching with 5-minute TTL. Use this agent when: - Implementing red-green-refactor TDD cycles that iterate until tests pass - Managing retry logic for flaky external API calls or transient failures - Executing environment-specific branches (development vs production) - Evaluating feature flags to determine execution path - Handling conditional deployment steps based on test results - Managing nested LOOP/CONDITIONAL combinations - Persisting control flow state across session boundaries - Enforcing iteration limits and timeout protection Use PROACTIVELY when ReAcTree workflows contain LOOP or CONDITIONAL nodes. Examples: <example> Context: TDD workflow with red-green-refactor loop user: (Workflow orchestrator triggers LOOP node) assistant: "Control Flow Manager: Executing LOOP node 'tdd-cycle'. **Loop Configuration:** - Type: RED_GREEN_REFACTOR - Max iterations: 10 - Termination: All specs pass AND coverage >= 85% **Iteration 1 (RED):** - Test Oracle: Wrote 12 failing specs - Status: ❌ Expected (specs should fail) - Continue: Yes **Iteration 2 (GREEN):** - Implementation Executor: Wrote minimal code - Test Oracle: 10/12 specs pass - Status: ❌ 2 specs still failing - Continue: Yes **Iteration 3 (GREEN continued):** - Implementation Executor: Fixed edge cases - Test Oracle: 12/12 specs pass, coverage 82% - Status: ❌ Coverage below threshold - Continue: Yes **Iteration 4 (REFACTOR):** - Implementation Executor: Added missing branch coverage - Test Oracle: 12/12 specs pass, coverage 87% - Status: ✅ Termination conditions met **Loop Complete:** - Total iterations: 4 - Final state: GREEN with 87% coverage - Persisted to .claude/reactree-state.jsonl" <commentary> Demonstrates LOOP execution with termination condition checking and iteration tracking. </commentary> </example> <example> Context: Conditional deployment based on test results assistant: "Control Flow Manager: Evaluating CONDITIONAL node 'deploy-check'. **Condition Tree:** ``` IF tests_pass AND coverage >= 85%: IF environment == 'production': → run_canary_deploy ELSE: → run_full_deploy ELSE: → skip_deploy_notify_team ``` **Evaluations (with caching):** | Condition | Result | Cached | TTL | |-----------|--------|--------|-----| | tests_pass | true | No (first eval) | 5min | | coverage >= 85% | true (87%) | No | 5min | | environment | 'staging' | Yes (env var) | ∞ | **Branch Selected:** `run_full_deploy` **Nested Conditional:** None for staging Proceeding with full deployment to staging environment." <commentary> Shows CONDITIONAL evaluation with nested conditions and caching for efficiency. </commentary> </example>

Database layer specialist for Rails applications. Creates database migrations, ActiveRecord models with validations/associations, and test factories. Uses Write tool to generate actual files following discovered project conventions. Use this agent when: Implementing database schema changes, creating models, adding associations, or generating factories. Always invoked by implementation-executor. Examples: <example> Context: Creating Payment model with Stripe integration user: "Create Payment model with amount, status, stripe_id, belongs_to user and account" assistant: "Creating database layer for Payment model. **Skill Analysis:** - activerecord-patterns: Use decimal for money, enum for status, add indexes - Project convention: All models include account_id for multi-tenancy **Files to Create:** 1. Migration: db/migrate/[timestamp]_create_payments.rb 2. Model: app/models/payment.rb 3. Factory: spec/factories/payments.rb 4. Model Spec: spec/models/payment_spec.rb **Generating Files...** <invoke name='Write'> <parameter name='file_path'>db/migrate/20250102120000_create_payments.rb</parameter> <parameter name='content'> class CreatePayments < ActiveRecord::Migration[7.1] def change create_table :payments do |t| t.references :account, null: false, foreign_key: true, index: true t.references :user, null: false, foreign_key: true, index: true t.decimal :amount, precision: 10, scale: 2, null: false t.integer :status, default: 0, null: false t.string :stripe_id t.timestamps end add_index :payments, :stripe_id, unique: true add_index :payments, :status end end </parameter> </invoke> ✅ Created migration: db/migrate/20250102120000_create_payments.rb <invoke name='Write'> <parameter name='file_path'>app/models/payment.rb</parameter> <parameter name='content'> class Payment < ApplicationRecord belongs_to :account belongs_to :user enum status: { pending: 0, processing: 1, succeeded: 2, failed: 3, refunded: 4 } validates :amount, presence: true, numericality: { greater_than: 0 } validates :stripe_id, uniqueness: true, allow_nil: true validates :status, presence: true end </parameter> </invoke> ✅ Created model: app/models/payment.rb **Summary:** - Migration created with proper indexes and foreign keys - Model includes validations and associations - Multi-tenancy (account_id) included per project convention - Money stored as decimal(10,2) per activerecord-patterns skill - Status enum following Rails best practices" <commentary> The data-lead agent uses the Write tool directly to create actual files, following discovered patterns from skills and project conventions. </commentary> </example>

Specialized agent for managing FEEDBACK edges in ReAcTree workflows - the backwards communication channels that enable self-correcting development cycles. Routes error reports, test failures, and architectural issues from child nodes back to parent nodes, coordinates fix-verify cycles, prevents infinite feedback loops through round limiting and cycle detection, and maintains complete audit trails. The coordinator implements four feedback types: FIX_REQUEST (code fixes needed), CONTEXT_REQUEST (more information needed), DEPENDENCY_MISSING (blocking dependency), and ARCHITECTURE_ISSUE (design problem requiring replanning). Each feedback type has different routing logic and resolution patterns. Maintains state in .claude/reactree-feedback.jsonl for session persistence. Use this agent when: - Test Oracle detects spec failures that need routing back to Implementation Executor - Implementation Executor discovers missing context that Codebase Inspector should provide - Dependency resolution is needed between parallel execution branches - Architecture issues discovered during implementation require Rails Planner revision - Need to prevent infinite fix-verify loops (max 2 rounds per agent pair) - Tracking feedback resolution across multi-session workflows - Coordinating parent re-execution after child provides fixed output - Managing escalation when feedback rounds are exhausted Use PROACTIVELY when FEEDBACK edges are triggered in any ReAcTree workflow. Examples: <example> Context: Test Oracle reports failing specs to Implementation Executor user: (Internal routing from Test Oracle) assistant: "FEEDBACK Coordinator activated. **Incoming Feedback:** - Type: FIX_REQUEST - Source: test-oracle - Target: implementation-executor - Payload: 3 failing specs with stack traces **Loop Prevention Check:** - Previous rounds between test-oracle → implementation-executor: 0 - Max allowed: 2 - Status: ✅ Proceeding **Routing Action:** 1. Packaging failure context for Implementation Executor 2. Including relevant source files from working memory 3. Setting fix deadline: 1 round 4. Registering callback for Test Oracle re-verification **Audit Entry:** ```json { \"timestamp\": \"2024-01-15T10:30:00Z\", \"feedback_id\": \"FB-001\", \"type\": \"FIX_REQUEST\", \"source\": \"test-oracle\", \"target\": \"implementation-executor\", \"round\": 1, \"status\": \"routed\" } ``` Implementation Executor will receive feedback with full context." <commentary> Demonstrates FIX_REQUEST routing with loop prevention, context packaging, and audit logging. </commentary> </example> <example> Context: Second round of feedback for same agent pair assistant: "FEEDBACK Coordinator: Round limit approaching. **Loop Prevention Alert:** - Agent pair: test-oracle → implementation-executor - Current round: 2 (max: 2) - Previous fix attempt: Stripe API parameter format **Escalation Protocol:** Since this is round 2, if fix fails again: 1. FEEDBACK will escalate to Workflow Orchestrator 2. May require Rails Planner revision (ARCHITECTURE_ISSUE) 3. Or human intervention flagged **This Round:** - Routing with elevated priority - Including both failure stack traces AND previous fix attempts - Implementation Executor has full history If this fix succeeds, feedback loop closes successfully. If it fails, escalating to workflow-orchestrator with ARCHITECTURE_ISSUE." <commentary> Shows round limit handling and escalation protocol when fixes aren't working. </commentary> </example>

Fast, lightweight file discovery agent optimized for quickly locating files within Rails project structures. Uses Glob patterns for path matching, Grep for content-based file finding, and Bash for directory exploration. Designed for minimal latency using the haiku model, making it ideal for quick lookups during development workflows. The finder understands Rails directory conventions (app/models, app/controllers, app/services, etc.) and can locate files by name patterns, content snippets, or structural queries. Returns results in a structured format with file paths, sizes, and modification times. Use this agent when: - Need to quickly find a file by partial name (e.g., "find user controller") - Looking for files matching a pattern (e.g., "all service objects") - Discovering what files exist in a directory structure - Finding files by content without reading them fully (e.g., "files containing PaymentService") - Locating configuration files (database.yml, routes.rb, etc.) - Exploring unfamiliar parts of a Rails codebase - Quick lookups during implementation where speed matters more than deep analysis Use PROACTIVELY for rapid file discovery during development workflows. Examples: <example> Context: Developer needs to find payment-related files user: "Find all payment service files" assistant: "Searching for payment service files... **Glob Pattern:** `app/services/**/payment*.rb` **Results:** | File | Size | Modified | |------|------|----------| | app/services/payment_service.rb | 2.4KB | 2 days ago | | app/services/payments/create_charge.rb | 1.1KB | 1 week ago | | app/services/payments/refund_service.rb | 890B | 3 days ago | | app/services/payments/webhook_handler.rb | 3.2KB | 1 day ago | Found 4 files matching payment service pattern." <commentary> Quick file discovery using Rails-aware glob patterns. Returns structured results for easy navigation. </commentary> </example> <example> Context: Looking for files that use a specific class user: "Find files that use StripeClient" assistant: "Searching for files containing 'StripeClient'... **Grep Search:** `StripeClient` in `app/**/*.rb` **Results:** | File | Line | Context | |------|------|---------| | app/services/payment_service.rb | 15 | `@client = StripeClient.new` | | app/services/subscription_service.rb | 8 | `StripeClient.configure` | | app/jobs/sync_stripe_job.rb | 22 | `StripeClient.fetch_all` | | spec/support/stripe_helper.rb | 5 | `let(:client) { StripeClient.mock }` | Found 4 files referencing StripeClient." <commentary> Content-based file finding using Grep, with line numbers and context for quick navigation. </commentary> </example>

Expert Git change analysis agent for understanding diffs, commit history, and code evolution. Analyzes current changes (staged/unstaged), compares branches, investigates file history, and provides git blame insights. Uses sonnet model for deeper reasoning about change patterns and impact assessment. Essential for PR descriptions, code review preparation, and understanding what changed. The analyzer groups changes by Rails layer (models, controllers, services, etc.), identifies breaking changes, and can generate structured summaries suitable for pull request descriptions. Understands Rails-specific change implications like migration additions or route modifications. Use this agent when: - Need to understand what changed since last commit or between branches - Preparing pull request descriptions with structured change summaries - Investigating who modified specific code and when (git blame) - Comparing feature branch against main before merge - Understanding the evolution of a file over time - Analyzing change patterns for code review - Finding when a bug was introduced (git bisect preparation) - Generating changelogs or release notes Use PROACTIVELY when preparing PRs, reviewing changes, or investigating code history. Examples: <example> Context: Developer needs PR description for feature branch user: "Analyze changes for PR description" assistant: "Analyzing changes between main and current branch... **Branch:** feature/subscription-billing **Commits:** 12 commits ahead of main **Files Changed:** 24 **Insertions:** +1,247 **Deletions:** -89 **Summary by Rails Layer:** | Layer | Files | Changes | Key Modifications | |-------|-------|---------|-------------------| | Migrations | 2 | +45 | create_subscriptions, create_plans | | Models | 3 | +156 | Subscription, Plan, User associations | | Services | 4 | +412 | SubscriptionService (Create, Cancel, Renew, Webhook) | | Controllers | 2 | +178 | Api::V1::SubscriptionsController, WebhooksController | | Specs | 8 | +367 | Full test coverage for above | | Config | 5 | +89 | Routes, Stripe config, locales | **Breaking Changes:** ⚠️ Migration required: Run `rails db:migrate` ⚠️ New ENV var: `STRIPE_WEBHOOK_SECRET` **PR Description Draft:** ## Summary Implements subscription billing with Stripe integration, including plan management, subscription lifecycle, and webhook handling. ## Changes - Added Subscription and Plan models with Stripe sync - Created SubscriptionService with Create/Cancel/Renew operations - Added API endpoints for subscription management - Implemented Stripe webhook handler for subscription events ## Testing - 47 new specs, 100% coverage on new code - Manual testing with Stripe test mode" <commentary> Comprehensive change analysis grouped by Rails layer, with breaking change detection and PR description generation. </commentary> </example> <example> Context: Investigating who changed specific code user: "Who last modified the PaymentService refund method?" assistant: "Analyzing git blame for PaymentService#refund... **File:** app/services/payment_service.rb **Method:** refund (lines 45-67) **Blame Results:** | Line | Author | Date | Commit | Change | |------|--------|------|--------|--------| | 45 | Sarah Chen | 2024-01-10 | abc123 | Method signature | | 46-50 | Sarah Chen | 2024-01-10 | abc123 | Stripe API call | | 51-55 | John Smith | 2024-01-15 | def456 | Added error handling | | 56-60 | Sarah Chen | 2024-01-10 | abc123 | Response formatting | | 61-67 | Maria Garcia | 2024-01-20 | ghi789 | Added partial refund support | **Key Commits:** 1. **abc123** (Sarah Chen, 2024-01-10) 'Implement PaymentService with refund support' Initial implementation of refund method 2. **def456** (John Smith, 2024-01-15) 'Add error handling for Stripe failures' Added rescue blocks for Stripe::Error 3. **ghi789** (Maria Garcia, 2024-01-20) 'Support partial refunds' Added amount parameter, changed from full refund Most recent significant change by Maria Garcia (8 days ago) added partial refund support." <commentary> Detailed blame analysis with commit context, showing the evolution of specific code. </commentary> </example>

Rails server log analysis agent for parsing development.log, production.log, and test.log files. Specializes in finding errors, analyzing slow queries, tracing request flows, and identifying performance issues. Uses haiku model for fast log parsing with pattern recognition for Rails log formats including SQL queries, controller actions, and error stack traces. The analyzer understands Rails log structure including request lifecycle (Started/Processing/Completed), SQL query timing, cache hits/misses, and error levels (DEBUG/INFO/WARN/ERROR/FATAL). Can correlate logs by request ID and identify patterns like N+1 queries. Use this agent when: - Need to find errors in Rails server logs - Looking for specific requests by path, controller, or request ID - Analyzing slow database queries (queries over 100ms) - Debugging request/response issues - Identifying N+1 query patterns - Monitoring application behavior in development or production - Finding the most common errors in recent logs - Tracing a single request through the Rails stack Use PROACTIVELY for debugging, performance analysis, or error investigation. Examples: <example> Context: Developer needs to find recent errors user: "Show me recent errors from the development log" assistant: "Analyzing log/development.log for errors... **Time Range:** Last 1 hour **Total Requests:** 342 **Errors Found:** 5 **Error Summary:** | Type | Count | Last Seen | Severity | |------|-------|-----------|----------| | NoMethodError | 3 | 10:45:23 | High | | ActiveRecord::RecordNotFound | 1 | 10:32:15 | Medium | | Stripe::InvalidRequestError | 1 | 10:28:44 | High | **Error Details:** 1. 🔴 **NoMethodError** (3 occurrences) 📍 Line 1234, 1456, 1678 ``` NoMethodError: undefined method `name' for nil:NilClass app/models/user.rb:45:in `display_name' app/controllers/users_controller.rb:12:in `show' ``` **Likely Cause:** User record not found before accessing name **Affected Requests:** GET /users/123, GET /users/456, GET /users/789 2. 🟡 **ActiveRecord::RecordNotFound** 📍 Line 892 ``` ActiveRecord::RecordNotFound: Couldn't find Order with 'id'=999 ``` **Request:** GET /orders/999 (user_id: 42) 3. 🔴 **Stripe::InvalidRequestError** 📍 Line 567 ``` Stripe::InvalidRequestError: No such customer: 'cus_invalid' ``` **Request:** POST /subscriptions (user_id: 15) **Likely Cause:** Stale Stripe customer ID in database" <commentary> Comprehensive error analysis with context, severity, and likely causes for quick debugging. </commentary> </example> <example> Context: Investigating slow performance user: "Find slow database queries in the logs" assistant: "Analyzing log/development.log for slow queries... **Threshold:** Queries > 100ms **Time Range:** Last 30 minutes **Slow Queries Found:** 8 **Top Slow Queries:** 1. 🐌 **423ms** - Line 2341 ```sql SELECT * FROM orders WHERE user_id = 42 ORDER BY created_at DESC ``` **Issue:** Missing index on user_id **Fix:** `add_index :orders, :user_id` 2. 🐌 **312ms** - Line 2567 ```sql SELECT * FROM products WHERE category_id IN (1,2,3,4,5,6,7,8,9,10) ``` **Issue:** Large IN clause, consider JOIN **Count:** 3 occurrences 3. 🐌 **187ms** - Line 1892 ```sql SELECT COUNT(*) FROM notifications WHERE user_id = 42 AND read = false ``` **Issue:** Full table scan on boolean column **Fix:** `add_index :notifications, [:user_id, :read]` **N+1 Query Pattern Detected:** 📍 Lines 3001-3045 ``` Order Load (2.1ms) SELECT * FROM orders WHERE id = 1 User Load (1.8ms) SELECT * FROM users WHERE id = 42 # repeated 15x ``` **Fix:** Add `includes(:user)` to order query **Performance Summary:** - Total query time in slow queries: 1,847ms - Most impactful fix: Index on orders.user_id (saves ~420ms)" <commentary> Identifies slow queries with actionable fix suggestions, including N+1 detection. </commentary> </example>

Strategic Rails implementation planning. Transforms requirements and codebase inspection findings into executable plans with database schemas, service architectures, API contracts, and component hierarchies. Optimizes for parallel execution. Use this agent when: Designing implementation after Phase 2 (Inspection), planning database schemas, architecting services, or identifying parallel execution opportunities. Use PROACTIVELY before implementation. Examples: <example> Context: Planning subscription billing after codebase inspection completed user: "Design the implementation plan for subscription billing" assistant: "Creating implementation plan using verified patterns from working memory. **Database Layer (Parallel Group A):** - Migration: create_subscriptions (user_id, plan_id, status, current_period_start/end, stripe_subscription_id) - Migration: create_plans (name, price_cents, interval, stripe_price_id) - Model: Subscription with belongs_to :user, :plan, enum status - Model: Plan with has_many :subscriptions, money :price **Service Layer (Parallel Group B, after A):** - SubscriptionService::Create < ApplicationService (per discovered pattern) - SubscriptionService::Cancel with proration handling - StripeWebhookService for subscription.updated events **API Layer (Parallel Group C, after B):** - Api::V1::SubscriptionsController (index, show, create, destroy) - Jbuilder views per project convention **Parallel Execution Map:** ``` [Migrations] ─┬─> [Models] ─┬─> [Services] ─┬─> [Controllers] │ │ │ └─> [Specs] └─> [Specs] └─> [Specs] ``` Total: 4 parallel groups, estimated 12 files, 47 RSpec examples needed." <commentary> The planner uses codebase inspector findings (ApplicationService pattern, Jbuilder, API namespacing) to design consistent implementations and identifies parallel execution opportunities. </commentary> </example> <example> Context: Hotwire-based real-time feature planning user: "Plan the implementation for live order status updates" assistant: "Designing Hotwire implementation using discovered Turbo Stream patterns. **From Working Memory:** - Turbo: Already using turbo-rails with ActionCable - Components: OrderStatusBadgeComponent exists, uses Stimulus - Broadcasts: Pattern is `Turbo::StreamsChannel.broadcast_update_to` **Implementation Plan:** 1. **Model Enhancement:** - Add `broadcasts_to :customer` to Order model - after_update_commit callback for status changes 2. **Turbo Stream Template:** - app/views/orders/_order.turbo_stream.erb - Updates order-status-{id} target 3. **Stimulus Controller Enhancement:** - Extend existing order_status_controller.js - Add sound notification on status change 4. **ViewComponent Update:** - OrderStatusBadgeComponent gains `streaming: true` option - Wraps content in turbo_frame_tag **Test Plan:** - System spec: Order status update broadcasts to customer - Component spec: Renders with correct turbo frame - Integration spec: ActionCable subscription works Zero new files needed - extending existing patterns." <commentary> Planner respects existing Hotwire setup from codebase inspection rather than introducing new patterns, ensuring consistency. </commentary> </example>

RSpec testing specialist for Rails applications. Creates comprehensive test coverage for models, services, controllers, and components. Uses Write tool to generate actual spec files following RSpec best practices and project conventions. Use this agent when: Adding test coverage for implemented features, creating model/service/controller/component specs, or improving test quality. Always invoked by implementation-executor or test-oracle. Examples: <example> Context: Testing Payment model with associations and validations user: "Create RSpec tests for Payment model" assistant: "Creating comprehensive test coverage for Payment model. **Test Coverage Plan:** - Associations (belongs_to :user, :account) - Validations (amount presence, status enum) - Scopes (recent, for_user) - Instance methods (if any) **Generating spec...** <invoke name='Write'> <parameter name='file_path'>spec/models/payment_spec.rb</parameter> <parameter name='content'> require 'rails_helper' RSpec.describe Payment, type: :model do describe 'associations' do it { should belong_to(:account) } it { should belong_to(:user) } end describe 'validations' do it { should validate_presence_of(:amount) } it { should validate_numericality_of(:amount).is_greater_than(0) } end describe 'enums' do it { should define_enum_for(:status) .with_values(pending: 0, succeeded: 1, failed: 2) } end end </parameter> </invoke> ✅ Created: spec/models/payment_spec.rb **Coverage: 100% of model behavior tested**" <commentary> The rspec-specialist uses shoulda-matchers for concise, readable specs that test all model behavior comprehensively. </commentary> </example>

Proactive technical debt scanner for Rails codebases. Analyzes code for debt indicators: code smells, complexity metrics, deprecations, security issues, performance anti-patterns, and architecture violations. Outputs categorized findings with severity scores and remediation recommendations. Use this agent when: (1) Auditing codebase health, (2) Before major feature work, (3) Planning refactoring sprints, (4) Periodic debt tracking, (5) Sprint estimation. Examples: <example> Context: Developer wants to audit codebase health before a major feature user: "Scan the codebase for technical debt before we start the billing rewrite" assistant: "Activating Technical Debt Detector for comprehensive audit. **Phase 1: Tool Availability Check** - Flog: Available (complexity scoring) - Reek: Available (code smell detection) - Rubocop: Available (style + lint) - Brakeman: Available (security vulnerabilities) - bundler-audit: Available (gem CVEs) **Phase 2: Code Smell Analysis** | Smell Type | Count | Worst Offenders | |------------|-------|-----------------| | Long Method | 12 | PaymentService#process (89 lines) | | Large Class | 3 | User model (542 lines) | | Feature Envy | 8 | OrderCalculator#apply_discount | | Data Clump | 5 | Address params across controllers | **Phase 3: Complexity Metrics** | File | Flog Score | Rating | |------|------------|--------| | app/services/payment_service.rb | 127.3 | Critical | | app/models/user.rb | 89.4 | High | | app/controllers/orders_controller.rb | 67.2 | High | **Technical Debt Report Summary:** - Critical: 2 items (address before feature work) - High: 8 items (include in sprint planning) - Medium: 15 items (track for future) - Low: 23 items (opportunistic fixes) Creating beads issues for critical items..." <commentary> The debt detector runs a systematic 7-phase analysis and outputs a prioritized report. Critical items block feature work; high items should be planned. </commentary> </example> <example> Context: Team planning refactoring sprint assistant: "Technical Debt Report for Sprint Planning **Top 10 Debt Items by Severity Score:** | # | Category | Location | Severity | Effort | ROI | |---|----------|----------|----------|--------|-----| | 1 | Security | User auth | Critical | 2d | High | | 2 | Complexity | PaymentService | Critical | 3d | High | | 3 | Architecture | God object User | High | 5d | Medium | | 4 | Performance | N+1 in OrdersController | High | 1d | High | | 5 | Deprecation | Rails 6.1 deprecation warnings | High | 2d | Medium | **Recommended Sprint Focus:** 1. Security debt (items #1) - immediate risk 2. Performance debt (item #4) - quick win, high impact 3. Complexity debt (item #2) - blocks billing feature **Beads Issues Created:** - PROJ-45: Fix auth vulnerability (Critical, blocked) - PROJ-46: Refactor PaymentService complexity (Critical) - PROJ-47: Fix N+1 queries in OrdersController (High)" <commentary> Demonstrates integration with beads for actionable sprint planning and provides ROI-based prioritization for team decision making. </commentary> </example>

Authoritative test planning and validation agent that ensures comprehensive test coverage before, during, and after implementation. Enforces test-driven development discipline through red-green-refactor cycles, validates test pyramid ratios (70% unit, 20% integration, 10% system), analyzes coverage gaps, and ensures test quality standards. Acts as the gatekeeper for Phase 5 (Verification) in ReAcTree workflows. The Test Oracle operates in two modes: (1) Pre-implementation test planning where it designs the complete test suite structure before any code is written (TDD mode), and (2) Post-implementation validation where it verifies coverage, runs specs, and identifies missing test scenarios. Uses FEEDBACK edges to report failures back to implementation-executor for fixes. Use this agent when: - Workflow orchestrator initiates Phase 5 (Verification) after implementation - Need to design test suite structure before implementation (TDD mode with --test-first) - Validating that implementation meets coverage thresholds (default 85%) - Analyzing test pyramid ratios to ensure proper unit/integration/system balance - Running RSpec suite and interpreting failures for FEEDBACK routing - Ensuring test quality (no pending specs, proper assertions, factory usage) - Creating red-green-refactor cycles with LOOP control flow - Verifying edge cases and error handling coverage Use PROACTIVELY in test-first mode or after implementation phase completes. Examples: <example> Context: User requests TDD approach for new feature user: "Implement user notifications with test-first approach" assistant: "Activating Test Oracle in TDD mode. **Test Suite Design (RED phase):** 📊 **Test Pyramid Plan:** | Level | Count | Percentage | |-------|-------|------------| | Unit (Models, Services) | 28 | 70% | | Integration (Requests) | 8 | 20% | | System (Features) | 4 | 10% | | **Total** | **40** | **100%** | **Unit Tests:** - Notification model: 6 specs (validations, associations, scopes) - NotificationService::Create: 8 specs (success, failures, edge cases) - NotificationService::MarkRead: 4 specs - NotificationDeliveryJob: 5 specs (retry logic, error handling) - NotificationComponent: 5 specs (rendering variants) **Integration Tests:** - POST /notifications: 3 specs (auth, params, response) - GET /notifications: 3 specs (pagination, filtering) - PATCH /notifications/:id/read: 2 specs **System Tests:** - User receives notification: 2 specs (web, email) - User marks notification read: 2 specs Writing failing specs now. Implementation can begin after RED phase confirms all 40 specs fail." <commentary> Test Oracle designs complete test structure upfront for TDD, ensuring proper pyramid ratios and comprehensive coverage before any production code. </commentary> </example> <example> Context: Phase 5 verification after implementation assistant: "Phase 5: Test Verification initiated. **Running RSpec Suite:** ``` 40 examples, 3 failures, 0 pending Coverage: 87.2% (threshold: 85%) ✅ ``` **Failure Analysis:** 1. `NotificationService::Create handles duplicate notifications` - Expected: raises DuplicateNotificationError - Actual: creates duplicate record - **Severity: High** - Data integrity issue 2. `Notification model validates presence of user` - Expected: to validate presence of :user - Actual: no validation present - **Severity: Medium** - Missing validation 3. `NotificationComponent renders unread badge` - Expected: badge with 'New' text - Actual: empty string - **Severity: Low** - UI issue **FEEDBACK Edge Triggered:** Routing 3 failures to Implementation Executor with fix requests. Priority order: High → Medium → Low Max feedback rounds: 2 Test Oracle will re-run specs after fixes applied." <commentary> Demonstrates post-implementation verification with failure analysis, severity classification, and FEEDBACK edge routing for fixes. </commentary> </example>

Frontend UI specialist for Rails applications. Creates ViewComponents, ERB views, Stimulus controllers, and Hotwire/Turbo integrations. Uses Write tool to generate actual files following discovered UI patterns and accessibility guidelines. Use this agent when: Implementing UI components, creating views, building Stimulus controllers, or adding Turbo Streams. Always invoked by implementation-executor. Examples: <example> Context: Payment card component with TailAdmin styling user: "Create PaymentCardComponent to display payment info with status badge" assistant: "Creating UI component for payment display. **Skill Analysis:** - viewcomponents-specialist: Expose all template methods as public - tailadmin-patterns: Use card layout with shadow, status colors - accessibility-patterns: Add ARIA labels, semantic HTML **Files to Create:** 1. Component: app/components/payments/card_component.rb 2. Template: app/components/payments/card_component.html.erb 3. Preview: spec/components/previews/payments/card_component_preview.rb 4. Spec: spec/components/payments/card_component_spec.rb **Generating Files...** <invoke name='Write'> <parameter name='file_path'>app/components/payments/card_component.rb</parameter> <parameter name='content'> module Payments class CardComponent < ApplicationComponent def initialize(payment:) @payment = payment end def formatted_amount helpers.number_to_currency(@payment.amount) end def status_badge_class case @payment.status when 'succeeded' 'bg-green-50 text-green-700 border-green-200' when 'pending' 'bg-yellow-50 text-yellow-700 border-yellow-200' when 'failed' 'bg-red-50 text-red-700 border-red-200' else 'bg-gray-50 text-gray-700 border-gray-200' end end def formatted_date @payment.created_at.strftime('%b %d, %Y') end end end </parameter> </invoke> ✅ Created: app/components/payments/card_component.rb **Summary:** - Component exposes public methods for template - Status badge uses TailAdmin color scheme - Accessible with proper semantic structure" <commentary> The ui-specialist agent uses the Write tool directly to create ViewComponents that follow the viewcomponents-specialist skill patterns. </commentary> </example>

Full UX lifecycle specialist providing real-time guidance on accessibility (WCAG 2.2 AA), responsive design, animations/transitions, user flows, dark mode, and performance optimization. Runs in PARALLEL with Phase 5 (View/UI) to ensure production-ready user experiences. Use this agent when: - Implementing UI components needing accessibility compliance - Designing responsive layouts for mobile-first development - Adding animations, transitions, and micro-interactions - Implementing dark mode with TailAdmin patterns - Optimizing for Core Web Vitals performance - Creating loading states, feedback systems, and form UX Trigger keywords: accessibility, a11y, WCAG, ARIA, responsive, mobile-first, animation, transition, dark mode, loading state, skeleton, toast, form UX, performance, Core Web Vitals

WCAG 2.2 Level AA compliance for Rails/ViewComponent/Hotwire. Use when: (1) Building interactive widgets, (2) Handling form validation errors, (3) Adding dynamic content with Turbo Streams, (4) Auditing existing components. Trigger keywords: accessibility, a11y, WCAG, ARIA, screen reader, keyboard, focus, contrast

Real-time WebSocket features with Action Cable in Rails. Use when: (1) Building real-time chat, (2) Live notifications/presence, (3) Broadcasting model updates, (4) WebSocket authorization. Trigger keywords: Action Cable, WebSocket, real-time, channels, broadcasting, stream, subscriptions, presence, cable

Complete guide to ActiveRecord query optimization, associations, scopes, and PostgreSQL-specific patterns. Use when: (1) Writing database queries, (2) Designing model associations, (3) Creating migrations, (4) Optimizing query performance, (5) Debugging N+1 queries and GROUP BY errors. Trigger keywords: database, models, associations, validations, queries, ActiveRecord, scopes, migrations, N+1, PostgreSQL, indexes, eager loading

Comprehensive guide to building production-ready REST APIs in Rails with serialization, authentication, versioning, rate limiting, and testing. Trigger keywords: REST API, JSON, serialization, versioning, authentication, JWT, rate limiting, API controllers, request specs, API testing, endpoints, responses

Expert decision trees for Solargraph, Sorbet, and Rubocop validation in Rails. Use when: (1) Choosing which quality tool for a task, (2) Debugging type errors or lint failures, (3) Setting up validation pipelines, (4) Deciding strictness levels. Trigger keywords: quality gates, validation, solargraph, sorbet, rubocop, type checking, linting, code quality, static analysis, type safety, srb tc

Mandatory inspection before writing any Rails code. Use when: (1) Starting ANY implementation task, (2) Making architectural decisions, (3) Suggesting patterns or conventions, (4) Creating new files/classes. Core rule: Never plan without file path citations. Trigger keywords: analyze, inspect, patterns, conventions, codebase, discover, structure, dependencies, existing, before

LSP-powered context extraction using cclsp MCP tools, Solargraph, and Sorbet for type-safe code generation. Trigger keywords: cclsp, LSP, context compilation, interface extraction, vocabulary, Guardian, Sorbet, type checking, find_definition, get_diagnostics, Solargraph, type safety

Complete guide to Hotwire implementation including Turbo Drive, Turbo Frames, Turbo Streams, and Stimulus controllers in Rails applications. Use when: (1) Implementing partial page updates, (2) Adding real-time features, (3) Creating Turbo Frames and Streams, (4) Writing Stimulus controllers, (5) Debugging Turbo-related issues. Trigger keywords: Turbo, Stimulus, Hotwire, real-time, SPA, live updates, ActionCable, broadcasts, turbo_stream, turbo_frame

Production-ready safety checklists for Rails implementation. Covers nil safety, ActiveRecord patterns, security vulnerabilities, error handling, and performance. Use before marking any file complete during implementation phases.

Chief Content Copywriter with comprehensive internationalization skill for Ruby on Rails applications with proper English, Arabic, French and Spanish translations, RTL support, pluralization rules, date/time formatting, and culturally appropriate content adaptation. Use when: (1) Setting up i18n in Rails, (2) Adding RTL/Arabic support, (3) Implementing pluralization, (4) Formatting dates/currency, (5) Creating locale files. Trigger keywords: i18n, translations, localization, internationalization, locale, RTL, Arabic, multilingual, localize, translate

Systematic verification of codebase context before code generation to prevent assumption bugs. Use when: (1) Working in unfamiliar namespace, (2) Using authentication helpers, (3) Copying patterns across namespaces, (4) Before any code generation. Trigger keywords: context, assumptions, helpers, authentication, current_user, verify, validate context

Ruby on Rails conventions, design patterns, and idiomatic code standards. Use when: (1) Writing controllers/models/services, (2) Choosing patterns (Service, Form, Query objects), (3) Making architectural decisions, (4) Reviewing code for conventions. Trigger keywords: rails conventions, design patterns, idiomatic code, best practices, code organization, naming conventions, MVC patterns

Expert checklist for preventing common Rails runtime errors BEFORE writing code. Use when: (1) Creating ViewComponents - template/method exposure errors, (2) Writing GROUP BY queries - PostgreSQL grouping errors, (3) Building views that call component methods, (4) Debugging 'undefined method' errors. Trigger keywords: errors, bugs, NoMethodError, template not found, N+1, GROUP BY, PG::GroupingError, undefined method, nil, debugging, prevention

**Hierarchical Agent Trees**: Complex tasks decomposed into tree structures where each node can be an agent (reasoning + action) or control flow coordinator.

Complete refactoring workflow with tracking, validation, and cross-layer impact checklists. Integrates with beads for progress tracking and ensures no references to old names remain after refactoring.

Translate user prompts into structured requirements, user stories, and beads tasks. Use when: (1) Parsing user feature requests, (2) Creating acceptance criteria, (3) Breaking down epics into tasks, (4) Auto-generating beads issues. Trigger keywords: requirements, user story, acceptance criteria, as a, i want, so that, given when then, task breakdown, epic creation

Write clear, testable requirements using User Stories and Gherkin scenarios. Capture functional and non-functional requirements with proper acceptance criteria. Use when defining new features or documenting system behavior. Trigger keywords: requirements, user stories, acceptance criteria, Gherkin, BDD, specifications, feature definition

Complete guide to testing Ruby on Rails applications with RSpec. Use when: (1) Writing unit tests, integration tests, system tests, (2) Setting up test factories, (3) Creating shared examples, (4) Mocking external services, (5) Testing ViewComponents and background jobs. Trigger keywords: tests, specs, RSpec, TDD, testing, test coverage, FactoryBot, fixtures, mocks, stubs, shoulda-matchers

Comprehensive guide to Object-Oriented Programming in Ruby and Rails covering classes, modules, design patterns, SOLID principles, and modern Ruby 3.x features. Trigger keywords: OOP, classes, modules, SOLID, design patterns, inheritance, composition, polymorphism, encapsulation, Ruby patterns, metaprogramming

Complete guide to implementing Service Objects in Ruby on Rails applications. Use when: (1) Creating business logic services, (2) Refactoring fat models/controllers, (3) Organizing service namespaces, (4) Handling service results, (5) Designing service interfaces. Trigger keywords: service objects, business logic, use cases, operations, command pattern, interactors, PORO, application services

Complete guide to background job processing with Sidekiq in Ruby on Rails. Use this skill when: (1) Creating background jobs, (2) Configuring queues and workers, (3) Implementing retry logic and error handling, (4) Designing idempotent jobs, (5) Setting up scheduled/recurring jobs, (6) Optimizing job performance. Trigger keywords: background jobs, async, Sidekiq, workers, queues, ActiveJob, cron, scheduling, Redis, concurrency

Automatic workflow suggestion and utility agent routing based on prompt analysis. Trigger keywords: auto-detect, intent, suggest, trigger, routing, workflow detection, utility agents, prompt analysis, smart routing

TailAdmin dashboard UI framework patterns and Tailwind CSS classes. ALWAYS use this skill when: (1) Building any dashboard or admin panel interface, (2) Creating data tables, cards, charts, or metrics displays, (3) Implementing forms, buttons, alerts, or modals, (4) Building navigation (sidebar, header, breadcrumbs), (5) Any UI work that should follow TailAdmin design. This skill REQUIRES fetching from the official GitHub repository to ensure accurate class usage - NEVER invent classes. Trigger keywords: TailwindCSS, admin, UI, styling, components, dashboard, tailadmin, tables, charts

Expert guide to detecting, categorizing, and prioritizing technical debt in Rails applications. Use when: (1) Auditing codebase health, (2) Planning refactoring sprints, (3) Estimating feature impact, (4) Identifying code smells, (5) Tracking deprecations. Trigger keywords: technical debt, code smell, complexity, cyclomatic, deprecation, legacy, refactor, audit, health check, god class

Comprehensive UX design patterns for Rails applications including responsive design, animations/transitions, dark mode, loading states, form UX, and performance optimization. Use this skill when implementing user-facing features requiring polished interactions and responsive layouts. Trigger keywords: UX, responsive, mobile-first, animation, transition, dark mode, loading, skeleton, progress, toast, form validation, performance, Core Web Vitals, user flow

Expert patterns for ViewComponent implementation, slots, previews, and method exposure. Use when: (1) Creating ViewComponents, (2) Implementing slots or content blocks, (3) Setting up component previews, (4) Debugging template/rendering errors, (5) Exposing service methods to views. Trigger keywords: ViewComponent, components, UI, rendering, slots, previews, partials, presenters, render_inline, erb

4 hooks across 4 events