Choose between a Skill, an AGENTS.md rule, and a plain prompt

You’ve now built a procedure Codex runs by itself. But “write something down so Codex does it right” describes three different containers, and reaching for the wrong one is a common way to fight the grain. This lesson is the decision: when the import procedure is genuinely a Skill, when the next thing you want to capture is really an AGENTS.md rule, and when it shouldn’t be written down at all.

Skill vs rule: what Codex does vs what it knows

This is the distinction that matters most, and the one most often gotten wrong. Both a Skill and AGENTS.md are “context you write down once” — but they load differently and they answer different questions.

• An AGENTS.md rule is a standing fact. “Money is integer cents, never float.” “The category list is groceries, rent, subscriptions…” Codex reads AGENTS.md automatically before every run, so a rule is always in view — it shapes everything Codex does, whether or not you mention it.
• A Skill is a procedure. “To onboard a new bank’s CSV: read a sample, map the columns, normalise dates, convert to cents, write an importer.” It loads only when the situation fires, runs as a sequence of steps, and is silent the rest of the time.

The test: can you run it? “Always store money as cents” isn’t something Codex runs — it’s a constraint it should hold at all times. That’s a rule. “Import a new bank’s CSV” is a multi-step thing Codex does on a specific occasion. That’s a Skill. Put a standing fact in a Skill body and it only applies when the Skill happens to fire — exactly when you don’t want a money rule to be conditional. Put a multi-step procedure in AGENTS.md and it’s loaded into every run whether you’re importing a bank that day or not, paying full context cost to sit idle.

You saw the two cooperate in the last lesson: the cents-not-float rule lives in AGENTS.md as a standing constraint and the import Skill restates it at the one step where it bites. That’s not redundancy — the rule governs everything; the Skill puts the reminder at the point of maximum risk. Rules are the floor; a Skill can reinforce the floor where a procedure tends to trip over it. The discovery walk and the rest of how AGENTS.md loads are back in the rules chapter.

Skill vs plain prompt: does it repeat?

The other failure is over-engineering — packaging something as a Skill that didn’t need packaging. The honest test is repetition:

• One-off, or rare and varied → a plain prompt. If you’re parsing one weird file once, just ask Codex to do it in the conversation. Writing a SKILL.md for it is busywork — if the SKILL.md takes longer to write than the task it automates, you’ve over-built.
• Same multi-step procedure, again and again → a Skill. The import job cleared this bar the moment you noticed you were re-narrating the same five steps for each new bank. That recurring re-explanation is the entire signal.

A good way to arrive at a Skill is to not write it first. Do the job by hand in a normal session — onboard the first new bank as a plain prompt. When you find yourself doing the same thing a third time, you’ll already know the exact steps, the failure modes, and the wording that triggers it. Then the SKILL.md writes itself, and it’s grounded in a procedure you’ve actually validated rather than one you guessed at.

The three-way test

When you’re about to write something down for Codex, ask in this order:

1. Is it a fact Codex should always hold, or a procedure it runs on occasion? Always-on constraint or domain fact → AGENTS.md rule. A multi-step thing it does at a specific moment → Skill.
2. Does the procedure actually repeat? A genuine, recurring, multi-step routine → Skill. A one-off or rarely-the-same task → just prompt it; don’t build a file.
3. If it’s a Skill, should Codex fire it on its own? Harmless if mistimed, like our preview-first import → leave implicit invocation on, let it fire on recognition. Expensive, slow, or state-changing → take it off the automatic menu with the per-Skill policy from the last lesson.

Keep those straight and you’ll almost always reach for the right container. Rules are what Codex knows; Skills are what it does; a plain prompt is for what it does once. The quiet mistake is cramming a standing fact into a Skill body, where it only loads when the Skill fires, instead of into AGENTS.md where it’s always in view — so when in doubt, ask whether the thing is a fact or an action.

Where this leads

Skills close a real gap: Codex now owns the procedures you used to narrate, firing them when the situation calls. But a Skill can only orchestrate what Codex can already reach — your files, your shell, the importers in the repo. The import procedure stays inside budgetcli because everything it touches is in budgetcli. The moment a procedure needs to touch a system outside the repo — pull a live exchange rate for a foreign-currency transaction, query an external service — or needs a check that runs every time, deterministically, no matter what Codex decides, you’ve reached the edge of what a Skill alone can do.

That’s the next chapter. Extending Codex gives the agent reach into external systems with MCP servers — that exchange-rate API your transactions have been waiting on — and deterministic gates that fire on their own with hooks, so a guardrail like “never write to the real ledger” holds regardless of what any Skill or prompt asks for. Skills taught Codex your procedures; next you give it new things to do them to, and new ways to draw a hard line.