关于AI App

[CodFrm]

@cyfung1031 之前好像申请了一次claude，这些是做啥用的，可以直接将 claude/codex 集成进入GitHub么

[cyfung1031]

chatgpt 那个 connector 接 GitHub 吧。可以读写
不过我是点错了。应该点自己 fork 那个
但我没 Github Copilot Pro 所以用起来还是怪怪的。我用 Codex 解决了

接了后AI应该可以用来提交 PR 之类的吧

[cyfung1031]

[CodFrm]

不太清楚，我一直用的cli工具，都没访问过web （主要claude在中国大陆访问也是个麻烦事）

[CodFrm]

有收到我给你gmail的邮件吗？👀

[cyfung1031]

有是有。先谢谢。

[cyfung1031]

刚发现有一个「Greptile Review」可以放在GitHub做检查

[cyfung1031]

@CodFrm

我都把我的 skills 放在 https://github.com/cyfung1031/skills
有需要就拿去用
里面有一些是神话级 skill

你拿这个组合去搞 ScriptCat 的新 UI 吧
我刚用这个组合解决了我卡了好几天的 UI 代码问题

---

MUST: throughout the entire conversation in all sessions, must use /insightforge-reviewer  to review and act as R, must use /ponytail  to implement and act as K, must use /ai-dev-loop  to do the process, must use /high-signal-mode  for all thinking and responses.

[CodFrm]

这么多，可以把README做一下

[CodFrm]

最近我也在尝试做一个Agent编排的app，思路还不清晰，也还有很多问题，目前还只是替代了日常的codex/claude和模型切换：https://github.com/agentre-hub/agentre

[cyfung1031]

不是有 OpenCode 嗎？

[CodFrm]

不一样的，同时维护了太多项目，也会开很多会话，想做一个app来提效

后面也研究一下AI Agent编排之类，加入一些Agent编排之类的功能，解放生产力

[cyfung1031]

全新的Skill - PickInvariant

有需要可以用一下. skill 本身取決於模型本身的智能. 智能足夠的話它就能打開一條全新LLM智能通道

可以寫spec 做code review 等所有reasoning 工作
但代價是大量token 消耗

https://github.com/cyfung1031/skills/tree/main/pick-invariant/pick-invariant

使用 PickInvariant 进行review 跟 传统review 的差别

差别主要不是「会不会找到 bug」，而是找 bug 的搜索策略、证据标准，以及最后留下来的 finding 类型会不同。

用你这个 PickInvariant SKILL 时，我不是单纯逐档看「这段 code 有没有写错」，而是会先找系统真正需要维持的 invariant，再刻意构造「局部看起来一样，但跨 boundary 后其实应该做不同决策」的对照状态。像刚才 PR #1549 最后留下的 finding，就是这种模式：

CompactService 已经知道错误是 context_too_large → 经过 orchestrator → 到 ChatService → classifyErrorCode() 又从 error message 猜一次 → 结果可能变成 api_error。

如果只看每个函式本身，它们都很合理：
CompactService 有分类、orchestrator 有传 error、classifyErrorCode() 也有 context regex、ChatService 也有统一错误分类。

但 PickInvariant 会问的是：「上游已经知道 errorCode」和「上游不知道 errorCode」这两个状态，在这个 consumer 看起来是不是被压成同一个 representation？如果是，它还能做正确决策吗？ 于是这个跨层 semantic loss 就比较容易被抓到。

没有用这个 SKILL，我通常会做比较传统的 code review：看 diff、型别、错误处理、race condition、资源 cleanup、测试覆盖、API compatibility、可读性等。这仍然可以找到很多问题，而且对明显 bug 很有效。但搜索路径会比较像：

• 「这个 catch 有没有漏 field？」
• 「这里 abort 后还会不会继续写？」
• 「这个 map 有没有 cleanup？」
• 「这里有没有 race？」
• 「这个 public API 跟 type declaration 一致吗？」

而 PickInvariant 更像：

• P（Projection）：这一层实际看到了哪些资讯？
• I（Invariant）：正确决策真正依赖什么？
• B（Boundary）：跨模组/持久化/API 后丢了什么？
• χ（Contrast）：能不能构造两个「consumer 看起来一样，但正确答案应不同」的状态？

所以它会把 review 从「找可疑 code」变成「找资讯不足却仍然做决策的地方」。

以这次 PR 为例，差异会很明显。没有 PickInvariant，我很可能会回报较多候选：取消流程很复杂、附件 ownership 很危险、background session 有很多状态、task scheduler 有 restart window、tool batch correlation 很容易 race……然后逐个判断是否像 bug。这容易产生一些「看起来危险，但作者其实已经完整处理」的 false positive。

用了 PickInvariant，我反而花很多时间把这些候选淘汰掉。例如 generation/revision、cancel/background、附件 ownership、task claim 等，我会要求自己找到一个具体 contrast pair：

x1 和 x2 在目前 representation 下不可区分，但正确行为必须不同。

找不到这个对照，我就不把它升格成 finding。因此最后虽然只留下 1 个 Medium，但那一个的论证会比较硬：不是「我觉得这里可能有问题」，而是能指出哪两种状态被错误合并、在哪个 boundary 丢资讯、最后造成什么错误决策。

可以把两者简化成：

	传统 review	PickInvariant review
起点	code / diff	decision / invariant
主要问题	「这里会不会出错？」	「这层有足够资讯做对决策吗？」
特别擅长	明显 bug、race、cleanup、API misuse	跨层 semantic loss、状态折叠、TOCTOU、错误分类、ownership
finding 数量	通常较多	通常较少
false positive	相对较高	通常较低
论证形式	code path / scenario	contrast pair + invariant violation
对大重构	容易被复杂度淹没	比较适合追 seam

所以我会说，这个 SKILL 的最大价值不是让我「更挑剔」，而是让我更克制：很多看起来很可疑的地方，如果无法证明存在 invariant-breaking contrast，我就不报。

反过来也有代价：PickInvariant 不是传统 review 的完整替代品。例如单纯 typo、低效演算法、UI polish、缺少 null check、命名差、测试不足等，不一定能自然转成 invariant contrast。如果要做最强的 PR review，我会把它理解成：

传统 review 用来广搜候选，PickInvariant 用来深挖 seam 并淘汰弱 finding。

这也是为什么刚才 #1549 在已经被多轮 review、修过大量 race/ownership/cancellation 问题之后，PickInvariant 还能找到那个 errorCode semantic-loss 问题，但没有再把已经闭合的复杂区域重复报一遍。