Work Items to Jira Tickets

Project Context

• personal config directory: !bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"
• project .han/config.md: !cat .han/config.md 2>/dev/null || echo ""

As your first action, use the Read tool on .han/config.md inside the personal config directory path above. A read that returns no file is no personal configuration: continue silently. When that file or the project .han/config.md probe supplies content, apply it per config-rule.md, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Work Items to Jira Tickets

Take an already-broken-down work-items.md file (produced by /plan-work-items) and publish each slice as a Jira ticket in a single target project.

The breakdown work — drafting slices, assigning symbolic IDs, specifying dependencies, inventorying references — has already been done upstream. This skill's job is to validate the format, confirm the target, create one ticket per slice through the Atlassian MCP server, link the within-file dependencies, and place the tickets in the chosen column.

Rules

• Every slice posts into one Jira project. This skill does not split work across repos or projects. A work-items.md that names multiple code repos still produces tickets in the single project you name; the repo prose is informational only.
• Dependencies are within-file only. Every SYM named in a Depends on line must resolve to another slice in the same file. A Depends on that names an unknown SYM is a format error to surface for repair.
• Symbolic-ID prefixes: accept whatever the input uses. Any uppercase prefix shape is valid (W-N, V2-N, EV-N, …); the prefix has no effect on Jira placement.
• Defaults: issue type Story, no assignee, reporter taken from the Atlassian MCP identity, and the project's initial status (Backlog). Each is overridable per run; nothing is assigned or moved unless asked.
• Parenting is optional and determines the child issue type. --parent <KEY> accepts an epic or a standard issue (a story, task, or bug). Under an epic, each item is a standard issue (default Story). Under a story (any standard issue), each item is a subtask (default the project's subtask issue type). You cannot parent under a subtask. --epic <KEY> is a deprecated alias for --parent; it resolves the same way regardless of the named issue's actual type.
• Every slice ticket MUST carry the reference artifacts an implementer needs — API/event contracts, design references, schema docs, runbooks, ADRs, coding standards. Tickets that consume an HTTP endpoint or event payload MUST reference the contract section that defines it. Full include/exclude list in references/reference-artifact-inventory.md.
• NEVER include process artifacts in ticket descriptions. Excluded: iteration histories, decision logs, review