KirinBoard

Call this before you claim or start an issue. One call returns, for the repository you are working in: every active claim (issue, phase, who, tool and model, branch, PR and checks, last active, live or stale); your own claims, if you pass session_id or branch; unclaimed issues in the ready phases (backlog, scoping, planning); who else is changing the paths you pass; and a one-line verdict per issue you name: free, held by someone (live), held by someone (stale, last active ...), or closed. It never fails: if the board cannot be checked it says why and you proceed uncoordinated. Pass repo as owner/name from your git remote.

The repositories (projects) this token can read, by owner/name.

Takes no parameters.

Pushes queued, running or finished in the last hour, with their outcome and checks; with a branch, that branch only (looking back 12 hours if it has nothing in the last hour). For pushes that finished more than an hour ago, use ci_history.

Whether anyone holds issue #N now (live or stale claim), and who last worked on it (the agent stamped on its pull request).

Agent sessions on a repository and the issues each holds: who, tool and model, state, last active. Live sessions only unless include_stale.

What was opened, worked on and closed in a window: counts by phase, blocked items, and the most recently closed. Give days (1 to 90, default 14) or from and to (YYYY-MM-DD).

Finds the last tickets that would finish an initiative, and which of them are free to pick up. An initiative is a parent ticket that groups the tickets of one larger piece of work. For a repository it lists the initiatives the dashboard classes as almost done (a few tickets left that belong to the original push; by default 3 or fewer open and at least 75% closed, a setting the team can change), smallest remainder first. Each comes with its remaining tickets (number, title, link, phase, whether someone is working on it, who has claimed it) and the dashboard's reason in plain words. Use it when your human asks what is close to finished, or when you are choosing what to work on: closing one of these tickets finishes something. unclaimed_only lists only tickets nobody is working on or has claimed. include_next_part also lists initiatives whose first part is done but whose remaining tickets were filed later and not started (better moved into a new initiative than counted as nearly done). Read-only, and it never fails: if the list cannot be read it says why. Before starting a ticket, check it with board and claim it as usual.

Shows how a repository's pull request gates have fared over the last 7 and 30 days. A gate is a check the dashboard grades every pull request by (for example agent identity, persona, or "closes an issue"). For each gate: how many pull requests passed it, failed it, would have failed it (the gate only warns for now), were not checked by it, are still pending or not read yet, and were exempt (promotions, bots, or an exempt label); and the dashboard's verdict on whether the gate is ready to enforce. The gates that refused the most pull requests come first. Call it before you open or push a pull request, to see which gates usually trip pull requests here and meet them first. Counts only, no logs. Gate compliance is switched on per repository; where it is off, the answer says so. Read-only, and it never fails: if the counts cannot be read it says why.

Answers "did the push I made a few hours ago pass?". Lists the pushes on a repository that finished between 1 and 12 hours ago (or 1 and 4 hours ago), newest first, each with its branch, pull request, title, who pushed it, outcome (passed, failed, awaiting, superseded), when it finished, how long it took, its commit and a link to the run, plus a count of each outcome. Narrow it by branch, pull request, commit (sha, 7 or more characters) or outcome. It does not cover the last hour: for pushes queued, running or finished in the last hour, use ci_status. Read-only, and it never fails: if CI cannot be read it says why.

Lists what is closest to finished in a repository, so you can pick work that completes something. Two lists, in the dashboard's Quick wins order: initiatives (an initiative is a parent ticket that groups the tickets of one larger piece of work) with open tickets, almost done first, then open, then those whose remaining tickets are a new part, each with what is left and its open tickets, marking the ones free to pick up (not started and claimed by nobody); and the open pull requests closest to merging: ready to merge, waiting for review, approved but needing a rebase, one failing check, the rest, drafts last, each with what is left before it can merge. Use it when your human asks what is nearly done or what to finish next, or when you are choosing what to work on. kind limits it to initiatives or pull requests. Each row carries the dashboard's tag (action_label, such as Merge Ready, Review Needed or Check to Fix) and quick, true when it is one step from done: act on quick rows first. A pull request also says who opened it and which tickets it closes (closes, and the initiative it finishes a ticket of). Only the 50 most recently updated open pull requests are read; the answer says when there are more, and when check results could not be read. Read-only, and it never fails: if the list cannot be read it says why. Before starting a ticket, check it with board and claim it as usual.

Call this before you start a shared operation such as a deploy or a restart (deploy:production, restart:api), to see whether another agent is already doing it. For a repository it lists the operations an agent holds, or held in the last 24 hours: the operation, who holds it, since when, until when the hold lasts unless it is renewed, and the last heartbeat. If someone holds the operation you need, wait for them rather than starting it again. Give operation to ask about one. Operations are claimed with the agent pack's op-claim on the repository's operations issue; this tool only reads them. Read-only, and it never fails: if they cannot be read it says why.

Lists what needs a person on a repository, as the dashboard's Needs you panel does and in its order, most urgent first: the main branch failing CI, failing pull requests nobody is on, work held by a session that has ended, green or approved pull requests left unmerged, pull requests waiting long for review, claims that have gone quiet, two pieces of work changing the same files, issues closed without shipping, and phases out of step with their pull request. Each item has its kind, how serious it is, the issue or pull request it is about (number, title, link) and a one-line reason with what to do. Use it when your human asks what needs attention, or before you pick work, to fix what is blocking others first. The answer says when the dashboard is still reading pull request states, or could not make a check. Read-only, and it never fails: if the list cannot be read it says why.

Call this before you push, to judge whether your job will wait for a runner and whether now is a busy time. For a repository it shows: what is waiting for a runner now (jobs, grouped by pull request or push, and the runner labels they wait on), how long the oldest has waited and whether the runners count as congested; the median wait for a runner (self-hosted jobs started today, else GitHub-hosted jobs in the last hour) and per workflow over its recent runs; which runners are busy and with which job (the runners the dashboard can see; where it cannot read the full list, those seen in recent jobs, and it says so); and runner capacity over the last 24 hours: the share of the day the runners were congested, and how much spare capacity there was. If the queue is long and your push is not urgent, keep committing locally and push once. Read-only, and it never fails: if the queue cannot be read it says why.

The dashboard's daily metric history for a repository, oldest day first, for trends: is CI getting slower or failing more, is the backlog growing, are runners congested more often? Each day carries what the dashboard recorded that day: issues filed and closed and open, CI runs passed and not passed, active agents, delivery counts (in progress, blocked, under an initiative, on the project board with a Status), and runner capacity (time congested out of time measured). Give days (1 to 90, default 14) and, to keep the answer short, sections. Counts only. Read-only, and it never fails: if the history cannot be read, or the dashboard keeps none, it says why.

The thresholds the dashboard uses to judge a repository, as its team set them, and where each value comes from (the repository, the workspace, a settings file, or the default): when an in-progress item counts as stalled, how few tickets left and how much closed make an initiative almost done, how long a finished initiative stays in Recently finished, when an agent session counts as idle or parked, and the green and amber targets of the hygiene lines. Use it to understand why the dashboard called something stalled, almost done or parked. Only these thresholds: no other setting. The CI thresholds (when runners count as congested) come with ci_queue. Read-only, and it never fails: where the dashboard keeps no settings it says so.

Answers "what did I or another session start and leave?". For a repository it lists three things. Left behind: open work held by a session that has ended, one row per open pull request (else per issue), most recently active first: the issue or pull request with its title and link, the session that held it, how long it has been quiet, and its status (recent, stale, or done when the issue was closed elsewhere), with the pull request's checks and merge state. Housekeeping: how many claims are still held for merged or closed pull requests, how many sessions have ended, and the running sessions that never registered. Active work by how long it has been quiet: the issues in progress, quietest first, marking those quiet for longer than the team's stall threshold. Use it when your human asks what was left unfinished, or before you pick work, to finish or hand on what is already started. Before taking over an item, check it with board and claim it as usual. Left behind needs the dashboard to read agent leases: where agents report through claim comments, the answer says it is not available. Read-only, and it never fails: if a part cannot be read it says why.

Lists the initiatives in a repository, and the container issues inside them, that hold at least the dashboard's threshold (default 70) of the 100 sub-issues GitHub allows one parent, fullest first: each with its sub-issue count, how many of those are closed, how many slots are free, and whether it is full. GitHub refuses a parent's 101st sub-issue, and closed sub-issues keep their slots. Use it before you add a sub-issue to an initiative, when your human asks why GitHub refused one, or to suggest which initiatives to split. Read-only, and it never fails: if the list cannot be read it says why.

Lists the open issues in a repository that have no area (no [persona] title prefix and no persona: label), as the dashboard's Has an area line counts them, each with a suggested area, the persona: label that gives it, a confidence (high or medium) and a one-line reason. The suggestion comes from the repository's own issues: the area most of the other issues under the same initiative have, or else the area most issues with the same title prefix or scope have. When there is no clear majority, there is no suggestion, and the reason says why. Use it when your human asks you to tidy up issues with no area. Show them the list first, then apply only the labels they agree to, with your own GitHub access: the dashboard never writes labels. Read-only, and it never fails: if the list cannot be read it says why.