10 条命令不是凭空写的：先找了 3 个开源轮子，再决定原创什么

整理说明：本文是 2026 年 10 月 1 日一次真实选型记录的整理，不是今天新跑的测试。所写星数、更新时间、许可证均来自当时的筛选记录；星数是当时的快照，本文不改写成今天的数字。

先立规矩：动手前先找轮子

做这个包之前，定下的规矩是：能想到的需求，99% 早就有人做过。正式动手之前，先去 GitHub 搜相关的开源项目，按更新时间、Star 数量、许可证、技术栈、部署难度筛出最合适的几个，做权衡分析：哪个能直接用、哪些功能需二次开发、改造成本与潜在风险。只改需要改的部分，不凭空造轮子。

这篇就是当时筛出来的 3 个轮子，以及最后定下的分工：结构借鉴、内容原创。

轮子 1：wshobson/agents，40,125 星，最重参考

当时记录：2026 年 9 月 29 日更新，MIT 许可证，技术栈是 Markdown 加 YAML frontmatter 加 .claude-plugin/marketplace.json，部署难度为零，因为是纯文本。

它是一个多 CLI 插件市场，覆盖 Claude Code、Codex、Cursor、OpenCode、Copilot、Antigravity、Pi，skills/ 目录组织。

能借什么：多 CLI 兼容写法——本包要求同时装 Claude Code 与 Codex，这一点直接对上；还有 skills 目录结构和 marketplace.json 插件格式。

不能直接用：全英文；且它是免费开源生态，付费包必须中文原创。

轮子 2：wshobson/commands，2,645 星，已归档

当时记录：2026 年 9 月 30 日归档前最后同步，MIT 许可证，技术栈是 Markdown workflows。workflows/ 下面有 feature-development、full-review、git-workflow、security-hardening 等完整工作流。

能借什么：工作流步骤设计的骨架——/review 可以参考 full-review 的检查维度组织，/commit 可以参考 git-workflow 的提交规范。只借思路与结构，不复制大段英文原文。

注意：MIT 允许商用改写，但为付费包干净起见，中文内容全部重写，仅致谢。

轮子 3：chenxiachan/xhs-claude-skills，420 星，中文直接参考

当时记录：2026 年 8 月 14 日更新，MIT 许可证，技术栈是 Markdown skills，中英双语 README。内容是中文语境的 Claude skills，小红书到 Obsidian 的笔记流。

能借什么：中文 prompt 的语气与用词范式、中英双语 README 的组织方式。它也证明了一件事：中文 skill 的需求真实存在且有人 star。

权衡结论：没有一个能直接用

三个轮子全是 MIT，可以商用；但没有一个能直接解决“中文 CLI 工作流包”——差异化空间确认存在。

当时定下的策略是：结构借鉴加内容原创。用 agents 的多 CLI 目录组织与 frontmatter 约定，用 commands/workflows 的工作流步骤思路，用 xhs-claude-skills 的中文表达范式；10 个 command 的中文 prompt 全部原创编写。部署难度均为零，纯 Markdown 加 shell，与本包技术栈一致，无需二次开发适配。

风险也当时就写下来了：上游均为英文生态，中文改写质量靠自测保证——每个 command 在 Claude Code 与 Codex 里实测调优是硬要求，不许跳过。这一点后来在 D1、D2 实测里确实兑现了，前面几篇写过，不重复。