What it does: Has Codex read your project and write a short AGENTS.md: how to run it, test it, and what not to touch.
Use it when: Codex keeps guessing how your project works and gets it wrong.
You get: An AGENTS.md under 50 lines, plus what Codex couldn't figure out and needs from you.
Open in
See the prompt
You are my setup helper, with access to my project.
What the project is: [one line]
What must never change: [files or folders]
Who works on it: [for example: just me, plus Codex]
1. Read the project: language, how to install, how to run, how to test, folder layout.
2. Write an AGENTS.md under 50 lines with:
- what the project is
- the exact commands to install, run and test, only ones you checked in the files
- the folder map, one line each
- the rules: small changes, run the tests, never touch the files I named, no new libraries without asking
3. List what you couldn't figure out (for example: no test command found) as questions for me.
4. Show me the file. Don't save it until I say yes.
Rules:
- Only commands you can find written in the project's files. If there's no install command written down, write [check: install command].
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Write AGENTS.md' so you do it this way each time I set up Codex on a project.
Built from: The E-Myth Revisited, Michael E. Gerber, Chapter 8: The Franchise Prototype
What it does: Turns a feature idea into one Codex task with what done looks like, the files in play, and the tests it must pass.
Use it when: You give Codex a big vague ask and get back something you can't use.
You get: One task brief for Codex, a done check list, and what to review in its change.
Open in
See the prompt
You are my task writer for Codex.
The feature, in my words: [what you want]
Who uses it and why: [one line]
Where it lives in the app: [page or file if you know]
1. Cut it down to the smallest piece that's useful on its own. If it's big, split it and give me the first task only.
2. Write the task brief:
- Goal in one line
- What done looks like, 3 to 5 checks a person can see
- Files likely to change, and files not to touch
- Tests to add or update
- Out of scope, in 2 lines
3. Write what I should look at when I review Codex's change.
Rules:
- One task, one change. No "and also".
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Codex Task' so you do it this way each time I give Codex a task.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 6: Simple
What it does: Has Codex read a change and explain what it does, what could break, and how to test it, in words a non-coder gets.
Use it when: Someone (or an AI) changed your code and you have to say yes without fully getting it.
You get: What changed in plain words, the risks, a test list, and MERGE, FIX FIRST or ASK.
Open in
See the prompt
You are my code reviewer, with access to my project.
The change: [the pull request or branch name]
What it was meant to do: [one line]
1. Explain what changed in plain words, under 100 words. No code words without a short meaning.
2. Does it do what it was meant to do? Yes, partly or no, and why.
3. What could break: list each risk, and how likely (low, medium, high).
4. Anything that touches money, log ins, customer data or deleting: flag it first.
5. A test list I can follow by clicking around, step by step.
6. Say MERGE, FIX FIRST (with what) or ASK (with the question for the person who wrote it).
Rules:
- Don't change any code. Only read and explain.
- Use only what is in my data and what I tell you. Never make up a name, number, date, price, link or promise.
- If something you need is missing, write [check: what is missing] in that spot and keep going.
Last, save these steps as a skill called 'Explain This Change' so you do it this way each time I review a code change.
Built from: Extreme Ownership, Jocko Willink and Leif Babin, Chapter 1: Extreme Ownership
Simple AI
Team and officeRun the business
