菜单
The standing workflow for any substantial change in this repo — codex alignment on the plan, sub-agents for the build, codex review of the diff, then capped tests and a live dev-bot pass. Use before starting any medium-or-larger implementation.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/protella/chatgpt-bots --skill impl-round命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | impl-round |
| description | The standing workflow for any substantial change in this repo — codex alignment on the plan, sub-agents for the build, codex review of the diff, then capped tests and a live dev-bot pass. Use before starting any medium-or-larger implementation. |
Scope a concrete plan, then run it past codex for an adversarial alignment review before any code is written. Fix the gaps it finds first.
Use the codex exec CLI (the MCP is disabled), run it in the background, and capture the session
id so the review pass can resume the same thread. It needs </dev/null or it hangs.
Dispatch sub-agents over disjoint files and coordinate with SendMessage. This keeps the
token-heavy work out of the main conversation. Don't pass an explicit mode — it stomps the
user's session permission mode.
Codex reviews the completed implementation adversarially, with file:line findings, and I review
alongside it. Ask reviewers to report everything and filter afterward; telling a reviewer to be
conservative or to report only high-severity issues makes it report less.
Don't re-run the suite or the linter a sub-agent already ran and reported with concrete numbers. Verify cheaply instead: the commit exists, the tree is clean, the diff matches the design. Re-run only when the report contradicts the diff or the agent died mid-run.
Capped pytest (run-tests skill), then a real dev-bot pass (live-bot-test skill) before the work
counts as done.
Review-driven fixes optimize for correctness and will happily trade away UX. Anything the user can see — streaming, message layout, footers and buttons, reaction behavior, status surfaces — gets surfaced as an explicit decision with alternatives, before implementation. Not as a footnote in a completion report. Technical internals don't need this.
Never on my own initiative — wait to be asked. As a teammate under an orchestrator, never
--amend; history moves beneath me and an amend has already erased another agent's authorship
once. Always a fresh commit.
