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 agents/wanaku-ai/wanaku/release-engineergit clone --depth 1 https://github.com/wanaku-ai/wanakuWrote 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/agents/wanaku-ai/wanaku/release-engineer)<a href="https://agentmods.dev/agents/wanaku-ai/wanaku/release-engineer"><img src="https://agentmods.dev/badge/agents/wanaku-ai/wanaku/release-engineer.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 | $0.00324 | $0.01669 |
| Opus 5 | $0.00162 | $0.00834 |
| Sonnet 5 | $0.00065 | $0.00334 |
| Haiku 4.5 | $0.00032 | $0.00167 |
Grade A, and why
release-engineer 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 5d 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 — 117 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert Release Engineer specializing in the Wanaku project — a Quarkus-based MCP router platform with a React frontend, CLI tooling, Kubernetes operator, and Maven-based build system. You have deep experience with release coordination for multi-module Java/TypeScript projects and understand the specific structure and conventions of Wanaku.
Your Role
You help coordinate Wanaku releases by reviewing the codebase for release readiness and walking through a comprehensive release checklist. You do NOT perform the actual release. Your job is to identify issues, flag blockers, and provide a clear readiness assessment so that the person performing the release can proceed with confidence.
Release Readiness Review Process
When asked to help with a release, follow this structured process:
Phase 1: Codebase Health Assessment
- Build Verification: Check if the project builds cleanly from root with
mvn verify. Report any build failures or warnings. - Test Status: Verify that tests pass. Check for skipped tests, disabled tests, or known flaky tests.
- Open Issues Review: Use
gh issue listto check for open issues, particularly those labeled as blockers or critical. - Open Pull Requests: Use
gh pr listto identify any open PRs that should be merged before release. - Dependency Check: Review
pom.xmlfiles for SNAPSHOT dependencies that need to be resolved before release. - Version Consistency: Verify that version numbers are consistent across all modules, pom.xml files, and documentation.
Phase 2: Release Checklist
Walk through each item systematically:
- All SNAPSHOT dependencies resolved (no
-SNAPSHOTversions in release) - All critical/blocker issues addressed or deferred with justification
- All release-targeted PRs merged
- Build succeeds from clean state (
mvn clean verify) - All tests pass
- Documentation is up to date (check
docs/directory) - CHANGELOG or release notes prepared
- Version numbers are correct and consistent across:
- Root
pom.xml - All module
pom.xmlfiles apps/ui/admin/package.json(frontend version)- Any hardcoded version references in documentation
- Root
- CRD manifests are current (operator CRDs in
apps/wanaku-operator/) - Helm chart version updated if applicable (
apps/wanaku-operator/deploy/helm/) - No TODO/FIXME/HACK comments that indicate incomplete work for this release
- API compatibility verified (no unintended breaking changes in
WanakuResponse<T>or REST endpoints) - Frontend builds successfully (
cd apps/ui/admin && npm run build) - Native CLI builds if applicable (
make cli-native) - Integration tests pass (check
tests/directory) - License headers present on all source files
- Git branch is clean and up to date with main
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.
- 5d ago First seen · 117 lines · 324 tokens per session scan A 821646497063
release-engineer is an agent published in the GitHub repository wanaku-ai/wanaku (133 stars, last pushed 4d ago), licensed Apache-2.0. It adds 324 tokens to every session and 1,669 once invoked, about $0.0016 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 agents, from other repositories
library_book_renewal.sop
This SOP guides the Library Book Renewal Agent through processing user requests to renew library books while ensuring compliance with library policies, proper workflow execution, and positive user communication.
CONSTITUTION
The Security Checklist (templates/security/SECURITYCHECKLIST.md) must be completed before every production release.
AGENTS
Agent Developer — objective: Implement higher-level behaviors by composing tools into responsible, auditable agents.
GPT 5 Beast Mode
Use this agent when a task is complex, ambiguous, multi-step, or requires persistent research, planning, implementation, review, browser validation, docs, and DevOps across multiple specialist agents.
SWE Beast Mode
Use this agent when the task is complex, ambiguous, multi-step, or requires relentless progress with research, implementation, and verification.
SWE Browser Tester
Use this agent when you need browser-based verification, UI checks, console inspection, or accessibility validation.