From lisa
Add a Validation Journey section to an existing JIRA ticket by analyzing the change type and generating appropriate verification steps with evidence markers.
npx claudepluginhub codyswanngt/lisa --plugin lisaThis skill uses the workspace's default tool permissions.
Read an existing JIRA ticket, analyze the change type, and generate a Validation Journey section with appropriate verification steps based on the project's verification patterns.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
Read an existing JIRA ticket, analyze the change type, and generate a Validation Journey section with appropriate verification steps based on the project's verification patterns.
$ARGUMENTS: <TICKET_ID>
TICKET_ID (required): JIRA ticket key (e.g., PROJ-123)JIRA_API_TOKEN environment variable setjira-cli configured (~/.config/.jira/.config.yml)Use the Atlassian MCP or jira-cli to read the full ticket details:
jira issue view <TICKET_ID>
Extract: title, description, acceptance criteria, components, labels, linked tickets.
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.
Examine the ticket description, acceptance criteria, and codebase to determine the change type:
Use the Explore agent or read the codebase directly to understand which files are affected and what verification approach is appropriate.
Based on the change type, generate verification steps using patterns from verfication.md:
| Change Type | Verification Approach |
|---|---|
| API/GraphQL | curl commands verifying endpoints, status codes, response schemas |
| Database migration | Migration execution + schema verification + rollback check |
| Background job/queue | Enqueue + process + state change verification |
| Library/utility | Test execution + build verification + export check |
| Security fix | Exploit reproduction pre-fix + exploit failure post-fix |
| Auth/authz | Multi-role verification with explicit status codes |
Compose the journey with [EVIDENCE: name] markers at key verification points:
h2. Validation Journey
h3. Prerequisites
- List required services, database, env vars
h3. Steps
1. Verify current state before changes
2. Apply the change
3. Verify expected new state [EVIDENCE: state-name]
4. Test error/edge cases [EVIDENCE: error-case]
5. Verify rollback if applicable [EVIDENCE: rollback]
h3. Assertions
- Describe what must be true after verification
curl -s localhost:3000/health | jq .status" not "Check the endpoint"api-response, schema-check, rate-limit-hit{status: ok}" not "API works correctly"Display the drafted Validation Journey to the user and ask for confirmation before appending it to the ticket.
After user approval, use the JIRA REST API to append the Validation Journey to the existing ticket description.
Run the parser again to confirm the journey was added correctly:
python3 .claude/skills/jira-journey/scripts/parse-plan.py <TICKET_ID>
jira-create guidelines