--- name: delegate-codex description: Use when the user explicitly asks to delegate a coding task to the codex harness. Return a result summary for review. license: FSL-1.1-MIT compatibility: 'Requires the pactify CLI (>= 0.13.0) and git on macOS or Linux; pactify runs harness CLIs outside the workspace, so the host must allow running `pactify sub` outside its sandbox.' --- Before using this skill, detect the CLI with `command -v pactify` and `pactify version`. Run `sh scripts/pactify-check` relative to this skill directory to check the minimum CLI version. If the CLI is missing or too old, show the user these commands and ask them to install or upgrade it. Never run these commands or any installer yourself: ```sh curl -fsSL https://raw.githubusercontent.com/agentjoey/pactify/main/install.sh | sh go install github.com/agentjoey/pactify/cmd/pactify@latest ``` The host must allow `pactify sub` outside its sandbox, since harness CLIs run outside the workspace. # Delegate to codex **If the user invoked this skill explicitly (`/delegate-codex`), always delegate — whatever the task size. The user chose the harness; do not do the work yourself instead.** Launch command (step 2 below): pactify sub run codex --write --worktree --wait 0s --json --brief-file For read-only tasks replace `--write` with `--read-only`; never pass both. Delegate only when the user explicitly asks: an explicit pactify skill invocation, or a clear request to delegate or hand off to a harness; otherwise do the work directly. Task size alone never authorizes delegation. If `PACTIFY_JOB` is set, you are already running inside a pactify job: do the task directly and never run `pactify sub run`; the CLI refuses it. agy runs only when the user explicitly invokes the delegate-agy skill; never select it on your own. Preserve the user's requested harness and access mode; harness permission restrictions still apply. Configured aliases can be used with `/delegate @alias `. Inspect `pactify sub router --json` for available aliases and preserve any route explicitly chosen by the user. 1. Write a self-contained brief using the five sections below. The callee starts cold and cannot see this conversation. Write a short title on the first line; if the user uses an issue tracker, its identifier can be included in the title. Include relevant paths, scope, access mode, numbered goals and exact acceptance commands. Known constraints and special cases must be written down: the callee cannot infer them. Before changing a rule, require checking callers, special cases and documented exceptions, and reporting those dependencies in the final reply. Do not edit existing tests to fit the new behavior unless the brief explicitly says the old behavior is wrong; name any such exception in the final reply. Require a failing regression test before each behavior change. The acceptance commands must include the project's **full** test command, not just affected packages. Forbid commits and credential access. Optionally add: "Do not spawn additional agents or write report files; put conclusions and command output in the final reply." Use this complete example as a template, replacing its paths, constraints and commands for the project: ```text Fix concurrent cache refresh ordering Background: src/cache/ expires entries on read; concurrent refreshes can serve stale data. Goals: 1. Fix refresh ordering in src/cache/ without changing its public API. 2. Add regression coverage; first run each new test and see it fail. Known constraints and special cases: Zero TTL means no expiry; preserve it. Inspect callers and document exceptions in the final reply. General constraints: Write access only in src/cache/. Do not commit or inspect credentials. Do not edit existing tests to fit the new behavior; fix the implementation instead. Do not spawn additional agents or write report files; reply with conclusions and command output. Acceptance commands: go build ./... go test ./... ``` 2. Start the launch command above from the host. Write the complete brief to a new file outside the repository, such as in the system temporary directory, and pass its path with `--brief-file`. Run each `pactify sub` command as one simple command, without heredocs, pipes, redirection or variable expansion, so host command rules can match it. Preserve requested models with `--model ` and effort with `--effort `, quoting shell arguments; never silently switch models. Quota fallback can create a new job; `sub wait` and `sub result` follow the fallback chain from the first job id to its final result. Use the returned final `jobId` for review/apply/discard. When a quota failure already left changes, automatic fallback stops. Review the diff first, then start a fresh session with `pactify sub run --worktree-from ` and a complete brief in `--brief-file`; this transfers the worktree while preserving its original base. For a legacy workspace job without a worktree, review and start a fresh workspace run instead. It exits 3 immediately with `{"jobId": ...}`: pending, not failure. Parse the job id from stdout. For any other error, report it and available models if supplied; do not blindly retry. Repeat this command while it exits 3 (pending); each timeout returns JSON with `jobId` and `status: "running"`. Parse the returned job id and preserve CLI errors: pactify sub wait --timeout 540s Exit 0 completes successfully; exit 1 reports a failed job; exit 2 reports invalid arguments. Review any terminal result, including failed jobs with changes. Do not start a duplicate job. If the host supports background commands, run the wait in the background instead and collect its result; repeat on exit 3 as needed. 3. When the job finishes, review before using or applying its changes: - Read the summary and first-line warnings (`Actual model does not match the requested model`, `Tool-call limit exceeded`, `Idle timeout`). Retrieve it again with `pactify sub result ` if needed. Only claim independent model verification when the result confirms it; full logs stay at the reported path. - If the result warns `empty final reply` (after one follow-up, or when the session ended first), handle it by access mode: For read-only, the task is not done: check `pactify sub logs `, then use `--resume ` with a short brief asking for the result. If it is still empty, rerun with another harness or model. For write, review the full diff and rerun acceptance as usual; get the handoff via `--resume `, or write it from the diff and your own checks. Preserve the original harness, cwd and access mode when resuming, and keep `--worktree` for a worktree job. - Inspect the complete diff first. Large tasks use a detached worktree based on the original HEAD; uncommitted source changes are not carried over. Read `worktreePath` and `baseCommit` from the result JSON (or `Worktree` and `Base commit` in the summary), then run: git -C diff -- git -C ls-files --others --exclude-standard Open the listed new files too: `git diff` alone does not show untracked content. - The host must personally rerun all acceptance commands, including the full test suite, in the worktree. Do not treat the callee's test report as host verification. If the host sandbox makes the worktree read-only, point tool caches such as `GOCACHE` at the system temporary directory; do not apply first just to run the tests. - Where feasible, personally try the change in the real environment: exercise the actual user flow and inspect output readability and actual model behavior when relevant. Record what was tried and what could not be verified; automated tests alone do not establish real-world behavior. - For high-risk changes involving concurrency, permissions, or data deletion, obtain an independent reviewer before approval. Give that reviewer the brief and complete diff; resolve findings and rerun acceptance. - Decide: on approval, run `pactify sub apply ` to apply without committing. Apply checks all affected paths first; related user edits or conflicts fail without partially applying. Resolve them deliberately; do not force or blindly retry. After successful apply, run `pactify sub discard ` to remove the worktree. For rework, keep it and follow step 4. To abandon, discard without apply; a running job must first be canceled with `pactify sub cancel `. 4. To request rework, do not apply or discard. Pass `--resume --worktree` on the next `run` with the id of the job being reviewed, the original `--cwd` and harness, preserving access mode, config mode and any requested model/effort. Supply a new brief in `--brief-file` and collect it with the same polling procedure in step 2. An exact id is safest; a unique prefix of the full id or its final random component also works. An ambiguous prefix fails and lists every candidate. Resume continues in the same worktree with the same base commit; the summary shows the full change across all turns. Omitting `--worktree` on resume also preserves existing isolation. Bare `--resume --worktree` still selects the most recent completed worktree session with a session id, including a failed or canceled turn; automatic legacy workspace selection requires success. With multiple resumable candidates it lists ids, titles and completion times on stderr and names the selected job. Prefer specifying the job id to avoid continuing a different task. The selected job must be finished and have a session id. Omitting the harness inherits that job's harness; an explicit harness must match. Check the returned worktree path/base commit. Do not start concurrent turns in one worktree. A discarded or missing worktree cannot resume. A legacy session cannot acquire isolation mid-session: start a fresh `--worktree` job instead. Apply and discard accept any job id in the resumed chain and affect its shared worktree; discard marks every turn as discarded. Use this rework message template, filling in concrete evidence and exact commands: ```text Continue the same task in the same worktree; the original scope and constraints still apply. Review findings: Required changes: Tests to add: Rerun acceptance: Reply with changes, command output and remaining gaps; do not commit or write report files. ``` Repeat step 3 after every rework turn; apply only after all required checks and reviews pass.