$npx -y skills add testdouble/han --skill project-documentation-to-confluenceCreates 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 lo
| 1 | # Project Documentation to Confluence |
| 2 | |
| 3 | This skill produces project documentation with the core `han-core:project-documentation` |
| 4 | skill, lets the user review the result, and then publishes it to a Confluence |
| 5 | location that **the user must specify**. It is a thin orchestrator: the |
| 6 | documentation work belongs to `han-core:project-documentation`, and the publishing work |
| 7 | belongs to `han-atlassian:markdown-to-confluence`. This skill only validates its inputs, |
| 8 | runs the documentation to a temporary file, gets the user's review and publish |
| 9 | choice, and hands the file to the publisher. |
| 10 | |
| 11 | The five steps below are the whole skill. It does not resolve Confluence pages or |
| 12 | call the Confluence MCP create/update tools itself; `han-atlassian:markdown-to-confluence` |
| 13 | owns all of that. |
| 14 | |
| 15 | ## Step 1: Validate Inputs |
| 16 | |
| 17 | Confirm the skill has everything it needs before spending effort producing |
| 18 | documentation: |
| 19 | |
| 20 | 1. **Atlassian MCP reachable (hard requirement).** Call |
| 21 | `mcp__claude_ai_Atlassian__getAccessibleAtlassianResources` to confirm the |
| 22 | server is connected and retrieve the cloud ID(s). If the tool is not |
| 23 | available, the call errors, or it returns no accessible resources (typically |
| 24 | an authentication or configuration problem), **stop immediately**. Tell the |
| 25 | user this skill requires the Atlassian MCP server to be installed, configured, |
| 26 | and authenticated, and that they can re-run it once it is connected. Do not |
| 27 | fall back to a local-only run; for local-only documentation, point them at |
| 28 | `han-core:project-documentation`. This preflight runs first so a missing server fails |
| 29 | before any documentation is generated. |
| 30 | 2. **A documentation subject.** Confirm the request names a feature, system, |
| 31 | component, or existing doc to document. This is forwarded to |
| 32 | `han-core:project-documentation` verbatim in Step 2. |
| 33 | 3. **A Confluence destination.** Confirm the request provides a target location: |
| 34 | a **Confluence page URL** (to update that page, or create a child under it), |
| 35 | or a **space** (key or name) plus an optional **parent page**. If none was |
| 36 | provided, ask for one with `AskUserQuestion`, explaining plainly that the |
| 37 | skill needs an exact destination because it does not search Confluence. Do not |
| 38 | resolve the page tree here — only confirm a location was given. Carry it |
| 39 | through to Step 5; `han-atlassian:markdown-to-confluence` resolves it. |
| 40 | |
| 41 | ## Step 2: Produce the Documentation to a Temporary File |
| 42 | |
| 43 | Invoke the `han-core:project-documentation` skill with the **Skill** tool, **forwarding |
| 44 | all provided context** verbatim: the feature name or document path argument, the |
| 45 | scope, any known entry points, and the relevant conversation context. Do not |
| 46 | summarize, trim, or reinterpret the user's context; pass it through so |
| 47 | `han-core:project-documentation` runs exactly as it would on its own — **except** add one |
| 48 | explicit instruction: it must write the resulting documentation to a file under |
| 49 | `/tmp/` (for example `/tmp/<feature-slug>.md`) rather than into the project's |
| 50 | docs directory. This keeps the working draft out of the repo until the user |
| 51 | decides to publish it. |
| 52 | |
| 53 | Let `han-core:project-documentation` complete its full process (codebase exploration, |
| 54 | writing the doc, content audit, information-architecture review, and |
| 55 | verification). **Capture the exact `/tmp/` file path it wrote.** That markdown |
| 56 | file is the source content for Confluence. Proceed to Step 3 once it finishes. |
| 57 | |
| 58 | ## Step 3: Show the File for Review |
| 59 | |
| 60 | Tell the user the exact `/tmp/` path of the generated documentation so they can |
| 61 | open and review it before deciding whether to publish. State plainly that the |
| 62 | content has not been published anywhere yet. |
| 63 | |
| 64 | ## Step 4: Confirm the Publish Choice |
| 65 | |
| 66 | Publishing to Confluence puts the content where other people can see it, so |
| 67 | require an explicit choice before posting. Ask with `AskUserQuestion`, restating |
| 68 | the **`/tmp/` f |