plan-a-feature-to-confluence

## 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.

# Plan a Feature to Confluence

This skill builds a feature specification with the core `han-planning:plan-a-feature` skill, lets the user review the
result, and then publishes it to a Confluence location that **the user must specify**. It is a thin orchestrator: the
planning work belongs to `han-planning:plan-a-feature`, and the publishing work belongs to
`han-atlassian:markdown-to-confluence`. This skill only validates its inputs, runs the planning skill to a temporary
folder, 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
artifacts under `artifacts/` (the decision log, the team findings, and a lazily-created technical-notes file). This
skill publishes the **spec as a parent page** and each companion artifact as a **child page** beneath it, so the whole
plan lands in Confluence as one small page tree. The files cross-reference each other with relative links that do not
resolve once each file is its own Confluence page. Because this skill decides every page's title up front, it rewrites
those cross-file links into Confluence **title-based page-link macros** (the
`<ac:link><ri:page ri:content-title="..."/>…</ac:link>` form; Step 5 gives the exact macro to emit, link body and all)
before creating any page — these resolve by title at view time, so no page URL or ID has to exist first. That collapses
publishing to a **single create pass**: there is no separate relink-and-update pass, and each page is created exactly
once.

The six steps below are the whole skill. It does not resolve Confluence pages or call the Confluence MCP create/update
tools itself; `han-atlassian:markdown-to-confluence` owns all of that.

## Step 1: Validate Inputs

Confirm the skill has everything it needs before spending effort producing a plan:

1. **Atlassian MCP reachable (hard requirement).** Call `mcp__claude_ai_Atlassian__getAccessibleAtlassianResources` to
   confirm the server is connected and retrieve the cloud ID(s). If the tool is not available, the call errors, or it
   returns no accessible resources (typically an authentication or configuration problem), **stop immediately**. Tell
   the user this skill requires the Atlassian MCP server to be installed, configured, and authenticated, and that they
   can re-run it once it is connected. Do not fall back to a local-only run; for local-only planning, point them at
   `han-planning:plan-a-feature`. This preflight runs first so a missing server fails before any planning work begins.
2. **A feature to plan.** Confirm the request names a feature, capability, or system behavior to specify. This —
   together with the `size` argument and any relevant conversation context — is forwarded to
   `han-planning:plan-a-feature` verbatim in Step 2. If the request is too thin to start, let
   `han-planning:plan-a-feature` run its own interview; do not pre-empt it here.
3. **A Confluence destination.** Confirm the request provides a target location: a **Confluence page URL** (to update
   that page, or create the spec as a child under it), or a **space** (key or name) plus an optional **parent page**. If
   none was provided, ask for one with `AskUserQuestion`, explaining plainly that the skill needs an exact destination
   because it does not search Confluence. Do not resolve the page tree here — only confirm a location was given. Carry
   it through to Step 5; `han-atlassian:markdown-to-confluence` resolves it.

## Step 2: Produce the Plan to a Temporary Folder

Invoke the `han-planning:plan-a-feature` skill with the **Skill** tool, **forwarding all provided context** verbatim:
the `size` argument (if the user passed `small`, `medium`, or `large`), the feature description, any known constraints
or entry points, and the relevant conversation context. Do not summarize, trim, or reinterpret the user's context; pass
it through so `han-planning:plan-a-feature` runs exactly as it would on its own — interview, review team, finding
resolution, and plan-synthesizer synthesis included — **except** add one explicit instruction: it must write its output
folder under `/tmp/` (for example `/tmp/<feature-slug>/`) rather than into the repo's docs directory, and it should not
prompt the user to choose or confirm an output location, because this skill owns that decision. This keeps the working
plan out of the repo until the user decides to publish it, and because the path is explicit input it outranks any
`output-directory` the project or personal `.han/config.md` supplies (see
[../../references/config-rule.md](../../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
  if at least one technical note qualified.** Confirm whether it exists before relying on it.

Proceed to Step 3 once it finishe