How to ask Codex for a task: provide inputs, outputs and conditions

‘Take a look at this material’ does not say whether you want a summary or a search for errors. Describe the result in one sentence and say where it will be used, such as a one-page summary for a team meeting.

If you need a file, specify its format and location. ‘Show me a table in chat’ and ‘Save a CSV file’ are different requests. If you receive only an answer when you expected a file, check whether the format was clear.

If there are several files, describe their names and roles: ‘meeting.txt is this week's note and template.txt is an example of the output format.’ This helps keep content and format distinct.

Set only the period or audience you need. There is no reason to examine an entire folder if only this month's material matters. If you do not know where the files are, ask for a list of candidates before organizing them.

Example request: ‘Find only text files in notes whose filenames contain 2026-09. Show the list of files to read first and exclude other months from this summary.’ This date is an exercise; change it to fit your material.

Use conditions to prevent mistakes that would make the result unusable. If the original must be preserved, separate the save location. If missing numbers must not be invented, ask for them to be marked as needing confirmation.

For example: ‘Do not change attendee names or dates. Leave an action item owner as undecided if none is listed.’ That makes the review criteria clear. Fixing every sentence length and step in advance can instead make the desired result harder to explain.

Distinguish drafting from actually sending an email or post. If you asked only for a draft file, verify the result within that scope.

If you want to decide on an approach first, ask for two organization methods without changing files. If the work is already defined, ask for the result file and a comparison with the original.

For work that is inconvenient to reverse, such as renaming files, you can inspect the first few proposed changes before applying them all. Not every task needs a separate approval step, but a small example helps when the criteria are unclear.

After reviewing the example, follow up: ‘Apply the table's criteria. Do not overwrite files with duplicate names; tell me about them separately.’

Instead of ‘Do it again,’ identify the mismatch. For example: ‘The first paragraph is too long. Reduce the conclusion to two sentences and leave the evidence below.’ This also makes clear what should remain.

Distinguish factual errors from stylistic preferences. A wrong owner name requires checking the source; a more casual tone is a wording preference. You can mention both at once, but say what is wrong.

After the revision, reopen the affected part and briefly check surrounding content too—for example, whether dates or table rows changed when only wording needed editing.

After producing a result several times, note the rules you always add, such as ‘mark unsupported information as undecided,’ ‘list decisions first’ and ‘save separately from the original.’ Next time, add only new material and changed conditions.

Once a repeated procedure is clear, you can turn it into a skill. There is no need to turn every one-time request into a skill; first check whether you will actually reuse the criteria.