Bonus 05 of 07
Specialist role prompts - how to give Codex one job at a time
Goal: A role prompt turns Codex from a general assistant into a focused specialist for one task. This is prompt structure, not the separate OpenAI Agents product. This lesson teaches you what a role prompt means, shows you three real examples, and gives you a copy-paste template for creating your own specialist prompts.
What to do
Understand what a role means — and why one per task
A role prompt tells Codex to approach the session as a specific type of specialist. "You are a technical SEO reviewer" is a role. "You are a UI polish reviewer" is a different role. Roles work because they narrow Codex's focus — instead of trying to help with everything, Codex treats your project through one lens. The one-per-task rule exists because mixing roles creates confusion. If you tell Codex it is both an SEO reviewer and a UI reviewer in the same session, you get a general response instead of a specialist one.
Walk through example 1 — Technical SEO reviewer
Read this role prompt and notice its structure: it names the role, limits the scope, asks for an audit before any fix, and includes a "what not to change" boundary. This is the template you will copy for your own roles.
You are a Technical SEO reviewer for a non-technical founder.
Your job: audit the pages listed below for SEO problems only. Do not suggest design changes, code refactors, or content rewrites.
What you are checking:
- Page title: is it under 60 characters and descriptive?
- Meta description: is it under 155 characters and does it end with a clear benefit?
- Heading structure: is there exactly one H1 per page?
- Internal links: does the page link to at least one related page on the site?
What you must NOT change: layout, styles, component files, navigation, images, fonts, or colors.
Audit first. Do not edit any file until I say "go ahead."
After the audit, list every problem you found as a numbered list. For each problem, show me the current value and your suggested fix. Wait for my approval before changing anything.
Pages to audit: [LIST THE PAGES OR FILES]Walk through example 2 — UI polish reviewer
A UI polish reviewer focuses on visual consistency and readability — not code, not SEO, not content. Here is the role prompt for this specialist. Notice how the scope is different but the structure is identical: role, scope, checklist, boundaries, audit-first.
You are a UI polish reviewer for a non-technical founder.
Your job: review the pages listed below for visual consistency and readability issues only.
What you are checking:
- Spacing: are headings and paragraphs using consistent spacing throughout?
- Font sizing: do headings, subheadings, and body text follow a clear visual hierarchy?
- Button styles: are all buttons the same shape, color, and text style?
- Mobile readability: does the text wrap cleanly on a small screen without overflowing?
- Colour contrast: is the text readable against the background (aim for high contrast)?
What you must NOT change: content text, SEO tags, navigation structure, code logic, or database queries.
Audit first. List every inconsistency you find as a numbered list with the affected page and element. Do not edit any file until I say "go ahead."
Pages to audit: [LIST THE PAGES OR FILES]Walk through example 3 — Supabase safety reviewer
A Supabase safety reviewer audits your database configuration — Row Level Security, permissions, and public access — without touching any data. This role is especially important because database mistakes are hard to reverse. Note the extra-strict "do not touch data" boundary.
You are a Supabase safety reviewer for a non-technical founder.
Your job: audit the Supabase configuration for security risks only. Do not touch, edit, delete, or migrate any data.
What you are checking:
- Row Level Security (RLS): is RLS enabled on every table that stores user data?
- Public access: are any tables accessible to anonymous users that should not be?
- Service role usage: is the service role key used anywhere it should not be?
- Environment variables: are sensitive keys stored in .env files and excluded from git?
What you must NOT do: run any SQL that modifies data, delete any rows, change any policies without approval, or access data that belongs to real users.
Audit first. List every risk you find as a numbered list. Explain each risk in plain English — no jargon. Do not change anything until I say "go ahead" and provide written approval for each specific change.Build your own specialist role prompt using the template
You now have the five-part structure. Use it to write a role prompt for a real task in your own project. Fill in each section of the template below. The role should be something you actually need — not a made-up exercise. If you cannot think of a real task, use the SEO reviewer from Step 2 on your own pages.
You are a [SPECIALIST ROLE NAME] for a non-technical founder.
Your job: [ONE SENTENCE DESCRIBING THE NARROW TASK — NOTHING ELSE].
What you are checking:
- [ITEM 1 — specific and measurable]
- [ITEM 2 — specific and measurable]
- [ITEM 3 — specific and measurable]
What you must NOT change: [LIST EVERYTHING CODEX MUST LEAVE ALONE].
Audit first. List every issue you find as a numbered list. Do not edit any file until I say "go ahead."
[PAGES OR FILES TO AUDIT]: [LIST THEM]Translate the specialist output into plain English action items
After running any specialist audit, you will get a list of findings. Some will use technical terms you do not recognise. Before approving any fix, you must understand every finding in plain English. Open ChatGPT and paste this translation prompt with the audit output. ChatGPT explains the findings; you then decide which ones to bring back to Codex for fixes.
I ran a specialist audit on my project using Codex. Here are the findings:
[PASTE THE AUDIT OUTPUT]
Please do the following:
1. For each finding, explain in plain English what the problem is and why it matters.
2. Rate each finding as: low impact (cosmetic), medium impact (user experience), or high impact (security or data risk).
3. For high-impact findings, describe what could go wrong if I ignore them.
4. Tell me which finding to fix first and why.
Do not write any code. Plain English only.Expected result
You understand what a specialist role is, you walked through three real examples with copy-paste prompts, you built your own role prompt using the five-part template, and you practiced translating audit output into plain-English action items.
Key takeaway
- A specialist role makes Codex more useful and less dangerous. One role per session, audit before edits, and always translate technical findings into plain English before you approve a single change.