Skills, tasks, and scheduled help (as product offers)

Monday morning. You finally have Codex pointed at a real repo. Parts 1 and 2 of this series got you opening the coding surface and exploring without thrashing files. Now a coworker pings you: “Did you try skills yet?” Another link says “tasks.” A third screen shows Automations or scheduled help that will “keep things moving while you sleep.” The names sound like a product catalog, not a workflow. You feel the usual agent FOMO: if you do not wire the fancy layer, you are using Codex “wrong.”

You are not. The power-ups only help after you can run a small change, read the diff, and undo safely. This is Part 3 of the ChatGPT Codex / coding tutorial. We map skills, tasks, and scheduled / automated help the way OpenAI packages them as product offers: what each is for, how they sit on a complexity ladder, and when to leave them off. Labels move (skills, automations, scheduled tasks, background runs). The judgment does not. If Chat vs Work vs Codex still blurs, keep the ChatGPT product map open. Everyday chat habits live in the ChatGPT everyday tutorial. Office-style agents stay in the ChatGPT Work tutorial. Account and privacy foundations stay in Learn ChatGPT from scratch.

What you’ll learn

A plain map of skills, tasks, and scheduled help without treating marketing names as gospel
A complexity ladder from ask-only up to scheduled jobs, and where most people should sit this month
When a reusable skill is better than re-pasting the same playbook every session
How to define a one-shot task so Codex does not invent a second project
Why unattended high-stakes work (deploys, production data, force-pushy git) is a bad first automation
A worked “triage only” schedule example and a refuse list you can paste into team notes

UI strings, plan gates, and exact menu paths change. Re-check OpenAI’s Codex product pages and ChatGPT help the week you train a team. This post teaches structure and risk, not a frozen screenshot tour.

Three product offers, one coding surface

Codex is the coding agent side of ChatGPT: repos, diffs, commands, multi-step code work. On top of “chat with me about this file,” OpenAI has been shipping extension points so the agent can reuse workflows, take a defined job, and sometimes run on a clock. In plain English:

Offer (plain name)	What it feels like	Good first use	Bad first use
Skills	Reusable playbooks the agent can load (checklists, domain steps, how you review PRs)	Same review or release checklist every week	Encoding secrets or “always push to main”
Tasks	One job you define with a goal, scope, and done condition	“Add regression test for filter X in these two files”	“Make the app better” with no bounds
Scheduled / automated help	Repeating or background runs (triage, reports, routine checks)	Draft a daily issue triage summary for humans	Unattended production deploy or secret rotation

OpenAI has described skills as a way to extend Codex beyond pure code generation into structured work (research, docs, repeatable procedures) using packaged instructions and tools. Automations (and related scheduled patterns in ChatGPT Work and the Codex app story) are framed as background or repeating work: issue triage, monitoring-style jobs, routine reporting. ChatGPT also has Scheduled Tasks in the broader product for actions that run once, on a schedule, or when something changes. Names will keep shifting. When you open the app, match the behavior to this table, not the marketing headline.

Hedge on purpose: If your screen says Automations, Skills, Tasks, Scheduled tasks, or something newer, map it to reusable playbook vs one job vs run on a clock. Train judgment, not a brand string.

The complexity ladder (climb in order)

Most Codex pain is skipping rungs. People jump from “hello world in chat” to “nightly agent with write access” because the UI makes the top look one click away. Use this ladder as a personal (and team) gate.

Rung	You can already…	You earn the next rung when…
1. Ask only	Explain a file, map entry points, list risks	You stop the agent before edits when you only needed a tour
2. Edit one file	Ship a tiny, reviewed change in a branch	Diff matches the ask; you can undo with git
3. Multi-file + tests	Change a few files, run the real test command yourself	You catch scope creep before commit (Part 4)
4. Skills / tasks	Reuse a playbook or run a well-bounded job without re-explaining house rules	The playbook is versioned, secret-free, and reviewable
5. Scheduled jobs	Repeat low-blast-radius work on a clock with human review of outputs	Failure mode is “noise in a doc,” not “prod is down”

If you are still shaky on rungs 1 to 3, Part 1 and Part 2 of this series are not optional homework. Skills and schedules amplify whatever habit you already have. A crisp explorer becomes a crisp automator. A sloppy explorer becomes a scheduled mess factory.

Skills: reusable workflows, not magic memory

A skill is a packaged way of working the agent can apply when relevant: how your team reviews PRs, how you generate a changelog, how you open a data pipeline ticket, how you write commit messages for this monorepo. In the broader Agent Skills idea (shared across tools, including OpenAI’s Codex framing), you put instructions, maybe scripts or references, into something the agent can load instead of you pasting a wall of text every Monday.

Think of it like a kitchen recipe card. The card is not the meal. It is the reliable sequence so two cooks do not invent two kitchens. Codex still needs a repo, permissions, and a human who tastes the food (Part 4: review).

What belongs in a skill

Checklists that almost never change (PR review steps, release gate, security notes for this stack)
Domain language (“order” means customer order, not purchase order, in this service)
Preferred commands: how to run tests, lint, typecheck in this repo
Hard no’s: never commit secrets, never force-push shared branches, never reformat the monorepo for a one-line fix

What does not belong in a skill

API keys, tokens, production connection strings
One-off ticket context that will be wrong next week
“Always merge without review” or “skip tests if they fail”
Personal grudges about coworkers, or political company drama (it will leak into tone and priorities)

If you already keep standing rules in something like an AGENTS.md, project config, or team doc that Codex discovers, skills are the on-demand playbooks that would bloat always-on memory. Standing facts stay short and always true. Long procedures become skills. Same split you would use in any coding agent: always-on vs load when needed.

Mini skill sketch (copy and adapt)

You do not need the exact file format from today’s UI to practice the content. Draft the body first. Ship packaging later.

# skill: pr-review-lite
# when: reviewing a Codex or human PR for this service

## Goal
Review for correctness, scope, and safety. Prefer small comments over rewrites.

## Always do
1. Summarize the intended change in 2-3 sentences.
2. List files that look outside the ticket.
3. Flag auth, money, PII, migrations, and config.
4. Require tests for bug fixes.
5. Never approve force-push or secret commits.

## Never do
- Rewrite style across the monorepo.
- Delete failing tests to go green.
- Invent product requirements not in the ticket.

## Output shape
- Summary
- Risks
- Suggested tests
- Approve / request changes / block

When the product lets you attach this as a named skill, you stop retyping the ritual. Until then, paste it at the start of a review session. The value is the discipline, not the chrome.

Tasks: one job you define

A task is a bounded assignment: goal, inputs, out of scope, done condition. Codex is good at filling space. If you leave space, it will decorate the empty walls. Tasks exist so you fill the walls with constraints first.

Task template that survives contact with a model

Goal: <one concrete outcome>
Context: <ticket link or 3 facts>
In scope files/dirs: <paths>
Out of scope: <paths, refactors, deps>
Tests: <exact command or “add unit test in X”>
Done when: <observable condition>
Do not: <reformat, force-push, touch secrets, …>

Filled example for a realistic small job:

Goal: Fix dashboard filter so archived accounts appear only when
includeArchived is true.
Context: Bug report from support; reproduced on staging.
In scope files/dirs: src/dashboard/query.ts, src/dashboard/query.test.ts
Out of scope: utils/, package.json, other pages, dependency upgrades
Tests: npm test -- src/dashboard/query.test.ts
Done when: unit test covers includeArchived true/false; manual note
for staging check is written in the PR body draft.
Do not: reformat unrelated files; delete tests; edit .env*

That task is boring on purpose. Boring tasks produce reviewable diffs. “Improve the dashboard experience” is a product roadmap, not a Codex task.

Tasks vs chat vs Work

Surface	Best for	Wrong for
Chat	Wording, explaining, light planning with no repo write	Multi-file code changes you need to ship
Work	Office artifacts: decks, sheets, multi-file docs, app connectors	Primary path for git-native code review culture
Codex task	Repo-bound code jobs with diffs and tests	Press-release rewrites and pure meeting notes

If you find yourself writing a Codex task that never touches a repo, you may be in the wrong mode. The product map series exists so you do not force every job through the coding agent because it feels “more advanced.”

Scheduled help: useful, not unattended high stakes

Scheduled or automated runs are where people get starry-eyed. “Codex will triage issues every morning.” “It will watch CI.” “It will keep the docs fresh.” Those can be real. They can also open a second shift of silent failure if nobody owns the output.

OpenAI’s public framing for Codex automations and ChatGPT scheduled patterns includes routine work: issue triage, monitoring-style jobs, reports, documentation updates, actions that fire once or on a schedule. That is a productivity story. It is not a permission slip to unplug your brain from production.

The blast-radius test

Before you schedule anything, finish this sentence:

“If this run goes wrong at 3 a.m. and nobody reads the log until 9 a.m., the worst realistic outcome is ___.”

If the blank is “a messy draft in a private doc” or “a noisy Slack message we can mute,” you may have a candidate. If the blank is “production deploy,” “customer data export,” “credential rotation,” “mass close of tickets,” or “force-push to main,” stop. That is not a beginner automation. That is an incident generator with a calendar invite.

Good first schedules

Draft a morning summary of new GitHub issues labeled bug into a team doc (human still triages)
List flaky test names from the last CI day into a checklist (human still prioritizes)
Generate a weekly “docs that mention removed endpoints” report (human still edits docs)
Remind you to renew a staging cert (notification only)

Refuse list (paste into team policy)

No unattended production deploys or migrations
No unattended writes to customer production data
No storing secrets inside skill text, task text, or schedule prompts
No auto-merge to protected branches
No force-push, history rewrite, or mass branch deletion on a clock
No “fix CI by deleting tests” loops, ever

Worked example: a low-risk morning triage automation

Imagine a small product team with a noisy issue tracker. You want Codex (or ChatGPT scheduled help wired to the same intent) to prepare a human-readable triage brief at 8:30 a.m., not to close tickets for you.

Schedule: weekdays 08:30 local
Goal: Draft a triage brief for issues created in the last 24 hours
      with label bug or support.
Output: Markdown in team/triage-drafts/YYYY-MM-DD.md (or a private doc)
Include for each issue:
  - title, link, reporter, labels
  - one-line guess at component (from path hints in the body)
  - severity guess: low / medium / high (with one reason)
  - whether it looks like a duplicate of an open issue (link if yes)
Do not:
  - close, reassign, or comment on issues
  - change labels
  - open PRs
  - access production systems
Done when: draft file exists; human reviews before stand-up.

What a good draft looks like (toy sample, not real issues):

Issue	Component guess	Severity guess	Notes for human
#412 filter ignores archived	dashboard query	medium	Matches last week’s support thread; needs repro steps
#413 logo blurry on retina	marketing site	low	Not product core; maybe design queue
#414 cannot login SSO	auth	high	If confirmed, page on-call; do not auto-close

Notice the automation never “fixed” login. It prepared attention. That is the product of a good schedule: better human mornings, not silent system changes.

How skills, tasks, and schedules fit together

These offers stack. They should not all turn on the same day.

Skill holds the house rules for “how we triage” and “how we review.”
Task is today’s specific job that may load that skill.
Schedule is a task (or skill-backed task) that repeats with a human review gate on the output.

A concrete chain for the filter bug from earlier:

Morning schedule drops a triage brief that flags #412.
You open a Codex task with the template bounds (two files + tests).
A pr-review-lite skill shapes the review of the resulting PR.
You still run Part 4’s loop: read diff, run tests, check secrets, check scope, human commit.

If any step feels like the agent is “the owner,” reverse it. You own merge. The agent owns drafts and proposals.

Common mistakes

Mistake	What happens	Fix
Skipping the ladder	Scheduled chaos before you can review a one-file PR	Prove rungs 1 to 3 first
Skills full of secrets	Keys leak into logs, git, or other machines	Env stores only; skills stay secret-free
Vague tasks	Huge diffs, surprise refactors, “helpful” dependency bumps	Use the task template; name out-of-scope paths
Schedule equals auto-merge	Broken main at 3 a.m.	Schedule drafts and reports, not merges
Chasing every rename	Team wiki outdated every quarter	Document behaviors, not only button labels
Using Codex for Work jobs	Awkward tools, wrong mental model	Send office artifacts to Work; keep code here

Practice this week

Write one skill body (even as a markdown note) for a review or release checklist you already retype.
Run three Codex jobs only as filled task templates. Refuse any job you cannot bound to paths and a done condition.
Design one schedule on paper that fails the blast-radius test. Redesign it until the worst case is a draft someone can ignore safely.
Only after that, turn on a real schedule if your plan and product surface support it. Watch it for a week with a named human owner.

Where this sits in the ChatGPT path

Codex is one deep track inside a longer ChatGPT curriculum on AMS:

Learn ChatGPT from scratch: product basics, plans, privacy judgment
ChatGPT product map: Chat vs Work vs Codex, models, API vs app
ChatGPT everyday tutorial: structure, verification, no auto-send habits
ChatGPT Work tutorial: multi-step office agents and result checks
ChatGPT Codex / coding tutorial (this series): open, explore, skills/tasks/schedule, review, git habits
Next after Codex: Custom GPTs tutorial for repeating non-repo playbooks shared as GPTs

Sibling coding-agent discipline on Anthropic’s side lives in the Claude Code tutorial. The tools differ. The ladder and the “no unattended high stakes” rule transfer.

Quick recap

Skills = reusable playbooks. Tasks = one bounded job. Scheduled help = repeats with a human gate.
Climb the ladder: ask → one file → multi-file + tests → skills/tasks → schedules.
Hedge renames: map UI labels to behavior, re-check official docs when training teams.
Never schedule unattended high-stakes changes. Drafts and reports first.
Part 4 is the brake: review, tests, and not trusting green checkmarks alone.

Sources

Research and further reading used for this article:

OpenAI: Codex product page (coding agents, scheduling-style routine work framing)
OpenAI: Introducing the Codex app (skills beyond code generation; Automations for scheduled background work)
OpenAI: ChatGPT for your most ambitious work (Work, Scheduled Tasks, Codex integration story; product surfaces evolve)
Agent Skills (shared skill packaging idea referenced in Codex skill messaging)
ChatGPT / Codex changelog (Learn) (desktop modes, discovery of AGENTS.md, skills, config; verify current labels)
AMS: ChatGPT product map (Chat vs Work vs Codex)
AMS: ChatGPT Work tutorial (multi-step jobs and result checks on the office agent)
AMS: ChatGPT Codex / coding tutorial (this series)
AMS: Learn (full series index)