您好👋，十分感谢您开源 AutoMCM-Pro 这样优秀的项目！
我已在学校举办的数学建模竞赛中使用 AutoMCM-Pro 辅助建模，并取得了不错的名次。后续我也打算在更多比赛中持续使用并改进这个项目，再次表示感谢🙏
我比较系统地阅读了项目内容，您对数学建模流程的理解，以及将抽象建模思想工程化为可执行工作流的能力，都令我印象很深。
我想先在 issue 中咨询一下：您是否愿意接受一个可选的 Codex 适配入口？
我提出这个想法的主要原因是可用性问题。当前 AutoMCM-Pro 和 Claude Code 深度绑定，这当然很合理，因为项目原本就是围绕 Claude Code skills、slash commands、子 Agent、claude CLI 等机制设计的。但对部分用户来说，Anthropic / Claude Code 的访问稳定性和账号可用性可能存在较大不确定性。这样一个很优秀的开源项目，如果只能依赖 Claude Code，可能会限制一部分用户的使用。
我的想法是新增一个可选的 Codex 入口，同时保持现有 Claude Code 工作流不变。
一个可能的结构如下：
AutoMCM-Pro/
├── AutoMCM_SOP.md # 现有 Claude Code SOP，保持不变
├── AutoMCM_SOP_CODEX.md # 新增：Codex 工作流 SOP
├── .claude/
│ └── skills/
│ └── auto-mcm/
│ └── SKILL.md # 现有 Claude Code 入口，保持不变
├── .codex/
│ └── skills/
│ └── auto-mcm/
│ ├── SKILL.md # 新增：Codex 入口
│ └── README.md
├── scripts/ # 尽量复用
├── templates/ # 尽量复用
└── docs/
└── codex-adapter.md # 新增：适配说明
我初步看了一下，原 skill 中有一些比较明显的 Claude Code 特性绑定，例如：
Agent(description=...) 子 Agent 调度；/auto-mcm、/draw-image 等 slash command；claude --print 启动方式；WebSearch / WebFetch 工具命名；AskUserQuestion / TodoWrite 工具命名；.claude/skills 安装结构。
这些内容如果强行抽象成通用薄适配层，可能会对原项目造成较大改动。因此我更倾向于做一个相对独立的 Codex 入口：保留 AutoMCM-Pro 原有流程思想和脚本能力，但在 Codex 版 SOP 中单独处理这些执行差异。这样可以尽量不影响现有 Claude Code 用户。
想先咨询一下您是否接受这个方向。如果您觉得可以，我可以先准备一个比较小的 PR，只新增 Codex 入口和相关文档，不对现有 .claude/ 工作流做改动。也可以先标记为 experimental，后续根据反馈再逐步完善。
如果上述表述或设计思路有不清楚的地方，也欢迎您直接指出。
最后，再次感谢您对这个项目的开源。
您好👋，十分感谢您开源 AutoMCM-Pro 这样优秀的项目！
我已在学校举办的数学建模竞赛中使用 AutoMCM-Pro 辅助建模，并取得了不错的名次。后续我也打算在更多比赛中持续使用并改进这个项目，再次表示感谢🙏
我比较系统地阅读了项目内容，您对数学建模流程的理解，以及将抽象建模思想工程化为可执行工作流的能力，都令我印象很深。
我想先在 issue 中咨询一下：您是否愿意接受一个可选的 Codex 适配入口？
我提出这个想法的主要原因是可用性问题。当前 AutoMCM-Pro 和 Claude Code 深度绑定，这当然很合理，因为项目原本就是围绕 Claude Code skills、slash commands、子 Agent、
claudeCLI 等机制设计的。但对部分用户来说，Anthropic / Claude Code 的访问稳定性和账号可用性可能存在较大不确定性。这样一个很优秀的开源项目，如果只能依赖 Claude Code，可能会限制一部分用户的使用。我的想法是新增一个可选的 Codex 入口，同时保持现有 Claude Code 工作流不变。
一个可能的结构如下：
我初步看了一下，原 skill 中有一些比较明显的 Claude Code 特性绑定，例如：
Agent(description=...)子 Agent 调度；/auto-mcm、/draw-image等 slash command；claude --print启动方式；WebSearch/WebFetch工具命名；AskUserQuestion/TodoWrite工具命名；.claude/skills安装结构。这些内容如果强行抽象成通用薄适配层，可能会对原项目造成较大改动。因此我更倾向于做一个相对独立的 Codex 入口：保留 AutoMCM-Pro 原有流程思想和脚本能力，但在 Codex 版 SOP 中单独处理这些执行差异。这样可以尽量不影响现有 Claude Code 用户。
想先咨询一下您是否接受这个方向。如果您觉得可以，我可以先准备一个比较小的 PR，只新增 Codex 入口和相关文档，不对现有
.claude/工作流做改动。也可以先标记为 experimental，后续根据反馈再逐步完善。如果上述表述或设计思路有不清楚的地方，也欢迎您直接指出。
最后，再次感谢您对这个项目的开源。