Spice is a Rust-based engine that combines SQL queries, search, and large-language-model inference to provide data for AI applications and agents. It runs beside an application or as a distributed cluster, connecting to existing data sources and supporting real-time analytics replicas for operational databases.
Borrowing it
Nothing to install: this file belongs to spiceai/spiceai. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/spiceai/spiceai/trunk/.github/prompts/writeReleaseNotes.prompt.mdgit clone --depth 1 https://github.com/spiceai/spiceaiWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/spiceai/spiceai/writereleasenotes)<a href="https://agentmods.dev/commands/spiceai/spiceai/writereleasenotes"><img src="https://agentmods.dev/badge/commands/spiceai/spiceai/writereleasenotes.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00087 | $0.03124 |
| Opus 5 | $0.00044 | $0.01562 |
| Sonnet 5 | $0.00017 | $0.00625 |
| Haiku 4.5 | $0.00009 | $0.00312 |
Grade A, and why
writeReleaseNotes scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write or update release notes for the specified version based on all changes since the specified previous release.
Modes
- Create: No release notes file exists yet for the version. Build the file from scratch following all steps below.
- Update: Argument is
update(or the release notes file already exists). Treat the existing file as the source of truth for tone, ordering and editorial decisions, and only ADD entries for commits landed onorigin/trunksince the file was last edited. Do not rewrite or reorder existing sections unless the user asks explicitly.
To detect update mode and find the relevant commit range:
- Check whether
docs/release_notes/<version>.mdexists. - Find when it was last edited:
git log -1 --format='%H' docs/release_notes/<version>.md - New commits to consider:
git fetch origin && git log <last-edit-sha>..origin/trunk --no-merges --format='%h | %an | %s'
Writing style: Simplified Technical English
Write every sentence you author in Simplified Technical English (ASD-STE100 writing rules). Release notes are read fast, by people deciding whether to upgrade, often in a second language or through a machine translator, and re-read months later by someone bisecting a behaviour change. A 50-word sentence with three subordinate clauses fails all of those readers. Short declarative sentences do not make the content less technical — they make each technical claim separately checkable.
Read .github/prompts/references/simplified_technical_english.md before writing prose. It carries the full rules, the rewrite patterns, the terminology table, and worked before/after examples from real Spice releases. The short version:
- One idea per sentence, 25 words or fewer. Split where the subject changes. The total gets longer; that is the trade.
- Active voice, named actor. "The runtime derives memory budgets from its cgroup limit", not "Memory budgets are derived". Passive is acceptable only when the actor is genuinely unknown.
- No participle clauses — no
using,enabling,including,allowing,by improving. Use a finite verb in its own sentence. Established technical nouns that end in-ing(caching, sharding, CPU sizing) are fine. - Simple tenses. Present for current behaviour, past for what a release changed.
- One word, one meaning. Hold each term for the whole document —
setting, not a rotation of knob/option/param. - Keep
that, articles, and prepositions. Dropping them is the ambiguity STE exists to prevent. - At most three stacked nouns. Break longer stacks with a preposition or hyphen.
- Give the number, not the intensifier. No
significantly,various,seamless,powerful,unlocks,under the hood,headlined by. If no measurement exists, describe the mechanism. - No semicolons, and at most one em-dash aside per sentence.
- Bug fixes in a fixed order: symptom, then cause, then current behaviour.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 143 lines · 87 tokens per session scan A 020f0c567786
writeReleaseNotes is a command published in the GitHub repository spiceai/spiceai (3,079 stars, last pushed today), licensed Apache-2.0. It adds 87 tokens to every session and 3,124 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-06.
Other commands, from other repositories
kz-release
Prepare a dated verified catalog snapshot and stop before tag or push.
tfw-release
TFW Release — cut a versioned release of the project.
changelog-validate
Validate configuration and environment before running changelog generation.
changelog-weekly
Generate changelog for the last 7 days using configured data sources.
changelog-custom
Generate changelog for a custom date range using configured data sources.
/openspec-archive
Archive a deployed OpenSpec change and update specs.