mirror of
https://github.com/gnekt/My-Brain-Is-Full-Crew.git
synced 2026-08-26 02:04:43 +00:00
Rebuilt from scratch following Codex CLI's actual architecture (as outlined in the review on PR #26). Closes the integration gap with a proper build adapter, correct install paths, TOML agent files, and all the architectural differences documented and tested. What changed vs the previous attempt (PR #26): - Agents: build adapter generates .toml files (name/description/ developer_instructions) into dist/codex-cli/.codex/agents/ instead of copying .md files with sed transforms - Skills: installed to .agents/skills/ (correct Codex discovery path) instead of .codex/skills/ - Dispatcher: AGENTS.md uses a root-context orchestration header that works within agents.max_depth=1 constraints; named-agent routing replaced with embedded-instructions workaround for the known spawn_agents limitation (openai/codex#15250) - Tool compat: AskUserQuestion and request_user_input removed; all prompts adapted to Codex's actual tool set and approval/confirmation flow - Installer/updater: launchme.sh --platform codex-cli and updateme.sh with Codex auto-detection, creating the correct split layout (AGENTS.md + .codex/agents/ + .codex/config.toml + .agents/skills/) - Tests: new per-adapter test suite (tests/adapters/codex-cli/), install/update smoke (tests/scripts/codex-cli-install.test.sh), and a four-platform parity gate that proves Codex changes do not regress Claude Code, Gemini CLI, or OpenCode - Docs: new codex-cli.md guide, codex-migration.md for users switching from other platforms, and README/getting-started/examples updated for four-platform positioning - Bash harness: .gitattributes added to enforce LF on .sh files; harness LF-normalized so tests/run.sh works on Windows checkouts - .gitignore: .planning/ added (internal GSD workflow artifacts) Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
2.1 KiB
2.1 KiB
exclude
| exclude | |||
|---|---|---|---|
|
Codex CLI Compatibility Guide
Use this reference when source workflows mention platform-specific tools or recursion rules that do not map 1:1 to Codex CLI.
| Source concept | Codex CLI mapping | Notes |
|---|---|---|
AskUserQuestion |
Ask a direct plain-text question in chat and wait for the reply | Codex uses the root conversation for confirmations and follow-up questions. |
request_user_input |
Ask a direct plain-text question in chat and wait for the reply | Use the same root-thread confirmation flow as any other user interaction. |
Skill tool |
Follow the relevant skill instructions directly in the root context | Skills stay in the main chat; do not invent a separate Skill API. |
Agent tool |
Use spawn_agent only for bounded child tasks |
The root context keeps orchestration and integration decisions. |
max chain depth 3 |
agents.max_depth = 1 with root-only orchestration |
A child can finish one bounded task; any next step is decided back in the root context. |
.mcp.json |
.codex/config.toml |
Codex MCP and profile settings live in the TOML config. |
Flattened Workflow Example
Source workflow wording:
- Call
AskUserQuestionfor confirmation. - Use the
Skill toolfor the setup flow. - Use the
Agent toolfor a follow-up task.
Codex CLI wording:
- Ask the user directly in chat and wait for the reply.
- Keep the setup flow in the root context by following the skill instructions directly.
- If a bounded side task remains, use
spawn_agent, then return to the root context to decide what happens next.
Troubleshooting
- Child approvals surface in the child thread. Approve or deny there, then continue orchestration from the root context after the child returns.
- If a task would require deeper recursion, stop spawning children and flatten the next step into the root context or split the work into separate bounded child tasks.
- Codex custom agents live in
.codex/agents/*.toml. - Repo-scoped Codex skills live in
.agents/skills/. - MCP servers, approval policy, sandbox mode, and profiles live in
.codex/config.toml.