Working with Codex

Codex is a coding agent. It reads the files in your project folder, proposes changes, writes code and runs commands, asking for your approval as it goes. It is not an image generator, and it is not the author.

Across the month you'll ask it to play five roles, one at a time. Naming the role in your prompt keeps it from drifting into the others.

Day 1, after you've set up GitHub and created your repository (Repository, part 01). About twenty minutes. If a step fails, stop and ask; don't work around it.

1. Open a terminal.

   Terminal on a Mac, or the terminal inside VS Code. If you've never used one, that's fine; you'll only need a few commands.

2. Install the Codex command-line tool.

   This needs Node.js. If the command isn't found, ask before installing anything else.

   npm install -g @openai/codex
3. Go to your project folder and start Codex.

   Always start Codex from inside your project, so it works on your files and nothing else.

   cd ~/Documents/your-project codex
4. Sign in with the studio account.

   Use the account the studio gives you, not a personal one. Never paste a password or key into a prompt.

5. Ask your first question, read-only.

   This checks that it can see your folder, and that you can read what it says.

   Read this folder and tell me, in plain language, what is in it. Don't change anything.
6. Make your first commit and push it.

   Git is your undo button. Commit before every change you ask Codex for, so you can always go back, and push to GitHub at the end of every day.

   git add -A git commit -m "start" git push

If you prefer working in an editor, Codex is also available as a VS Code extension, using the same account. Keep approvals on, so Codex asks before it edits files or runs commands, until you're confident reading its changes. Your project's AGENTS.md tells Codex about you and your identity; section 09 of the handbook covers it.

Codex is fast and fluent, which is exactly why authorship needs rules. These hold all month.

1. You decide; Codex proposes. Every rule in the system has a reason in the identity's position. Codex doesn't get to supply the reasons.
2. Plan before code. Ask for a plan first, agree it, then ask for one step at a time.
3. Read every change before you accept it. If a change is too big to read, ask for a smaller one.
4. If you can't explain it, you can't keep it. Ask Codex to explain the code, then explain it back in your own words in your log.
5. The words are yours. Codex never writes your manifesto, your statement, or the Decided line in your log. It may question them.
6. Record what you rejected. The authorship log keeps what Codex suggested, what you kept and what you turned down, with reasons.
7. Check every fact. Codex can invent libraries, datasets and references that don't exist. Open them yourself.
8. Nothing private goes in. No passwords, keys or other people's personal data in prompts or in the repo.

A good prompt has five parts. Point at your files rather than retyping them: Codex can read identity.md, manifesto.md and your code.

make it look cooler and add more stuff

You're my collaborator. Read manifesto.md and src/draw.js.
Rule 2 says absence is drawn heavier than presence, but
line weight is currently fixed. Change only the line-weight
calculation so it follows the deficit column in data/rain.csv.
Don't touch the grid or the export. When you're done, render
seed 41822 and tell me the thinnest and thickest weights.

Twenty prompts, in the order you'll need them. Replace anything in [brackets], and add your own limits.

Read this folder and tell me, in plain language, what is in it and what each file is for. Then list anything that looks missing for a generative art project. Don't change anything.

Explain what [file] does, section by section, as if to an artist who has never coded. Use the names in the code. Then ask me three questions to check that I understood it.

Something broke after your last change. Show me exactly what changed since my last commit, in plain language, and tell me how to return to that commit. Don't run anything until I say yes.

You're an interlocutor. Read identity.md. Interview this identity as a sceptical journalist who knows its field. Ask one hard question at a time and wait for my answer. Don't suggest answers, and don't make the identity more likeable.

You're an interlocutor. Read identity.md, especially the condition, the position, the beliefs and the rules. Don't write code. Propose five computational metaphors for how this identity might make work. For each: the process, what in the condition it stands for, and one way it could fail to carry the identity's position. Then ask me two questions that would sharpen them.

You're an interlocutor. Read manifesto.md. Don't rewrite it. Tell me which sentence is the most generic, which claim is least supported by identity.md, and which line someone could reasonably disagree with. Then stop.

You're a researcher. My identity works on [condition]. Where could I find real, public data or archives about it? For each source: what it contains, who publishes it, and a link. Mark clearly anything you're not certain exists.

You're a researcher. My metaphor is: [metaphor]. What algorithms or techniques could realise it? For each one: a plain explanation, one artist or artwork known for it, and how hard it is for a beginner. No code yet.

You're my collaborator. Read identity.md, manifesto.md and system.md. Before writing any code, propose an architecture: the files and what each is for; every parameter in one config with a default and range; one seeded random generator for every random choice; an export that names each file by its seed and parameters. Show how each of my rules maps to the code. Wait for my go-ahead.

Implement only step [n] of the plan we agreed. Keep every value that might change in the config. When you're done, show me what changed and explain it in plain language. Don't start the next step.

Make every random choice in the system come from one seeded random generator. Put the seed and the key parameters in each output's filename. Then prove it: render seed [n] twice and confirm the two files are identical.

Add a way to render twenty outputs in one run, with seeds [1–20] or a list I give you, into outputs/digital. Write a contact sheet image showing all twenty with their seeds underneath. Don't change how a single output is drawn.

Here is the error I get:

[paste the error]

Explain what it means in plain words and where it comes from in my code. Then propose the smallest fix. Don't change anything else.

You're a critic, not a collaborator. Read manifesto.md and system.md, and look at the contact sheet in outputs/digital. Which outputs carry the manifesto most clearly, and which least, and why? Which rule does the most work, and which could go? Don't suggest new features. Don't rewrite my voice.

You're a critic. My system uses [technique]. Compare my outputs with what that technique typically produces in tutorials and well-known examples. What in mine is the default look of the technique, and what belongs to the identity? Be specific.

You're a fabricator. Prepare seed [n] for an A2 pen plotter (420 × 594 mm, units in mm). Strokes only, no fills. Remove duplicate and overlapping lines, merge paths that touch, and order paths to reduce pen travel. Report the number of paths and the total drawing length. Don't change the composition.

You're a fabricator. Export seed [n] as a watertight STL in millimetres, no larger than [size]. Every wall at least [thickness] mm thick. Check for holes and non-manifold edges and report them. Report the final dimensions and volume.

You're a fabricator. Render seed [n] at its final print size of [size] at 300 PPI, as a TIFF with an embedded colour profile. Render it at full resolution from the system; don't upscale a smaller image. Report the pixel dimensions and file size.

Read my code, system.md and log.md. Suggest an outline for process.md: headings only, in the order a visitor would need them to understand how the system works. Don't write the text; I'll write it.

Check my repo for the final submission. It needs: README with parameter table, identity.md, manifesto.md, references.md, system.md, process.md, log.md, the authorship log, outputs/digital with twenty outputs, and photographs of the final work. List what's missing or incomplete. Don't write anything for me.

Keep authorship.md next to log.md. Add an entry whenever Codex suggests something that matters, especially when you say no.

# Authorship log

## Day 09 · Thu 3 Dec

**Codex suggested:**
**I kept:**
**I rejected, and why:**
**What this says about the identity:** 

The last line matters most. A good rejection says something about the identity that the work then has to honour.

• It changed far more than you asked.Don't accept it. Go back to your last commit (prompt 03) and ask again with tighter limits.
• It's going round in circles.Start a fresh session. Give it a three-line summary: what works, what doesn't, the one thing to fix.
• It says it's done, but the output is wrong.Ask it to run the code and show you the result, then describe what you expected to see.
• It used a library or source you can't find.Assume it doesn't exist until you've found it yourself.
• You don't understand what it wrote.Stop and use prompt 02. Don't build on code you can't explain.
• The outputs have started to look like everyone else's.Use prompt 15, then go back to the manifesto, not to Codex, for the next rule.