@codyswann/lisa 1.47.1 → 1.49.0

package/{all/copy-overwrite/.claude/commands/plan/create.md → plugins/lisa-cdk/commands/plan-create.md}

@@ -3,4 +3,4 @@ description: "Creates an implementation plan from a ticket URL, file path, or te
 argument-hint: "<ticket-url | @file-path | description>"
 ---
 
-Use the /plan-execute skill on $ARGUMENTS
+Use the /lisa:plan-execute skill on $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/plan/execute.md → plugins/lisa-cdk/commands/plan-execute.md}

@@ -4,4 +4,4 @@ argument-hint: "<ticket-url | @file-path | description>"
 ---
 
 
-Use the /plan-execute skill on $ARGUMENTS
+Use the /lisa:plan-execute skill on $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/plan/fix-linter-error.md → plugins/lisa-cdk/commands/plan-fix-linter-error.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<rule-1> [rule-2] [rule-3] ..."
 ---
 
-Use the /plan-fix-linter-error skill to fix linter errors. $ARGUMENTS
+Use the /lisa:plan-fix-linter-error skill to fix linter errors. $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/plan/local-code-review.md → plugins/lisa-cdk/commands/plan-local-code-review.md}

@@ -3,4 +3,4 @@ description: "Review local branch changes compared to main"
 allowed-tools: ["Skill"]
 ---
 
-Use the /plan-local-code-review skill to review local changes.
+Use the /lisa:plan-local-code-review skill to review local changes.

package/{all/copy-overwrite/.claude/commands/plan/lower-code-complexity.md → plugins/lisa-cdk/commands/plan-lower-code-complexity.md}

@@ -3,4 +3,4 @@ description: "Reduce the cognitive complexity threshold by 2 and fix all violati
 allowed-tools: ["Skill"]
 ---
 
-Use the /plan-lower-code-complexity skill to lower code complexity.
+Use the /lisa:plan-lower-code-complexity skill to lower code complexity.

package/{all/copy-overwrite/.claude/commands/plan/reduce-max-lines-per-function.md → plugins/lisa-cdk/commands/plan-reduce-max-lines-per-function.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<max-lines-per-function-value>"
 ---
 
-Use the /plan-reduce-max-lines-per-function skill to reduce max function lines. $ARGUMENTS
+Use the /lisa:plan-reduce-max-lines-per-function skill to reduce max function lines. $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/plan/reduce-max-lines.md → plugins/lisa-cdk/commands/plan-reduce-max-lines.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<max-lines-value>"
 ---
 
-Use the /plan-reduce-max-lines skill to reduce max lines. $ARGUMENTS
+Use the /lisa:plan-reduce-max-lines skill to reduce max lines. $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/pull-request/review.md → plugins/lisa-cdk/commands/pull-request-review.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<github-pr-link>"
 ---
 
-Use the /pull-request-review skill to check for code review comments and implement them. $ARGUMENTS
+Use the /lisa:pull-request-review skill to check for code review comments and implement them. $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/security/zap-scan.md → plugins/lisa-cdk/commands/security-zap-scan.md}

@@ -3,4 +3,4 @@ description: "Run an OWASP ZAP baseline security scan locally using Docker"
 allowed-tools: ["Skill"]
 ---
 
-Use the /security-zap-scan skill to run an OWASP ZAP baseline security scan.
+Use the /lisa:security-zap-scan skill to run an OWASP ZAP baseline security scan.

package/{all/copy-overwrite/.claude/commands/sonarqube/check.md → plugins/lisa-cdk/commands/sonarqube-check.md}

@@ -3,4 +3,4 @@ description: "Uses SonarQube / SonarCloud to get the reason that last pull reque
 allowed-tools: ["Skill"]
 ---
 
-Use the /sonarqube-check skill to check why the last PR failed SonarQube quality gates.
+Use the /lisa:sonarqube-check skill to check why the last PR failed SonarQube quality gates.

package/{all/copy-overwrite/.claude/commands/sonarqube/fix.md → plugins/lisa-cdk/commands/sonarqube-fix.md}

@@ -3,4 +3,4 @@ description: "Run SonarQube check, fix failures, and commit"
 allowed-tools: ["Skill"]
 ---
 
-Use the /sonarqube-fix skill to check, fix, and commit SonarQube quality gate failures.
+Use the /lisa:sonarqube-fix skill to check, fix, and commit SonarQube quality gate failures.

package/{all/copy-overwrite/.claude/commands/tasks/load.md → plugins/lisa-cdk/commands/tasks-load.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<project-name>"
 ---
 
-Use the /tasks-load skill to load tasks from a project directory. $ARGUMENTS
+Use the /lisa:tasks-load skill to load tasks from a project directory. $ARGUMENTS

package/{all/copy-overwrite/.claude/commands/tasks/sync.md → plugins/lisa-cdk/commands/tasks-sync.md}

@@ -4,4 +4,4 @@ allowed-tools: ["Skill"]
 argument-hint: "<project-name>"
 ---
 
-Use the /tasks-sync skill to sync current session tasks to a project directory. $ARGUMENTS
+Use the /lisa:tasks-sync skill to sync current session tasks to a project directory. $ARGUMENTS

package/{typescript/copy-overwrite/.claude → plugins/lisa-cdk}/hooks/install-pkgs.sh

@@ -2,9 +2,9 @@
 # This file is managed by Lisa.
 # Do not edit directly — changes will be overwritten on the next `lisa` run.
 
-# Only run package installation in remote (Claude Code web) environment
-# node_modules are gitignored, so they need to be installed remotely
-if [ "$CLAUDE_CODE_REMOTE" != "true" ]; then
+# Only run package installation when node_modules are missing.
+# This covers remote environments, new worktrees, fresh clones, and CI.
+if [ -d "node_modules" ]; then
   exit 0
 fi
 

package/plugins/lisa-cdk/rules/lisa.md

@@ -0,0 +1,37 @@
+# Lisa-Managed Files
+
+The following files are managed by Lisa and will be overwritten on every `lisa` run. Never edit them directly. Where a local override exists, edit that instead.
+
+## Files with local overrides (edit the override, not the managed file)
+
+| Managed File (do not edit) | Local Override (edit this instead) |
+|---|---|
+| `eslint.config.ts` | `eslint.config.local.ts` |
+| `jest.config.ts` | `jest.config.local.ts` |
+| `tsconfig.json` | `tsconfig.local.json` |
+
+## Create-only files (edit freely, Lisa won't overwrite)
+
+- `.claude/rules/PROJECT_RULES.md`
+- `eslint.thresholds.json`
+- `jest.thresholds.json`
+
+## Deep-merged by Lisa (Lisa wins conflicts, but project can add its own keys)
+
+- `.claude/settings.json`
+
+## Plugin-managed content (agents, skills, hooks, commands, rules)
+
+These resources are distributed via the stack Claude Code plugin (e.g., `typescript@lisa`). Rules — including this file — are injected into each prompt automatically. Do not add these files to your project directory.
+
+## Copy-overwrite files (do not edit — full list)
+
+- `.prettierrc.json`, `.prettierignore`, `.lintstagedrc.json`, `.versionrc`, `.nvmrc`
+- `.yamllint`, `.gitleaksignore`, `.coderabbit.yml`, `commitlint.config.cjs`, `sgconfig.yml`, `knip.json`
+- `.safety-net.json`, `audit.ignore.config.json`
+- `eslint.base.ts`, `eslint.typescript.ts` (+ `expo`/`nestjs`/`cdk` variants), `eslint.slow.config.ts`
+- `jest.base.ts`, `jest.typescript.ts` (+ variants)
+- `tsconfig.base.json`, `tsconfig.typescript.json` (+ variants), `tsconfig.eslint.json`, `tsconfig.build.json`, `tsconfig.spec.json`
+- `.github/workflows/quality.yml`, `release.yml`, `claude.yml`, and all other Claude/CI workflows
+- `.github/dependabot.yml`, `.github/GITHUB_ACTIONS.md`
+- `ast-grep/rules/`, `ast-grep/utils/`, `ast-grep/rule-tests/`

package/plugins/lisa-cdk/skills/jira-add-journey/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: jira-add-journey
+description: "Add a Validation Journey section to an existing JIRA ticket by analyzing the change type and generating appropriate verification steps with evidence markers."
+---
+
+# Add Validation Journey to Existing JIRA Ticket
+
+Read an existing JIRA ticket, analyze the change type, and generate a Validation Journey section with appropriate verification steps based on the project's verification patterns.
+
+## 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 Change Type
+
+Examine the ticket description, acceptance criteria, and codebase to determine the change type:
+
+1. **API/GraphQL changes** — New or modified endpoints, request/response schemas
+2. **Database migration** — Schema changes, new tables/columns, indexes
+3. **Background job/queue** — New job processors, queue consumers, event handlers
+4. **Library/utility** — Exported functions, shared modules, npm package changes
+5. **Security fix** — Auth, authorization, input validation, OWASP vulnerabilities
+6. **Authentication/authorization** — Role-based access, session management, tokens
+
+Use the Explore agent or read the codebase directly to understand which files are affected and what verification approach is appropriate.
+
+### Step 4: Map Change Type to Verification Pattern
+
+Based on the change type, generate verification steps using patterns from `verfication.md`:
+
+| Change Type | Verification Approach |
+|---|---|
+| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
+| Database migration | Migration execution + schema verification + rollback check |
+| Background job/queue | Enqueue + process + state change verification |
+| Library/utility | Test execution + build verification + export check |
+| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
+| Auth/authz | Multi-role verification with explicit status codes |
+
+### Step 5: Draft the Validation Journey
+
+Compose the journey with `[EVIDENCE: name]` markers at key verification points:
+
+```text
+h2. Validation Journey
+
+h3. Prerequisites
+- List required services, database, env vars
+
+h3. Steps
+1. Verify current state before changes
+2. Apply the change
+3. Verify expected new state [EVIDENCE: state-name]
+4. Test error/edge cases [EVIDENCE: error-case]
+5. Verify rollback if applicable [EVIDENCE: rollback]
+
+h3. Assertions
+- Describe what must be true after verification
+```
+
+### Guidelines for Drafting
+
+1. **2-5 evidence markers** — Focus on proving the change works and handles errors
+2. **Concrete, runnable steps** — "Run `curl -s localhost:3000/health | jq .status`" not "Check the endpoint"
+3. **Include environment setup** — Database connection, running services, env vars
+4. **Evidence names in kebab-case** — `api-response`, `schema-check`, `rate-limit-hit`
+5. **Assertions are measurable** — "Returns 200 with `{status: ok}`" not "API works correctly"
+6. **Cover happy path and error path** — At minimum, one success and one failure evidence marker
+
+### Step 6: Present to User for Approval
+
+Display the drafted Validation Journey to the user and ask for confirmation before appending it to the ticket.
+
+### Step 7: Append to Ticket Description
+
+After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
+
+### Step 8: Verify
+
+Run the parser again to confirm the journey was added correctly:
+
+```bash
+python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
+```
+
+## When to Use This Skill
+
+- Ticket was created before the Validation Journey convention was established
+- Ticket was created manually without following `jira-create` guidelines
+- Ticket needs a journey added or updated based on implementation progress
+- Before starting work on a ticket, to ensure verification steps are documented

package/plugins/lisa-cdk/skills/jira-create/SKILL.md

@@ -0,0 +1,95 @@
+---
+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", "mcp__atlassian__createJiraIssue", "mcp__atlassian__getVisibleJiraProjects", "mcp__atlassian__getJiraProjectIssueTypesMetadata", "mcp__atlassian__getAccessibleAtlassianResources"]
+---
+
+# Create JIRA Issues from $ARGUMENTS
+
+Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
+
+## Process
+
+1. **Analyze**: Read $ARGUMENTS to understand scope
+2. **Determine Structure**:
+   - Epic needed if: multiple features, major changes, >3 related files
+   - Direct tasks if: bug fix, single file, minor change
+3. **Create Issues** with hierarchy:
+   ```
+   Epic → User Story → Tasks (test, implement, document, cleanup)
+   ```
+
+## 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
+**Cleanup**: Remove temporary code, scripts, dev configs
+
+## Validation Journey
+
+Tickets that change runtime behavior should include a `Validation Journey` section in the description. This section is consumed by the `jira-journey` skill to automate verification.
+
+### When to Include
+
+Include a Validation Journey when the ticket involves:
+- API endpoint changes (new, modified, or removed routes)
+- Database schema changes (migrations, new columns, index changes)
+- Background job or queue processing changes
+- Library or utility function changes that affect exports
+- Security fixes (authentication, authorization, input validation)
+- Performance-critical changes requiring measurement
+
+### When to Skip
+
+Skip the Validation Journey for:
+- Documentation-only changes
+- Config-only changes (env vars, CI/CD, feature flags with no code)
+- Type-definition-only changes (interfaces, types, no runtime effect)
+
+### How to Write
+
+Design the journey based on the **change type**. The agent executing the journey determines how to verify each step using patterns from the project's `verfication.md`. Place `[EVIDENCE: name]` markers at key verification points.
+
+Add this section to the ticket description:
+
+```text
+h2. Validation Journey
+
+h3. Prerequisites
+- Local dev server running
+- Database accessible
+- Required environment variables set
+
+h3. Steps
+1. Verify the current state before changes
+2. Apply the change (run migration, deploy, etc.)
+3. Verify the expected new state [EVIDENCE: state-after-change]
+4. Test error/edge cases [EVIDENCE: error-handling]
+5. Verify rollback or cleanup if applicable [EVIDENCE: rollback-check]
+
+h3. Assertions
+- Describe what must be true after verification
+- Each assertion is verified against the captured evidence
+```
+
+### Guidelines
+
+1. **Steps must be concrete and verifiable** — "Run `curl -s localhost:3000/health`" not "Check the API"
+2. **Evidence markers at verification points** — Place `[EVIDENCE: name]` at states that prove the change works. Use descriptive kebab-case names (e.g., `api-response`, `schema-check`, `rate-limit-hit`)
+3. **Include 2-5 evidence markers** — Enough to prove the change works across happy path and error cases
+4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works"
+5. **Prerequisites include environment setup** — Database connection, env vars, running services
+
+## Issue Requirements
+
+Each issue must clearly communicate to:
+
+- **Coding Assistants**: Implementation requirements
+- **Developers**: Technical approach
+- **Stakeholders**: Business value
+
+Default project: from jira-cli config (override via arguments)
+Exclude unless requested: migration plans, performance tests
+
+Execute the analysis and create the complete JIRA structure with proper parent-child relationships.

package/plugins/lisa-cdk/skills/jira-evidence/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: jira-evidence
+description: "Upload text evidence to GitHub pr-assets release, update PR description, post JIRA comment with code blocks, and move ticket to Code Review. 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
+
+- `JIRA_API_TOKEN` environment variable set
+- `jira-cli` configured (`~/.config/.jira/.config.yml`) — server and login are read from there
+- `gh` CLI authenticated
+- Evidence directory containing:
+  - `NN-name.txt` or `NN-name.json` text evidence files (e.g., `01-health-check.json`)
+  - `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** — Reads `~/.config/.jira/.config.yml` to obtain `server` and `login` dynamically
+2. **Upload to GitHub `pr-assets` release** — Uploads evidence files via `gh release upload --clobber`
+3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body
+4. **Post JIRA comment** — Posts `comment.txt` as a new comment (wiki markup with code blocks)
+5. **Move ticket to Code Review** — Transitions the JIRA ticket
+
+## Evidence Naming Convention
+
+Text evidence files are named: `{NN}-{evidence-name}.txt` or `{NN}-{evidence-name}.json`
+
+```text
+evidence/
+  01-health-check.json          uploaded
+  02-schema-after-migration.txt uploaded
+  03-rate-limit-response.txt    uploaded
+  comment.txt                   used for JIRA comment
+  comment.md                    used for PR description
+```
+
+## Troubleshooting
+
+### Evidence not appearing in GitHub PR
+
+Evidence files must be in the `pr-assets` GitHub release. If the release does not exist:
+
+```bash
+gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence"
+```
+
+### JIRA API returns 403
+
+Ensure `JIRA_API_TOKEN` is set and `login` in `~/.config/.jira/.config.yml` matches your Atlassian account email.

package/plugins/lisa-cdk/skills/jira-evidence/scripts/post-evidence.sh

@@ -0,0 +1,163 @@
+#!/usr/bin/env bash
+# post-evidence.sh — Upload evidence and post to JIRA + GitHub PR description
+#
+# Usage:
+#   bash post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>
+#
+# Prerequisites:
+#   - JIRA_API_TOKEN env var set
+#   - jira-cli configured (~/.config/.jira/.config.yml)
+#   - gh CLI authenticated
+#
+# What it does:
+#   1. Uploads evidence files to the 'pr-assets' GitHub release
+#   2. Updates the GitHub PR description with evidence/comment.md
+#   3. Uploads image evidence as JIRA attachments
+#   4. Posts/updates the JIRA comment with evidence/comment.txt
+#   5. Moves the JIRA ticket to "Code Review"
+
+set -euo pipefail
+
+TICKET_ID="${1:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
+EVIDENCE_DIR="${2:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
+PR_NUMBER="${3:?Usage: post-evidence.sh <TICKET_ID> <EVIDENCE_DIR> <PR_NUMBER>}"
+
+JIRA_CONFIG="${HOME}/.config/.jira/.config.yml"
+if [[ ! -f "$JIRA_CONFIG" ]]; then
+  echo "ERROR: jira-cli config not found at $JIRA_CONFIG — run 'jira init' first" >&2
+  exit 1
+fi
+JIRA_SERVER=$(grep '^server:' "$JIRA_CONFIG" | awk '{print $2}')
+JIRA_USER=$(grep '^login:' "$JIRA_CONFIG" | awk '{print $2}')
+GH_REPO=$(gh repo view --json nameWithOwner --jq '.nameWithOwner')
+RELEASE_TAG="pr-assets"
+
+if [[ -z "${JIRA_API_TOKEN:-}" ]]; then
+  echo "ERROR: JIRA_API_TOKEN environment variable is not set" >&2
+  exit 1
+fi
+
+# Collect numbered evidence files (images + text)
+SCREENSHOTS=()
+while IFS= read -r -d '' f; do
+  SCREENSHOTS+=("$f")
+done < <(find "$EVIDENCE_DIR" -maxdepth 1 -name '[0-9][0-9]-*.png' -print0 | sort -z)
+
+TEXT_EVIDENCE=()
+while IFS= read -r -d '' f; do
+  TEXT_EVIDENCE+=("$f")
+done < <(find "$EVIDENCE_DIR" -maxdepth 1 \( -name '[0-9][0-9]-*.txt' -o -name '[0-9][0-9]-*.json' \) ! -name 'comment.txt' -print0 | sort -z)
+
+ALL_EVIDENCE=("${SCREENSHOTS[@]}" "${TEXT_EVIDENCE[@]}")
+
+if [[ ${#ALL_EVIDENCE[@]} -eq 0 ]]; then
+  echo "ERROR: No numbered evidence files found in $EVIDENCE_DIR (expected NN-*.png, NN-*.txt, or NN-*.json)" >&2
+  exit 1
+fi
+
+echo "Found ${#SCREENSHOTS[@]} screenshots and ${#TEXT_EVIDENCE[@]} text evidence files to upload"
+
+# Compute JIRA auth early (used in steps 3 and 4)
+JIRA_AUTH=$(echo -n "$JIRA_USER:$JIRA_API_TOKEN" | base64)
+
+# ── Step 1: Upload to GitHub pr-assets release ──────────────────────────────
+echo ""
+echo "==> Uploading to GitHub release '$RELEASE_TAG'..."
+
+for FILE in "${ALL_EVIDENCE[@]}"; do
+  FILENAME=$(basename "$FILE")
+  echo "  ↑ $FILENAME"
+  gh release upload "$RELEASE_TAG" "$FILE" --repo "$GH_REPO" --clobber
+done
+
+echo "  ✓ GitHub release assets uploaded"
+
+# ── Step 2: Update GitHub PR description with evidence ──────────────────────
+COMMENT_MD="$EVIDENCE_DIR/comment.md"
+if [[ ! -f "$COMMENT_MD" ]]; then
+  echo "ERROR: $COMMENT_MD not found — run generate-templates.py first" >&2
+  exit 1
+fi
+
+echo ""
+echo "==> Updating GitHub PR #$PR_NUMBER description..."
+
+CURRENT_BODY=$(gh pr view "$PR_NUMBER" --json body --jq '.body')
+
+# Replace or append the Evidence section
+if echo "$CURRENT_BODY" | grep -q "^## Evidence"; then
+  # Replace from "## Evidence" to end of file
+  NEW_BODY=$(echo "$CURRENT_BODY" | sed '/^## Evidence/,$d')
+  EVIDENCE_SECTION=$(cat "$COMMENT_MD")
+  UPDATED_BODY="${NEW_BODY}
+${EVIDENCE_SECTION}"
+else
+  EVIDENCE_SECTION=$(cat "$COMMENT_MD")
+  UPDATED_BODY="${CURRENT_BODY}
+
+${EVIDENCE_SECTION}"
+fi
+
+gh pr edit "$PR_NUMBER" --body "$UPDATED_BODY"
+echo "  ✓ PR description updated with evidence"
+
+# ── Step 3: Upload image evidence as JIRA attachments ───────────────────────
+if [[ ${#SCREENSHOTS[@]} -gt 0 ]]; then
+  echo ""
+  echo "==> Uploading image attachments to JIRA $TICKET_ID..."
+
+  for IMG in "${SCREENSHOTS[@]}"; do
+    FILENAME=$(basename "$IMG")
+    echo "  ↑ $FILENAME"
+    RESP=$(curl -s -w "\nHTTP_CODE:%{http_code}" \
+      -X POST \
+      -H "Authorization: Basic $JIRA_AUTH" \
+      -H "X-Atlassian-Token: no-check" \
+      -F "file=@$IMG" \
+      "$JIRA_SERVER/rest/api/3/issue/$TICKET_ID/attachments")
+    HTTP_CODE=$(echo "$RESP" | grep "HTTP_CODE:" | cut -d: -f2)
+    if [[ "$HTTP_CODE" != "200" ]]; then
+      echo "  WARNING: Failed to upload $FILENAME (HTTP $HTTP_CODE)" >&2
+    fi
+  done
+
+  echo "  ✓ JIRA attachments uploaded"
+fi
+
+# ── Step 4: Post JIRA comment ────────────────────────────────────────────────
+COMMENT_TXT="$EVIDENCE_DIR/comment.txt"
+if [[ ! -f "$COMMENT_TXT" ]]; then
+  echo "ERROR: $COMMENT_TXT not found — run generate-templates.py first" >&2
+  exit 1
+fi
+
+echo ""
+echo "==> Posting JIRA comment on $TICKET_ID..."
+
+COMMENT_BODY=$(cat "$COMMENT_TXT")
+COMMENT_JSON=$(python3 -c "import sys, json; print(json.dumps(sys.stdin.read()))" <<< "$COMMENT_BODY")
+
+RESP=$(curl -s -w "\nHTTP_CODE:%{http_code}" \
+  -X POST \
+  -H "Authorization: Basic $JIRA_AUTH" \
+  -H "Content-Type: application/json" \
+  "$JIRA_SERVER/rest/api/2/issue/$TICKET_ID/comment" \
+  -d "{\"body\": $COMMENT_JSON}")
+HTTP_CODE=$(echo "$RESP" | grep "HTTP_CODE:" | cut -d: -f2)
+
+if [[ "$HTTP_CODE" == "201" ]]; then
+  echo "  ✓ JIRA comment posted"
+else
+  echo "  WARNING: JIRA comment returned HTTP $HTTP_CODE" >&2
+  echo "$RESP" | grep -v "HTTP_CODE:" | head -3
+fi
+
+# ── Step 5: Move ticket to Code Review ──────────────────────────────────────
+echo ""
+echo "==> Moving $TICKET_ID to Code Review..."
+jira issue move "$TICKET_ID" "Code Review" 2>&1 && echo "  ✓ Ticket moved to Code Review" || echo "  WARNING: Could not move ticket" >&2
+
+echo ""
+echo "==> Done!"
+echo "    JIRA:   $JIRA_SERVER/browse/$TICKET_ID"
+echo "    GitHub: https://github.com/$GH_REPO/pull/$PR_NUMBER"

package/plugins/lisa-cdk/skills/jira-fix/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: jira-fix
+description: This skill should be used when fixing a bug ticket in JIRA
+---
+
+1. Use the JIRA/Atlassian MCP or CLI to fully read this issue, including comments and attachments: $ARGUMENTS
+2. Extract sign-in information if available from the ticket (e.g., test credentials, OTP codes)
+3. Use the project's verification method to attempt to reproduce the bug:
+   - For UI projects: Use Playwright MCP browser tools to record a replication
+   - For API projects: Use curl or test commands to reproduce the error
+   - For library projects: Write a minimal reproduction test
+4. If you cannot reproduce the issue, upload the evidence to the JIRA ticket explaining that you can't replicate it and skip the remaining steps
+5. If there have already been attempts to fix this bug, understand the previous attempts by looking for pull requests and git commits related to it
+6. Fix the bug
+7. Verify the fix using the same verification method used in step 3
+8. Upload the evidence to the JIRA ticket and explain the fix

package/plugins/lisa-cdk/skills/jira-implement/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: jira-implement
+description: This skill should be used when implementing the requirements in a JIRA ticket.
+---
+
+Use either the Atlassian MCP or CLI to examine the contents of the JIRA ticket: $ARGUMENTS
+
+If neither is available, stop and report that you cannot access the ticket.
+
+Read all the details in the ticket, including any URLs and attachments.
+
+Make a plan to fulfill the requirements of the ticket.
+
+Important: If this involves UI changes, use Playwright MCP browser tools to access the app and get a better understanding of what needs to be done. Create a verification task using browser tools to confirm the implementation.
+
+Important: If this involves API or backend changes, use curl or test commands to understand current behavior. Create a verification task to confirm the implementation.
+
+If you don't know how to access the app or service, clarify when making the plan.