ticket-research

Ticket Research

A ticket records what to do; the reasons — the decisions, the meeting where it came up, who wanted it and why — usually live outside it. This skill assembles both halves into one cited brief: what Jira says, what organizational memory adds, and what remains genuinely unknown. The brief makes a ticket's context reliable; it does not replace the developer's judgment — every claim carries its source, and thin evidence is labeled thin rather than smoothed over.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking when a summary names more than it states, and memory-capture owns any durable write. Those ship with the gutt-pro plugin (this plugin depends on it); without them, follow the rules below and note the gap in one line. Jira access comes from whatever Atlassian tooling the session surfaces — an issue fetch, a JQL search, a comment tool. Find them in your tool list; names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. Jira is read-only here — with one gated exception. Never edit a ticket's fields, status, description, or acceptance criteria. The only write this skill may produce is one comment, drafted in your reply and posted only after the user approves the exact text in this session. Treat the posted comment as final: approval is the gate, not an undo. If a correction is truly needed and the comment tool can target an existing comment, use that with freshly approved text rather than posting a second comment. Write the body as markdown and set the tool's content-format parameter to markdown when it exposes one.
2. Every finding cited. Every positive finding names its source: a ticket field, a comment (author, date), a memory node, fact, or episode (id, date), or a linked ticket key. A claim you cannot cite does not go in the brief. Gaps are the exception by nature: a gap names what is absent and where an answer might come from, not a source.
3. Evidence, not verdicts. Report what was found and what it implies as a question, not a conclusion — "X was decided on (id) — does it still hold here?" beats "do X". The developer keeps the judgment.
4. Org scope is enforced at the output, not the request. Pass explicit group_ids naming the org group on reads — take the name from results already in the session or ask; never guess one, a guessed group id is a fabricated identifier. And treat scope as server-decided: the parameter states intent, it does not reliably filter. The check that holds happens at condense time — before any item enters the offered Jira comment, confirm that item's own scope is the org group; personal-scope findings stay in the in-session brief, marked as personal.
5. Bare tool names. Call memory and Jira tools by whatever names your tool list surfaces; the mcp__…__ prefix varies per install. Probe with ToolSearch before concluding a tool is missing.
6. No memory writes. If research surfaces something durable — a gap pattern, a decision nobody recorded — hand it to memory-capture (its trust-tier gate applies). This skill only reads.