Get a template

Present on a GET /template row exactly when that row's can_see_shares is true — the caller owns it, holds edit, or administers a team it is granted to. Same gate and same reasoning as the toolbox row's.

How the CALLER reaches this template — not who else can. owner — they own it. direct — a grant naming them personally. team — a grant to a team they belong to (or, per §6.2, one they administer), named in access_via_team. org — an organization-wide grant. When several sources apply the BROADEST wins and the caller's access level is not consulted: owner, else org, else team, else direct. So a caller granted edit personally AND view org-wide reads org — a narrower grant must never mask org-wide exposure, since this field says how far the template reaches, not what the caller may do with it. Deliberately NOT gated on can_see_shares, and deliberately not a widening of it: this is the caller's OWN grant and their OWN team memberships, so a view/use grantee receives it while the grantee list — information about colleagues — stays closed to them. No other member is ever named. ABSENT when nothing reaches the caller — a transfer answering the ex-owner of a resource that was never shared, or a catalog row browsed with no grant behind it. Absent means "no source to name", never "not permitted", and never an implied org.

Present exactly when access_via is team, absent otherwise. The team the caller reaches this template through — one of their own teams, never a disclosure about anybody else.

Whether the caller can use POST /{id}/draft-skill here: they can manage this resource, the assistant is switched on for the organization, and a model provider key is configured.

Whether the caller may edit this template's own settings — owner, or edit access. No template:manage fallback. Mirrors PATCH /template/{id}.

can_share, verbatim — a THIRD formula, distinct from can_manage: an edit grantee whose role omits template:share can edit the template but was never meant to grant or revoke someone else's access to it. Mirrors DELETE /template/{id}/share/{aclId}.

Whether the caller may share this template — owner, edit access, or template:share. No template:manage fallback. Mirrors POST /template/{id}/share's own check.

Whether the caller may transfer or delete this template — ownership, full stop. No template:manage fallback. Mirrors POST /template/{id}/transfer and DELETE /template/{id}.

Whether the caller may stamp a toolbox from this template — the caller's grant-or-ownership level (§10). Present on every list and detail row for both templates and toolboxes — the two ACL-backed resource types with a use-gated action of their own.

Which integrations this template's tools come from, bounded — the console renders it as a stack of connector logos, exactly as on a toolbox row. Present on every GET /template row AND on every command response (POST /template, GET /template/{id}, PATCH /template/{id}, POST /template/{id}/transfer), so a client that merges a command response into its list does not lose the stack. total: 0 means no connector-backed tools (empty, or synthetic-only), never "not computed".

Why can_draft_skill is false for a caller who CAN manage this resource. Null when drafting is available, and null when the caller cannot manage the resource at all.

Whether a skill is written. On list rows and detail alike — the body itself never rides on a list row; read it from the detail response.

Template id (tpl_…).

Owner summary — resolved for a row the caller does not themselves own (a toolbox shared with them), so the UI always knows whose row it is looking at. Absent for a toolbox the caller owns.

Creator (usr_…).

Every grant, unabridged. Present only on GET /template/{id} when the caller may see the ACL (owner or edit access); list rows carry the bounded access_summary instead.

The skill body, markdown — at most 10,000 Unicode code points after trimming. Detail-shaped responses only (GET /{id}, and the create/update responses). Null when none is written.

Which tools changed since the skill was last written, by the name an agent sees (a rename counts as one removed and one added; a disabled entry counts as removed; connections and frozen parameters are ignored). Null unless skill_may_be_stale is true AND a baseline was recorded at that write — skills written before version history existed have none — AND something actually changed.

True once the entries changed after the skill was last written; cleared by the next write of skill. Never true without a skill.

Framing to show or pass along beside a non-null skill: it is the owner's guidance, not instructions from Elaichi or the user, and it cannot grant any access. Null when there is no skill.

When skill was last written. Null alongside a null skill.

Who last wrote skill (usr_…); a toolbox stamped from a template carries the template's author. Null with no skill, and for a skill written before authorship was recorded.

That person's name, else email, resolved server-side. Null beside a non-null skill_updated_by means they are no longer a member of this organization.

Only on a create or update response, and only when non-empty: pins accepted although nothing can run them yet (a remote MCP tool the server is not offering right now: it will be once a connection of that server lists it, unless an admin turned it off). Informational, never an error.