work-items-to-jira

## 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 not ask for:

- **Target project or board** — `--project <KEY>` (e.g., `ACME`) or `--board <name/URL>`. **Required.** If absent, ask
  for it in Step 3.
- **Parent** — `--parent <KEY>` (an epic like `ACME-12`, or a story / standard issue like `ACME-34`) or an issue URL.
  Optional. When present, every created ticket is parented to it. `--epic <KEY>` is accepted as a deprecated alias for
  the same option; if both are given and name different keys, stop and ask which one. The parent's hierarchy level
  decides the child issue type (resolved in Step 3): standard issues under an epic, subtasks under a story.
- **Issue type** — `--type <name>`. Optional; defaults to `Story` at the project top level or under an epic, and to the
  project's subtask issue type when the parent is a story.
- **Assignee** — `--assignee <accountId or email>`. Optional; defaults to unassigned.
- **Column** — `--column <name>`. Optional; defaults to the project's initial status (Backlog).

### 3. Resolve the target against Jira

Using the cloud ID from Step 0, resolve everything concretely now so failures surface before any ticket is created:

- **Project (required).** If given a project key, confirm it with `mcp__claude_ai_Atlassian__getVisibleJiraProjects`. If
  given a board, resolve it to its underlying project (list projects and match; if a board maps to more than one project
  or is ambiguous, ask the user which project to use). If no project or board was provided, ask for one — do not proceed
  without a project key.
- **Par