### Templates (stable-ID, data-only)
- Templates live in `tix.toml` under `[issue_templates.<id>]`, keyed by an
**immutable stable ID** with a mutable display `name`. A rename changes only
the label, so scope, defaults, prompts, references and preserved unknown
metadata survive it. The **ID** is what `tix create --template` and MCP
`create_issue(template=…)` select — never the name, which is only a label
- `tix template list` / `tix template show <id-or-name>` read a
`id<TAB>name<TAB>scope` row per template, or one structured `key: value`
block. Read-only
- `tix template create --id <id> [--name <n>] [--scope <scope>]
[--default FIELD=VALUE]… [--prompt key=FIELD[,kind=…][,required=…]]…
[--reference kind=KIND,value=VALUE[,required=…]]…`
- `tix template update <ref> [--name <n>] [--scope <scope>] [--default …]…
[--prompt …]… [--reference …]…` replaces only the parts supplied: an absent
flag leaves the stored value as it was, and a same-content update reports
`unchanged`
- `tix template duplicate <ref> [--id <new>] [--name <n>]` copies to a new ID
(`<source>-copy`, then `-copy-2`, …); `tix template delete <ref> [--yes]`
removes the **definition** only — never an issue created from it
- Scope is explicit: `repository` (the default), `board:<name>` or
`team:<label>`. There is no implicit inheritance, and a scope naming an
unknown board or team is refused
- `tix create --template <stable-id> [--scope <scope>] [normal create flags]`
merges the template with the flags through a **pure resolver**, then calls the
same create core `tix create` does — there is no second issue writer. `--title`
is required unless the template defaults one, because resolution never prompts
- A template is **data**: defaults name normal create fields only, prompts carry
a closed kind (`text | select | multi-select | date`), and references are typed
(`label | assignee | file | cycle | milestone | relationship`). Nothing is
executable
- Required prompts and missing references are validated **before** any issue file
is written: a failure prints every diagnostic as `kind: field: message` and
creates no partial issue, leaving the template and the store untouched