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.

Quellinformationen

Repository
DUTSTECH/ceoralph
Letzte Quellaktivität
8. Februar 2026 um 23:35
Erkannte Sprache von SKILL.md
Englisch
Sterne
1
Forks
0

Installationsoptionen

Standardmäßig ist der Prompt ausgewählt, der zuerst die Quelle prüft. Sie können zu einem direkten Befehl wechseln oder eine lokale Kopie herunterladen.

Quelldateien prüfen

Lesen Sie SKILL.md und alle von SkillsMP angezeigten Begleitdateien, bevor Sie sich für eine Installation entscheiden.

SKILL.md wird angezeigt

SKILL.md
Quellanweisungen · Schreibgeschützte Vorschau
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.
Auf GitHub ansehen