Help us improve
Share bugs, ideas, or general feedback.
From issuekit
Investigates Bugs and Incidents on Azure DevOps or Jira by searching chats (Slack/Teams), docs (Confluence), Datadog, and the codebase, then produces an evidence-tagged investigation report.
npx claudepluginhub incubyte/ai-pluginsHow this skill is triggered — by the user, by Claude, or both
Slash command
/issuekit:issue-investigatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a structured report that orients an engineer for a tracker Bug or Incident. The report names what is broken, ranks 2-3 hypotheses, lists concrete next-step queries, and tags every claim with its evidence level.
Investigates a non-bug issue (Story, Feature, Task, Spike) on Azure DevOps or Jira by reading tracker data, searching Slack/Teams chat and Confluence/Wiki docs for prior decisions, and producing an evidence-tagged orientation report.
Triages bug reports and error messages by searching Jira for duplicates, checking fix history, and creating structured issues or adding comments.
Analyzes GitHub issues to identify possible root causes by examining issue content, code repository, and related resources. Provides investigation directions with probability estimates.
Share bugs, ideas, or general feedback.
Produce a structured report that orients an engineer for a tracker Bug or Incident. The report names what is broken, ranks 2-3 hypotheses, lists concrete next-step queries, and tags every claim with its evidence level.
Scope: Bug and Incident archetypes only. For Feature, User Story, Task, or Spike, the calling agent uses requirements-investigator instead.
This skill investigates. It does not solve, post, or modify anything.
This skill runs without user interaction. The constraints below let it work cleanly inside the issue-triage and incident-postmortem agents (which own their own confirmation gates) and standalone.
[VERIFIED], [OBSERVED], [INFERRED], [UNKNOWN].addComment, transition, updateFields, etc.). Posting is the caller's job.All tracker calls go through the issuekit:tracker-adapter skill. Use the abstract verbs:
getIssue(id) — issue payload, body in markdowngetIssueComments(id) — comment threadsearchIssues({ keywords, scope, types, states, dateWindow }) — related issueslinkedPullRequests(id) — PRs that reference this issueDo not name vendor-specific MCP tools (wit_get_work_item, getJiraIssue, etc.) in the skill body. The adapter resolves them.
Investigation runs four levels top to bottom. Each level has a gate: if it produces enough evidence to write a useful report, skip the remaining levels.
Before running the levels, fetch the issue once and cache it for the rest of the skill.
12345, PROJ-1234, or extracted from a pasted URL). If the calling agent has already fetched the issue and exposed the payload, reuse that payload; do not re-fetch.getIssue(id). The returned Issue shape is normalized regardless of tracker.title, body, created, relations (the Issue.parent, Issue.customFields.linkedIssues or similar), reporter, etc.If getIssue fails, stop and tell the caller which call failed. Do not proceed without issue data.
Skip this level entirely if chat == none. The detection result is set by the adapter at session start.
Run 2-3 queries via the chat backend's searchMessages (Slack: slack_search_public_and_private; Teams: teams_search_messages):
12345, AB#12345, PROJ-1234).For each relevant hit, follow the thread in full via readThread (Slack: slack_read_thread; Teams: teams_read_thread).
What you are looking for:
Gate: if a thread contains a confirmed root cause or workaround, write the report citing that thread and skip Levels 2-4.
Read the issue payload (cached in Setup) carefully. Signals are easy to miss on a fast scan: error messages, timestamps, customer names, browser/device, the question the reporter is actually asking.
Then search:
searchIssues. Common queries:
{ keywords: "<error string>", states: ["!Closed"], dateWindow: { from: <issue.created - 30d> } }{ keywords: "<feature area>", states: ["!Closed"] }{ scope: "<component or area>", types: ["Bug", "Incident"] }customFields.linkedIssues (or the equivalent relations array for AzDO, issuelinks for Jira — both surfaced via the adapter). Read the linked issue's title, state, and the most relevant scope statement.searchConfluenceUsingCql; Azure Wiki: wiki_search or search_wiki). Look for runbooks, architecture pages, known-issues pages, onboarding docs. Use the feature area, system name, or entity type as the search term. Skip if doc == none.For each related issue, record: ID, title, state, assignee, the most relevant finding from description or comments. For each doc page, record: URL and a 1-line summary.
Gate: if a runbook describes the exact scenario or a prior issue has the resolution, write the report pointing at that source. Skip Levels 3-4.
Skip this level entirely if log == none.
Build queries from signals collected in Levels 1-2: error strings, service names, entity IDs, HTTP status codes.
Call search_datadog_logs with:
query: e.g., service:my-service status:error @http.status_code:500 @user_id:abc123from: 7 days before the issue's created date, or the timeframe mentioned in the issueto: issue created date or nowlimit: 10-25Build a Logs URL the engineer can click:
https://app.datadoghq.com/logs?query=<url-encoded-query>&from_ts=<epoch_ms>&to_ts=<epoch_ms>
Suppression rule: if Datadog returns any error (auth, 403/404, timeout, rate limit, empty results, or any non-success), treat Datadog as unavailable for this issue. Do not mention Datadog anywhere in the report. This rule overrides every other instruction that references Datadog data.
Gate: if Datadog returned usable results that identify a service, an error pattern, or a timeline gap, write the report incorporating those findings. Skip Level 4 unless an external source points specifically to a code-level cause.
Enter only when Levels 1-3 turned up nothing useful, OR external sources point to a code-level cause that needs tracing.
Bash (e.g., grep -r 'pattern' path/) or Grep to find error messages in the codebase. Identify which service owns the error.Read to open source files near the relevant code; find logging and monitoring calls. For each call found, note the log message string and any structured tags so the "Where To Look" section can name them.git log --since="2 weeks ago" -- <path> via Bash to find commits that correlate with the reported timeline.Stop when you can name: which service is involved, what signals are observable, and 2-3 concrete observability queries. Do not trace full call chains unless the chain itself is the finding.
Every claim in the report carries one of four tags.
| Tag | Meaning |
|---|---|
[VERIFIED] | Directly confirmed. Read in code, or a source explicitly states this. |
[OBSERVED] | A pattern matches the reported behavior, but reaching the conclusion required a logical step. |
[INFERRED] | Logical deduction from available information. Not directly observed. |
[UNKNOWN] | Cannot determine from available sources. Requires runtime data. |
If the finished report has more [INFERRED] than [VERIFIED] findings, the search was insufficient. Go back and search more before writing.
Every [UNKNOWN] becomes a "Where To Look" item: name the runtime check that would resolve it.
Investigation is done when all three are true:
If any one is missing, keep investigating.
Every report has all six sections. If a section has nothing meaningful to say, write a 1-line note ("Not applicable for this issue") rather than skip the section.
1-2 sentences. Name what is broken and your single best hypothesis. Inline evidence tag. Do not restate the issue title.
Example:
Sessions for tenant
MapleTowerstarted failing at the join step yesterday after deploy2026-04-29T18:00Z; the new SSO middleware is the most likely cause[OBSERVED].
Who is affected (one user, a segment, or all). Whether investigation is complete or needs runtime verification. Stale-issue flag if the issue has been quiet for more than 2 weeks while the bug may already be fixed.
2-4 sentences. Define vendor names, internal acronyms, or product terminology a new team member would not know. Skip with "Not applicable" if the affected area is obvious from the title.
2-4 sentences. Plain language. Include the exact error message and when the issue started if known.
Narrative prose with evidence tags inline. Cover:
No tables in this section. No code snippets unless the snippet itself is the finding (then keep it short).
2-5 tool-by-tool items. Each item:
Example:
- Code search:
grep -r 'SSO_TOKEN_EXPIRED' services/auth/to find the error string in source. A hit identifies the service that owns the failure mode; a miss means the error originates outside the auth service.
These rules adjust section order or content emphasis. All six sections still appear every run.
path/to/file.ext:line. No long code snippets unless the snippet is the finding.Where To Look item naming the specific information the reporter could provide, phrased as a concrete question for the owning team to use if they choose to contact the reporter. The skill itself never contacts the reporter.These apply to all text in the report.
For deeper guidance, the calling agent may invoke issuekit:prose-style on the finished report.