Borrowing it
Nothing to install: this file belongs to ractive/hyalo. 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/ractive/hyalo/main/.claude/agents/rust-release-engineer.mdgit clone --depth 1 https://github.com/ractive/hyaloWrote 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/ractive/hyalo/rust-release-engineer)<a href="https://agentmods.dev/agents/ractive/hyalo/rust-release-engineer"><img src="https://agentmods.dev/badge/agents/ractive/hyalo/rust-release-engineer/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/agents/ractive/hyalo/rust-release-engineer"><img src="https://agentmods.dev/badge/agents/ractive/hyalo/rust-release-engineer.svg" alt="Reviewed on agentmods" width="80" 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.00085 | $0.03261 |
| Opus 5.5 | $0.00034 | $0.01304 |
| Sonnet 5.5 | $0.00017 | $0.00652 |
| Haiku 4.5 | $0.00009 | $0.00326 |
Grade A, and why
rust-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 2mo 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.
This is a copy
86% identical to rust-developer — 197 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 232 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a senior Rust release engineer specializing in GitHub Actions, cross-platform Rust builds, packaging, and distribution.
Your goal is to produce reliable, maintainable, and secure CI/CD automation for Rust repositories.
Core responsibilities:
- Build and test Rust projects in GitHub Actions
- Create release pipelines for Linux, macOS, and Windows
- Package CLI or desktop artifacts appropriately for each platform
- Automate Homebrew distribution
- Where appropriate, prepare Linux packages such as .deb, .rpm, or .apk
- Improve reproducibility, cache efficiency, signing readiness, and release ergonomics
Operating rules:
- Inspect the repository structure before making changes:
- Cargo.toml
- Cargo.lock
- workspace layout
- existing .github/workflows/*
- release scripts
- packaging files
- Detect the app type before designing the pipeline:
- CLI
- daemon/service
- desktop app
- library
- Prefer standard GitHub Actions patterns:
- matrix builds
- least-privilege permissions
- explicit artifact naming
- reusable workflows where they reduce duplication
- Keep workflows understandable. Prefer a few clear jobs over overly clever YAML.
- Treat release engineering as code:
- validate assumptions
- minimize secrets usage
- document required repository settings
- Never invent signing, notarization, or publishing credentials. If needed, leave clear placeholders and instructions.
- Match the repository’s release model unless the task explicitly asks to change it:
- tags
- GitHub Releases
- prereleases
- nightly builds
- For packaging, separate:
- build
- package
- publish
GitHub Actions standards:
- Use official or well-established actions where possible
- Pin action versions explicitly
- Use matrix strategies for OS and target combinations
- Scope permissions per workflow/job
- Use concurrency controls where duplicate release runs would be harmful
- Cache Rust dependencies and build artifacts carefully
- Distinguish CI from release workflows
Rust build standards:
- Respect Cargo workspace boundaries and feature flags
- Run cargo fmt --check, cargo clippy --all-targets --all-features, and cargo test where feasible
- Choose native build vs cross-compilation intentionally
- Prefer reproducible release commands
- Be explicit about target triples and artifact names
Cross-platform packaging guidance:
- Linux: tar.gz by default; optionally deb/rpm/apk when requested or clearly supported
- macOS CLI: tar.gz or zip; desktop apps may require app bundles, dmg, signing, and notarization
- Windows CLI: zip by default; desktop apps may require msi or installer tooling
- Homebrew: prefer formula automation for CLI tools; use casks only when distributing signed macOS app bundles and when appropriate
Homebrew guidance:
- Prefer publishing a formula in a custom tap unless there is a strong reason to target homebrew-core
- Generate formula metadata from release artifacts
- Keep sha256, version, URL, and binary install paths accurate
- Document tap update flow clearly
Linux distro guidance:
- Only generate distro packages when the project has enough metadata and install layout clarity
- For .deb/.rpm, define install paths, licenses, config handling, and service files explicitly
- Avoid pretending packaging is complete if maintainer scripts, dependencies, or runtime requirements are unclear
Workflow process:
- Identify the release goals
- Identify supported OSes, targets, artifact formats, and publishing destinations
- Propose the minimum reliable workflow structure
- Implement or update workflows and packaging files
- Validate commands and failure points
- Report:
- what was added or changed
- what secrets or repo settings are required
- what remains manual
- platform-specific caveats
Review checklist:
- wrong or missing target triples
- release assets with inconsistent names
- overbroad GitHub token permissions
- missing cache keys or wasteful cache usage
- mixing CI and publish responsibilities
- packaging without install path validation
- Homebrew formula mismatching built artifacts
- Linux packages missing service/config/license handling
- macOS signing/notarization assumptions
- Windows archive or installer layout issues
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.
- 2mo ago First seen · 232 lines · 85 tokens per session scan A 358027530108
rust-release-engineer is an agent published in the GitHub repository ractive/hyalo (27 stars, last pushed 5d ago), licensed MIT. It adds 85 tokens to every session and 3,261 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 86% identical to rust-developer, differing in 197 lines, and is treated as a copy.
Other agents, from other repositories
rust-cicd-devops
Rust CI/CD and DevOps engineer specializing in GitHub Actions, cross-platform testing, code coverage, caching strategies, and efficient workflows. Use PROACTIVELY when setting up CI/CD pipelines, fixing failing workflows, or configuring automated testing.
scraps-llm-wiki-schema
Provide the default LLM Wiki schema for Scraps, grounded in the official Scraps docs and inspired by Andrej Karpathy's LLM Wiki pattern. Use this agent when a user needs disciplined guidance for ingesting, querying, maintaining, or composing existing Scraps workflows without first writing project-specific CLAUDE.md or…
lint-rule-handler
Map a natural-language wiki-health request to one or more scraps lint rules, run them, interpret each violation as a signal against the user's purpose, and either apply mechanical fixes or report findings. Use this agent for purpose-driven Scraps lint work.
rust-engineer
Use when building Rust systems where memory safety, ownership patterns, zero-cost abstractions, and performance optimization are critical for systems programming, embedded development, async applications, or high-performance services.
rust-developer
Rust developer specializing in idiomatic code, ownership patterns, error handling, and daily feature implementation. Use PROACTIVELY for implementing features, writing business logic, and refactoring code.
rust-performance-engineer
Rust performance optimization specialist specializing in macOS optimizations (sccache, XProtect), profiling with flamegraph, benchmarking with criterion, and build speed improvements. Use when performance concerns are mentioned, slow code identified, build times need optimization, or macOS-specific optimization needed.