issue_get read

Read one issue before you change it: its type and whether that type is a document, its labels, its 10 newest comments and events with the true totals and truncation flags, and its links both ways. links_out are this issue's own links to other issues and links_in are everyone else's to it, every one of them. A link is stale when the linked issue's description changed, or another issue superseded it, after the link was confirmed. issue_get never returns confirm, so writing what you read back re-confirms nothing: re-read the linked issue, then set confirm with issue_update. In the embedded events, a description or comment-body change carries from_length and to_length instead of its text, and a link change from_count and to_count; the reply's events_read_more names the issue_history call that has the text itself. proposals are the document's pending proposals, each with its author, note and whole body; the owner decides them with proposal_decide. attachments are the issue's and its comments' files, each with the roadmap://attachment/{id} uri that returns its bytes.

Arguments

Input schema

Exactly what tools/list serves.

{
  "additionalproperties": false,
  "properties": {
    "issue": {
      "description": "an issue key like ENG-142, or a ULID",
      "type": "string"
    }
  },
  "required": [
    "issue"
  ],
  "type": "object"
}