/project-documentation-to-confluence

name: project-documentation-to-confluence
description: >
  Creates or updates project documentation for a feature, system, or component and publishes it to a user-specified
  Confluence location. Use when the user wants feature or system documentation written to Confluence, posted to a
  Confluence space or page, or synced to a Confluence location. Requires a configured Atlassian MCP server. Does not
  document to local files only — use project-documentation for that. Does not publish an arbitrary existing markdown
  file — use markdown-to-confluence for that. Does not plan or specify a new feature to Confluence — use
  plan-a-feature-to-confluence for that. Does not create architectural decision records — use
  architectural-decision-record. Does not create coding standards — use coding-standard. Does not produce runbooks — use
  runbook.
argument-hint: "[feature-name or doc-path] [confluence location: page URL or space + parent]"
allowed-tools:
  Read, Glob, Grep, Skill, Agent, Bash(date *), Bash(git config *), Bash(whoami), Bash(mkdir *), 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.

Project Documentation to Confluence

This skill produces project documentation with the `han-documentation:project-documentation` 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 documentation work belongs to `han-documentation:project-documentation`, and the publishing work belongs to `han-atlassian:markdown-to-confluence`. This skill only validates its inputs, runs the documentation to a temporary file, gets the user's review and publish choice, and hands the file to the publisher.

The five 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 documentation:

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 documentation, point them at `han-documentation:project-documentation`. This preflight runs first so a missing server fails before any documentation is generated. 2. **A documentation subject.** Confirm the request names a feature, system, component, or existing doc to document. This is forwarded to `han-documentation:project-documentation` verbatim in Step 2. 3. **A Confluence destination.** Confirm the request provides a target location: a **Confluence page URL** (to update that page, or create 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 Documentation to a Temporary File

Invoke the `han-documentation:project-documentation` skill with the **Skill** tool, **forwarding all provided context** verbatim: the feature name or document path argument, the scope, any known entry points, and the relevant conversation context. Do not summarize, trim, or reinterpret the user's context; pass it through so `han-documentation:project-documentation` runs exactly as it would on its own — **except** add one explicit instruction: it must write the resulting documentation to a file under `/tmp/` (for example `/tmp/<feature-slug>.md`) rather than into the project's docs directory. This keeps the working draft 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-documentation:project-documentation` complete its full process (codebase exploration, writing the doc, content audit, information-architecture review, and verification). **Capture the exact `/tmp/` file path it wrote.** That markdown file is the source content for Confluence. Proceed to Step 3 once it finishes.

Step 3: Show the File for Review

Tell the user the exact `/tmp/` path of the generated documentation so they can open and review it before deciding whether to publish. State plainly that the content has not been published anywhere yet.

Step 4: Confirm the Publish Choice

Publishing to Confluence puts the content where other people can see it, so require an explicit choice before posting. Ask with `AskUserQuestion`, restating the **`/tmp/` file path** and the **Conf