Codex Skills, MCP, Subagents, and Scheduled Tasks

Codex skills use SKILL.md and may include scripts or references. MCP exposes external tools or context. Subagents support delegated work on supported clients and can increase token use. Scheduled tasks depend on the configured surface and execution settings; a schedule is not evidence that a run completed.

Define the output, permissions, and owner of the task first. This guide does not create a schedule, install a connector, or connect an account. Review executable scripts and remote destinations before granting access.

A skill can hold the recurring review checklist. A bounded reviewer can inspect a completed patch without editing it. A scheduled check is useful only if the environment can reach the current project and the result has somewhere to be reviewed. MCP adds no value if every required file is already local.

• Skill output: a checklist with evidence fields, not a claim that tests ran.
• Delegated output: findings with file and behavior, not a competing patch in the same files.
• Scheduled output: run status, revision checked, failures, and required owner action. Unchanged non-actionable state should stay quiet.

1. Write the task without naming a feature: “inspect the current form and report new failures.”
2. Choose the minimum capability that can produce that output. Check client support and settings in current docs.
3. For a connector, inspect provenance, payload, and permissions. For a schedule, confirm where execution occurs and what happens when that environment is unavailable.
4. Trial the check manually with a known failure before making it recurring. Define who handles failures and how the schedule will be stopped.

The design should tell you what success and failure look like for each run. Do not promise that every task runs on a closed laptop, or interpret an installed skill as proof that its procedure was followed.

Stop when the check cannot identify the revision it reviewed, a connector requires unexplained write access, or repeated runs consume resources without an actionable result. Revisit the design instead of increasing frequency.

• Is this capability necessary for the stated output?
• Is a failed or missed run distinguishable from a clean result?
• Are budget, notifications, and stop conditions explicit?