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.
This skill builds a feature specification with the core han-planning:plan-a-feature skill, lets the user review the\nresult, and then publishes it to a Confluence location that the user must specify. It is a thin orchestrator: the\nplanning work belongs to han-planning:plan-a-feature, and the publishing work belongs to\nhan-atlassian:markdown-to-confluence. This skill only validates its inputs, runs the planning skill to a temporary\nfolder, gets the user's review and publish choice, and hands each file to the publisher.
han-planning:plan-a-feature produces a small set of files — the primary feature-specification.md plus companion\nartifacts under artifacts/ (the decision log, the team findings, and a lazily-created technical-notes file). This\nskill publishes the spec as a parent page and each companion artifact as a child page beneath it, so the whole\nplan lands in Confluence as one small page tree. The files cross-reference each other with relative links that do not\nresolve once each file is its own Confluence page. Because this skill decides every page's title up front, it rewrites\nthose cross-file links into Confluence title-based page-link macros (the\n<ac:link><ri:page ri:content-title=\"...\"/>…</ac:link> form; Step 5 gives the exact macro to emit, link body and all)\nbefore creating any page — these resolve by title at view time, so no page URL or ID has to exist first. That collapses\npublishing to a single create pass: there is no separate relink-and-update pass, and each page is created exactly\nonce.
The six steps below are the whole skill. It does not resolve Confluence pages or call the Confluence MCP create/update\ntools itself; han-atlassian:markdown-to-confluence owns all of that.
Confirm the skill has everything it needs before spending effort producing a plan:
\nmcp__claude_ai_Atlassian__getAccessibleAtlassianResources to\nconfirm the server is connected and retrieve the cloud ID(s). If the tool is not available, the call errors, or it\nreturns no accessible resources (typically an authentication or configuration problem), stop immediately. Tell\nthe user this skill requires the Atlassian MCP server to be installed, configured, and authenticated, and that they\ncan re-run it once it is connected. Do not fall back to a local-only run; for local-only planning, point them at\nhan-planning:plan-a-feature. This preflight runs first so a missing server fails before any planning work begins.size argument and any relevant conversation context — is forwarded to\nhan-planning:plan-a-feature verbatim in Step 2. If the request is too thin to start, let\nhan-planning:plan-a-feature run its own interview; do not pre-empt it here.AskUserQuestion, explaining plainly that the skill needs an exact destination\nbecause it does not search Confluence. Do not resolve the page tree here — only confirm a location was given. Carry\nit through to Step 5; han-atlassian:markdown-to-confluence resolves it.Invoke the han-planning:plan-a-feature skill with the Skill tool, forwarding all provided context verbatim:\nthe size argument (if the user passed small, medium, or large), the feature description, any known constraints\nor entry points, and the relevant conversation context. Do not summarize, trim, or reinterpret the user's context; pass\nit through so han-planning:plan-a-feature runs exactly as it would on its own — interview, review team, finding\nresolution, and plan-synthesizer synthesis included — except add one explicit instruction: it must write its output\nfolder under /tmp/ (for example /tmp/<feature-slug>/) rather than into the repo's docs directory, and it should not\nprompt the user to choose or confirm an output location, because this skill owns that decision. This keeps the working\nplan out of the repo until the user decides to publish it, and because the path is explicit input it outranks any\noutput-directory the project or personal .han/config.md supplies (see\n../../references/config-rule.md).
Let han-planning:plan-a-feature complete its full process. Capture the exact /tmp/ paths of every file it wrote:
/tmp/<feature-slug>/feature-specification.md — the primary spec (always written)./tmp/<feature-slug>/artifacts/decision-log.md — the decision history (always written)./tmp/<feature-slug>/artifacts/team-findings.md — the review-team findings (always written)./tmp/<feature-slug>/artifacts/feature-technical-notes.md — load-bearing mechanics. Lazily created — only present\nif at least one technical note qualified. Confirm whether it exists before relying on it.Proceed to Step 3 once it finishes.
\nTell the user the exact /tmp/ paths of every generated file — the spec and each companion artifact that was actually\nwritten (the technical-notes file only if it exists) — so they can open and review them before deciding whether to\npublish. State plainly that nothing has been published anywhere yet.
Publishing to Confluence puts the content where other people can see it, so require an explicit choice before posting.\nAsk with AskUserQuestion, restating the /tmp/ file paths and the Confluence destination the user provided,\nand making clear that publishing creates one parent page (the spec) plus one child page per companion artifact, and\nthat the cross-page links between them resolve by page title — so the published pages should not be renamed in\nConfluence afterward, or the inbound cross-links break. Offer three options, listing the draft option first as the\nrecommended default:
If the user keeps it local only, stop. Report the /tmp/ folder path and state clearly that nothing was published\nto Confluence. Otherwise, record the chosen publish mode (draft or live) for Step 5. The chosen mode applies to every\npage in the tree.
Publishing is a single create pass: rewrite the cross-file links into title-based page-link macros first, then\ncreate each page once with its final body. No second update pass is needed, because the macros resolve by title and do\nnot depend on any page URL or ID.
\nDecide every page's final title up front. The title is used in two places — as the page's create-title, and as the\nri:content-title in every macro that links to that page — so pick each title once and reuse it in both, so they can\nnever drift apart:
<Feature Name> — Decision Log.<Feature Name> — Team Findings.<Feature Name> — Technical Notes.These titles must be distinct within the target space for the macros to resolve unambiguously. A ri:content-title\nmacro resolves against the whole space, not just this tree, so a title that collides with a page that already exists\nin the destination space is a real hazard: the link can resolve to the wrong page, and the create call may fail or be\nrejected for a duplicate title. The feature-name prefix keeps the four titles distinct from each other; pick a spec\ntitle specific enough that it is unlikely to already exist in the space, and if you have any signal that one does (for\nexample the user pointed at a page that already carries the feature name), choose a more specific title before\npublishing.
Rewrite cross-file links to title macros, leaving the /tmp/ originals intact. Write the rewritten copies to a\ndedicated subfolder (for example /tmp/<feature-slug>/.confluence-publish/) so the originals the user reviewed in\nStep 3 keep their working local markdown links. For each file, read it once and rewrite only the cross-file\nlinks:
Resolve each relative markdown link target against the directory of the file being rewritten. If it resolves to\nanother file in the published set, replace the whole markdown link [text](target#fragment) with a Confluence\ntitle-based page-link macro pointing at that file's pre-decided title:
<ac:link><ri:page ri:content-title=\"TARGET PAGE TITLE\"/><ac:plain-text-link-body><![CDATA[text]]></ac:plain-text-link-body></ac:link>\nOmit ri:space-key — the whole tree lands in one space, so a same-space title reference resolves without it. Keep\nthe original link text inside the link body. If that text contains the sequence ]]>, it would close the CDATA\nsection early and produce malformed storage XML, so split it across two CDATA sections (]] in the first, > in\nthe next) or drop the CDATA wrapper and XML-escape the text instead. Plain markdown emphasis in the link text\n(**bold**) is not rendered inside a plain-text link body; it posts as literal characters.
Drop the #fragment (the #d4-..., #t3-..., or section anchor). Confluence Cloud generates its own heading\nanchors with a scheme that does not match these slugs, so the link lands the reader at the top of the correct\npage, not the exact heading. (The macro form leaves the door open to add an explicit ri:anchor later if a\nspace's heading-anchor scheme is pinned down; do not emit anchors now.)
Leave every other link, and all other content, exactly as written. Do not touch links that point outside the\npublished set (external URLs, code references).
\nPublish the tree in one create pass. Use the Skill tool for every call, and apply the publish mode the user\nchose in Step 4 to all of them — state it explicitly so han-atlassian:markdown-to-confluence does not re-ask.
han-atlassian:markdown-to-confluence, forwarding the rewritten spec copy's path, the Confluence destination\nthe user provided in Step 1 (passed through verbatim), the publish mode from Step 4, and the spec title\ndecided above. Capture the resulting spec page's URL and page ID — the parent for the artifact pages, and\nneeded for the final report.decision-log.md, team-findings.md, and feature-technical-notes.md only if it was created),\ninvoke han-atlassian:markdown-to-confluence again, forwarding the rewritten artifact copy's path, the spec\npage's URL as the destination with the intent to create a new child page under it (state this explicitly so\nthe publisher does not ask whether to update the spec page), the same publish mode, and the artifact's\npre-decided title. Publish the artifacts one at a time so each create resolves against the same parent.han-atlassian:markdown-to-confluence owns location resolution, the create call, and Mermaid handling for each file.\nBecause every body already carries its final title-macro links, each page is created exactly once — there is no\nupdate pass.
Mermaid still posts as source. As han-atlassian:markdown-to-confluence reports, Mermaid diagrams publish as fenced\ncode blocks, not rendered diagrams, unless the space has a Mermaid macro. This is not something to silently fix.
Relay the result to the user: the spec parent page's URL, every artifact child page's URL, whether the tree went live or\nwas saved as drafts, and the caveats: cross-page links resolve by page title and land at the top of the target\npage (heading-level anchors are not preserved); because they resolve by title, renaming a published page in\nConfluence may break inbound cross-page links; and the Mermaid note. If any create fails partway through the tree,\nreport which file failed and its error, and note which pages were already created. Warn the user that those\nalready-created pages carry title-macro links pointing at the pages that did not get created, so those links dangle\nuntil the missing pages exist under their intended titles — and that simply re-running the whole skill would re-create\nthe pages that already succeeded, producing duplicate-title pages that break title resolution for the tree. Recommend\nthey create the missing page(s) by hand under the intended titles, or delete the partial tree and re-publish from clean.\nConfirm the /tmp/ originals are unchanged and intact either way.
han-planning:plan-a-feature ran with the full forwarded context and wrote its files\nunder a /tmp/ folder whose paths were captured, including whether the lazily-created technical-notes file exists./tmp/ paths were shown to the user before any publish..confluence-publish/ (fragments dropped, /tmp/\noriginals untouched), the spec was posted as the parent page and each existing companion artifact as a child page in\nthe chosen mode, and each page was created exactly once with its URL captured./tmp/ files exist.