/plan-a-feature-to-confluence

name: plan-a-feature-to-confluence
description: >
  Builds a feature specification from scratch with plan-a-feature and publishes it to a user-specified Confluence
  location, posting the spec as a parent page and each companion artifact (decision log, team findings, technical notes)
  as a child page beneath it. Use when the user wants a new feature planned, designed, scoped, or specified AND posted
  to a Confluence space or page. Requires a configured Atlassian MCP server. Does not plan to local files only — use
  plan-a-feature. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not refine or
  stress-test an existing plan — use iterative-plan-review. Does not document already-built features to Confluence — use
  project-documentation-to-confluence.
arguments: size
argument-hint:
  "[size: small | medium | large] [feature description] [confluence location: page URL or space + parent] [--mode
  draft|live (default draft)]"
allowed-tools:
  Read, Write, Edit, Glob, Grep, Skill, Bash(find *), mcp__claude_ai_Atlassian__getAccessibleAtlassianResources,
  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.

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 i