# Lisa Jira Create > 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. - Skill: `codyswanngt/lisa-jira-create` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add codyswanngt/lisa-jira-create` - Raw SKILL.md: https://api.skillmd.com/api/skills/codyswanngt/lisa-jira-create/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: codyswanngt (https://skillmd.com/u/codyswanngt) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/codyswanngt/lisa-jira-create --- # Create JIRA Issues from $ARGUMENTS All Atlassian operations in this skill go through `lisa-atlassian-access`. Do not call MCP tools or `acli` directly. Analyze the provided file(s) and plan a JIRA hierarchy. **This skill plans structure only — every individual ticket write is delegated to `lisa-jira-write-ticket`.** Do not invoke `lisa-atlassian-access` write operations directly from this skill — all writes go through `lisa-jira-write-ticket`. ## Process 1. **Analyze**: Read $ARGUMENTS to understand scope. 2. **Extract source artifacts**: invoke the `lisa-tracker-source-artifacts` skill, then enumerate every external URL, embed, attachment, or example payload in the input and classify each by domain per its rules. Build the `artifacts` map (one entry per artifact: url, title, domain, source page, classification reason). See "Source Artifacts" below. 3. **Walk the live product** (when applicable): if the work touches existing user-facing surfaces, invoke the `lisa-product-walkthrough` skill to capture current behavior, design-vs-product divergence, and reuse candidates. Skip when the work is purely backend or affects a screen that does not yet exist. See "Live Product Walkthrough" below. 4. **Determine structure**: - Epic needed if: multiple features, major changes, >3 related files - Direct tasks if: bug fix, single file, minor change 5. **Plan hierarchy**: ```text Epic → User Story → Tasks (test, implement, document, cleanup) ``` 6. **Delegate every write to `lisa-jira-write-ticket`** in dependency order (epic first, then stories with the epic as parent, then sub-tasks with their story as parent). Pass the artifacts (filtered by domain per `lisa-tracker-source-artifacts` inheritance rules) and the walkthrough findings (under `## Current Product`). See "Delegation to jira-write-ticket" below. 7. **Run the artifact preservation gate** (`lisa-tracker-source-artifacts` §8): after all writes complete, build the preservation matrix and verify every extracted artifact is reachable from the created tickets. Fail loudly if anything was dropped. ## Mandatory for Every Code Issue **Test-First**: Write tests before implementation **Quality Gates**: All tests/checks must pass, no SonarCloud violations **Documentation**: Check existing, update/create new, remove obsolete **Cleanup**: Remove temporary code, scripts, dev configs ## Validation Journey Tickets that change runtime behavior should include a `Validation Journey` section in the description. This section is consumed by the `lisa-jira-journey` skill to automate verification. ### When to Include Include a Validation Journey when the ticket involves: - API endpoint changes (new, modified, or removed routes) - Database schema changes (migrations, new columns, index changes) - Background job or queue processing changes - Library or utility function changes that affect exports - Security fixes (authentication, authorization, input validation) - Performance-critical changes requiring measurement ### When to Skip Skip the Validation Journey for: - Documentation-only changes - Config-only changes (env vars, CI/CD, feature flags with no code) - Type-definition-only changes (interfaces, types, no runtime effect) ### How to Write Design the journey based on the **change type**. The agent executing the journey determines how to verify each step using patterns from the project's `verfication.md`. Place typed `[EVIDENCE: : ]` markers at key verification points (types: `screenshot`, `recording`, `http-transcript`, `cli-output`, `log-snippet`, `db-query-output`, `perf-trace`, `test-run-log`, `deploy-log`, `state-dump` — see the `verification` rule). Add this section to the ticket description: ```text h2. Validation Journey h3. Prerequisites - Local dev server running - Database accessible - Required environment variables set h3. Steps 1. Verify the current state before changes 2. Apply the change (run migration, deploy, etc.) 3. Verify the expected new state [EVIDENCE: http-transcript: state-after-change] 4. Test error/edge cases [EVIDENCE: screenshot: error-state-rendered] 5. Verify rollback or cleanup if applicable [EVIDENCE: db-query-output: rows-restored-after-rollback] h3. Assertions - Describe what must be true after verification - Each assertion is verified against the captured evidence ``` ### Guidelines 1. **Steps must be concrete and verifiable** — "Run `curl -s localhost:3000/health`" not "Check the API" 2. **Evidence markers at verification points** — Place typed `[EVIDENCE: : ]` at states that prove the change works. The type names HOW the proof is captured, the kebab-case name WHAT it proves (e.g., `[EVIDENCE: http-transcript: api-response-200]`, `[EVIDENCE: screenshot: error-state-rendered]`). An untyped assertion label like `[EVIDENCE: works-gracefully]` fails validation gate S14 - To point at evidence owned by another work item, use exactly `[EVIDENCE-REF: | : ]`. It is non-claiming and cannot satisfy S14; never paste or quote the sibling's `[EVIDENCE: ...]` marker into this ticket. 3. **Include 2-5 evidence markers** — Enough to prove the change works across happy path and error cases 4. **Assertions are testable statements** — "Health check returns 200 with status ok" not "API works" 5. **Prerequisites include environment setup** — Database connection, env vars, running services ## Source Artifacts If $ARGUMENTS includes (or references) any external artifact — PRD, design doc, Figma URL, Lovable prototype, Loom walkthrough, screenshot, example payload — those references MUST be preserved as remote links on the created tickets. Silent artifact loss is the single most common quality failure in this pipeline. **Invoke the `lisa-tracker-source-artifacts` skill** for the canonical rules: domains, per-tool classification (Figma `/proto/` vs design, Lovable, Loom, screenshots), source precedence, conflict handling under `## Open Questions`, inheritance from epic → story → sub-task, and the existing-component reuse expectation. Do not restate the rules here — invoke the skill so any rule change propagates uniformly. When delegating actual writes to `lisa-jira-write-ticket`, pass the extracted artifact list so its Phase 4c (Remote Links) step can attach them. ## Live Product Walkthrough When the work touches existing user-facing surfaces, invoke the `lisa-product-walkthrough` skill before drafting tickets. The walkthrough findings (current behavior, design-vs-product divergence, reuse candidates, behavioral surprises) become inputs to the ticket plan and surface under `## Current Product` on the resulting tickets. Skip only when the work is purely backend or affects a screen that does not yet exist. ## Issue Requirements Each issue must clearly communicate to: - **Coding Assistants**: Implementation requirements - **Developers**: Technical approach - **Stakeholders**: Business value Default project: from jira-cli config (override via arguments) Exclude unless requested: migration plans, performance tests ## Delegation to jira-write-ticket **Mandatory.** Every ticket created by this skill MUST go through `lisa-jira-write-ticket`. This skill never invokes `lisa-atlassian-access` write operations itself — all writes are delegated so the gate cannot be bypassed. `lisa-jira-write-ticket` enforces things this skill does not, and which determine ticket quality: - 3-audience description (Context / Technical Approach / Acceptance Criteria) - Gherkin acceptance criteria - Epic parent validation (non-bug, non-epic types) - Explicit link discovery (`blocks` / `is blocked by` / `relates to` / `duplicates` / `clones`) - Remote links (PRs, Confluence, dashboards) - Single-repo scope check for Bug / Task / Sub-task - Sign-in account and target environment recorded in description - Post-create verification **Declare readiness on every leaf write.** Per the `ready-role-filing` rule an omitted `build_ready` is **not build-ready** on any tracker, so pass `build_ready: true` on each Sub-task (the leaf work units this skill plans) and never on the Epic or Stories, which are containers per `leaf-only-lifecycle`. A leaf that is deliberately held instead passes `human_gate: ""`. Filing a leaf with neither is an incomplete handoff and `lisa-jira-write-ticket` rejects it. ### Invocation order Tickets must be created in parent-before-child order so each child can be passed its parent key: 1. Invoke `lisa-jira-write-ticket` for the epic. Capture the returned key. 2. For each story, invoke `lisa-jira-write-ticket` with the epic key as the epic parent. Capture each story key. 3. For each sub-task, invoke `lisa-jira-write-ticket` with the parent story key. ### What to pass to each invocation For every delegated write, pass: - The summary, issue type, project key, and priority you decided - The 3-section description body you drafted (Context / Technical Approach / Acceptance Criteria) - Gherkin acceptance criteria - Parent key (epic key for stories; story key for sub-tasks) - The artifact list extracted in "Source Artifacts", filtered by domain per the inheritance rules — `lisa-jira-write-ticket` Phase 4c attaches them as remote links - For tickets that change runtime behavior: the Validation Journey draft (or instruct it to call `lisa-jira-add-journey` after create) ### What this skill is responsible for This skill owns: - Deciding the *shape* of the hierarchy (what's an epic vs. story vs. sub-task) - Drafting the description body and acceptance criteria from the input - Extracting and classifying source artifacts - Threading parent keys through subsequent writes - Running the Phase 5.5-style preservation check after all writes complete It does not own the actual JIRA write — that's `lisa-jira-write-ticket`'s job.