Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/komunite/kalfa/releasegit clone --depth 1 https://github.com/komunite/kalfaWhat 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 | $0.00013 | $0.01078 |
| Opus 5 | $0.00006 | $0.00539 |
| Sonnet 5 | $0.00003 | $0.00216 |
| Haiku 4.5 | $0.00001 | $0.00108 |
Grade A, and why
release 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 3d 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 — 108 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Git geçmişinden otomatik sürüm notları oluştur. Aynı veriden hedef kitleye uygun sürümler üretir — teknik değişiklik günlüğü, pazarlama duyurusu veya yönetici özeti.
Adımlar
Adım 1: Aralığı belirle
Hangi commit'lerin dahil edileceğini belirle:
- Kullanıcı bir sürüm belirttiyse → etiket aralığını bul (örn.
git log v1.2.0..v1.3.0) - Kullanıcı tarih belirttiyse → tarih aralığını kullan (
git log --after="2025-01-01" --before="2025-02-01") - Hiçbir şey belirtilmediyse → son etiketten bu yana değişiklikler (
git log $(git describe --tags --abbrev=0)..HEAD)
Adım 2: Commit verilerini topla
git log [aralık] --format="%h %s" --no-merges
Ayrıca kontrol et:
- Varsa PR açıklamaları (merge commit mesajları için
git log --merges) - Mevcut CHANGELOG girdileri
- Kapsamı anlamak için değiştirilen dosyalar (
git diff --stat [aralık])
Adım 3: Değişiklikleri kategorize et
Her değişikliği şuna göre sınıflandır:
| Kategori | Simge | Örnek |
|---|---|---|
| Yeni Özellikler | Eklendi | Yeni yetenek, yeni endpoint, yeni bileşen |
| İyileştirmeler | Değiştirildi | Performans artışı, UX iyileştirmesi, yeniden yapılandırma |
| Hata Düzeltmeleri | Düzeltildi | Çözülen sorun, düzeltilen davranış |
| Kırıcı Değişiklikler | Kırıcı | API değişikliği, kaldırılan özellik, geçiş gerekli |
| Bağımlılıklar | Bağımlılıklar | Güncellenen paketler, yeni bağımlılıklar |
| Dahili | Dahili | Testler, CI, belgeler, yeniden yapılandırma |
Adım 4: Sürüm notlarını yaz (3 versiyon)
Versiyon 1 — Teknik Değişiklik Günlüğü (geliştiriciler için):
# [Sürüm] — [Tarih]
## Kırıcı Değişiklikler
- [geçiş talimatlarıyla değişiklik]
## Yeni Özellikler
- [özellik]: [açıklama] ([commit hash])
## İyileştirmeler
- [iyileştirme] ([commit hash])
## Hata Düzeltmeleri
- [düzeltme] ([commit hash])
## Bağımlılıklar
- [paket] [eski] sürümünden [yeni] sürümüne güncellendi
Versiyon 2 — Pazarlama Duyurusu (müşteriler/genel kitle için):
# [Sürüm]'deki Yenilikler
[1-2 cümlelik çekici giriş — en heyecan verici değişiklik]
### [Özellik Adı]
[Fayda odaklı açıklama — nasıl çalıştığı değil, kullanıcı için ne anlama geldiği]
### [İyileştirme]
[Kullanıcıya yönelik iyileştirme, varsa öncesi/sonrası ile]
### Hata Düzeltmeleri
[Özet — "X dahil olmak üzere X sorun düzeltildi..." — commit hash'leri yok]
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.
- 3d ago First seen · 108 lines · 13 tokens per session scan A 8fcb0096c5fe
release is a command published in the GitHub repository komunite/kalfa (244 stars, last pushed 4mo ago), licensed MIT. It adds 13 tokens to every session and 1,078 once invoked, about $0.0001 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-08-30.
Other commands, from other repositories
ship
Run the pre-launch checklist via parallel fan-out to specialist personas, then synthesize a go/no-go decision.
generate-changelog
Generate a changelog from git history, grouping commits by type and version.
tfw-release
TFW Release — cut a versioned release of the project.
write-changelog
Generate a detailed changelog entry from git history and merged PRs.
vios-release-note
Generate a complete VIOS multi-arch release note for a given build drop version. Fetches container images from GitLab compose.env, GitLab commit titles since the previous release tag, Jira VST tickets, NVBugs entries, Slack channel evidence, and Outlook email evidence, then renders and saves a formatted release note.
release
Deliver a feature end-to-end — verify, docs, merge, tag (publish stays manual).