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 skills/chrysb/alphaclaw/release-analysisnpx skills add chrysb/alphaclaw --skill release-analysisgit clone --depth 1 https://github.com/chrysb/alphaclawWrote 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/chrysb/alphaclaw/release-analysis)<a href="https://agentmods.dev/skills/chrysb/alphaclaw/release-analysis"><img src="https://agentmods.dev/badge/skills/chrysb/alphaclaw/release-analysis.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.00114 | $0.01513 |
| Opus 5 | $0.00057 | $0.00757 |
| Sonnet 5 | $0.00023 | $0.00303 |
| Haiku 4.5 | $0.00011 | $0.00151 |
Grade A, and why
release-analysis 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 4d 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 — 228 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Release Analysis
Goal
Turn upstream release notes into a downstream product assessment:
- What could break
- What becomes redundant
- What gets easier to support or expose
- What should be updated, tested, or ignored
Default to a product-and-maintainer lens, not a changelog summary.
The user may provide only a package or repo name. In that case, resolve the upstream repository first, then inspect the latest release or tag notes before analyzing impact.
Workflow
- Start from the package or repo name the user gave.
- Resolve the canonical upstream repository.
- Open the repository's latest stable release notes. If needed, use the tags page to find the newest relevant release/tag and read its notes.
- Identify how this repo depends on or wraps that upstream project.
- Separate automatic benefits from places where this repo has its own assumptions.
- Look for regressions, redundancy, opportunity, and maintenance work.
- End with concrete recommended actions.
Resolving The Repo
When the user provides only a package or repo name:
- Prefer the canonical GitHub repository for that package.
- If the package name is ambiguous, use package metadata, project docs, or the dependency declaration in this repo to confirm the source.
- If multiple plausible repos exist and you cannot confidently resolve the right one, ask one short clarifying question before continuing.
Default to GitHub releases/tags as the source of truth for the analysis when available.
Find The Release Notes
Use this order:
- Latest stable GitHub release page
- Latest relevant tag page if the project publishes notes on tags
- Release notes linked from the repository if GitHub has no usable notes
Prefer the latest stable release unless the user explicitly asks about beta, prerelease, or a specific version.
Gather Context
Read only what is needed:
- The release notes or announcement from the latest release/tag
AGENTS.mdand nearby project guidancepackage.jsonor dependency pins- Version/update code paths
- Any UI, route, or service files that expose the affected area
- Tests covering the affected area, when the release looks risky
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.
- 4d ago First seen · 228 lines · 114 tokens per session scan A 2ac46f57c4a4
release-analysis is a skill published in the GitHub repository chrysb/alphaclaw (1,471 stars, last pushed yesterday), licensed MIT. It adds 114 tokens to every session and 1,513 once invoked, about $0.0006 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
context-recovery
Recovers project handoff context from local Codex, Claude Code, Gemini, CodeBuddy, and codexmate-derived sessions. Use when the user asks what happened in prior project/PR/branch/file/error work, needs a handoff brief, wants old decisions or validations recovered, or asks to summarize cross-session project activity…
wecom-doc-manager
企业微信文档管理技能。提供文档的创建、读取和编辑能力，支持通过 docid 或文档 URL 操作企业微信文档（doctype=3）和智能表格（doctype=10）。适用场景：(1) 以 Markdown 格式导出获取文档完整内容（异步轮询） (2) 新建文档或智能表格 (3) 用 Markdown 格式覆写文档内容。当用户需要查看文档内容、创建新文档、编辑文档正文时触发此 Skill。.
wecom-preflight
WeCom MCP 文档/智能表格调用前置检查。仅当已经决定调用 wecommcp 的 doc 类能力时使用；不要用于给企业微信用户或群发消息、联系人查询、日程、会议或待办。发消息必须使用 OpenClaw core message 工具。.
hotplex-release
通过判断 SemVer 影响、整理 CHANGELOG、对账版本面和验证发布输入来准备或发布 HotPlex 版本。不要用于主机二进制更新、运行时诊断或文档巡逻。.
hotplex-docs-patrol
维护 HotPlex 当前文档，将代码、配置、API 或发布变更映射到 BFS 可达文档，只修复已验证的文档漂移。不要用于普通润色、运行时诊断或版本发布。.
hotplex-stt-tts
初始化或修复 HotPlex 本地 STT 和 MOSS TTS 运行时，包括 Python 依赖、官方模型、配置和验收。仅在明确授权主机变更时使用；只读检查请使用 hotplex-cli 或 hotplex-diagnostics。.