One release and its readiness, feature by feature, worked out from the board by the rules of D113 (never by AI).
get_releaseOne release and its readiness, feature by feature, worked out from the board by the rules of D113 (never by AI).
Feature = an epic in the release; issues with no epic are grouped as other. Each feature lists the checks it passes and, when it is not Ready, the reasons. For people who do not manage releases (manage: false) the gate items, baseline and scope history are left out — frontmatter.gate is [], baseline null, scope_log [] and gate / scope are null — only gate_summary is given, and added_after_baseline is false (D113 (4)). Use the numbers as they are; do not guess.
Read this before answering anything about a release ("are we ready?", "what is blocked?", "summarise for the steering meeting"). Use status, features[] (status, checks, reasons), other, counts, gate_summary and scope exactly as returned — never guess, round or invent numbers, and name the issue keys from reasons. manage: false is the member view (no gate items, no scope history) — say so rather than guessing them. You may create a planned release (create_release) and edit its name, date, milestones and description until the baseline is locked (update_release), with your user's rights (D189). You cannot tick its gate, lock its baseline, mark it shipped, reopen or delete it: that is for people in the web app — an AI agent never approves a release.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| release_id | Yes | Release id (spec D113): `R-` + a number, unique in its project; the file is `releases/R-{n}.md`. | |
| project_key | Yes | Project key, e.g. `KJ`. 2–10 chars, uppercase letters and digits, starts with a letter. |