From lisa-expo
This skill should be used when creating JIRA epics, stories, and tasks from code files or descriptions. It analyzes the provided input, determines the appropriate issue hierarchy, and creates issues with comprehensive quality requirements including test-first development and documentation.
npx claudepluginhub codyswanngt/lisa --plugin lisa-expoThis skill is limited to using the following tools:
Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Analyze the provided file(s) and create a comprehensive JIRA hierarchy with all mandatory quality gates.
Epic → User Story → Tasks (test, implement, document, cleanup)
Test-First: Write tests before implementation Quality Gates: All tests/checks must pass, no SonarCloud violations Documentation: Check existing, update/create new, remove obsolete Feature Flags: All features behind flags with lifecycle plan Cleanup: Remove temporary code, scripts, dev configs Validation Journey: Every ticket that touches UI must include a Validation Journey section (see below)
Every ticket that changes, adds, or fixes UI must include a Validation Journey section in the description. This section is consumed by the jira-journey skill to automate visual verification via Playwright.
Include a Validation Journey when the ticket involves:
Skip the Validation Journey only for:
Design the journey from the end user's perspective. Walk through the exact steps a human would take to verify the change. Place [SCREENSHOT: name] markers at the key visual checkpoints.
Add this section to the ticket description:
h2. Validation Journey
h3. Prerequisites
- App running locally or on dev
- Authenticated as test user
- Any required feature flags enabled
h3. Steps
1. Navigate to the relevant page
2. Perform the first action
3. Verify the expected state [SCREENSHOT: state-name]
4. Perform the next action
5. Verify the final state [SCREENSHOT: final-state]
h3. Viewports
||Name||Width||Height||
|Desktop|1512|768|
|Mobile|375|812|
h3. Assertions
- Describe what must be visually true at each viewport
- Each assertion is verified against the captured screenshots
[SCREENSHOT: name] at states that prove the change works. Use descriptive kebab-case names (e.g., modal-open, button-disabled, form-error)Each issue must clearly communicate to:
Default project: from jira-cli config (override via arguments) Exclude unless requested: migration plans, performance tests
Execute the analysis and create the complete JIRA structure with proper parent-child relationships.