Turn a selected range of commits or merged pull requests into release notes grouped by change type. Describe user-visible effects, link to supporting changes, and highlight breaking changes so readers can assess an upgrade.
Turn a range of commits or merged PRs into a changelog entry grouped by change type. Use when the user asks for release notes, a changelog, or "what changed" between two points.
Review the instructions the agent will receive before you install.
Turn a range of history into a clear changelog entry that a user can read to decide whether and how to upgrade.
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> --merges or gh pr list --search "merged:>=<date>" for PRs.git diff <range> --stat to see the surface area, and gh 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.
Use the Keep a Changelog categories, dropping any that are empty:
## <version or range> — <YYYY-MM-DD>
### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security
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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Test Omnigent’s native Antigravity integration with a live local server and the real agy CLI. Verify messages traveling between the web interface and terminal, mirrored replies, permission requests, interruption, session resumption, and process cleanup.
Test Omnigent’s Antigravity SDK integration against a live local server. Build test agents and run real conversations to check Gemini authentication, model selection, tool connections, and failures across the full execution path.
Create reference documentation directly from source code for public functions, classes, command-line commands, and endpoints. Organize parameters, defaults, return values, errors, and runnable examples, then check that the documentation matches the implementation.
Create an Omnigent agent directory using validated templates for configuration and instructions. Choose how the agent runs, then add web search, shell access, external tool connections, or subagents only when the task requires them.
Test Omnigent’s setup, help, and terminal interactions by driving the real CLI in an isolated environment. Capture rendered screens and compare checks before and after a change to establish whether a reported interface problem was fixed.
Test Omnigent’s GitHub Copilot SDK integration on a live local server. Build test agents, run real conversations, and inspect authentication, model selection, tool connections, policy enforcement, and leftover processes to investigate integration failures.