OrchestKit AI 开发工具箱

README 对 171 个广域生命周期钩子所观察的数据、本地 JSONL 目的地、轮转、禁用方式以及可选网络出口作了异常具体的说明，并明确称不记录提示词或文件内容、不读取密钥存储及常见凭据文件。SECURITY.md 还定义了私密报告渠道、响应目标、运行时依赖风险范围、固定 SHA 的 Actions、CodeQL、依赖审查和秘密审计，因此数据流、敏感数据和依赖安全证据充分。最小权限未满分，因为钩子覆盖 32 类事件且本地记录没有全局关闭开关，只能禁用插件；Codex 的 ork-mech 配置采用 approval=never、工作区写权限和网络访问，虽保留沙箱并避免完全绕过，但权限仍较宽。用户确认只明确覆盖 setup 写 MCP 配置，未证明所有技能、代理和钩子的有副作用操作均逐项确认。外部效果描述清楚且远程同步默认关闭，获高分。卸载、禁用和非覆盖式安装提供一定恢复路径，但没有面向所有自动修改的统一回滚合同。作者、仓库、贡献者版权和维护方式均有标识，但出版者未由指定企业注册表验证，故来源归属不作满分认定。

README、包元数据和测试文件共同展示了版本检查、参数约束、离线 fetch stub、真实构建产物启动、退出码、限流、错误正文、传输配置和发布包二进制陷阱的覆盖；错误信息尤其具体，包含未知命令、不可达 API、无效 API key 和 Retry-After。依赖可用性说明非常完整，明确 Claude Code 与 Node/Python 版本下限、Context7 是否随宿主打包、密钥缺失行为、缓存更新滞后、stdin 阻塞和 worktree git-common-dir 问题。自洽性扣分源于对象描述为 106 个技能，而 README、package/pyproject 均称 107；README 的 Claude 配置段称插件不携带 .mcp.json，而 Codex 段又称 Codex 插件携带自己的 context7 MCP，虽可由宿主差异解释，但需要仔细区分。测试仅作为静态文件证据，未声称执行。

材料按 Claude Code、Cursor、Codex、pi 和 skills.sh 分别给出支持矩阵、安装方式、命令命名、角色、钩子、规则与 MCP 差异，并区分完整插件、便携工作流包和 starter 12，受众与场景覆盖充分。能力边界明确指出哪些宿主没有 hooks 或 agents、Context7 缺失时会退回训练数据、pi 的禁用模型调用技能、Codex 自定义角色必须单独安装，以及 ork-mech 只适合机械性工作。触发精度由窄描述、显式调用名称、auto 路由、disable-model-invocation 和触发评估脚本支持。环境适配还覆盖版本下限、重启要求、无头 stdin、linked worktree、MCP 配置优先级和非覆盖式安装，证据足以支持满分。

README 具有目录、快速开始、宿主矩阵、配置、可观察数据、安装、FAQ、开发、更新和社区入口，信息架构清晰。安装说明对四类宿主包含命令、重启、验证和常见陷阱；FAQ 与示例覆盖普通及高级场景。命名总体明确，但 ork、ork-alpha、ork-codex、implement、/ork:implement 与 $ork-implement 并存，且说明文本自身强调版本与命名混淆风险，因此命名稳定性扣一分。已知限制公开且具体，包括无 LTS、仅最新版获安全修复、solo maintenance、缓存快照、密钥认证误判、钩子宿主限制及性能基准非门禁。MIT 正文与两份包元数据一致。README 展示详细 beta 变更记录和完整 CHANGELOG 入口。SECURITY.md 明确个人维护责任、响应目标、升级路径和披露流程；身份未知不会被当作可疑，但责任渠道在仓库内足够明确。

命令设计、宿主专用调用方式、doctor、JSON 输出、规范退出码、配额显示和可复制配置，使产物具有较高可用性。107 技能、36 代理及 171 钩子的组合相对于基础编码代理可能提供明显增量，且按需加载、starter 12 和小型 Codex 包体现了控制开销的意识。然而生产模式自动应用、正确完成任务和‘zero overhead’等价值主张主要来自 README，给出的测试侧重 CLI、结构和安全合同，没有静态结果证明这些大量技能对真实任务的增量质量，因此 marginal_value 不满分。成本披露涵盖 Context7 免费额度、Pro 价格、约 150ms 冷启动、进程扇出以及按需上下文，但没有整体 token、维护复杂度或 171 个钩子的持续开销汇总，故 cost_benefit 为中等。

多项声明能追溯到具体配置、脚本名、环境变量、测试名称、版本、错误文本和更新条目；README 的生成标记与 CI stale-check 声明也改善了可追踪性。但提供的材料没有关键实现文件、锁文件、工作流全集或测试结果，诸如‘无硬编码远程主机’、‘永不记录内容’和安装时 Snyk 扫描仍主要是项目自述，故不满分。版本和作者由 README、package.json 与 pyproject.toml 交叉印证，CLI 行为由单元及 E2E 测试交叉支持；技能数量却与对象描述不一致，且缺少独立来源，因此交叉佐证仅为充分但非彻底。文本经常明确区分 measured、advisory、optional、prerequisite、fail-open policy 和未执行测试，有较好的事实/推断分离；但营销性比较和若干绝对安全陈述没有在所给实现中直接展示，仍需扣分。