@codyswann/lisa 2.195.4 → 2.195.6

package/plugins/lisa-rails/.codex-plugin/skills/action-view-best-practices/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Action View Best Practices"
+short_description: "Build or Refactor Rails views…"
+default_prompt:
+  - "Use $action-view-best-practices: Build or Refactor Rails views…."

package/plugins/lisa-rails/.codex-plugin/skills/active-record-model-best-practices/SKILL.md

@@ -0,0 +1,166 @@
+---
+name: active-record-model-best-practices
+description: "Best practices for Ruby on…"
+---
+
+# Rails Model Refactoring
+
+When refactoring a Rails model, analyze the file and extract code into the appropriate pattern based on what the code does. The model itself should only contain associations, enums, basic validations, and concern includes.
+
+## Decision Framework
+
+Read the model file and classify each block of code:
+
+| Code type | Extract to | Location |
+|---|---|---|
+| Related scopes + simple methods sharing a theme | Concern | `app/models/concerns/` |
+| Business logic, multi-step operations, callbacks with side effects | Service object | `app/services/` |
+| Complex queries, multi-join scopes, reporting queries | Query object | `app/queries/` |
+| Context-specific validations (e.g. registration vs admin update) | Form object | `app/forms/` |
+| Domain concepts beyond a primitive (money, coordinates, scores) | Value object | `app/models/` |
+| Associations, enums, core validations, simple scopes | Keep on model | — |
+
+## Patterns
+
+### Concerns
+
+Use for grouping related scopes, validations, callbacks, and simple instance methods that share a single theme. Name the concern after the capability it provides.
+
+```ruby
+# app/models/concerns/searchable.rb
+module Searchable
+  extend ActiveSupport::Concern
+
+  included do
+    scope :search, ->(query) { where("name ILIKE ?", "%#{query}%") }
+  end
+
+  def matching_terms(query)
+    name.scan(/#{Regexp.escape(query)}/i)
+  end
+end
+```
+
+### Service Objects
+
+Use for business logic, orchestration of multiple models, and anything triggered by a user action that involves more than a simple CRUD operation. Follow the single-responsibility principle — one service, one operation.
+
+```ruby
+# app/services/players/calculate_stats.rb
+module Players
+  class CalculateStats
+    def initialize(player)
+      @player = player
+    end
+
+    def call
+      # complex logic here
+    end
+  end
+end
+```
+
+Conventions:
+- Namespace under the model name: `Players::CalculateStats`
+- Single public method: `call`
+- Accept dependencies via `initialize`
+- Return a result or raise a domain-specific error
+
+### Query Objects
+
+Use for complex database queries that involve joins, subqueries, CTEs, or multi-condition filtering that would clutter a model with scopes.
+
+```ruby
+# app/queries/players/free_agent_query.rb
+module Players
+  class FreeAgentQuery
+    def initialize(relation = Player.all)
+      @relation = relation
+    end
+
+    def call(filters = {})
+      @relation
+        .where(contract_status: :expired)
+        .where("age < ?", filters[:max_age])
+        .joins(:stats)
+        .order(war: :desc)
+    end
+  end
+end
+```
+
+Conventions:
+- Accept a base relation in `initialize` (default to `Model.all`)
+- Return an ActiveRecord relation so it remains chainable
+- Single public method: `call`
+
+### Form Objects
+
+Use when validations only apply in specific contexts, or when a form spans multiple models.
+
+```ruby
+# app/forms/player_registration_form.rb
+class PlayerRegistrationForm
+  include ActiveModel::Model
+  include ActiveModel::Attributes
+
+  attribute :name, :string
+  attribute :email, :string
+  attribute :team_id, :integer
+  attribute :position, :string
+
+  validates :name, :email, :position, presence: true
+  validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }
+
+  def save
+    return false unless valid?
+    Player.create!(attributes)
+  end
+end
+```
+
+### Value Objects
+
+Use for domain concepts that deserve their own identity beyond a raw primitive.
+
+```ruby
+# app/models/batting_average.rb
+class BattingAverage
+  include Comparable
+
+  def initialize(hits, at_bats)
+    @hits = hits
+    @at_bats = at_bats
+  end
+
+  def value
+    return 0.0 if @at_bats.zero?
+    (@hits.to_f / @at_bats).round(3)
+  end
+
+  def elite?
+    value >= 0.300
+  end
+
+  def <=>(other)
+    value <=> other.value
+  end
+end
+```
+
+## Refactoring Process
+
+1. **Read the entire model** and identify every method, scope, callback, and validation.
+2. **Classify each block** using the decision framework table above.
+3. **Extract in order**: value objects first, then query objects, then service objects, then concerns. Do concerns last because some may become unnecessary after other extractions.
+4. **Update the model** to include concerns and delegate to new objects.
+5. **Verify** that the slimmed-down model only contains: associations, enums, core validations, and concern includes.
+6. **Create or update tests** for each extracted class. Each new class gets its own spec file mirroring the source path.
+
+## What NOT to Do
+
+- Don't extract everything — simple one-line scopes and basic validations belong on the model.
+- Don't create a class for trivial logic just to hit a line count target.
+- Don't use concerns as junk drawers — each concern should have a clear, single theme.
+- Don't break ActiveRecord conventions (e.g. don't move associations into concerns).
+- Don't introduce callback-heavy service objects — prefer explicit invocation over implicit hooks.

package/plugins/lisa-rails/.codex-plugin/skills/active-record-model-best-practices/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Active Record Model Best Practices"
+short_description: "Best practices for Ruby on…"
+default_prompt:
+  - "Use $active-record-model-best-practices: Best practices for Ruby on…."

package/plugins/lisa-rails/.codex-plugin/skills/e2e-coverage-gaps/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: e2e-coverage-gaps
+description: "Playwright/e2e coverage-gap…"
+---
+
+# E2E Coverage Gaps
+
+## Overview
+
+Find where the automated end-to-end (Playwright) suite is **blind**: routes with no test at all, and
+flows that only assert the **happy path** while ignoring error, permission, empty, loading, and edge
+cases. Inventory the app's routes and the existing tests, explore the running app to confirm each gap
+is real and reachable, then file each gap as a **build-ready missing-test work item** so it enters the
+Lisa lifecycle.
+
+This skill is purely about **automated-coverage gaps**. It does not judge whether the UI is confusing
+or pretty — for human usability findings, use the `lisa-exploratory-qa` skill.
+
+## Parameters
+
+- **`target-url | env`** (first positional) — the app to inventory and explore.
+- **`ready=true|false`** — build-ready state for the missing-test tickets (**default `true`**). Adding
+  missing coverage is safe to queue, so these default to build-ready; pass `ready=false` to leave them
+  in the backlog for human triage.
+
+## Core Workflow
+
+### 1. Establish Scope
+
+- Identify the target environment, account type, and browser requirement, and read the `ready` flag
+  (default `true`).
+- **Confirm the tracker is configured.** Gaps are filed as tickets, so read `tracker` from
+  `.lisa.config.json` (local overrides global). If it is unset, stop and report that the tracker must
+  be configured (via `/lisa:setup:jira` / `:github` / `:linear`) before gaps can be filed.
+
+### 2. Inventory App Routes
+
+- Enumerate every route/screen from the project's routing source — filesystem routes, the router
+  config, navigation definitions, or a generated sitemap.
+- For each route capture: its path + params, the auth/role it requires, and the primary user actions
+  reachable from it (forms, mutations, filters, flows).
+
+### 3. Inventory Existing Playwright Coverage
+
+- Inspect the Playwright config, auth/setup projects, fixtures, constants, selectors, spec directories,
+  skipped/TODO/flaky tests, retries, and viewport/device projects.
+- For each spec, record which route(s)/flow(s) it exercises and whether it asserts **behavior** or just
+  **presence**.
+- Use existing test helpers/selectors when exploring — they reveal intended flows and stable hooks.
+
+### 4. Compute the Gap Matrix
+
+Map routes/flows against existing coverage and classify each gap:
+
+- **Uncovered route/flow:** no test touches it at all.
+- **Happy-path-only:** the success case is tested but the non-happy paths are not — missing
+  error/validation, permission/denied, empty/zero-state, loading/slow, and boundary/edge scenarios.
+- **Assertion-thin:** a test exists but asserts presence rather than behavior/outcome.
+- **Skipped/TODO/flaky:** coverage exists but is disabled or unreliable.
+- **Breakpoint gap:** a flow is only tested at a single viewport when behavior changes across
+  breakpoints.
+
+### 5. Explore to Confirm
+
+- Navigate each candidate gap in the running app to confirm it is real, reachable, and worth a test.
+  Discard gaps that aren't actually reachable or are intentionally out of scope.
+
+### 6. File One Ticket Per Gap
+
+Each confirmed gap becomes a leaf **missing-test** work item created via `lisa-tracker-write` (the
+vendor-neutral writer — it dispatches to the configured tracker and runs the validation gate; never
+call a vendor `*-write-*` skill directly), `issue_type: Task`, **build-ready per the `ready` flag
+(default `true`)**. Pass `build_ready` explicitly on every create. Each ticket MUST specify:
+
+- The **route/flow** and the exact **user behavior the test must assert**.
+- **Which scenario is missing** (uncovered vs which non-happy path: error / validation / permission /
+  empty / loading / edge / breakpoint).
+- The **stable selector / fixture / flow** to use — concrete and automatable.
+- **Three-audience description** + **Gherkin acceptance criteria** describing the test to add.
+
+### Idempotency — don't spam duplicates
+
+Before creating a ticket, search the tracker for an **open** ticket carrying a stable marker
+`[lisa-e2e-coverage-gaps] <gap-key>` in its body (the `<gap-key>` is a stable slug of route + missing
+scenario, e.g. `checkout/payment-declined` or `dashboard/empty-state@mobile`). If one exists, reference
+it instead of duplicating. **Match by the marker, never by title.** A *closed* prior ticket does not
+suppress a genuine new gap.
+
+## Output
+
+No report file. Emit a concise in-session summary:
+
+- **Route inventory:** count of routes/screens discovered.
+- **Existing coverage:** strengths and thin areas (skipped/flaky, assertion-thin, single-viewport).
+- **Gap matrix:** uncovered vs happy-path-only vs breakpoint gaps.
+- **Tickets filed:** each gap with its created/referenced ticket ref and build-ready state.
+
+## Quality Bar
+
+- Distinguish **no coverage** from **happy-path-only** — both are gaps, but the ticket must say which.
+- Every ticket must stand alone for an implementer who was not in the session and must be concretely
+  automatable (named route, behavior, and stable hook).
+- Do not refile gaps already covered or already ticketed (marker check).
+- This skill is about automated coverage only — route human usability issues to `lisa-exploratory-qa`.
+- Preserve unrelated repo changes.

package/plugins/lisa-rails/.codex-plugin/skills/e2e-coverage-gaps/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "E2e Coverage Gaps"
+short_description: "Playwright/e2e coverage-gap…"
+default_prompt:
+  - "Use $e2e-coverage-gaps: Playwright/e2e coverage-gap…."

package/plugins/lisa-rails/.codex-plugin/skills/fix-linter-error/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: fix-linter-error
+description: "fixing all violations of one or…"
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+
+---
+
+# Fix Linter Errors
+
+Target cops: $ARGUMENTS
+
+If no arguments provided, prompt the user for at least one RuboCop cop name.
+
+## Step 1: Gather Requirements
+
+1. **Parse cops** from $ARGUMENTS (space-separated)
+2. **Run RuboCop** to collect all violations:
+   ```bash
+   bundle exec rubocop --format json 2>&1
+   ```
+3. **Group violations** by cop, then by file, noting:
+   - File path and line numbers
+   - Violation count per file
+   - Sample offense messages
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Fix RuboCop violations for cops: $ARGUMENTS
+
+Violations by cop:
+- [CopName1]: X total violations across Y files
+  - [file]: N violations (lines: ...)
+  - ...
+- [CopName2]: X total violations across Y files
+  - ...
+
+Fix strategies: extract methods, reduce complexity, apply auto-correct where safe
+
+Verification: `bundle exec rubocop --format simple 2>&1 | grep -E "($ARGUMENTS)" | wc -l` -> Expected: 0
+```
+
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa-rails/.codex-plugin/skills/fix-linter-error/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Fix Linter Error"
+short_description: "fixing all violations of one or…"
+default_prompt:
+  - "Use $fix-linter-error: fixing all violations of one or…."

package/plugins/lisa-rails/.codex-plugin/skills/improve-code-complexity/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: improve-code-complexity
+description: "reducing the code complexity…"
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+---
+
+# Lower Code Complexity
+
+Reduces the CyclomaticComplexity threshold by 2 and fixes all violations.
+
+## Step 1: Gather Requirements
+
+1. **Read current threshold** from `.rubocop.yml` (`Metrics/CyclomaticComplexity` Max)
+2. **Calculate new threshold**: current - 2 (e.g., 10 -> 8)
+3. **Run RuboCop and flog** to find violations:
+   ```bash
+   bundle exec rubocop --only Metrics/CyclomaticComplexity,Metrics/PerceivedComplexity --format json 2>&1
+   ```
+   ```bash
+   bundle exec flog --all --group app/ 2>&1 | head -50
+   ```
+4. **Note for each violation**:
+   - File path and line number
+   - Method name
+   - Current complexity score (RuboCop and/or flog)
+
+If no violations at new threshold, report success and exit.
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Reduce CyclomaticComplexity threshold from [current] to [new].
+
+Methods exceeding threshold (ordered by complexity):
+1. [file:method_name] (complexity: X, target: [new]) - Line Y
+   - flog score: Z
+2. ...
+
+Configuration change: .rubocop.local.yml, Metrics/CyclomaticComplexity Max from [current] to [new]
+
+Refactoring strategies: extract methods, early returns, extract conditions, use lookup hashes, replace conditionals with polymorphism
+
+Verification: `bundle exec rubocop --only Metrics/CyclomaticComplexity --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
+```
+
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa-rails/.codex-plugin/skills/improve-code-complexity/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Improve Code Complexity"
+short_description: "reducing the code complexity…"
+default_prompt:
+  - "Use $improve-code-complexity: reducing the code complexity…."

package/plugins/lisa-rails/.codex-plugin/skills/improve-max-lines/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: improve-max-lines
+description: "reducing the maximum…"
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+
+---
+
+# Reduce Max Lines
+
+Target threshold: $ARGUMENTS lines per class/module
+
+If no argument provided, prompt the user for a target.
+
+## Step 1: Gather Requirements
+
+1. **Read current config** from `.rubocop.yml` or `.rubocop.local.yml` (`Metrics/ClassLength` and `Metrics/ModuleLength`)
+2. **Run RuboCop** with the target threshold to find violations:
+   ```bash
+   bundle exec rubocop --only Metrics/ClassLength,Metrics/ModuleLength --format json 2>&1
+   ```
+3. **Note for each violation**:
+   - File path
+   - Class/module name
+   - Current line count
+
+If no violations at $ARGUMENTS, report success and exit.
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Reduce max class/module lines threshold to $ARGUMENTS.
+
+Classes/modules exceeding threshold (ordered by line count):
+1. [file:ClassName] - [current] lines (target: $ARGUMENTS)
+2. ...
+
+Configuration change: .rubocop.local.yml, Metrics/ClassLength Max to $ARGUMENTS, Metrics/ModuleLength Max to $ARGUMENTS
+
+Refactoring strategies: extract concerns, extract service objects, remove duplication, delete dead code, simplify logic
+
+Verification: `bundle exec rubocop --only Metrics/ClassLength,Metrics/ModuleLength --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
+```
+
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa-rails/.codex-plugin/skills/improve-max-lines/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Improve Max Lines"
+short_description: "reducing the maximum…"
+default_prompt:
+  - "Use $improve-max-lines: reducing the maximum…."

package/plugins/lisa-rails/.codex-plugin/skills/improve-max-lines-per-function/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: improve-max-lines-per-function
+description: "reducing the maximum lines per…"
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+
+---
+
+# Reduce Max Lines Per Method
+
+Target threshold: $ARGUMENTS lines per method
+
+If no argument provided, prompt the user for a target.
+
+## Step 1: Gather Requirements
+
+1. **Read current config** from `.rubocop.yml` or `.rubocop.local.yml` (`Metrics/MethodLength`)
+2. **Run RuboCop** with the target threshold to find violations:
+   ```bash
+   bundle exec rubocop --only Metrics/MethodLength --format json 2>&1
+   ```
+3. **Note for each violation**:
+   - File path and line number
+   - Method name
+   - Current line count
+
+If no violations at $ARGUMENTS, report success and exit.
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Reduce max lines per method threshold to $ARGUMENTS.
+
+Methods exceeding threshold (ordered by line count):
+1. [file:method_name] (lines: X, target: $ARGUMENTS) - Line Y
+2. ...
+
+Configuration change: .rubocop.local.yml, Metrics/MethodLength Max to $ARGUMENTS
+
+Refactoring strategies: extract methods, early returns, extract conditions, use lookup hashes, consolidate logic
+
+Verification: `bundle exec rubocop --only Metrics/MethodLength --format simple 2>&1 | grep "offense" | wc -l` -> Expected: 0
+```
+
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa-rails/.codex-plugin/skills/improve-max-lines-per-function/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Improve Max Lines Per Function"
+short_description: "reducing the maximum lines per…"
+default_prompt:
+  - "Use $improve-max-lines-per-function: reducing the maximum lines per…."

package/plugins/lisa-rails/.codex-plugin/skills/improve-test-coverage/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: improve-test-coverage
+description: "increasing test coverage to a…"
+allowed-tools: ["Read", "Bash", "Glob", "Grep"]
+
+---
+
+# Increase Test Coverage
+
+Target threshold: $ARGUMENTS%
+
+If no argument provided, prompt the user for a target.
+
+## Step 1: Gather Requirements
+
+1. **Find coverage config** (`.simplecov` or `spec/spec_helper.rb`)
+2. **Run test suite with coverage** to get current state:
+   ```bash
+   bundle exec rspec 2>&1 | tail -50
+   ```
+3. **Check SimpleCov output** in `coverage/index.html` or console output
+4. **Identify the 20 files with lowest coverage**, noting:
+   - File path
+   - Current coverage % (lines, branches)
+   - Which lines/branches are uncovered
+
+## Step 2: Compile Brief and Delegate
+
+Compile the gathered information into a structured brief:
+
+```
+Increase test coverage from [current]% to $ARGUMENTS%.
+
+Files needing coverage (ordered by coverage gap):
+1. [file] - [current]% coverage (target: $ARGUMENTS%)
+   - Uncovered: [lines]
+   - Missing branch coverage: [lines]
+2. ...
+
+Configuration: .simplecov, update minimum_coverage to $ARGUMENTS%
+
+Verification: `bundle exec rspec` -> Expected: SimpleCov reports >= $ARGUMENTS% coverage
+```
+
+Invoke `/implement` with this brief to create the implementation plan.

package/plugins/lisa-rails/.codex-plugin/skills/improve-test-coverage/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Improve Test Coverage"
+short_description: "increasing test coverage to a…"
+default_prompt:
+  - "Use $improve-test-coverage: increasing test coverage to a…."

package/plugins/lisa-rails/.codex-plugin/skills/jira-add-journey/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: jira-add-journey
+description: "Add a Validation Journey…"
+---
+
+# Add Validation Journey to Existing JIRA Ticket
+
+Read an existing JIRA ticket, understand the feature or fix it describes, analyze the codebase to determine the verification approach, and append a Validation Journey section to the ticket description.
+
+## Arguments
+
+`$ARGUMENTS`: `<TICKET_ID>`
+
+- `TICKET_ID` (required): JIRA ticket key (e.g., `PROJ-123`)
+
+## Prerequisites
+
+- `JIRA_API_TOKEN` environment variable set
+- `jira-cli` configured (`~/.config/.jira/.config.yml`)
+
+## Workflow
+
+### Step 1: Read the Ticket
+
+Use the Atlassian MCP or jira-cli to read the full ticket details:
+
+```bash
+jira issue view <TICKET_ID>
+```
+
+Extract: title, description, acceptance criteria, components, labels, linked tickets.
+
+### Step 2: Check for Existing Journey
+
+Run the parser to see if a Validation Journey already exists:
+
+```bash
+python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID> 2>&1
+```
+
+If the parser succeeds and returns steps, the ticket already has a journey. Report this to the user and stop.
+
+### Step 3: Analyze the Feature
+
+Based on the ticket description and acceptance criteria, determine the appropriate verification approach. Stack-specific overrides provide the analysis logic.
+
+### Step 4: Draft the Validation Journey
+
+Compose the journey following the Validation Journey format with: Prerequisites, Steps (with evidence markers), and Assertions.
+
+### Step 5: Present to User for Approval
+
+Display the drafted Validation Journey to the user and ask for confirmation before appending it to the ticket.
+
+### Step 6: Append to Ticket Description
+
+After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
+
+### Step 7: Verify
+
+Run the parser again to confirm the journey was added correctly:
+
+```bash
+python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
+```

package/plugins/lisa-rails/.codex-plugin/skills/jira-add-journey/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Jira Add Journey"
+short_description: "Add a Validation Journey…"
+default_prompt:
+  - "Use $jira-add-journey: Add a Validation Journey…."