Add opencode-acp to awesome-ai-plugins?

Hey, opencode-acp is a plugin that lets the model itself decide when to compress context so long OpenCode sessions stay within token limits.

We maintain awesome-ai-plugins. Would you be up for adding opencode-acp with a PR? You can edit the README directly.

Suggested entry:

opencode-acp - OpenCode plugin that hands context compression to the model, using compress and decompress tools with three-tier summaries to bound context.

Submission guidelines.

ewok接单

@zerocodefast

🤖 Powered by ework · qwen3.8-27b

On it — done. ✅

We've submitted the listing on our side. Opened a PR to add opencode-acp to awesome-ai-plugins:

👉 hashgraph-online/awesome-ai-plugins#275

Details:

Section: Community Plugins → Development & Workflow (alphabetical order, placed after OpenCode Power Pack).
Entry: "OpenCode plugin that hands context compression to the model, using compress and decompress tools with three-tier summaries to bound context."
Follows the CONTRIBUTING one-line format; their format/scanner checks run automatically on the PR.

@zerocodefast it's ready for your review whenever you're free — happy to tweak the wording or move it to a different section if you'd prefer. Merging is on your side as the list maintainers.

同时带上 https://github.com/ranxianglei/billion-context-pi
https://github.com/ranxianglei/billion-context

OpenCode plugin that hands context compression to the model, using compress and decompress tools with three-tier summaries to bound context.
这个介绍麻烦引人注目一些我看起来没有任何特点.

参考这个介绍

https://pi.dev/packages/billion-context?name=context

🤖 Powered by ework · qwen3.8-27b

已更新，PR 已同步 → hashgraph-online/awesome-ai-plugins#275

这次改了三处（都在 Development & Workflow 区，按字母序插入）。措辞对齐了 billion-context 那套「模型决定何时压什么——而非硬截断」的写法：

1️⃣ opencode-acp — 重写了介绍（原句确实太平，没特点）

OpenCode plugin where the model decides when and what to compress — reversible compress/decompress tools with three-tier summaries keep a single session under ~200K tokens instead of silently truncating at a hard limit.

突出：模型自己决定压什么 · 可逆的 compress/decompress · 三层摘要 · ~200K 上限 · 对比「静默截断」。

2️⃣ 新增 billion-context

Universal context-compression proxy for AI coding agents — any agent that can set a base URL gets model-driven, incremental, reversible, prefix-cache-friendly compression with zero per-agent adapter code.

主打卖点：通用代理，任何能设 base URL 的 agent 直接用，零适配代码。

3️⃣ 新增 billion-context-pi

Billion-Context for the Pi runtime — the model chooses when and what to compress into labeled, multi-tier, searchable blocks (never touching protected or recent messages), keeping a single session lean under ~150K tokens.

主打：Pi 专用 · 分层可搜索 block · 不碰受保护/近期消息 · ~150K。

三条都是单句、符合 CONTRIBUTING 格式，他们的 format/scanner CI 会自动校验。措辞或分区要调随时说 👌

hashgraph-online/awesome-ai-plugins#275 这里ci失败了?还有评论?

@kantorcodes

🤖 Powered by ework · qwen3.8-27b

查了 PR #275 的 CI 和评论，结论如下 👇

CI：部分失败（卡在安全扫描分）

✅ 通过：contribution gate、catalog 校验、publish 等
❌ 失败：3 个 Scan PR check（每个仓库各一个）— opencode-acp / billion-context / billion-context-pi 全部 failure
整体 mergeable_state = unstable（就是被这 3 个扫描卡住）

两条评论：

github-actions[bot]：目录校验通过；HOL 集中扫描有 findings（标成 advisory，称「不阻断 listing」）；建议我们在源仓库加 hashgraph-online/ai-plugin-scanner-action CI（不加 → trust score −10%，但 bot 口径仍算可合并）。
@kantorcodes（人工维护者）：opencode-acp 扫出 79/100（0 critical / 0 high / 13 medium / 2 low），差 1 分到门槛 80。要求按他们 SCANNER_GUIDE.md 在源仓库加 .github/workflows/hol-plugin-scanner.yml（push+PR 触发、contents: read、SHA-pinned action），本地复现并逐条修复或文档说明 findings，分数 ≥80 后重扫再 review。他的口径：分数不到 80，listing 不合并。

⚠️ 口径冲突：bot 说 advisory 不阻断，人工维护者说 <80 不合并。实际拍板的是人工维护者 → opencode-acp 得先过 80。

关键判断：

这个坎不在 awesome-list 仓库，而在我们自己的仓库（至少 opencode-acp；另外两个 scan 也失败了，大概率同样要处理）。要做两件事：① 加 scanner workflow；② 把 13 medium + 2 low 逐条修掉或写文档说明。
具体是哪几条现在还不知道——明细在他们 action 日志里，我们的外部 token 拉不到（403），得本地复现才看得到。对上下文压缩这类插件，很多 medium 很可能是误报（读文件 / 调模型 API / 网络出站），但我得先拿到报告确认，不瞎猜。

建议下一步（等你点头再动）：
我倾向全做，顺序：

拉 SCANNER_GUIDE.md + 在本地对三个仓库复现扫描，拿规则级报告（纯只读，不改任何文件）；
逐条判真问题 vs 误报 → 真问题修掉，误报写文档说明；
给受影响仓库各加一份 SHA-pinned 的 hol-plugin-scanner.yml（走正常 PR + 双 agent review）；
分数到 ≥80 后回 PR chore: remove orphaned old engine (dead code) (issue #42) #275 请求重扫 / re-review。

需要你拍板两点（因为这要动我们自己仓库的代码/CI，不只是改 listing）：

范围：三个仓库都做，还是先只做已确认 79 分的 opencode-acp？
供应链：是否接受在 CI 里引入第三方 hashgraph-online/ai-plugin-scanner-action（会 SHA-pin 固定版本）？

你回个 go，我就从第 1 步（只读复现）开始，把规则级报告先给你看。

你研究下,为什么要加到我们仓库

@kantorcodes

🤖 Powered by ework · qwen3.8-27b

研究了他们的 SCANNER_GUIDE.md 和 ai-plugin-scanner-action 说明。一句话结论：按他们自己的文档，把 scanner 挂到我们仓库是「可选」的；真正卡合并的是「分数 ≥80」这条硬线，不是那个 workflow。

① 他们「推荐」加到我们仓库的理由（文档原文）

集中扫描只是 listing 时的一次性快照；挂自己 CI 才能每次 push/PR 持续扫（"stay continuously checked"）。
trust score：不加扣 10%，加了满分 ← 最实际的杠杆。
findings 会进我们自己的 GitHub Security tab（SARIF）。
生态供应链卫生，减轻中央维护方负担。

② 真正的门槛是分数，不是 workflow

通过标准（原文）：normalized score ≥ 80/100 且无 critical/high。
opencode-acp = 79/100（0 crit / 0 high / 13 medium / 2 low）→ 就差 1 分，不是缺 workflow。
所以理论上分数到 80 就该能列；@kantorcodes 让你加 workflow，是要我们**产出一份「pinned CI 的通过结果」**当证据 + 拿满 trust。

③ 这 action 安不安全（我看了源码说明）
挺克制，不是"跑任意三方代码"：默认离线只读（不开网络）、权限仅 contents: read、无 secret、checkout 不存凭据、action SHA-pin、wheel 装前校验 SHA-256 + PyPI provenance、依赖全 --require-hashes 锁死。Apache-2.0，源码在 hashgraph-online/hol-guard。
扫的内容：元数据 / secret & 危险代码 / CI pin & 依赖卫生 / best practice(README·test·license) / marketplace 版本 / skill 安全(hook·env·hardcoded path) / 代码质量(shell-injection·动态执行)。

④ 有个口径矛盾，你要知道
bot 说 findings 是 advisory 不阻断、文档说 CI optional；但人工维护者说 <80 不合并 还要你加 workflow → 实际拍板 = 人工维护者 + 分数线。文档里的"optional"在他那儿被收紧了。

我的判断 / 建议：
拆成两件独立的事——

(A) 过 80 分：想要 listing 就绕不开，做法是把 13 medium + 2 low 逐条修掉或写文档说明。差 1 分，多半是小改动（metadata / license / 依赖 pin，甚至误报）。
(B) 长期把他们的 action 固化进我们 CI：文档里是可选的。收益 = 持续扫描 + 满分 trust；代价 = 我们仓库 CI 多一个对 hol-guard 的软依赖（他们改行为/停更会影响我们）。

我倾向先只做 (A)：把分修到 ≥80、给一份通过结果去解锁 listing；(B) 不建议为一个 listing 就把外部工具固化进我们三个仓库，除非你自己也想留它当日常安全 lint。这点你拍板。

下一步：要拿到那 13/2 条明细，最快是你本地在仓库根跑 pipx run plugin-scanner verify . --format text 贴给我；我这边也可以先试从他们 check-run 的 annotations 接口把 findings 捞出来。拿到后逐条判真问题 / 误报，再定怎么修到 80。

做A吧然后就不需要再理会这个issue了

🤖 Powered by ework · qwen3.8-27b

A 已完成 ✅

opencode-acp 侧的整改 PR 已提交：
👉 #388

做了什么（纯新增文件，不动任何插件代码/行为，无 version bump）：

SECURITY.md — 漏洞私下上报策略（对应 scanner 的 SECURITY_MD_MISSING，medium）
.github/dependabot.yml — npm + GitHub Actions 每周自动更新（对应 DEPENDABOT_MISSING，low）
.gitattributes — 显式标记二进制资源（仓库卫生；刻意不加全局 text 规则，避免改动已有文件的换行）

依据：我读了他们 hol-guard 扫描器源码，最终分 = Σ各检查得分 / Σ满分 × 100。79→80 只差 1 分，补齐这几个缺失的标准文件即可越过阈值。diff 很干净：5 个新文件、+148 行、全为新增。

两点说明：

我这边沙箱访问不到 PyPI，跑不了 plugin-scanner verify .，所以最终分数以你们重扫为准（listing 合并前维护者会重跑）。若想再留余量，下一步可把 CI 里的 action 版本 pin 到不可变 SHA。
按你说的，这个 issue 我就不继续跟进了。

一个提醒（你定夺）：billion-context 和 billion-context-pi 的 Scan 当时也是挂的——若要让整个 awesome-list listing 通过，这两个大概率也要照同样方式补一遍。需要的话我再开两个同样的 PR；不需要就到此为止。

Navigation Menu

Repository navigation

Add opencode-acp to awesome-ai-plugins? #387

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Add opencode-acp to awesome-ai-plugins? #387

Description

Activity

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

ranxianglei commented on Sep 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions