plugins/lisa-expo/skills/jira-journey/SKILL.md
Read a JIRA ticket's Validation Journey section, execute the steps using Playwright MCP browser tools across all defined viewports, capture screenshots at each marker, generate evidence templates, and post to JIRA + GitHub PR using the jira-evidence skill.
npx skillsauth add codyswanngt/lisa jira-journeyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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: <TICKET_ID> [PR_NUMBER]
TICKET_ID (required): JIRA ticket key (e.g., PROJ-123)PR_NUMBER (optional): GitHub PR number to update descriptionJIRA_API_TOKEN environment variable setjira-cli configured (~/.config/.jira/.config.yml)gh CLI authenticatedRun the parser script to extract the Validation Journey from the JIRA ticket description:
python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
The script outputs JSON to stdout:
{
"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.
Before starting the journey, verify each prerequisite:
browser_navigate to the app URL).env.localhost or .env.local)For each viewport defined in the journey:
browser_resize to set the viewport dimensionsscreenshot marker, use browser_take_screenshot to capture the screenshotScreenshots 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 stepviewport-name: lowercase viewport name from the Viewports tableExample: For a journey with 3 screenshot markers and 2 viewports:
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
Execute the full journey once per viewport. Between viewports:
browser_resizeThis ensures each screenshot is captured at the correct viewport dimensions with the correct application state.
After capturing all screenshots, run the template generator:
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:
Use the jira-evidence skill to post everything:
bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> ./evidence <PR_NUMBER>
Confirm images render inline at both the JIRA ticket and GitHub PR.
The JIRA ticket description must contain a section with this structure:
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
[SCREENSHOT: name] markers define where to capture. The name is used in the filename.Some modals close when the viewport changes. The viewport execution strategy (full journey per viewport) handles this — each viewport starts fresh.
If the app requires re-authentication after resize/navigation, include the auth steps in the journey.
If a step is conditional, capture the screenshot at the state described in the step text, not after the conditional action.
documentation
Onboard a user to the project via its LLM Wiki. Interviews the user about themselves in relation to the project, captures that to project-scoped memory only, then gives a guided tour of what the project is and sample questions they can ask. Use when someone is new to the project or asks to be onboarded. Read-mostly — it does not open PRs or write PII into the wiki.
documentation
Migrate an existing, hand-rolled wiki implementation onto the lisa-wiki kernel — phased and compatibility-first, with a strict no-loss guarantee. Use when adopting lisa-wiki in a repo that already has its own wiki/, ingest skills, docs, or roles. Renaming things into the canonical shape is fine; losing functionality or data is not. Ends by running /doctor.
development
Health-check the LLM Wiki. Reports orphan pages, contradictions, stale claims, broken internal links, missing index/log coverage, structure-manifest violations, and secret/tenant leaks. Use periodically or before hardening a wiki. Read-only — it reports findings, it does not fix them.
testing
Ingest source material into the LLM Wiki. With an argument (URL, file path, or prompt) it ingests that one source; with no argument it runs a full ingest across every enabled non-external-write source. Routes to the right connector, then runs the ordered pipeline (source note → synthesis → index → log → verify → state → commit/PR). Use whenever new knowledge should enter the wiki.