Omnigent is an open-source orchestration layer for running and coordinating different AI coding agents through one system. It is for developers who want to combine agents, apply policies and sandboxing, and continue sessions across devices. The catalogue add-ons extend its agent workflows.
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 skills add omnigent-ai/omnigent --skill changeloggit clone --depth 1 https://github.com/omnigent-ai/omnigentWrote 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/skills/omnigent-ai/omnigent/changelog)<a href="https://agentmods.dev/skills/omnigent-ai/omnigent/changelog"><img src="https://agentmods.dev/badge/skills/omnigent-ai/omnigent/changelog.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector pass
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.00044 | $0.00524 |
| Opus 5 | $0.00022 | $0.00262 |
| Sonnet 5 | $0.00009 | $0.00105 |
| Haiku 4.5 | $0.00004 | $0.00052 |
Grade A, and why
changelog 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 9d 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.
What it actually says
changelog — write a changelog from a commit/PR range
Turn a range of history into a clear changelog entry that a user can read to decide whether and how to upgrade.
Gather the range
Establish the range first. Honor an explicit one ("since v1.2.0", "the last 10
commits", "PRs merged this week"); otherwise default to commits since the most
recent tag (git describe --tags --abbrev=0 then git log <tag>..HEAD).
Collect the raw material yourself with sys_os_shell:
git log <range> --no-merges --pretty=format:'%h %s'for the commit subjects.git log <range> --mergesorgh pr list --search "merged:>=<date>"for PRs.git diff <range> --statto see the surface area, andgh pr view <n>for a PR's intent when a subject line is terse.
When a subject is unclear about user impact, dispatch the researcher
(purpose: explore) to read the diff and report what actually changed for
users — do not guess from the subject alone.
Group by change type
Use the Keep a Changelog categories, dropping any that are empty:
## <version or range> — <YYYY-MM-DD>
### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security
Write each entry
- One line per user-visible change, in the imperative or past tense, describing the effect on the user — not the internal mechanics.
- Lead with the change, link the PR or commit in parentheses at the end.
- Omit pure-internal churn (refactors, test-only changes, CI) unless it changes behavior. A changelog is for users, not a commit dump.
- Call out breaking changes explicitly and point to the migration-guide skill if upgrade steps are needed.
Verify
Before finalizing, route the draft through the reviewer (purpose: review)
when the changelog will ship — version numbers, "removed"/"breaking" claims, and
flag names are exactly what a fact-check catches.
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.
- 9d ago First seen · 55 lines · 44 tokens per session scan A f3df773601f1
changelog is a skill published in the GitHub repository omnigent-ai/omnigent (9,768 stars, last pushed today), licensed Apache-2.0. It adds 44 tokens to every session and 524 once invoked, about $0.0002 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 skills, from other repositories
taiyi-integration
A project workflow skill for closing a TaiyiForge change and recording it in a CHANGELOG.md file. It checks review results, tests, and the state of the working tree before archiving the change.
ship
Enter the Ship phase of CocoBrew. Reads review.md approval, generates structured commit, creates semantic version tag, optionally creates PR via gh CLI, and records deployment details. Requires approved review.
changelog
Update per-package CHANGELOG.md files for a Ratel release. Drafts entries with git-cliff (scoped per package), lets you curate, then writes the CHANGELOGs. Handles both RC entries and GA-graduation collapse (merging X.Y.Z-rc. sections into a single X.Y.Z section). Invoke before tagging a release.
swarm-migrate
Cross-repo migration swarm — one coordinator + N parallel subagents (one per target repo) that apply the same transformation, open PRs, wait for CI, and report back to a shared JSON ledger. Coordinator handles topology, conflict auto-rebase, and stop-on-novel-failure. Use when bumping a shared dependency, rolling out…
release-management
Automates GitHub releases with semantic versioning, changelog generation from merged PRs, and gh CLI integration. Supports draft, prerelease, and standard release workflows with task-tracked multi-phase execution. Use when creating releases, tagging versions, or publishing changelogs.
release-sync
Syncs latest release content to NotebookLM and HQ Knowledge Base after version tagging. Reads CHANGELOG, CLAUDE.md, and hook README, updates notebook sources, and ingests release digest. Optionally generates podcast from updated knowledge base. Use after tagging a new version to propagate release knowledge.