本文へ移動
cccskills
無料GitHub で公開

investigate-to-confluence

Runs an evidence-based investigation of a bug, failure, or unexpected behavior with investigate and publishes the resulting investigation report to a user-specified Confluence location. Use when the user wants something debugged, diagnosed, or root-caused AND the findings posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not investigate to a local file only — use investigate. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

インストール方法を見る

含まれるファイル(1)

  • SKILL.md9.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

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, which governs precedence between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

Investigate to Confluence

This skill runs an evidence-based investigation with the core han-coding:investigate skill, lets the user review the resulting report, and then publishes it to a Confluence location that the user must specify. It is a thin orchestrator: the investigation work belongs to han-coding:investigate, and the publishing work belongs to han-atlassian:markdown-to-confluence. This skill only validates its inputs, runs the investigation to a temporary file, gets the user's review and publish choice, and hands the file to the publisher.

han-coding:investigate produces a single report file (the investigation plan: problem statement, evidence summary, root cause analysis, planned fix, validation results, and summary). It does not produce companion artifacts, so this skill publishes that one file as a single Confluence page — the single-page sibling of han-atlassian:project-documentation-to-confluence, not the parent-plus-children tree of han-atlassian:plan-a-feature-to-confluence.

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 on an investigation:

  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 a local-only investigation, point them at han-coding:investigate. This preflight runs first so a missing server fails before any investigation work begins.
  2. A symptom or question to investigate. Confirm the request names a bug, failure, error, integration, or unexpected behavior to investigate. This — together with any relevant conversation context — is forwarded to han-coding:investigate verbatim in Step 2. If the request is too thin to start, let han-coding:investigate run its own investigation rather than pre-empting it here.
  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 Investigation Report to a Temporary File

Invoke the han-coding:investigate skill with the Skill tool, forwarding all provided context verbatim: the symptom or question, any known reproduction steps or error messages, any suspected entry points, and the relevant conversation context. Do not summarize, trim, or reinterpret the user's context; pass it through so han-coding:investigate runs exactly as it would on its own (parallel investigators, conditional specialist analysts, adversarial validation, and the final report) — except add two explicit instructions:

  • It must write the resulting investigation report to a file under /tmp/ (for example /tmp/<symptom-slug>.md) rather than into the project's docs or plans directory. This keeps the working report 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).
  • It must stop after producing the report. han-coding:investigate normally ends by presenting the plan for approval and can trigger the fix's implementation on approval; this skill wants the report only, so instruct it not to implement the fix or change any code — this skill publishes findings, it does not ship them.

Let han-coding:investigate complete its full investigation process. 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 investigation report so they can open and review it before deciding whether to publish. State plainly that the content has not been published anywhere yet, and that no code was changed.

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 Confluence destination the user provided. Offer three options, listing the draft option first as the recommended default:

  • "Yes, save it as a draft to edit later (recommended)" — published as an unpublished Confluence draft for the user to review, edit, and publish themselves. This is the default. (Publish mode: draft.)
  • "Yes, publish it live now" — the page goes live immediately. (Publish mode: live.)
  • "No, keep it local only" — nothing is published.

If the user keeps it local only, stop. Report the /tmp/ report path and state clearly that nothing was published to Confluence. Otherwise, record the chosen publish mode (draft or live) for Step 5.

Step 5: Publish with markdown-to-confluence

Invoke the han-atlassian:markdown-to-confluence skill with the Skill tool, forwarding:

  • the /tmp/ markdown file path captured in Step 2,
  • the Confluence destination the user provided in Step 1 (the page URL, or the space plus optional parent page), passed through verbatim, and
  • the publish mode the user chose in Step 4 (draft or live), stated explicitly so han-atlassian:markdown-to-confluence does not re-ask.

han-atlassian:markdown-to-confluence resolves the location, reads the file, creates or updates the page in the chosen mode, handles Mermaid diagrams, and reports the resulting page URL. Relay its result to the user: the created or updated page's URL and whether it went live or was saved as a draft. If publishing fails, report the error and confirm the /tmp/ markdown file is unchanged and intact.

Verification

  1. Inputs validated: the Atlassian server was reachable, a symptom or question to investigate was present, and a Confluence location was provided — or the skill stopped before doing any work.
  2. Report produced to /tmp: han-coding:investigate ran with the full forwarded context, wrote the investigation report to a /tmp/ file whose path was captured, and did not implement the fix or change any code.
  3. User reviewed: the /tmp/ path was shown to the user before any publish.
  4. Explicit choice obtained: the user chose draft, live, or local-only.
  5. Publish delegated and reported: when the user chose to publish, han-atlassian:markdown-to-confluence created or updated the page in the chosen mode and its URL was relayed; when the user declined, only the /tmp/ report exists.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Builds a new Claude Code agent (subagent) from scratch through a relentless, evidence-based interview that walks the agent's design tree decision-by-decision — entity fit, domain focus and vocabulary, role identity, anti-patterns, description, model tier, tools, and self-containment — then reviews the finished agent against the plugin-building guidance and applies every fix it finds. Use when creating, authoring, scaffolding, designing, or drafting a new agent or subagent. Does not build a skill or slash command — use skill-builder. Does not serve, vendor, or refresh the authoring guidance itself — use guidance.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Performs deep architectural analysis of a specified module, directory, or feature area by examining structural coupling, data flow, concurrency patterns, risk, and SOLID alignment. Use when the user wants to assess, evaluate, or review the architecture, design quality, dependency structure, coupling, cohesion, or technical debt of an existing part of the codebase. Not for investigating specific bugs, runtime errors, or failures — use investigate. Not for test planning — use automated-test-planning. Not for file-level code review — use code-review. Not for researching open-ended options, prior art, or how something works — use research. Not for designing a new interface or contract — use design-an-api. Not for planning the change its findings imply — use plan-a-change. Not for discovering bounded contexts, ubiquitous language, or where code boundaries diverge from domain boundaries — use ddd-analysis. Not for writing documentation or architectural decision records.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Create, extract, or convert an ADR (architectural decision record) using the ADR template. Use when creating new ADRs, extracting an ADR from existing documentation, converting a document into an ADR, recording an architecture or design decision, or updating the status of an existing ADR. Does not create or update enforceable coding standards or conventions — use coding-standard for that. Does not write feature or system documentation — use project-documentation instead.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produce a standalone test plan by analyzing code for test coverage gaps and edge cases. Use when you need to create, generate, or draft a test plan for a branch, need to analyze test coverage, or need to identify what tests to write for specific files or directories. Does not produce a plain-language plan for a person to run tests by hand — use manual-test-planning for that. Does not write test code — use tdd to implement behavior test-first. Does not refine existing plans — use iterative-plan-review. Does not review code quality, security, or style — use code-review for full code review. Does not evaluate architectural testability or structural coupling — use architectural-analysis for architectural assessment.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a human-readable, progressive-disclosure overview of unfamiliar code or a pull request's changes — why it exists (the real problem it solves or goal it serves for the business or a user), and from there what it does, how it flows, and where to start — so you can get up to speed before working on or reviewing it. Use when you want to understand, get oriented in, make sense of, explain, or get up to speed on a chunk of code, a file, a directory, a symbol, or a PR's changes. Writes the overview to a scratch file and changes no code. Does not review code quality or raise findings — use code-review for auditing changes or post-code-review-to-pr for posting them. Does not produce durable feature or system documentation — use project-documentation. Does not assess architecture or structural risk — use architectural-analysis. Does not diagnose bugs or root-cause failures — use investigate. Does not pace a person through the code one step at a time in conversation — use code-walkthrough.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

Produces a progressive-disclosure overview of unfamiliar code or a pull request's changes with code-overview and publishes the resulting overview to a user-specified Confluence location. Use when the user wants code or a PR explained, oriented, or made sense of AND the overview posted to a Confluence space or page. Requires a configured Atlassian MCP server. Does not produce the overview to a local file only — use code-overview. Does not publish an arbitrary existing markdown file — use markdown-to-confluence. Does not document an already-understood feature to Confluence — use project-documentation-to-confluence. Does not root-cause a bug to Confluence — use investigate-to-confluence. Does not plan or specify a new feature to Confluence — use plan-a-feature-to-confluence. Does not publish to Jira — use work-items-to-jira.

日本語の概要は準備中です。原文の説明を表示しています。

testdouble/han2812026年10月1日 更新

testdouble のスキルをすべて見る

このスキルの問題を報告する