feat: templates list, read, create, update, and delete commands

[lightstrike]

Summary

Add a new top-level templates command to manage Linear issue templates (and potentially other template types) via the CLI. Currently, templates are only manageable through the Linear web UI or raw GraphQL calls.

Proposed subcommands

Command	Description
lineark templates list [--team KEY]	List all templates (optionally filtered by team; org-wide templates have no team)
lineark templates read <ID>	Show full template detail including templateData
lineark templates create <NAME> --type issue --team KEY [--template-data JSON]	Create a new template
lineark templates update <ID> [--name NAME] [--template-data JSON]	Update an existing template
lineark templates delete <ID>	Delete a template

GraphQL API reference

The Linear API exposes the following for templates:

Query — list all templates

{
  templates {
    id
    name
    type
    description
    sortOrder
    team { key name }
    creator { displayName }
    templateData
  }
}

Note: templates returns a flat list (not a paginated connection with nodes).

Template type fields: id, name, type, description, icon, color, templateData (JSON), sortOrder, team, creator, lastUpdatedBy, inheritedFrom, hasFormFields, createdAt, updatedAt, archivedAt, lastAppliedAt

Mutation — templateCreate

mutation($input: TemplateCreateInput!) {
  templateCreate(input: $input) {
    success
    template { id name team { key name } }
  }
}

TemplateCreateInput fields:

• type — required (String, e.g. "issue")
• name — required (String)
• templateData — required (JSON — the template body including title, descriptionData, priority, estimate, labelIds, etc.)
• teamId — optional (String — omit for org-wide template)
• id, description, icon, color, sortOrder — optional

Mutation — templateUpdate

mutation($id: String!, $input: TemplateUpdateInput!) {
  templateUpdate(id: $id, input: $input) {
    success
    template { id name }
  }
}

TemplateUpdateInput fields: name, description, icon, color, teamId, templateData (JSON), sortOrder — all optional.

Mutation — templateDelete

mutation($id: String!) {
  templateDelete(id: $id) {
    success
  }
}

Notes

• templateData is an opaque JSON blob whose shape depends on the template type. For issue templates it typically contains title, descriptionData (ProseMirror doc), priority, estimate, labelIds, stateId, and teamId.
• Templates can be org-wide (team is null) or team-scoped.
• Name resolution for --team should follow the existing pattern (key, name, or UUID).
• The type field appears to currently only support "issue" but the schema accepts a generic string, so it may expand in the future.

Test plan

• cargo build --workspace compiles
• cargo clippy --workspace -- -D warnings clean
• cargo fmt --check passes
• Offline tests: help text, validation for required flags
• Online tests: full CRUD lifecycle (create → read → update → delete), team-scoped and org-wide listing

[flipbit03]

Hey @lightstrike, how is it going? I wonder what is the agentic/CLI use case you have for managing templates through a CLI - imho this seems highly tangential to the core value of the tool. Keep in mind that I'm not trying to achieve full 1:1 parity with Linear GraphQL API, or the support surface alone would completely eschew any context-saving gains we're having right now.

Also, another thing I dislike is that templates seem to receive a raw, mostly untyped JSON object.

templateData is an opaque JSON blob whose shape depends on the template type.

I don't see this being a good fit for the CLI tool, to be honest, as something which is not well typed and can changed based on knowledge that the agent will not know at runtime.