Skip to main content

codex-delegation

How to delegate implementation tasks to workers via Codex MCP or Task sub-agents. Use when executing tasks that require code implementation.

Source facts

Repository
DUTSTECH/ceoralph
Last source activity
February 8, 2026 at 23:35
Detected SKILL.md language
English
Stars
1
Forks
0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
codex-delegation
description
How to delegate implementation tasks to workers via Codex MCP or Task sub-agents. Use when executing tasks that require code implementation.
# Worker Delegation Skill This skill defines how the CEO (Claude) delegates tasks to workers. Workers can be either Codex MCP (GPT) or Claude Task sub-agents. ## Executor Selection The executor is determined by priority: 1. `--executor` argument (explicit override) 2. `./specs/.ralph-executor.json` (saved config from `/ceo-ralph:setup`) 3. Runtime detection: check if `mcp__codex__codex` tool exists 4. Default: `auto` (try Codex, fall back to Task) ### Codex MCP Executor - Tool: `mcp__codex__codex` - Runs GPT models in a sandboxed environment - Best for: code generation, file manipulation - Requires: Codex CLI installed + authenticated ### Task Sub-agent Executor - Tool: `Task` with `subagent_type: "general-purpose"` - Runs Claude sub-agents (model: sonnet) - Best for: when Codex is unavailable, or for Claude-native tasks - Requires: nothing (built into Claude Code) ## When to Delegate Delegate to workers when: - Task is implementation-focused (writing code) - Task has clear acceptance criteria - Task doesn't require strategic decisions - Task is scoped to specific files Do NOT delegate when: - Task requires architecture decisions - Task is a [VERIFY] checkpoint (delegate to qa-engineer instead) - Task requires user interaction - Task involves research or analysis ## Preparing Context Packages ### Minimal Context Package ```json { "taskId": "1.1", "task": { "title": "Task title", "do": "What to do", "doneWhen": "Completion criteria", "acceptance": ["Criterion 1", "Criterion 2"] } } ``` ### Full Context Package ```json { "taskId": "1.1", "task": { "title": "Implement user login form", "do": "Create login form component at src/components/Login.tsx", "doneWhen": "Form renders with email/password fields and validation", "acceptance": [ "Form has email input with validation", "Form has password input with masking", "Submit button triggers onSubmit handler", "Shows validation errors" ] }, "files": { "src/components/Form.tsx": { "path": "src/components/Form.tsx", "content": "// Existing form component for reference...", "language": "typescript", "relevantSections": [ { "startLine": 10, "endLine": 50, "description": "Form pattern" } ] } }, "design": { "architecture": "React functional component with hooks", "patterns": ["controlled inputs", "form validation", "error display"] }, "constraints": [ "Follow existing Form component pattern", "Use project's validation library (zod)", "Match existing styling approach" ], "workingDirectory": "/path/to/project", "commitPrefix": "feat(auth)" } ``` ## Context Optimization ### File Selection 1. Include files directly mentioned in task 2. Include pattern files from same directory 3. Include type definitions if TypeScript 4. Limit to ~5 files maximum 5. Use relevant sections, not entire files ### Context Pruning If context is too large: 1. Extract only relevant functions/classes 2. Remove comments and whitespace 3. Summarize repetitive patterns 4. Reference design.md instead of repeating ## Delegation Protocol ### Step 1: Prepare ```markdown I am preparing to delegate Task {id} to a worker. **Task**: {title} **Executor**: {codex|task-agent} **Files to include**: {list} **Constraints**: {list} ``` ### Step 2: Delegate **Codex MCP:** ``` mcp__codex__codex({ prompt: "<spec-executor instructions>\n\nTask: <task block>\n\nContext: <files>", sandbox: "workspace-write" }) ``` **Task sub-agent:** ``` Task({ subagent_type: "general-purpose", model: "sonnet", prompt: "<spec-executor instructions>\n\nTask: <task block>\n\nContext: <files>\n\nIMPORTANT: Output TASK_COMPLETE when done." }) ``` ### Step 3: Monitor ```markdown [<executor>] Task {id} delegated. Status: {pending|running|completed|failed} ``` ### Step 4: Receive ```markdown Received result from worker. Signal: {TASK_COMPLETE|TASK_BLOCKED|NO_SIGNAL} Files modified: {count} ``` ## Handling Worker Output ### On TASK_COMPLETE 1. Parse file modifications 2. Verify "Done when" criteria 3. Update delegation log 4. Proceed to next task ### On TASK_BLOCKED 1. Read block reason 2. Assess if CEO can unblock 3. If yes: Provide guidance and retry 4. If no: Escalate to user ### On NO_SIGNAL 1. Check if output looks complete 2. If yes: Treat as soft completion, verify carefully 3. If no: Retry with explicit signal instruction ## Retry Strategy When retrying: ```json { "previousAttempts": [ { "attempt": 1, "executor": "codex", "feedback": "Missing validation on email field", "issues": [ "Email input lacks validation", "Error messages not displayed" ] } ] } ``` ### Feedback Quality Good feedback: - "In Login.tsx line 23, add email regex validation" - "The onSubmit handler doesn't prevent default" Bad feedback: - "Fix the validation" - "It doesn't work" ## Delegation Logging Every worker dispatch is logged to `./specs/$spec/.ralph-delegation.json`. See `schemas/delegation.schema.json` for the full schema. Each worker entry tracks: - Worker ID, task ID, executor type - Start/complete timestamps, duration - Result signal, summary, files changed - Commit hash Aggregate stats are updated after each worker completes.
View on GitHub