The plugin had a single named agent (`agents/code-reviewer.md`) used by two skills, while every other reviewer/implementer subagent in the repo is dispatched as `general-purpose` with the prompt template living alongside its skill. That asymmetry had no upside and several costs: - Two sources of truth for the code review checklist (the agent file and `requesting-code-review/code-reviewer.md`), both drifting independently. - `Codex` users could not use the named agent directly; the codex-tools reference doc had a workaround section explaining how to flatten the named agent into a `worker` dispatch. - No third-party reliance on `superpowers:code-reviewer` inside this repo. Changes: - Merge `agents/code-reviewer.md` (persona + checklist) and `skills/requesting-code-review/code-reviewer.md` (placeholder template) into a single self-contained Task-dispatch template, matching the shape of `implementer-prompt.md`, `spec-reviewer-prompt.md`, etc. - Update `skills/requesting-code-review/SKILL.md` and `skills/subagent-driven-development/code-quality-reviewer-prompt.md` to dispatch `Task (general-purpose)` instead of the named agent. - Drop the now-obsolete "Named agent dispatch" workaround sections from `codex-tools.md` and `copilot-tools.md` — superpowers no longer ships any named agents, so those instructions documented nothing. - Delete `agents/code-reviewer.md` and the empty `agents/` directory. Tier 3 coverage for the change: a new behavioral test `tests/claude-code/test-requesting-code-review.sh` plants real bugs (SQL injection, plaintext password handling, credential logging) into a tiny project, runs the actual `requesting-code-review` skill against the working tree, and asserts the dispatched reviewer flags every planted issue at Critical/Important severity and refuses to approve the diff. Verified end-to-end on this branch: - The new test passes (5/5 assertions; reviewer caught all planted bugs and several others). - The existing SDD integration test still passes (7/7 subagents dispatched, all as `general-purpose`; spec compliance still rejects extra features; produced code is correct). - Session JSONLs confirm zero remaining `superpowers:code-reviewer` dispatches anywhere in the SDD pipeline.
2.4 KiB
Codex Tool Mapping
Skills use Claude Code tool names. When you encounter these in a skill, use your platform equivalent:
| Skill references | Codex equivalent |
|---|---|
Task tool (dispatch subagent) |
spawn_agent (see Subagent dispatch requires multi-agent support) |
Multiple Task calls (parallel) |
Multiple spawn_agent calls |
| Task returns result | wait_agent |
| Task completes automatically | close_agent to free slot |
TodoWrite (task tracking) |
update_plan |
Skill tool (invoke a skill) |
Skills load natively — just follow the instructions |
Read, Write, Edit (files) |
Use your native file tools |
Bash (run commands) |
Use your native shell tools |
Subagent dispatch requires multi-agent support
Add to your Codex config (~/.codex/config.toml):
[features]
multi_agent = true
This enables spawn_agent, wait_agent, and close_agent for skills like dispatching-parallel-agents and subagent-driven-development.
Legacy note: Codex builds before rust-v0.115.0 exposed spawned-agent
waiting as wait. Current Codex uses wait_agent for spawned agents. The
wait name now belongs to code-mode exec/wait, which resumes a yielded exec
cell by cell_id; it is not the spawned-agent result tool.
Environment Detection
Skills that create worktrees or finish branches should detect their environment with read-only git commands before proceeding:
GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
BRANCH=$(git branch --show-current)
GIT_DIR != GIT_COMMON→ already in a linked worktree (skip creation)BRANCHempty → detached HEAD (cannot branch/push/PR from sandbox)
See using-git-worktrees Step 0 and finishing-a-development-branch
Step 1 for how each skill uses these signals.
Codex App Finishing
When the sandbox blocks branch/push operations (detached HEAD in an externally managed worktree), the agent commits all work and informs the user to use the App's native controls:
- "Create branch" — names the branch, then commit/push/PR via App UI
- "Hand off to local" — transfers work to the user's local checkout
The agent can still run tests, stage files, and output suggested branch names, commit messages, and PR descriptions for the user to copy.