plugins/lisa-copilot/skills/jira-journey/SKILL.md
Parse a JIRA ticket's Validation Journey section, execute the verification steps using appropriate tools (curl, test commands, database queries), capture evidence, 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.
All Atlassian operations in this skill go through lisa:atlassian-access. Do not call MCP tools or acli directly. Note: the helper scripts (scripts/parse-plan.py, scripts/jira-evidence/post-evidence.sh) currently use direct API calls and are pending migration to route through atlassian-access.
Parse a JIRA ticket's Validation Journey, execute the verification steps using the appropriate tools for the change type, capture evidence at each [EVIDENCE: name] marker, and post to JIRA + 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 with: ticket, prerequisites, steps, viewports, assertions.
Note: viewports may be empty for TypeScript tickets — that is expected.
Before starting the journey, verify each prerequisite:
Execute each step sequentially. For each step, determine the verification approach based on the step text and change type:
evidence/NN-name.txtevidence/NN-name.txtevidence/NN-name.txtevidence/NN-name.txtevidence/NN-name.txtAt each [EVIDENCE: name] marker, capture stdout/stderr to a numbered file:
Evidence files are named: {NN}-{evidence-name}.txt (or .json for structured data)
NN: zero-padded sequential number (01, 02, 03...)evidence-name: the value from [EVIDENCE: name] in the JIRA stepExample:
evidence/
01-health-check.json
02-schema-after-migration.txt
03-rate-limit-response.txt
comment.txt
comment.md
After capturing all evidence, 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 evidence formatted as code blocks.
Use the jira-evidence skill to post everything:
bash .claude/skills/jira-evidence/scripts/post-evidence.sh <TICKET_ID> ./evidence <PR_NUMBER>
Confirm evidence is posted to both the JIRA ticket and GitHub PR.
The agent should use patterns from the project's verfication.md when executing steps:
| Change Type | Verification Method | Evidence Format |
|---|---|---|
| API endpoint | curl -s localhost:PORT/endpoint | JSON response |
| Database migration | psql -c "\d table" or migration output | Schema text |
| Background job | Trigger + check state | Log output |
| Library/utility | bun run test -- path/to/test | Test output |
| Security fix | Reproduce + verify fix | Request/response |
| Auth/authz | Multi-role verification | Status codes per role |
Ensure the command succeeded and produced output. Use 2>&1 to capture both stdout and stderr.
The ticket may not have a Validation Journey section. Use /jira-add-journey <TICKET_ID> to add one.
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.