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 skills add TNT-Likely/honeycomb --skill triagegit clone --depth 1 https://github.com/TNT-Likely/honeycombWrote 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/tnt-likely/honeycomb/triage)<a href="https://agentmods.dev/skills/tnt-likely/honeycomb/triage"><img src="https://agentmods.dev/badge/skills/tnt-likely/honeycomb/triage.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.1 | $0.00224 | $0.01645 |
| Opus 5 | $0.00112 | $0.00822 |
| Sonnet 5 | $0.00045 | $0.00329 |
| Haiku 4.5 | $0.00022 | $0.00164 |
Grade A, and why
github-issue-triage 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 8d 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 — 96 lines — stays where its author put it; the contents beside it link to each section on GitHub.
GitHub Issue Triage 技能
做什么
把一个 GitHub repo 的全部 open issue 拉下来,按统一维度分级排序,产出一份可维护的优先级文档(.docs/issue-triage.md),并可配合 /schedule 定期增量更新。目标:把"几十个 issue 的噪声"压成"先做哪几个"的清晰判断。
核心信念:triage 是只读的决策支持,不是替用户做决定 —— 产出文档,排好序,讲清理由,把"做不做、先做谁"留给人。
何时触发
- 用户问"还有哪些有价值的需求 / 急需修的 bug"
- 要给 backlog 排优先级 / 出 roadmap
- 要定期(周/双周)自动巡检新 issue
流程
1. 拉取(注意网络兜底)
gh 已认证即可。坑:某些网络环境(如公司 Zscaler 代理)下 gh 走 HTTPS GraphQL API 会 TLS 握手超时;失败就 unset 代理重试(git push 走 SSH 不受影响,只有 gh API 需要):
env -u HTTPS_PROXY -u HTTP_PROXY -u https_proxy -u http_proxy -u ALL_PROXY -u all_proxy \
gh issue list --repo OWNER/REPO --state open --limit 100 \
--json number,title,labels,body,comments,reactionGroups,createdAt
repo 从用户给的、或当前目录 git remote 推断。
2. 读呼声信号
- 👍 =
reactionGroups里THUMBS_UP的users.totalCount - 💬 =
comments数组长度 - 先扫一眼这个 repo 用哪个信号为主:很多 repo 用户根本不点 👍(全 0),呼声只能看评论数。别只按 👍 排序得出"全都不重要"的错误结论。
用 jq 一把梭出按呼声排序的总览:
... gh issue list ... --json number,title,labels,comments,reactionGroups \
| jq -r 'map({n:.number, up:([.reactionGroups[]?|select(.content=="THUMBS_UP")|.users.totalCount]|add // 0), c:(.comments|length), l:(.labels|map(.name)|join(",")), t:.title}) | sort_by(-.up,-.c) | .[] | "#\(.n)\t👍\(.up)\t💬\(.c)\t[\(.l)]\t\(.t)"'
3. 四级分流(核心维度)
| 级 | 判据 |
|---|---|
| 🔴 P0 | 数据正确性错误 / 崩溃卡死 / 核心功能首用即失效。最优先:用户数据被悄悄记错那种(总额对、方向/归类错,用户自己发现不了) |
| 🟡 P1 | 高呼声需求、明显性能问题、与产品核心卖点强相关的体验缺陷 |
| 🟢 P2 | 局部体验改善、有用但非紧急的功能 |
| ⚪ P3 | 锦上添花、长尾、小众、含义模糊待澄清 |
排序权重:数据正确性/崩溃 > 呼声 > 与核心卖点相关度。一个安静(0💬)但会记错账的 bug,排在热闹(5💬)的外观需求前面。
4.(深入时)用代码验证 bug
对 P0/P1 的 bug,别只信描述 —— 在 codebase 里定位相关代码,确认 bug 真实存在、找到根因行号。把"疑似 bug"升级成"已定位、可修",triage 的含金量主要来自这一步。能顺手判断工作量(S <1天 / M 1–3天 / L >3天建议拆)。
5. 主题聚类(epic 视角)
把同主题的 issue 归成 epic(例:「自动记账可靠性」「平账/余额修正」「特殊交易类型(退款/报销/红包)」「CSV 导入」)。很多 issue 一次设计能解决一串 —— 这个视角往往比逐条排序更有决策价值。
6. 产出文档
写 / 更新 .docs/issue-triage.md:
# <Repo> Issue 优先级 Triage
> 生成于 <日期> · 共 N 个 open issue
> 排序依据 + 呼声说明 + 工作量图例
## 🔴 P0 … (表格:# / 标题 / 一句判断 / 呼声 / 工作量)
## 🟡 P1 …
## 🟢 P2 …
## ⚪ P3 …
## 🧩 主题聚类(epic)
## 🗺️ 推荐 Roadmap(分波次:先数据正确性+核心功能,再高呼声功能,再体验打磨)
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.
- 8d ago First seen · 96 lines · 224 tokens per session scan A e3b2bc6a3b19
github-issue-triage is a skill published in the GitHub repository TNT-Likely/honeycomb (2 stars, last pushed 8d ago), licensed MIT. It adds 224 tokens to every session and 1,645 once invoked, about $0.0011 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
catchup
Summarize and review what changed while you were away. Use after a weekend, vacation, or flight to check missed PRs, git commits, Linear tickets, and meetings — one prioritized brief, not a firehose.
glab
Expert guidance for using the GitLab CLI (glab) to manage GitLab issues, merge requests, CI/CD pipelines, repositories, and other GitLab operations from the command line. Use this skill when the user needs to interact with GitLab resources or perform GitLab workflows.
onboard
Scan and diagnose a project, or scaffold a new client from scratch. Works for code and venture clients. Auto-detects project type.
drain
Parallel-worktree auto-drain of the board. One /super-bootstrap:drain turn = scan the pipeline sources (specs/plans/backlog, plus the scale module's test queue when present) → keep only admissible items → relation-analyze into a conflict-free wave → confirm with the user → spawn one isolated git worktree + headless…
git-for-research-code
When the user wants to version-control optimization research code - small commits per experiment change, tags for paper result snapshots, .gitignore for solver logs, linking result tables to commit hashes, and branch strategy for risky refactors. Also use when the user mentions "git workflow," "version control…
team-dev
A workflow for splitting a software task into smaller jobs and assigning independent jobs to coding agents working in separate Git worktrees. A worktree is an isolated working folder connected to the same Git repository.