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/lion-1209/coderio/commit-messagenpx skills add Lion-1209/coderio --skill commit-messagegit clone --depth 1 https://github.com/Lion-1209/coderioWhat 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.00015 | $0.01247 |
| Opus 5 | $0.00008 | $0.00624 |
| Sonnet 5 | $0.00003 | $0.00249 |
| Haiku 4.5 | $0.00002 | $0.00125 |
Grade A, and why
commit-message 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 yesterday.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- commit-message — 100% identical, 0 lines differ
How it starts
The opening of the file, as written. The whole thing — 98 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Commit Message
概述
把一团 diff 提炼成规范、可追溯的提交信息。核心：一条提交说清"做了什么"和"为什么"，让未来的自己（和同事）能从提交历史里读懂项目演进。
何时使用
- 写完代码要提交，需要写 commit message
- 改了多处，不知怎么概括
- 现有提交信息太笼统（"update""fix bug"），要重写
- 想统一团队提交规范
不该用：还没写完代码（先写代码）；只想看 diff（用 git diff）。
核心内容
格式：Conventional Commits
<type>(<scope>)<!>: <subject>
<body 可选：为什么改>
<footer 可选：BREAKING CHANGE: ... / Closes #123>
破坏性变更（不向后兼容的改动）两种写法，二选一或并用：
!标记：紧贴 type/scope 之后、冒号之前，如feat(api)!: 改用 token 鉴权替代 cookie——一眼标红，提醒 reviewer 注意。- 脚注
BREAKING CHANGE:：放 footer，写清破坏了什么、怎么迁移，如BREAKING CHANGE: /api/login 改为返回 token，前端需改用 Authorization 头——给受影响方具体的迁移指引。
破坏性变更必须二选一明确标注，别藏在普通提交里让下游踩坑。
type 选一个：feat（新功能）、fix（修 bug）、docs（文档）、refactor（重构不改行为）、test（测试）、chore（构建/杂务）、perf（性能）。带可追溯业务变更的迁移脚本（如新增用户表）可算 feat，纯基础设施改动算 chore。
从 diff 提炼三步
- 归类：主要是加功能（feat）、修 bug（fix）、还是重构（refactor）？
- 定 scope：影响哪个模块/文件？（如
auth、api、ui）可省略。 - 写 subject：一行，祈使句，说"做了什么"不说"怎么做的"，≤50 字符。
多处改动怎么办
- 相关改动 → 一条提交，body 列要点
- 不相关改动 → 拆成多条（用
git add -p分块暂存）
判断"相不相关"：这些改动服务于同一个目的吗？是 → 一条；否 → 拆。
灰色地带——"主线 + 顺带小修复"：重构或加功能时顺手修了个同处的小 bug（例 1 就是这种），可以合并：主线作 subject，bug 修复在 body 一行带过。但若两件事跨文件、跨关注点、或各自都够大，就该拆。一个简单的尺子：能不能用一句话（一个 subject）概括全部改动？能 → 合；不能 → 拆。
body 写什么
写为什么和影响，不写代码细节（代码自己会说话）：动机/背景、副作用/破坏性变更的迁移说明、关联 issue/PR（如 Closes #123）。破坏性变更的标注方式见上面「格式」节。subject 够清楚的小改动可以只写 subject，别硬凑 body。
语言
subject 跟随仓库现有风格（多数中文团队和本仓库用中文 subject；Conventional Commits 生态也常见英文）——没有仓库上下文时跟随团队语言；body 语言同 subject；用户明确偏好优先。
例子
例 1（单改动） — 把 useState 换成 useReducer：
refactor(auth): 用 useReducer 替换登录表单的状态管理
复杂的状态转换用 reducer 更清晰，也为后续多步校验做准备。
顺带修了 useEffect 未清理订阅导致的内存泄漏。
例 2（多相关改动） — 加登录接口 + 测试：
feat(auth): 实现邮箱密码登录接口
- 新增 /api/login 端点
- 加密码哈希校验
- 补单元测试覆盖成功/失败场景
例 3（该拆的） — 登录接口、迁移脚本、README 三件不相关事，拆三条：
feat(auth): 实现登录接口
chore(db): 添加用户表迁移脚本
docs: 更新 README 部署说明
常见错误
| 问题 | 修法 |
|---|---|
| 太笼统（"update""改了点"） | 写清 type + 具体做了什么 |
| 一条提交塞多个无关改动 | 拆成多条 |
| subject 写"怎么做"而非"做了什么" | "用 useReducer 替换"而非"改了 state 逻辑" |
| 只说现象不说动机 | body 补上为什么 |
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- yesterday First seen · 98 lines · 15 tokens per session scan A 81379d0bd3e6
commit-message is a skill published in the GitHub repository Lion-1209/coderio (9 stars, last pushed 4d ago), licensed MIT. It adds 15 tokens to every session and 1,247 once invoked, about $0.0001 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-31.
Other skills, from other repositories
blog-writer
Peri 项目博客写作风格指南。当用户说"写博客"、"写文章"、"出稿"、 "按风格写"、"博客"时触发。也适用于用户丢过来素材说"帮我写篇博客"的场景。 覆盖项目介绍、技术复盘、架构讨论、性能优化、架构设计等类型。.
auto-devflow
Use when starting an issue, bugfix, feature, or refactor that benefits from an adaptive development workflow. Select lite, normal, pro, max, or ultra from task complexity and risk, then use only the coordination, review, and verification phases that the task actually needs.
langfuse
Interact with Langfuse and access its documentation. Use when needing to (1) query or modify Langfuse data programmatically via the CLI — traces, prompts, datasets, scores, sessions, and any other API resource, (2) look up Langfuse documentation, concepts, integration guides, or SDK usage, or (3) understand how any…
self-build
Builds isolated npm capability packages that operate on real project code and connects them to Peri through MCP/MCPP and MetaHarness. Use when adding tools, resources, remote skills or agents, creating a Bun/Node.js stdio server, linking .mcp.json, or changing the active prompt and middleware set.
project-maturity
对任意项目进行全面的成熟度评估扫描。当用户说"检查项目成熟度"、"项目评估"、 "maturity assessment"、"代码质量扫描"、"项目健康度"、"项目体检"、 "scan project maturity"、"项目有多成熟"时触发。适用场景：接手新项目前的摸底、 发布前的质量审查、技术尽调、团队内部代码健康度盘点。.
auto-issue-fixer
Issue 全生命周期管理——从创建到归档。当用户描述技术问题、提 bug、"帮我记录"、 "修一下 X issue"、"验证一下"、"归档 issue"时立即触发。单入口自动分发， 替代旧 issue-create/fix-issue/issue-verify/issue-archive 四个技能。 即使用户没有用"issue"这个词，只要在描述值得追踪的技术问题就应触发。.