@codyswann/lisa 4.74.9 → 4.75.0

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

@@ -0,0 +1,51 @@
+---
+name: improve-code-complexity
+description: This skill should be used when reducing the code complexity threshold of the codebase. It lowers the CyclomaticComplexity threshold by 2, identifies methods that exceed the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to fix all violations.
+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
+   status=0
+   bundle exec flog --all --group app/ >flog.log 2>&1 || status=$?
+   head -n 50 flog.log; echo "exit=$status"
+   ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `head` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
+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-devin/skills/improve-max-lines/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: improve-max-lines
+description: This skill should be used when reducing the maximum class/module lines threshold and fixing all violations. It updates the RuboCop configuration, identifies classes and modules exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized files.
+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-devin/skills/improve-max-lines-per-function/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: improve-max-lines-per-function
+description: This skill should be used when reducing the maximum lines per method threshold and fixing all violations. It updates the RuboCop configuration, identifies methods exceeding the new limit, generates a brief with refactoring strategies, and creates a plan with tasks to split oversized methods.
+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-devin/skills/improve-test-coverage/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: improve-test-coverage
+description: This skill should be used when increasing test coverage to a specified threshold percentage. It runs the test suite with SimpleCov, identifies files with the lowest coverage, generates a brief with coverage gaps, and creates a plan with tasks to add the missing tests.
+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
+   status=0
+   bundle exec rspec >rspec.log 2>&1 || status=$?
+   tail -n 50 rspec.log; echo "exit=$status"
+   ```
+   The status is captured before the pipe, because a pipeline reports its LAST stage's exit code — `tail` always succeeds, so a failing run reads as `exit=0` (`falsifiable-checks`, pager-shadowed status). `|| status=$?` rather than `; status=$?`: under `set -e` the `;` form exits before the assignment, so the failure is never reported at all.
+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-devin/skills/jira-add-journey/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: jira-add-journey
+description: "Add a Validation Journey section to an existing JIRA ticket by reading the ticket description, understanding the feature, and generating the journey steps and assertions."
+---
+
+# 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. Prefer the config Lisa writes at
+  `.lisa/jira-cli/.config.yml` (the `setup-jira-cli` SessionStart hook writes it
+  from `JIRA_SERVER` / `JIRA_LOGIN` / `JIRA_PROJECT` on a project whose
+  `tracker` is `jira`), and pass it explicitly with `--config`. A developer's
+  own `~/.config/.jira/.config.yml` still works as jira-cli's default when no
+  `--config` is given.
+
+## Workflow
+
+### Step 1: Read the Ticket
+
+Use the Atlassian MCP or jira-cli to read the full ticket details:
+
+```bash
+# Run from the project root. --config pins jira-cli to the file Lisa's
+# setup-jira-cli hook wrote, instead of the machine's own ~/.config/.jira.
+# jira-cli resolves --config > JIRA_CONFIG_FILE > ~/.config/.jira/.config.yml,
+# and a --config path that does not exist fails closed with "Missing
+# configuration file." rather than silently using the default.
+jira --config .lisa/jira-cli/.config.yml issue view <TICKET_ID>
+```
+
+If `.lisa/jira-cli/.config.yml` does not exist, drop `--config` to fall back to
+the machine's own jira-cli config — but say so in your report rather than
+letting the Lisa-written config go quietly unused.
+
+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-devin/skills/jira-create/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: jira-create
+description: This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
+allowed-tools: ["Read", "Glob", "LS", "Skill", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Create JIRA Issues from $ARGUMENTS
+
+Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa:jira-write-ticket`.** Do not call `mcp__atlassian__createJiraIssue` from this skill; the necessary write tools are intentionally not in `allowed-tools`.
+
+## Process
+
+1. **Analyze**: Read $ARGUMENTS to understand scope.
+2. **Extract source artifacts**: invoke the `lisa:tracker-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload and classify each by domain per its rules. Build the `artifacts` map. See "Source Artifacts" below.
+3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Skip only when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below.
+4. **Determine structure**:
+   - Epic needed if: multiple features, major changes, >3 related files
+   - Direct tasks if: bug fix, single file, minor change
+5. **Plan hierarchy**:
+   ```text
+   Epic → User Story → Tasks (test, implement, document, cleanup)
+   ```
+6. **Delegate every write to `lisa:jira-write-ticket`** in dependency order (epic first, then stories with the epic as parent, then sub-tasks with their story as parent). Pass the artifacts (filtered by domain per `lisa:tracker-source-artifacts` inheritance rules) and the walkthrough findings (under `## Current Product`). See "Delegation to jira-write-ticket" below.
+7. **Run the artifact preservation gate** (`lisa:tracker-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped.
+
+## Mandatory for Every Code Issue
+
+**Test-First**: Write tests before implementation
+**Quality Gates**: All tests/checks must pass, no SonarCloud violations
+**Documentation**: Check existing, update/create new, remove obsolete
+**Feature Flags**: All features behind flags with lifecycle plan
+**Cleanup**: Remove temporary code, scripts, dev configs
+
+## Source Artifacts
+
+If $ARGUMENTS includes (or references) any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as remote links on the created tickets. Silent artifact loss is the single most common quality failure in this pipeline.
+
+**Invoke the `lisa:tracker-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here.
+
+Rails-specific note: the existing-component reuse rule applies to view partials and ViewComponents — the closest existing partial/component is usually the right answer over pixel-matching a mock from scratch.
+
+When delegating writes to `lisa:jira-write-ticket`, pass the extracted artifact list so its Phase 4c step can attach them.
+
+## Live Product Walkthrough
+
+When the work touches existing user-facing surfaces, invoke the `lisa:product-walkthrough` skill before drafting tickets. Findings (current behavior, design-vs-product divergence, reuse candidates, behavioral surprises) become inputs to the ticket plan and surface under `## Current Product` on the resulting tickets. Skip only when the work is purely backend or affects a screen that does not yet exist.
+
+## Issue Requirements
+
+Each issue must clearly communicate to:
+
+- **Coding Assistants**: Implementation requirements
+- **Developers**: Technical approach
+- **Stakeholders**: Business value
+
+Default project: SE (override via arguments)
+Exclude unless requested: migration plans, performance tests
+
+## Delegation to jira-write-ticket
+
+**Mandatory.** Every ticket created by this skill MUST go through `lisa:jira-write-ticket`. This skill never calls `mcp__atlassian__createJiraIssue` itself — that tool is intentionally excluded from `allowed-tools` so the gate cannot be bypassed.
+
+`lisa:jira-write-ticket` enforces things this skill does not, and which determine ticket quality:
+- 3-audience description (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Epic parent validation (non-bug, non-epic types)
+- Explicit link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`)
+- Remote links (PRs, Confluence, dashboards)
+- Single-repo scope check for Bug / Task / Sub-task
+- Sign-in account and target environment recorded in description
+- Post-create verification
+
+### Invocation order
+
+Tickets must be created in parent-before-child order so each child can be passed its parent key:
+
+1. Invoke `lisa:jira-write-ticket` for the epic. Capture the returned key.
+2. For each story, invoke `lisa:jira-write-ticket` with the epic key as the epic parent. Capture each story key.
+3. For each sub-task, invoke `lisa:jira-write-ticket` with the parent story key.
+
+### What to pass to each invocation
+
+For every delegated write, pass:
+- The summary, issue type, project key, and priority you decided
+- The 3-section description body you drafted (Context / Technical Approach / Acceptance Criteria)
+- Gherkin acceptance criteria
+- Parent key (epic key for stories; story key for sub-tasks)
+- The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `lisa:jira-write-ticket` Phase 4c attaches them as remote links
+- For tickets that change runtime behavior: the Validation Journey draft, or instruct it to call `lisa:jira-add-journey` after create
+
+### What this skill is responsible for
+
+This skill owns:
+- Deciding the *shape* of the hierarchy (what's an epic vs. story vs. sub-task)
+- Drafting the description body and acceptance criteria from the input
+- Extracting and classifying source artifacts
+- Threading parent keys through subsequent writes
+- Running the artifact preservation check after all writes complete
+
+It does not own the actual JIRA write — that's `lisa:jira-write-ticket`'s job.

package/plugins/lisa-rails-devin/skills/jira-evidence/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: jira-evidence
+description: "Upload evidence to GitHub pr-assets release, update PR description, upload attachments to JIRA, post comment, and move ticket to the configured review status only when `jira.workflow.review` is set (otherwise leave it in `claimed`). Reusable by any skill that captures evidence and generates evidence/comment.txt + evidence/comment.md."
+---
+
+# JIRA Evidence Posting
+
+Upload captured evidence and generated templates to GitHub PR description and JIRA ticket. This skill is the posting step — it assumes evidence files and comment templates already exist in the evidence directory.
+
+## Arguments
+
+`$ARGUMENTS`: `<TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>`
+
+- `TICKET_ID` (required): JIRA ticket key (e.g., `PROJ-123`)
+- `EVIDENCE_DIR` (required): Directory containing evidence and templates (e.g., `./evidence`)
+- `PR_NUMBER` (required): GitHub PR number to update description
+
+## Prerequisites
+
+- `python3` for destination validation. Configure `server` as a bare HTTPS origin:
+  no userinfo, path prefix, query, or fragment. Invalid destinations are rejected
+  before Basic authorization is constructed.
+- `JIRA_API_TOKEN` environment variable set
+- a jira-cli config — `.lisa/jira-cli/.config.yml` if the `setup-jira-cli`
+  SessionStart hook wrote one, otherwise `~/.config/.jira/.config.yml`. `server`
+  and `login` are read from whichever is used, and the fallback is announced on
+  stderr rather than taken silently.
+- `gh` CLI authenticated
+- Evidence directory containing:
+  - Evidence files: `NN-name-viewport.png` (screenshots) and/or `NN-name.txt`/`NN-name.json` (text evidence)
+  - `comment.txt` — JIRA wiki markup (generated by `generate-templates.py`)
+  - `comment.md` — GitHub markdown (generated by `generate-templates.py`)
+
+## Usage
+
+```bash
+bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>
+```
+
+### Example
+
+```bash
+bash .claude/skills/jira-evidence/scripts/post-evidence.sh PROJ-123 ./evidence 42
+```
+
+## What It Does
+
+1. **Read JIRA config** — Resolves the jira-cli config (`$PROJECT_DIR/.lisa/jira-cli/.config.yml` first, then `~/.config/.jira/.config.yml`, announcing the fallback) and reads `server` and `login` from it dynamically — no hardcoded values. Exits 1 naming both paths when neither exists. The same resolved path is then passed to `jira issue move` as `--config`, so the CLI cannot end up on a different config than the one this script parsed.
+2. **Upload to GitHub `pr-assets` release** — Uploads evidence files via `gh release upload --clobber`, creating CDN URLs
+3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body using `gh pr edit`
+4. **Upload JIRA attachments** — Uploads image evidence via REST API v3 so `!filename.png!` wiki markup renders inline
+5. **Post JIRA comment** — Posts `comment.txt` as a new comment via REST API v2 (wiki markup)
+6. **Move ticket to the configured review status** — Resolves `jira.workflow.review` (or the `jira.workflow.code_review` alias) from `.lisa.config.json` / `.lisa.config.local.json` and transitions via `jira issue move`. `review` is optional; when unset, the ticket stays in `claimed` and this step is skipped. Never transition to a status not named in `config.jira.workflow`. If the configured status is not a valid transition from the current state, log a warning and skip.
+
+## Evidence Naming Conventions
+
+- Image evidence: `NN-name-viewport.png` (e.g., `01-search-step-desktop.png`)
+- Text evidence: `NN-name.txt` or `NN-name.json` (e.g., `01-health-check.json`)
+
+## Troubleshooting
+
+### Images not rendering in GitHub PR
+
+Images must be in the `pr-assets` GitHub release. If the release does not exist, create it first:
+
+```bash
+gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence"
+```
+
+### JIRA comment shows `!filename.png!` as text (not image)
+
+The screenshot must be uploaded as a JIRA attachment before posting the comment. The script uploads attachments first then posts the comment.
+
+### JIRA API returns 403 on attachment upload
+
+Ensure `JIRA_API_TOKEN` is set and `login` in the resolved jira-cli config (`.lisa/jira-cli/.config.yml`, else `~/.config/.jira/.config.yml`) matches your Atlassian account email.