Help us improve
Share bugs, ideas, or general feedback.
From issue-triage
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.
npx claudepluginhub incubyte/ai-pluginsHow this skill is triggered — by the user, by Claude, or both
Slash command
/issue-triage:requirements-investigatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produce a structured report that orients a developer about to pick up a Story, Feature, Task, or Spike. The report names what is being built (or asked), surfaces prior decisions found in chat and docs, lists the open questions that block start-of-work, and tags every claim with its evidence level.
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.
Fetches JIRA issues by key or search, distills into structured tasks, analyzes codebase for gaps and risks, optionally enriches JIRA or spawns subtasks. Use before coding workflows.
Browses Arness-labeled issues from GitHub, Jira, or local feature backlog, selects unblocked one via dependency resolution, and routes to implementation pipeline.
Share bugs, ideas, or general feedback.
Produce a structured report that orients a developer about to pick up a Story, Feature, Task, or Spike. The report names what is being built (or asked), surfaces prior decisions found in chat and docs, lists the open questions that block start-of-work, and tags every claim with its evidence level.
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 agent (which has its own confirmation gate) and standalone.
Calling context: archetype=Story.); when running standalone, infer from the issue type field.[VERIFIED], [OBSERVED], [INFERRED], [UNKNOWN].All tracker calls go through the issuekit:tracker-adapter skill. Use the abstract verbs:
getIssue(id) — issue payloadgetIssueComments(id) — commentssearchIssues({ keywords, scope, types, states, dateWindow }) — related issuesChat/doc/log backends are detected at session start by the adapter. This skill uses chat (searchMessages, readThread) and docs (searchPages for Confluence or Azure Wiki) opportunistically.
Investigation runs three levels top to bottom. Each level has a gate: if it produces enough evidence to write a useful report, skip the remaining levels. Datadog is not in the ladder by default; non-bug issues rarely have runtime telemetry to query.
Before running the levels, fetch the issue data once and cache it for the rest of the skill.
issue-triage agent in Phase 1) has already fetched the issue and exposed the payload, reuse it; don't re-fetch.getIssue(id) via the adapter. Include comments and history.Calling context: archetype=<value>.. If running standalone, map issue.type and labels per the agent's taxonomy (Story / Feature / Task / Spike). If the type is Bug or Incident, stop and tell the caller to route to issuekit:issue-investigator instead.If getIssue fails, stop and tell the caller which call failed. Do not proceed without issue data.
Skip entirely if chat == none.
Run 2-3 queries via the chat backend's searchMessages:
PROJ-1234, AB#12345).For each relevant hit, follow the thread in full via readThread.
What you are looking for:
Gate: if a chat thread contains a confirmed scope statement, an approved design link, or a clear "out of scope" decision, write the report citing that thread and skip Levels 2-3.
Read the issue payload (cached in Setup) carefully. Signals are easy to miss on a fast scan: linked design docs, mentions of related issues, vocabulary like "blocks" or "depends on" that points at sequencing constraints, the question the reporter is actually asking.
Then search:
customFields.linkedIssues and the parent field. Read the related issue descriptions and the most recent 1-2 comments. Note: state, assignee, the most relevant scope statement.searchIssues. Common queries:
{ keywords: "<feature name>", types: ["Story", "Feature", "Task", "Spike"] }{ scope: "<component>", types: ["Story", "Feature", "Task", "Spike"], dateWindow: { from: <issue.created - 90d> } }{ parent: "<epic id>" } when the issue has an epic parent.searchConfluenceUsingCql; Azure Wiki: wiki_search / search_wiki). Search for product briefs, design docs, ADRs, RFCs, runbooks for the area. Use the feature area, system name, or product theme as the search term. Skip if doc == none.For each related issue, record: id, title, state, assignee, the most relevant scope or AC finding. For each doc page, record: URL and a 1-line summary of what it contains.
Gate: if a product brief or design doc explicitly states the scope and acceptance criteria for this work, write the report citing that source. Skip Level 3 unless the issue also references existing code that needs orientation.
Enter only when Levels 1-2 turned up nothing useful, OR the issue explicitly references existing code that needs context to size or scope the work.
Bash (e.g., git ls-files | grep -i 'pattern') or Grep to locate it in the repository. Note the relative path.Grep to find the X pattern and Read the existing implementation. Record the path and a 1-line summary of the pattern.git log --since="2 months ago" -- <path> via Bash to find commits in the affected area. The recent change list informs the "Where To Look" section.Stop when you can name: which area of the code is involved, what existing patterns to follow, and 1-3 specific files or directories the developer should open first. Do not trace full call chains; this is orientation, not implementation.
Every claim in the report carries one of four tags.
| Tag | Meaning |
|---|---|
[VERIFIED] | Directly confirmed. Read in code or in an authoritative source (design doc, ADR, issue description) that explicitly states this. |
[OBSERVED] | A pattern matches the reported scope, but reaching the conclusion required a logical step. |
[INFERRED] | Logical deduction from available information. Not directly observed. |
[UNKNOWN] | Cannot determine from available sources. Requires asking a person or reading docs that were not found. |
If the finished report has more [INFERRED] than [VERIFIED] findings, the search was insufficient. Go back and search more before writing.
Every [UNKNOWN] becomes either an "Open Questions" item (when the unknown blocks start of work and a person can answer it) or a "Where To Look" item (when the unknown can be resolved by reading or searching).
Investigation is done when all three are true:
If any one is missing, keep investigating.
The template differs by archetype. Read references/report-template.md when you reach the report-writing step. Pick the matching template based on the archetype determined in Setup.
Section orders and definitions live in references/report-template.md. The three templates share five concepts: a one-line Lead, a context section (Background or Why Now or Question to Answer), a scope-or-knowledge section, an unknowns section, and a Where To Look section.
These rules adjust section emphasis without changing the section list.
path/to/file.ext (no line numbers; this is orientation, not pinpointing). When the existing pattern is the finding, name the file in the context section.These apply to all text in the report.