/work-items-to-jira

name: work-items-to-jira
description: >
  Break a work-items.md file (produced by /plan-work-items) into independently-grabbable Jira tickets, one per slice, in
  a single Jira project. Use when you want to turn a work-items file into Jira tickets, publish work items as Jira
  issues, or create implementation tickets that can be worked on and tracked in Jira. Requires a configured Atlassian
  MCP server. Does not produce the work-items file itself — use plan-work-items to break a plan into work items first.
  Does not post to GitHub — use work-items-to-issues for GitHub issues.
argument-hint:
  "[path to work-items.md] [--project KEY or --board name] [--parent KEY, epic or story (optional; --epic is a
  deprecated alias)] [--type issue type, default Story] [--assignee accountId or email (optional)] [--column name,
  default Backlog]"
allowed-tools:
  Read, Write, Edit, Glob, Grep, Bash(find *), mcp__claude_ai_Atlassian__getAccessibleAtlassianResources,
  mcp__claude_ai_Atlassian__atlassianUserInfo, mcp__claude_ai_Atlassian__getVisibleJiraProjects,
  mcp__claude_ai_Atlassian__getJiraProjectIssueTypesMetadata, mcp__claude_ai_Atlassian__lookupJiraAccountId,
  mcp__claude_ai_Atlassian__createJiraIssue, mcp__claude_ai_Atlassian__editJiraIssue,
  mcp__claude_ai_Atlassian__getJiraIssue, mcp__claude_ai_Atlassian__getTransitionsForJiraIssue,
  mcp__claude_ai_Atlassian__transitionJiraIssue, mcp__claude_ai_Atlassian__searchJiraIssuesUsingJql,
  Bash(bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh")

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](../../references/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](./references/reference-artifact-inventory.md).

• **NEVER include process artifacts in ticket descriptions.** Excluded: iteration histories, decision logs, review

findings, team findings, facilitation summaries, gap analyses, and anything under an `artifacts/` subfolder of the plan that is not a contract or design reference.

• **No screenshot upload or image embedding.** Design references are carried as links, not uploaded into Jira. See

[references/jira-ticket-template.md](./references/jira-ticket-template.md).

Process

0. Atlassian MCP preflight (hard requirement)

This skill cannot run without a configured and connected Atlassian MCP server. Confirm it is reachable by calling `mcp__claude_ai_Atlassian__getAccessibleAtlassianResources` to retrieve the cloud ID(s). If the tool is unavailable, the call errors, or it returns no accessible resources, **stop immediately** and tell the user the skill requires the Atlassian MCP server to be installed, configured, and authenticated. Do not fall back to any other publishing target.

If more than one site is accessible, note which are available; you will confirm the right one while resolving the project in Step 3.

1. Locate the work-items file

If the path is not provided, ask for it. The input is a single `work-items.md` produced by `/plan-work-items`. Read it. Its format is described in [references/work-items-file-format.md](./references/work-items-file-format.md).

2. Gather the run options

Read these from the arguments and conversation; do not guess defaults the user did