codyswanngt/jira-add-journey
plugins/lisa-expo-agy/skills/jira-add-journey/SKILL.md
Add a Validation Journey section to an existing JIRA ticket by reading the ticket description, understanding the feature, and generating the journey steps, viewports, and assertions.
$ install --global
skillsauthnpx skillsauth add codyswanngt/lisa jira-add-journeyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Jun 3, 2026, 4:39 AM84.8s1 file scanned
SKILL.md
- 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, viewports, 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 user flow, 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_TOKENenvironment variable setjira-cliconfigured (~/.config/.jira/.config.yml)
Workflow
Step 1: Read the Ticket
Use the Atlassian MCP or jira-cli to read the full ticket details:
jira issue view <TICKET_ID>
Extract:
- Title and description (what the feature/fix is)
- Acceptance criteria (what needs to be verified)
- Components or labels (frontend, mobile, responsive, etc.)
- Any linked tickets or parent epic context
Step 2: Check for Existing Journey
Run the parser to see if a Validation Journey already exists:
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:
- Identify the UI surface — Which pages, modals, or components are affected?
- Identify the user flow — What steps does a user take to exercise the feature?
- Identify visual checkpoints — At which states should screenshots be captured?
- Identify viewports — Does this feature have responsive behavior? Always include Desktop. Add Mobile for responsive changes.
- Identify assertions — What must be visually true for the feature to be correct?
Use the Explore agent or read the codebase directly to understand:
- Which components are involved (search by ticket ID, feature name, or file paths mentioned in the ticket)
- What testIDs exist (for Playwright interaction)
- What the user flow looks like (Container/View structure, navigation, modals)
Step 4: Draft the Validation Journey
Compose the journey following the format:
h2. Validation Journey
h3. Prerequisites
- List what must be true before starting (backend, auth, feature flags)
h3. Steps
1. First action the user takes
2. Second action [SCREENSHOT: descriptive-name]
3. Continue the flow
4. Final verification [SCREENSHOT: final-state]
h3. Viewports
||Name||Width||Height||
|Desktop|1512|768|
|Mobile|375|812|
h3. Assertions
- Testable visual statement about the expected behavior
- Another assertion about responsive layout
Guidelines for Drafting
- 3-7 screenshot markers — Enough to prove the feature, not so many that execution is slow
- Concrete steps — "Click the 'Add action' button" not "Interact with the controls"
- Include auth if needed — If the journey requires login, include credentials in Prerequisites
- Name feature flags explicitly — If the feature is behind a PostHog flag, name it
- Assertions must be testable — "Buttons stacked vertically on mobile" not "Layout looks good"
- Screenshot names in kebab-case —
confirm-step-disabled,modal-open,form-error
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. The user may want to:
- Add or remove steps
- Change screenshot markers
- Adjust viewports or assertions
- Modify prerequisites
Step 6: Append to Ticket Description
After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
Use the Atlassian MCP updateJiraIssue to update the description field. The journey section must be appended after the existing description content, not replace it.
Step 7: Verify
Run the parser again to confirm the journey was added correctly:
python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
The parser should now return the steps, viewports, and assertions from the newly added section.
When to Use This Skill
- Ticket was created before the Validation Journey convention was established
- Ticket was created manually without following
lisa:jira-createguidelines - Ticket needs a journey added or updated based on implementation progress
- During sprint planning, to ensure all frontend tickets have journeys before work starts
Related Skills
codyswanngt/lisa-wiki-onboard-me
documentation
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-migrate
documentation
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-lint
development
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026
codyswanngt/lisa-wiki-ingest
testing
VerifiedTrustedCommunity
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.
1SKILL.mdUpdated Jun 5, 2026