bash \"${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh\" 2>/dev/null || echo \"$HOME/.claude\"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\nthat returns no file is no personal configuration: continue silently. When that file or the project .han/config.md\nprobe supplies content, apply it per config-rule.md, which governs precedence\nbetween the two files, relative-path resolution, and what to do with a file that reads but cannot be used.
Take an already-broken-down work-items.md file (produced by /plan-work-items) and publish each slice as a Jira\nticket in a single target project.
The breakdown work — drafting slices, assigning symbolic IDs, specifying dependencies, inventorying references — has\nalready been done upstream. This skill's job is to validate the format, confirm the target, create one ticket per slice\nthrough the Atlassian MCP server, link the within-file dependencies, and place the tickets in the chosen column.
\nwork-items.md that names multiple code repos still produces tickets in the single project you name; the repo prose\nis informational only.Depends on line must resolve to another slice in the\nsame file. A Depends on that names an unknown SYM is a format error to surface for repair.W-N, V2-N, EV-N,\n…); the prefix has no effect on Jira placement.Story, no assignee, reporter taken from the Atlassian MCP identity, and the project's\ninitial status (Backlog). Each is overridable per run; nothing is assigned or moved unless asked.--parent <KEY> accepts an epic or a standard issue (a\nstory, task, or bug). Under an epic, each item is a standard issue (default Story). Under a story (any\nstandard issue), each item is a subtask (default the project's subtask issue type). You cannot parent under a\nsubtask. --epic <KEY> is a deprecated alias for --parent; it resolves the same way regardless of the named issue's\nactual type.artifacts/ subfolder of the\nplan that is not a contract or design reference.This skill cannot run without a configured and connected Atlassian MCP server. Confirm it is reachable by calling\nmcp__claude_ai_Atlassian__getAccessibleAtlassianResources to retrieve the cloud ID(s). If the tool is unavailable, the\ncall errors, or it returns no accessible resources, stop immediately and tell the user the skill requires the\nAtlassian 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\nproject in Step 3.
\nIf the path is not provided, ask for it. The input is a single work-items.md produced by /plan-work-items. Read it.\nIts format is described in references/work-items-file-format.md.
Read these from the arguments and conversation; do not guess defaults the user did not ask for:
\n--project <KEY> (e.g., ACME) or --board <name/URL>. Required. If absent, ask\nfor it in Step 3.--parent <KEY> (an epic like ACME-12, or a story / standard issue like ACME-34) or an issue URL.\nOptional. When present, every created ticket is parented to it. --epic <KEY> is accepted as a deprecated alias for\nthe same option; if both are given and name different keys, stop and ask which one. The parent's hierarchy level\ndecides the child issue type (resolved in Step 3): standard issues under an epic, subtasks under a story.--type <name>. Optional; defaults to Story at the project top level or under an epic, and to the\nproject's subtask issue type when the parent is a story.--assignee <accountId or email>. Optional; defaults to unassigned.--column <name>. Optional; defaults to the project's initial status (Backlog).Using the cloud ID from Step 0, resolve everything concretely now so failures surface before any ticket is created:
\nProject (required). If given a project key, confirm it with mcp__claude_ai_Atlassian__getVisibleJiraProjects. If\ngiven a board, resolve it to its underlying project (list projects and match; if a board maps to more than one project\nor is ambiguous, ask the user which project to use). If no project or board was provided, ask for one — do not proceed\nwithout a project key.
Parent (optional). If a parent was named (--parent, or the deprecated --epic), fetch it with\nmcp__claude_ai_Atlassian__getJiraIssue to confirm it exists and is in the target project, then read its issue type's\nhierarchy level to decide the child mode:
Story.Record the parent's key and which child mode applies.
\nIssue type. Call mcp__claude_ai_Atlassian__getJiraProjectIssueTypesMetadata for the project. Determine the\neffective default from the parent mode above (no parent or epic parent → Story; story parent → the project's subtask\nissue type, the one flagged as a subtask in the metadata). Then confirm the chosen type — the --type override when\ngiven, otherwise the effective default — both exists in the project and sits at the correct hierarchy level\nfor the parent: under a story it must be a subtask type, otherwise it must be a standard (non-subtask) type. If the\nchosen type is missing or at the wrong level, surface the available types at the correct level and ask the user to\npick one. If a story parent is named but the project exposes no subtask type, stop and tell the user subtasks are not\nenabled in this project.
Assignee (optional). If an assignee was named, resolve it to an account ID with\nmcp__claude_ai_Atlassian__lookupJiraAccountId. If unset, leave tickets unassigned.
Column (optional). If a column was named, hold it for Step 8. Resolve the matching status when you transition\n(Step 8), since transitions are per-issue.
\nCheck the work-items file against the invariants in\nreferences/jira-ticket-template.md and\nreferences/work-items-file-format.md:
\n## <SYM-N> — <title> with an em-dash separator (already-published\nheadings annotated as ## <SYM-N> (<KEY>) — <title> are valid too).Depends on line. Literal bold marker **Depends on.**, trailing period, None. or comma-separated SYMs.Depends on line resolves to another slice in this file.artifacts/ subfolder that is not a contract or design reference.When a check fails, attempt evidence-based repair. Pull evidence from the source work-items.md, the parent plan\nreferenced in its intro, the feature spec in the same folder, sibling files in the plan folder, and the relevant repo's\nADRs / coding standards / docs:
Depends on line — propose None. if no blockers are evident in the slice's prose. Cite the absence.Depends on — propose either the correct in-file SYM (if a typo is evident) or None.. Cite the SYM\nlist this file actually defines.After validation, report findings in plain language. For each finding name: (1) what is wrong — slice SYM, line\nreference, failing invariant; (2) the proposed fill — corrected line, new bullet, removed link; (3) the evidence — file\npath with line number, document section, or named source.
\nThen give the user three actions: Continue with fills (apply the repairs to the source work-items.md and proceed),\nCorrect the fills (user provides the right values; apply those and proceed), or Stop (exit without creating\ntickets). If validation passes with no findings, proceed to Step 5.
Creating Jira tickets writes to a shared system, so confirm before doing it. Present a summary and wait for an explicit\nyes:
\n(<KEY>) annotation.| SYM | \nSummary (ticket title) | \nDepends on | \n
|---|---|---|
| W-1 | \nBackend per-list validator generalization | \nNone | \n
| W-2 | \n… | \nW-1 | \n
State the total count and that reporter will be the authenticated Atlassian user. Do not create anything until the user\nconfirms.
\nWalk the slices in file order (blocker-first, as authored). Skip any slice whose heading already carries a (<KEY>)\nannotation so a re-run resumes cleanly. For each remaining slice, call mcp__claude_ai_Atlassian__createJiraIssue with:
Story at the top level or under an epic; the project's subtask\ntype when the parent is a story),— in the heading),parent field the project's create metadata exposes; for a subtask, Jira requires\nparent. If parent is rejected for an epic in a company-managed project, surface the legacy \"Epic Link\" field\nrequirement rather than dropping the parent silently.After each successful create, capture the returned Jira key and rewrite that slice's heading in place from\n## <SYM-N> — <title> to ## <SYM-N> (<KEY>) — <title> using Edit, so dependencies resolve and re-runs skip it. Report\neach creation as created: <SYM-N> -> <KEY>.
Once every slice has a Jira key, build the SYM→key map from the annotated headings and walk each slice's\n**Depends on.** line. For each blocker (skip None.):
Depends on line in its description\nfrom symbolic IDs to the blockers' Jira keys (linked), via mcp__claude_ai_Atlassian__editJiraIssue. This survives\nregardless of native-link support.Report each as linked: <SYM-A>(<KEY-A>) blocked_by <SYM-B>(<KEY-B>).
By default, leave every ticket in the project's initial status (Backlog) and do nothing here.
\nWhen the user named a --column, transition each created ticket toward the matching status: call\nmcp__claude_ai_Atlassian__getTransitionsForJiraIssue for the ticket, find the transition whose target status matches\nthe requested column, and apply it with mcp__claude_ai_Atlassian__transitionJiraIssue. If no transition leads to the\nrequested column for a ticket, do not force it — report that ticket as left in Backlog and name the column it could not\nreach, so the user can move it by hand.
Summarize: the project and parent (if any, named as the epic or story it is), the issue type used (noting \"subtask\" when\nitems were nested under a story), the assignee (or unassigned), and the column. List every created ticket as\n<SYM-N> — <KEY> with its URL, the count of dependency links made (and whether they are native Jira links or\ndescription references), and any slices skipped because they already carried a key. If any step failed, report the error\nand confirm the source work-items.md annotations reflect exactly which tickets were created.