Frad 的 Claude Code 插件集
为开发、研究与生产力工作流提供可按需安装的 Claude Code 插件。
- Star 数
- ★ 593
- 最近更新
- 3 天前
- License
- MIT
- 主语言
- JavaScript
- FA 评分
- 45/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 平台专用Claude Code
- 费用
- 免费，无需付费服务
- 上手难度
- 低 · 几分钟可跑通
- 开始前需要
- 典型场景
- 使用 Claude Code 管理代码库的开发者，希望用质量检查生成常规化、原子化提交。
- 不适合
- 不使用 Claude Code 的团队
- 需要独立应用或自托管服务的用户
- 希望所有功能都无需外部密钥或工具的用户
- 源码审查
- 45/100 · 缺口较多
这个 Agent 能做什么，适合哪些场景？
dotclaude 是一个面向 Claude Code 的插件集合，覆盖 Git 与 GitHub 自动化、代码重构、BDD、SwiftUI 审查、安全检查、研究、内容生产和硬件设计等工作流。仓库中的交付单元是独立插件，每个插件通过 `claude plugin install <name>@frad-dotclaude` 安装，而不是作为单一应用或后台服务运行。插件可包含代理、技能和斜杠命令；已明确列出的接口包括 `/git-agent:commit`、`/github:review-pr`、`/memory:consolidate` 和 `/pi:delegate`。具体输出取决于所选插件，包括原子提交、PR 审查结果、研究文章、专利申请、视频、图像、PCB 制造文件以及 STL、DXF 和 PNG 文件。其主要部署边界是 Claude Code，部分插件还会调用外部 CLI、搜索服务或模型端点，并可能需要各自的凭据。
用户先从集合中选择并安装一个插件，然后在 Claude Code 中调用其技能、代理或斜杠命令。git 处理常规提交、仓库管理和 GitFlow 分支；git-agent 的 @git-agent 会检查 gitignore 完整性、提交范围新鲜度、TruffleHog 密钥泄漏和共同变更索引健康状况。github 提供质量门禁、TDD 工作流、验证以及由 /github:review-pr 执行的持续 CI 与审查意见监控；refactor 和 swiftui 分别处理跨文件重构和 SwiftUI Clean Architecture 审查。研究与内容插件可运行 autoresearch 迭代循环、STORM 式检索写作、图像生成、Remotion 或 HyperFrames 视频制作，以及营销和办公文档工作流。其他插件可通过 Gemini Managed Agents、pi、Feishu/Lark CLI、KiCad 9.0、OpenSCAD、DeepWiki、Context7、Exa、Git clone 和网页搜索执行专门任务并返回相应工件。
- 使用 Claude Code 管理代码库的开发者，希望用质量检查生成常规化、原子化提交。
- 维护 GitHub 项目的团队，需要持续观察 PR 的 CI 状态并分类处理审查意见。
- 采用 BDD 或 TDD 的工程团队，希望把检查清单、验证和开发流程编排安装到 Claude Code。
- iOS 或 macOS 开发者，需要依据 Clean Architecture 和 SwiftUI 最佳实践审查代码。
- 研究人员或技术写作者，需要运行可恢复的多视角检索、提纲和长文生成流程。
- 硬件设计人员，需要通过 KiCad 9.0 或 OpenSCAD CLI 生成制造文件、检查报告或三维模型。
如何安装或部署这个 Agent？
需要 Claude Code v0.6+。源材料给出了各插件的直接安装命令，但没有说明首次使用时如何添加 frad-dotclaude 市场；如果该市场尚未配置，这一步的准确命令并未提供。选择所需插件并执行对应命令，例如：
claude plugin install git@frad-dotclaude安装 GitHub 工作流插件：
claude plugin install github@frad-dotclaude安装完整性扫描与原子提交插件：
claude plugin install git-agent@frad-dotclaude各插件可能还有单独依赖。例如 antigravity 明确要求 GEMINI_API_KEY 和 uv，而硬件插件调用 KiCad 9.0 或 OpenSCAD CLI。
如何使用这个 Agent？
安装后，在目标工作区的 Claude Code 会话中调用该插件公开的代理、技能或斜杠命令。以下是源材料明确列出的首次可用入口；README 没有提供这些命令的参数示例：
@git-agent它会运行 Git 健康扫描。原子提交、相关文件查询和工作区初始化分别使用：
/git-agent:commit
/git-agent:related
/git-agent:init持续监控 GitHub PR 的 CI 和审查意见：
/github:review-pr手动整理记忆或把任务委派给 pi：
/memory:consolidate
/pi:delegate首次使用依赖外部服务的插件前，应先满足该插件注明的条件；例如 antigravity 需要 GEMINI_API_KEY 和 uv。
这个 Agent 有哪些优点和局限？
- 插件按职责拆分，可只安装 Git、GitHub、重构、研究、硬件或界面设计等需要的部分。
- 开发流程覆盖面具体，包括 GitFlow、语义化版本、TDD/BDD、PR 持续监控和 TruffleHog 密钥泄漏检查。
- 不仅处理代码，还提供 KiCad/OpenSCAD 制造输出、图像与视频生成、长文研究和主动记忆等专门工作流。
- 多个插件公开了明确的斜杠命令，便于从 Claude Code 会话直接触发。
- 核心交付形式绑定 Claude Code，没有文档证明可原样用于 ChatGPT、Codex 或独立服务。
- 源材料未给出添加
frad-dotclaude市场的命令，因此全新环境的完整引导存在缺口。 - 不同插件依赖差异较大；例如 Antigravity 需要
GEMINI_API_KEY和uv，硬件流程需要 KiCad 9.0 或 OpenSCAD。 - 插件会涉及外部模型、搜索、CLI 和远程沙箱，但源材料没有统一说明费用、权限、数据处理或失败恢复策略。
- README 的徽章显示 23 个插件，而介绍文字称 22 个，集合规模的元数据不一致。
这个 Agent 与同类方案有什么区别？
部分内容来自或对接已有项目：mattpocock 是 mattpocock/skills v1.2.3 的分支并增加自改进检查清单；storm 是 Stanford STORM 两阶段研究写作流程的 Claude 原生移植；pi 插件并不替代 Claude Code，而是把执行或只读审查委派给 dev/pi。选择这些插件的理由主要是将相应流程封装为 Claude Code 可安装组件，而不是采用上游项目的原始使用方式。
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| Frad 的 Claude Code 插件集 当前 | 45 · 缺口较多 | Agent 插件 / 技能免费 | ★ 593 | 3 天前 | JavaScript | Claude Code |
| 工作流插件：Claude Workflow V2 | 50 · 缺口较多 | Agent 插件 / 技能免费 + 模型费 | ★ 1.4k | 3 个月前 | Python | Claude Code |
| OpenCode Swarm | 74 · 存在缺口 | Agent 插件 / 技能免费 + 模型费 | ★ 478 | 1 天前 | TypeScript | — |
| ECC 工程智能体工作台 | 66 · 存在缺口 | Agent 插件 / 技能免费版 + 付费版 | ★ 268k | 2 天前 | JavaScript | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示部分安全意识：git-agent 的钩子限制原始提交和独立暂存，memory 声称隐私清理，git-agent 扫描密钥泄漏，autoresearch 会逐项征求决定，远程 Antigravity 也明确提到 API 密钥和远程沙箱。扣分在于这些措施只覆盖个别插件；仓库整体缺少统一的最小权限、确认策略、数据流清单、凭据生命周期、网络目的地、外部写操作边界及恢复方案。CI 依赖和 GitHub Actions 使用浮动版本，未见锁定、漏洞扫描或供应链缓解。来源对部分 fork/mirror 有署名，但并非所有插件都有清晰出处。
CI 会发现插件、校验清单并在存在测试时运行 pytest；所给测试还覆盖命令匹配边界、无 jq 回退和包解耦。不过无测试的插件会直接跳过，README 的“23”徽章与“22 plugins”文字自相矛盾，且材料未给出整个集合的依赖清单、兼容性矩阵或统一错误消息规范。不能从静态文件推断运行可靠性。
README 覆盖 Git、GitHub、重构、研究、办公、硬件、营销和界面等明确场景，对普通开发工作有较好的受众定位。git-agent 测试展示了较精确的命令触发和误匹配防护。但仓库级能力边界、各插件适用条件、冲突处理和降级行为不完整；环境要求仅零散出现，如 Claude Code v0.6+、uv、API 密钥、KiCad 9.0，缺少统一的平台与版本兼容说明。
顶层 README 按插件组织并为每个插件提供一致的安装命令，也说明新增插件的基本结构；命名及清单校验有测试支持。MIT 正文完整且与元数据一致，因此许可满分。扣分在于缺少集中示例、FAQ、已知限制、完整版本策略和变更日志；维护责任仅能从版权名和新增插件步骤推断，没有明确维护者渠道、支持承诺或发布流程。
插件覆盖面广，描述了可直接使用的提交、评审、研究、文档、图像和硬件产物，部分能力如 Git 钩子守卫和多种代码上下文检索具有明显增量价值。扣分在于多数效果是 README 概述，缺少代表性输入输出、质量基准、工作量节省证据及资源、API、模型调用或远程执行成本说明。
README 的部分陈述可由 CI 和测试交叉支持，例如插件结构校验、git-agent 的提交守卫及 git 与 git-agent 的解耦。其余大量能力只在目录简介中出现，未提供相应实现文件、测试或示例；宣传性描述也未系统地区分已验证事实、设计目标与推断，因此追踪性和事实—推断分离仅属有限。
- 这是低置信度静态审查；未执行插件、测试或远程服务，不能确认运行结果、确定性或实际正确性。
- 多个插件可提交代码、操作 GitHub、调用远程代理、生成媒体或访问协作系统，但材料未给出统一的确认、权限和外部数据传输策略。
- git-agent 钩子在输入为空、JSON 损坏或缺少 command 字段时明确 fail-open，可能让预期的提交保护被绕过。
- CI 对没有测试目录的插件直接跳过，且依赖安装与 Actions 引用未锁定到不可变摘要；不能把 CI 存在等同于全仓库安全或测试覆盖。
- README 的插件数量存在 23 与 22 的不一致，安装前应核对实际 marketplace 清单和每个插件的依赖、权限及来源。
常见问题
必须一次安装整个集合吗？
它能在 ChatGPT、Codex 或普通终端代理中直接使用吗？
所有插件都不需要 API 密钥吗？
antigravity 明确要求 GEMINI_API_KEY；图像插件也会连接 Gemini 或 OpenAI 兼容端点，但源材料没有说明其凭据配置步骤。