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: Aug 27, 2026, 3:59 AM121.0s1 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. Prefer the config Lisa writes at.lisa/jira-cli/.config.yml(thesetup-jira-cliSessionStart hook writes it fromJIRA_SERVER/JIRA_LOGIN/JIRA_PROJECTon a project whosetrackerisjira), and pass it explicitly with--config. A developer's own~/.config/.jira/.config.ymlstill works as jira-cli's default when no--configis given.
Workflow
Step 1: Read the Ticket
Use the Atlassian MCP or jira-cli to read the full ticket details:
# 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 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-setup-workstation
development
VerifiedTrustedCommunity
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-remote-env
tools
VerifiedTrustedCommunity
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-setup-local-env
tools
VerifiedTrustedCommunity
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
3SKILL.mdUpdated Aug 30, 2026
codyswanngt/lisa-remote-dispatch
tools
VerifiedTrustedCommunity
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.
3SKILL.mdUpdated Aug 30, 2026