@codyswann/lisa 2.195.4 → 2.195.7

package/plugins/lisa-expo/.codex-plugin/skills/jira-create/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: jira-create
+description: "creating JIRA epics, stories…"
+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. Especially load-bearing for Expo/React Native — a UI ticket without a current-product walkthrough is missing context the implementer needs. 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), the walkthrough findings (under `## Current Product`), and — for UI tickets — the Validation Journey draft with `[SCREENSHOT: ...]` markers. 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
+**Validation Journey**: Every ticket that touches UI must include a Validation Journey section (see below)
+
+## Validation Journey (Frontend Tickets)
+
+Every ticket that changes, adds, or fixes UI must include a `Validation Journey` section in the description. This section is consumed by the `lisa:jira-journey` skill to automate visual verification via Playwright.
+
+### When to Include
+
+Include a Validation Journey when the ticket involves:
+- New UI components or screens
+- Layout or styling changes (responsive, spacing, colors)
+- Modal, drawer, or popover behavior
+- Form validation or user input flows
+- Bug fixes that are visually verifiable
+
+Skip the Validation Journey only for:
+- Pure backend/API changes with no UI surface
+- Config-only changes (env vars, feature flags)
+- Test-only or documentation-only changes
+
+### How to Write
+
+Design the journey from the **end user's perspective**. Walk through the exact steps a human would take to verify the change. Place `[SCREENSHOT: name]` markers at the key visual checkpoints.
+
+Add this section to the ticket description:
+
+```text
+h2. Validation Journey
+
+h3. Prerequisites
+- App running locally or on dev
+- Authenticated as test user
+- Any required feature flags enabled
+
+h3. Steps
+1. Navigate to the relevant page
+2. Perform the first action
+3. Verify the expected state [SCREENSHOT: state-name]
+4. Perform the next action
+5. Verify the final state [SCREENSHOT: final-state]
+
+h3. Viewports
+||Name||Width||Height||
+|Desktop|1512|768|
+|Mobile|375|812|
+
+h3. Assertions
+- Describe what must be visually true at each viewport
+- Each assertion is verified against the captured screenshots
+```
+
+### Guidelines
+
+1. **Steps must be concrete and executable** — "Navigate to Players page" not "Go to the relevant section"
+2. **Screenshot markers at visual checkpoints** — Place `[SCREENSHOT: name]` at states that prove the change works. Use descriptive kebab-case names (e.g., `modal-open`, `button-disabled`, `form-error`)
+3. **Include 3-7 screenshot markers** — Enough to prove the feature works, not so many that execution is slow
+4. **Viewports match the change scope** — Always include Desktop (1512x768). Add Mobile (375x812) for responsive changes. Add Tablet (768x1024) only if relevant.
+5. **Assertions are testable statements** — "Buttons stacked vertically on mobile" not "Layout looks good"
+6. **Prerequisites include feature flags** — If the feature is behind a PostHog flag, name it explicitly
+7. **Auth steps included when needed** — If the journey requires login, include the test credentials in Prerequisites
+
+## 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.
+
+Expo-specific note: the existing-component reuse rule is especially load-bearing for React Native — the project has an established component library; pixel-matching a mock instead of reusing components is the most common drift mode.
+
+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, complementing the Validation Journey (which describes how to verify the *new* behavior, not what exists today). 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: from jira-cli config (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 UI-touching tickets: the Validation Journey draft (with `[SCREENSHOT: ...]` markers, viewports, and feature-flag prerequisites). If the journey is missing, 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
+- Drafting the Validation Journey for UI tickets (this is Expo-specific guidance the base skill doesn't have)
+- 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-expo/.codex-plugin/skills/jira-create/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Jira Create"
+short_description: "creating JIRA epics, stories…"
+default_prompt:
+  - "Use $jira-create: creating JIRA epics, stories…."

package/plugins/lisa-expo/.codex-plugin/skills/jira-evidence/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: jira-evidence
+description: "Upload screenshots to GitHub…"
+---
+
+# JIRA Evidence Posting
+
+Upload captured screenshots and generated templates to GitHub PR description and JIRA ticket. This skill is the posting step — it assumes screenshots 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 screenshots 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-viewport.png` screenshots (numbered, e.g., `01-search-step-desktop.png`)
+  - `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 (no hardcoded values)
+2. **Upload to GitHub `pr-assets` release** — Uploads `NN-name-viewport.png` screenshots via `gh release upload --clobber`, creating CDN URLs that render in GitHub markdown
+3. **Update PR description** — Replaces or appends the `## Evidence` section in the PR body using `gh pr edit`
+4. **Upload JIRA attachments** — Uploads screenshots 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 with embedded images)
+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.
+
+## Screenshot Naming Convention
+
+Only files matching `NN-*.png` (two-digit prefix) are uploaded. Other files in the evidence directory are ignored.
+
+```text
+evidence/
+  01-search-step-desktop.png    ✓ uploaded
+  02-confirm-step-desktop.png   ✓ uploaded
+  03-search-step-mobile.png     ✓ uploaded
+  comment.txt                   used for JIRA comment
+  comment.md                    used for PR description
+```
+
+## Troubleshooting
+
+### Images not rendering in GitHub PR
+
+Images must be in the `pr-assets` GitHub release (not committed to git). The script handles this via `gh release upload`. If the release does not exist, create it first:
+
+```bash
+gh release create pr-assets --title "PR Assets" --notes "CDN for PR evidence screenshots"
+```
+
+### 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 — always in that order.
+
+### JIRA API returns 403 on attachment upload
+
+Ensure `JIRA_API_TOKEN` is set and `login` in `~/.config/.jira/.config.yml` matches your Atlassian account email.

package/plugins/lisa-expo/.codex-plugin/skills/jira-evidence/agents/openai.yaml

@@ -0,0 +1,4 @@
+display_name: "Jira Evidence"
+short_description: "Upload screenshots to GitHub…"
+default_prompt:
+  - "Use $jira-evidence: Upload screenshots to GitHub…."

package/plugins/lisa-expo/.codex-plugin/skills/jira-evidence/scripts/post-evidence.sh

@@ -0,0 +1,180 @@
+#!/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 the configured jira.workflow.review status
+#      (skipped entirely when review is unconfigured — stays in claimed)
+
+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 the configured review status (if any) ────────────
+# A transition may target only a status named in .lisa.config.json jira.workflow.
+# `review` is OPTIONAL: when it is not configured, the build lifecycle stays in
+# `claimed` until `done` — do NOT invent a transition. (See config-resolution.md.)
+REVIEW=""
+if [ -f .lisa.config.json ]; then
+  _cfg=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.json 2>/dev/null)
+  [ -n "$_cfg" ] && REVIEW="$_cfg"
+fi
+if [ -f .lisa.config.local.json ]; then
+  _local=$(jq -r '.jira.workflow.review // .jira.workflow.code_review // empty' .lisa.config.local.json 2>/dev/null)
+  [ -n "$_local" ] && REVIEW="$_local"
+fi
+echo ""
+if [ -n "$REVIEW" ]; then
+  echo "==> Moving $TICKET_ID to $REVIEW..."
+  jira issue move "$TICKET_ID" "$REVIEW" 2>&1 && echo "  ✓ Ticket moved to $REVIEW" || echo "  WARNING: Could not move ticket to $REVIEW (not a valid transition?); leaving in current status" >&2
+else
+  echo "==> No jira.workflow.review configured; leaving $TICKET_ID in its current (claimed) status per config-resolution."
+fi
+
+echo ""
+echo "==> Done!"
+echo "    JIRA:   $JIRA_SERVER/browse/$TICKET_ID"
+echo "    GitHub: https://github.com/$GH_REPO/pull/$PR_NUMBER"

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

@@ -0,0 +1,190 @@
+---
+name: jira-journey
+description: "Read a JIRA ticket's Validation…"
+---
+
+# JIRA Validation Journey
+
+Read a JIRA ticket's Validation Journey, execute it via Playwright MCP browser tools, capture screenshots at every `[SCREENSHOT: name]` marker across all viewports, and post evidence to both JIRA and GitHub PR.
+
+## Arguments
+
+`$ARGUMENTS`: `<TICKET_ID> [PR_NUMBER]`
+
+- `TICKET_ID` (required): JIRA ticket key (e.g., `PROJ-123`)
+- `PR_NUMBER` (optional): GitHub PR number to update description
+
+## Prerequisites
+
+- `JIRA_API_TOKEN` environment variable set
+- `jira-cli` configured (`~/.config/.jira/.config.yml`)
+- `gh` CLI authenticated
+- Playwright MCP server running (browser tools available)
+- Dev server running
+
+## Workflow
+
+### Step 1: Parse the Validation Journey
+
+Run the parser script to extract the Validation Journey from the JIRA ticket description:
+
+```bash
+python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
+```
+
+The script outputs JSON to stdout:
+
+```json
+{
+  "ticket": "PROJ-123",
+  "prerequisites": [
+    "Backend dev server running",
+    "Admin user with test credentials"
+  ],
+  "steps": [
+    {"number": 1, "text": "Navigate to Players page", "screenshot": null},
+    {"number": 5, "text": "Open transfer modal", "screenshot": "confirm-step-disabled"}
+  ],
+  "viewports": [
+    {"name": "Desktop", "width": 1512, "height": 768},
+    {"name": "Mobile", "width": 375, "height": 812}
+  ],
+  "assertions": [
+    "Modal fills entire screen on mobile (no horizontal overflow)"
+  ]
+}
+```
+
+Read the JSON output and use it to drive the Playwright session.
+
+### Step 2: Satisfy Prerequisites
+
+Before starting the journey, verify each prerequisite:
+
+1. Check if the dev server is running (try `browser_navigate` to the app URL)
+2. Authenticate if needed (use test credentials from `.env.localhost` or `.env.local`)
+3. Navigate to the starting point described in step 1
+
+### Step 3: Execute Steps at Each Viewport
+
+For **each viewport** defined in the journey:
+
+1. Use `browser_resize` to set the viewport dimensions
+2. Execute each step sequentially using Playwright MCP tools
+3. At each step with a `screenshot` marker, use `browser_take_screenshot` to capture the screenshot
+
+#### Screenshot Naming Convention
+
+Screenshots are named: `{NN}-{screenshot-name}-{viewport-name}.png`
+
+- `NN`: zero-padded sequential number (01, 02, 03...)
+- `screenshot-name`: the value from `[SCREENSHOT: name]` in the JIRA step
+- `viewport-name`: lowercase viewport name from the Viewports table
+
+Example: For a journey with 3 screenshot markers and 2 viewports:
+
+```text
+evidence/
+  01-search-step-desktop.png
+  02-confirm-step-desktop.png
+  03-success-step-desktop.png
+  04-search-step-mobile.png
+  05-confirm-step-mobile.png
+  06-success-step-mobile.png
+  comment.txt
+  comment.md
+```
+
+#### Viewport Execution Strategy
+
+Execute the **full journey once per viewport**. Between viewports:
+
+1. Resize the browser using `browser_resize`
+2. Navigate back to the starting point
+3. Re-execute all steps from the beginning
+
+This ensures each screenshot is captured at the correct viewport dimensions with the correct application state.
+
+### Step 4: Generate Evidence Templates
+
+After capturing all screenshots, run the template generator:
+
+```bash
+python3 .claude/skills/jira-journey/scripts/generate-templates.py \
+  <TICKET_ID> \
+  <PR_NUMBER> \
+  <BRANCH_NAME> \
+  ./evidence
+```
+
+This generates `evidence/comment.txt` (JIRA wiki markup) and `evidence/comment.md` (GitHub markdown) with:
+
+- PR and branch metadata
+- All screenshots organized by viewport
+- The verification journey steps
+- Assertions as verification results
+
+### Step 5: Post Evidence
+
+Use the jira-evidence skill to post everything:
+
+```bash
+bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> ./evidence <PR_NUMBER>
+```
+
+### Step 6: Verify
+
+Confirm images render inline at both the JIRA ticket and GitHub PR.
+
+## Validation Journey Format in JIRA
+
+The JIRA ticket description must contain a section with this structure:
+
+### ADF Structure
+
+```text
+h2. Validation Journey
+
+h3. Prerequisites
+- App running locally or on dev
+- Authenticated as test user
+- Required feature flags enabled
+
+h3. Steps
+1. Navigate to the relevant page
+2. Perform the first action
+3. Click on the element [SCREENSHOT: element-state]
+4. Complete the flow
+5. Verify the final state [SCREENSHOT: final-state]
+
+h3. Viewports
+||Name||Width||Height||
+|Desktop|1512|768|
+|Mobile|375|812|
+
+h3. Assertions
+- Visual assertion about expected behavior
+- Another assertion about responsive layout
+```
+
+### Key Rules
+
+1. **`[SCREENSHOT: name]`** markers define where to capture. The `name` is used in the filename.
+2. **Steps without markers** are executed but not captured.
+3. **Viewports** define all resolutions to test. Each viewport runs the full journey.
+4. **Assertions** describe what to verify visually in each screenshot.
+5. **Prerequisites** describe what must be true before starting.
+
+## Troubleshooting
+
+### Modal closes on viewport resize
+
+Some modals close when the viewport changes. The viewport execution strategy (full journey per viewport) handles this — each viewport starts fresh.
+
+### Authentication required at each viewport
+
+If the app requires re-authentication after resize/navigation, include the auth steps in the journey.
+
+### Screenshot markers in conditional steps
+
+If a step is conditional, capture the screenshot at the state described in the step text, not after the conditional action.

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

@@ -0,0 +1,4 @@
+display_name: "Jira Journey"
+short_description: "Read a JIRA ticket's Validation…"
+default_prompt:
+  - "Use $jira-journey: Read a JIRA ticket's Validation…."