Codex skills: de meegeleverde set, de marketplace en zelf bouwen

De basis

Wat een skill bij Codex is, en waarom hij bijna geen context kost

De officiele definitie is kort: een skill verpakt instructies, resources en optionele scripts zodat ChatGPT of Codex een werkwijze betrouwbaar volgt. Technisch is het een map met daarin een bestand SKILL.md, met bovenin twee regels YAML (een name en een description) en daaronder gewone tekst. Dat is alles wat verplicht is. Het verschil met een prompt die je steeds opnieuw plakt, zit in het moment waarop hij laadt.

Progressive disclosure, met een hard budget dat je moet kennen

ChatGPT en Codex beginnen met alleen de naam en de beschrijving van elke skill, en laden de volledige SKILL.md pas op het moment dat ze besluiten die skill te gebruiken. In Codex staat in die eerste lijst ook het bestandspad van elke skill. Het budget voor die lijst is gedocumenteerd en hard: maximaal 2 procent van het contextvenster van het model, of 8.000 tekens wanneer het contextvenster onbekend is. Heb je veel skills geinstalleerd, dan kort Codex eerst de beschrijvingen in; bij grote sets kan Codex skills helemaal uit de beginlijst weglaten en toont hij een waarschuwing. Het budget geldt alleen voor die beginlijst: kiest Codex een skill, dan leest hij daarna wel de volledige SKILL.md.

De beschrijving is de schakelaar

Omdat Codex alleen op naam en beschrijving matcht, bepaalt je description of de skill ooit aanslaat. De officiele instructie is letterlijk: schrijf beknopte beschrijvingen met een duidelijke scope en duidelijke grenzen, en zet het belangrijkste gebruiksmoment plus je triggerwoorden vooraan, zodat een host de skill nog steeds kan matchen als beschrijvingen worden ingekort. Dat laatste zinnetje is de reden dat "Helpt met sales" nooit werkt en "Schrijft opvolgmails na een uitgebrachte offerte. Gebruik bij offertes opvolgen, nabellen en herinneringsmails" wel.

De mapstructuur die de standaard kent

Naast SKILL.md kent de structuur vier optionele mappen:

mijn-skill/
SKILL.md (verplicht: instructies plus metadata)
scripts/ (optioneel: uitvoerbare code)
references/ (optioneel: achtergronddocumentatie)
assets/ (optioneel: sjablonen en bronbestanden)
agents/openai.yaml (optioneel: uiterlijk en afhankelijkheden)

De map agents/ met daarin openai.yaml is het Codex-specifieke stuk. Daarin zet je hoe de skill eruitziet in de ChatGPT desktop-app (display_name, short_description, icon_small, icon_large, brand_color en default_prompt), of Codex hem uit zichzelf mag inzetten (policy.allow_implicit_invocation), en welke tools hij nodig heeft (dependencies.tools, bijvoorbeeld een MCP-server met transport en url).

Skills zijn geen OpenAI-only formaat

De documentatie zegt het zelf: skills bouwen voort op de open agent skills-standaard van agentskills.io. Datzelfde formaat wordt gelezen door Claude Code, Cursor, Gemini CLI en anderen. Voor bedrijven waar niet iedereen op dezelfde AI-tool zit, is dat het praktische argument om je werkwijzen in dit formaat vast te leggen in plaats van in de instellingen van een tool. Codex gaat daar nog een stap verder in: de CLI heeft een commando /import dat je setup, je project en recente chats uit Claude Code overneemt, en de plugin-loader leest naast .agents/plugins/marketplace.json ook het oudere pad .claude-plugin/marketplace.json.

Wanneer je er een maakt

De vuistregel uit de documentatie: maak een skill zodra goede resultaten afhangen van een herhaalbare aanpak. De voorbeelden die OpenAI zelf noemt zijn een wekelijkse update, een campagnebrief, een meeting-follow-up, een releaseprocedure en een reviewroutine. In de praktijk merk je het aan jezelf: zodra je dezelfde uitleg voor de derde keer in een sessie typt, hoort die uitleg in een SKILL.md. Wat je in AGENTS.md zet zijn feiten over je project; wat je in een skill zet is een procedure die pas laadt op het moment dat hij nodig is.

Meegeleverd

De zes skills die Codex zelf meebrengt

Er is geen lange lijst officiele skills zoals bij de Claude-tegenhanger. Codex levert er zes mee in de binary zelf, in de scope die de documentatie SYSTEM noemt. Ze staan in de broncode onder codex-rs/skills/src/assets/samples en worden bij het starten uitgepakt naar de cachemap $CODEX_HOME/skills/.system. Je installeert er niets voor en ze zijn er voor iedereen die Codex start.

Wat er niet bij zit, en waarom dat opvalt

Wie van de Claude-kant komt, mist hier iets. In de Claude-wereld zitten er vier documentskills standaard aan (pptx, xlsx, docx en pdf) en heeft de CLI dertien eigen slash-skills. Bij Codex zijn dat er zes, en vier daarvan gaan over Codex zelf: skills maken, skills installeren, plugins maken en de documentatie opzoeken. Er is dus geen meegeleverde documentskill voor PowerPoint, Excel of Word. Wil je dat, dan haal je het uit de catalogus (bijvoorbeeld de skill pdf uit de gecureerde lijst, of google-slides en google-sheets uit de Google Drive-plugin) of je schrijft het zelf.

De gecureerde lijst achter $skill-installer

De installer haalt standaard uit github.com/openai/skills, map skills/.curated. Daar stonden op 1 augustus 2026 39 skills, waaronder pdf, linear, sentry, acht figma-varianten, playwright, screenshot, jupyter-notebook, transcribe, speech, gh-fix-ci, gh-address-comments, cli-creator, define-goal, migrate-to-codex, security-threat-model, security-ownership-map, security-best-practices en deploy-skills voor Vercel, Netlify, Render en Cloudflare. Installeren gaat per naam:

$skill-installer linear

Je kunt de installer ook een GitHub-map geven om uit een andere repo te installeren. Na installatie is de skill beschikbaar vanaf je volgende beurt; ziet Codex hem niet, dan herstart je.

Let op: die repo is gedeprecieerd

Bovenaan de README van openai/skills staat inmiddels dat de repository deprecated is en dat je voor actuele skill- en pluginvoorbeelden bij openai/plugins moet zijn. De repo stond op 1 augustus 2026 op 24.405 sterren en 1.658 forks, met als laatste wijziging 14 juli 2026. De installer werkt nog gewoon en de gecureerde skills staan er nog, maar dit is wel het moment om te weten dat OpenAI het zwaartepunt naar plugins heeft verlegd. De README verwijst daarnaast nog naar een map skills/.experimental die er op onze peildatum niet meer was; wie een tutorial volgt die daarnaar verwijst, loopt dus vast.

Twee marketplaces die je niet ziet staan

In de broncode staan vier gereserveerde marketplacenamen: openai-curated, openai-api-curated, openai-bundled en openai-bundled-alpha. Die laatste twee bevatten geen gewone plugins uit de catalogus maar de ingebouwde uitbreidingen: in de allowlist van de broncode staan chrome@openai-bundled en computer-use@openai-bundled. Dat verklaart waarom je Computer Use via het plugin-menu aanzet terwijl het geen gewone community-plugin is.

Aanroepen

Aanroepen met $, en waar skills wel en niet werken

Er zijn twee manieren om een skill in te zetten en het verschil is groter dan het lijkt. Expliciet betekent dat jij hem noemt. Impliciet betekent dat Codex hem zelf kiest op basis van je description. De meeste teleurstellingen over skills gaan over die tweede route.

Het teken verschilt per omgeving, en dat gaat een keer mis

In Codex is $ het teken voor skills en apps, en is @ alleen voor bestanden in je workspace. In ChatGPT is @ juist het teken voor skills, plugins en bestanden. Wie op een dag in beide werkt, typt dit gegarandeerd verkeerd. Het menu dat opengaat verraadt meteen in welke omgeving je zit. De volledige composer-syntax met alle vier de tekens staat op Codex-commands.

Impliciet aanroepen kun je per skill uitzetten

Zet je in agents/openai.yaml het veld policy.allow_implicit_invocation op false, dan zet Codex de skill nooit uit zichzelf in; expliciet aanroepen met $naam blijft wel werken. De standaardwaarde is true. Dit is de instelling die je wilt bij skills met bijwerkingen: deployen, mail versturen, een factuur klaarzetten, iets naar een klantsysteem schrijven. Voor alles wat alleen tekst oplevert laat je hem juist aan staan, want dan is de hele winst dat je er niet aan hoeft te denken.

Gebundelde skills komen pas na een nieuwe sessie

Dit is de meest voorkomende "hij doet het niet"-melding bij plugins. De documentatie zegt het expliciet: gebundelde skills worden beschikbaar zodra je na de installatie een nieuwe chat of CLI-sessie start. Bij losse skills is het andersom: Codex detecteert wijzigingen aan skills automatisch, en alleen als een update niet verschijnt herstart je. Wijzig je ~/.codex/config.toml, dan is herstarten wel altijd nodig.

Zit dit in mijn abonnement?

Skills zelf zijn geen apart betaald product: ze horen bij Codex, en Codex zit in je ChatGPT-abonnement. Wat je precies aan Codex-gebruik krijgt per abonnement staat op Kosten van Codex. Twee dingen zijn wel plan- of modusgebonden. Plugins vragen om ChatGPT Work op het web, of om ChatGPT Work of Codex in de desktop-app. En log je in Codex in met een OpenAI API-sleutel in plaats van een ChatGPT-account, dan zie je een aparte catalogus (openai-api-curated, 29 plugins op 1 augustus 2026) omdat sommige plugins verbindingsflows gebruiken die met API-sleutel-authenticatie niet werken.

Marketplace

De officiele marketplace en hoe je installeert

Bij de Claude-tegenhanger heet de officiele marketplace claude-plugins-official en voegt de CLI die bij de eerste start toe. Bij Codex werkt het net anders, en dat verschil verklaart waarom je geen installatiecommando voor de officiele catalogus tegenkomt: die catalogus zit er al in.

De officiele catalogus heet openai-curated en staat er al

ChatGPT en Codex delen een universele plugin directory: dezelfde publieke plugins zijn vindbaar vanaf de ondersteunde oppervlakken van beide producten. De inhoud daarvan staat open op github.com/openai/plugins (4.860 sterren, 657 forks, laatste wijziging 14 juli 2026). Het marketplacebestand daar draagt de naam openai-curated en de weergavenaam Codex official, en bevatte op 1 augustus 2026 180 plugins. Voor wie met een API-sleutel inlogt is er een tweede bestand, openai-api-curated, met 29 plugins. Beide namen zijn in de broncode gereserveerd, dus je hoeft (en kunt) ze niet zelf toevoegen: Codex beheert ze.

Wel zelf toevoegen: elke andere marketplace

Een marketplace is niets meer dan een JSON-catalogus van plugins. Een bron toevoegen doe je met codex plugin marketplace add, en dat accepteert vier soorten bronnen: GitHub-shorthand (owner/repo of owner/repo@ref), HTTP- of HTTPS-Git-URL's, SSH-Git-URL's en lokale mappen.

codex plugin marketplace add owner/repo
codex plugin marketplace add owner/repo --ref main
codex plugin marketplace add https://github.com/example/plugins.git --sparse .agents/plugins
codex plugin marketplace add ./local-marketplace-root

Met --ref pin je een Git-ref vast. Met --sparse doe je een sparse checkout, wat alleen geldig is voor Git-bronnen; je mag die vlag herhalen. Beheren gaat met codex plugin marketplace list (toont elke marketplace die Codex overweegt plus het pad waar hij vandaan komt), codex plugin marketplace upgrade (met of zonder naam) en codex plugin marketplace remove. Aan alle vier kun je --json toevoegen voor scriptbaar uitvoer.

Installeren: drie routes, en de valkuil zit in de vierde stap

In de CLI open je met /plugins de plugin browser. Die groepeert per marketplace: je wisselt met de tabbladen van bron, opent een plugin voor details, installeert of deinstalleert, en drukt op de spatiebalk bij een geinstalleerde plugin om hem aan of uit te zetten. Vanaf de gewone terminalprompt gebruik je codex plugin add, codex plugin list en codex plugin remove. In de desktop-app en op het web open je Plugins, zoekt of bladert, klikt de plus-knop, en verbindt een connector als daarom gevraagd wordt (sommige plugins vragen bij installatie om authenticatie, andere pas bij eerste gebruik). En dan de stap die mensen overslaan: start een nieuwe chat of CLI-sessie, want gebundelde skills komen pas daarna beschikbaar.

Waar een geinstalleerde plugin belandt

Plugins worden geinstalleerd in ~/.codex/plugins/cache/$MARKETPLACE_NAME/$PLUGIN_NAME/$VERSION/. Bij lokale plugins is $VERSION gewoon "local", en laadt de host de geinstalleerde kopie uit die cache in plaats van rechtstreeks uit de marketplace-entry. Dat is precies waarom je na het wijzigen van een lokale plugin de bronmap moet bijwerken en de app moet herstarten: de cache verandert niet vanzelf mee. Of een plugin aan of uit staat, wordt bewaard in ~/.codex/config.toml.

Marketplace-entries hoeven niet lokaal te zijn

Een entry kan naar drie soorten bronnen wijzen. local met een pad relatief aan de marketplace-root, beginnend met ./ en binnen die root. url of git-subdir voor een Git-repo, met een ref of een sha als selector; git-subdir gebruik je wanneer de plugin in een submap staat. En npm, met een verplicht package-veld en optioneel version en registry; Codex downloadt het pakket zonder lifecycle-scripts te draaien, de npm-CLI moet geinstalleerd zijn en de registratie-authenticatie komt uit de npm-configuratie. Kan Codex een bron niet oplossen, dan slaat hij die ene entry over in plaats van de hele marketplace te laten falen.

Catalogus

Wat er in de officiele catalogus zit, geteld

De 180 plugins in openai-curated zijn geen homogene set. We hebben de git-tree van openai/plugins op 1 augustus 2026 doorgeteld: 154 plugins brengen een .app.json mee (een geregistreerde MCP-serververbinding, oftewel een connector), 8 hebben een eigen .mcp.json met een meegeleverde MCP-server, 72 hebben een skills/-map en 24 daarvan zijn skills-only. Bij elkaar zitten er 580 skill-mappen in de catalogus.

De plugins met de meeste skills erin

Geteld op skill-mappen staat twilio-developer-kit bovenaan met 56, gevolgd door life-science-research (50), vercel (48), zoom (27), daloopa (23), render (21), shopify (20), en met 18 elk ngs-analysis en build-web-data-visualization. Daarna volgen superpowers (14), expo (13), en met 12 elk netlify, figma en codex-security. Dat patroon zegt iets: de plugins met veel skills zijn bijna allemaal van een leverancier die zijn eigen product uitlegt. Voor de meeste teams zijn de kleine plugins nuttiger dan de grote.

De veertien die Codex zelf mag voorstellen

In de broncode staat een allowlist van plugins die Codex uit zichzelf mag aanraden wanneer je taak erom vraagt. Dat zijn er precies veertien: github, notion, slack, gmail, google-calendar, google-drive, openai-developers, canva, teams, sharepoint, outlook-email, outlook-calendar, linear en figma. Zit je werk in een van die systemen, dan is de kans het grootst dat Codex je er zelf op wijst. Voor de overige 166 moet je zelf zoeken.

De richer voorbeelden die OpenAI zelf aanwijst

De README van openai/plugins noemt zeven plugins als uitgebreidere voorbeelden om van te leren: figma (use_figma, Code to Canvas, Code Connect en design system rules), notion (plannen, onderzoek, meetings en kenniscaptatie), build-ios-apps, build-macos-apps, build-web-apps, expo en de combinatie netlify plus remotion. Wil je zien hoe een goede skill eruitziet voordat je er zelf een schrijft, dan zijn dat de mappen om te openen. De README noemt daarnaast google-slides als voorbeeld, maar die map bestond op onze peildatum niet als aparte plugin; de google-slides-skill zit in de Google Drive-plugin.

Publiceren in de officiele catalogus

Wil je een plugin openbaar aanbieden, dan gaat dat via het inzendportaal van OpenAI; na publicatie staat hij in de universele directory die ChatGPT en Codex delen. De procedure, de vereiste rechten, het reviewmateriaal, de MCP-controles en de vereiste testcases staan op Submit plugins. Lokale marketplaces en repo-marketplaces staan daar los van: die zijn bedoeld voor ontwikkelen, testen en distributie binnen een team.

Community

Community-skills voor Codex, met de cijfers van 1 augustus 2026

Eerst de kanttekening die bepaalt hoe je deze cijfers moet lezen. GitHub kent geen sterren per skill, alleen per repository. Elke bron die een sterrenaantal aan een losse skill hangt, verzint dat. Alle getallen hieronder zijn repo-cijfers, live opgehaald via de GitHub API op 1 augustus 2026. En sterren meten interesse, niet kwaliteit en niet gebruik. We hebben van elke repo ook de git-tree opgehaald om te controleren of er daadwerkelijk Codex-structuur in zit (.agents/plugins/marketplace.json of .codex-plugin/plugin.json), want een repo die "Codex" in de titel heeft is niet automatisch voor Codex gebouwd.

De valkuil met de grootste naam: awesome-codex-skills

De repo composio-community/awesome-codex-skills (15.521 sterren) heet "Codex" maar is grotendeels de Claude-verzameling met een ander jasje. We hebben de inhoud doorgelopen: van de 880 SKILL.md-bestanden zitten er 832 in de map composio-skills als automatisch gegenereerde connector-skills, en tussen de 28 losse skills staan canvas-design, brand-guidelines, theme-factory, slack-gif-creator, mcp-builder en webapp-testing. Dat zijn de officiele skills van Anthropic. Het enige marketplacebestand in de repo staat op .claude-plugin/marketplace.json, dus in het Claude-formaat. Er is geen .agents-map en er is geen licentiebestand. Bruikbaar als inspiratie, maar behandel het niet als een Codex-catalogus.

Nog een naamverwarring: skill-codex is geen Codex-skill

Zoek je op "skill codex", dan komt skills-directory/skill-codex (1.399 sterren, MIT) hoog naar boven. Dat is het omgekeerde van wat je zoekt: het is een Claude Code-skill die prompts naar Codex delegeert. Nuttig als je vanuit Claude Code een tweede model wilt laten meekijken, maar je installeert hem in Claude Code en niet in Codex. Dit soort verwisselingen komt in dit ecosysteem vaak voor, omdat veel repo's beide tools noemen zonder te zeggen welke kant op.

De echte community-marketplace om te proberen

hashgraph-online/awesome-codex-plugins is de enige community-bron die we tegenkwamen die volledig in het Codex-formaat is opgezet: een marketplacebestand op .agents/plugins/marketplace.json met de naam awesome-codex-plugins en de weergavenaam "Awesome Codex Plugins", 183 plugin-entries, 220 .codex-plugin-manifests in de repo en Apache 2.0 als licentie. Toevoegen gaat zoals elke andere bron:

codex plugin marketplace add hashgraph-online/awesome-codex-plugins

Daarna blader je met /plugins door de nieuwe tab. Met 740 sterren is het een stuk kleiner dan de awesome-lijsten hierboven, maar het is wel de bron die daadwerkelijk werkt zoals de documentatie beschrijft. Kleinere alternatieven met dezelfde structuur die we verifieerden: fivetaku/gptaku-plugins-codex (112 sterren, marketplace gptaku-codex, 14 plugins), duyet/codex-claude-plugins (9 sterren, 23 plugins) en corezoid/corezoid-ai-plugin (71 sterren, MIT).

Waar je op let voordat je iets overneemt

Drie dingen zie je in dertig seconden en ze voorkomen de meeste ellende. De structuur: staat er een .agents/plugins/marketplace.json of minstens .codex-plugin/plugin.json in, of is het een verzameling losse mappen die je zelf moet verplaatsen? De licentie: composio-community/awesome-codex-skills, proflead/codex-skills-library en am-will/codex-skills hadden op onze peildatum geen licentiebestand, en juridisch betekent dat standaard alle rechten voorbehouden. De datum van de laatste push: jMerta/codex-skills stond op 6 februari 2026, dus bijna een half jaar stil, terwijl de rest van deze lijst in juli nog werd bijgewerkt. Sterren zeggen daar niets over.

Wat je hieruit mag concluderen

Het Codex-skillecosysteem is jonger en kleiner dan dat van Claude. De grote getallen in de tabel horen bijna allemaal bij repo's die primair voor Claude Code zijn gebouwd en Codex erbij ondersteunen. De repo's die echt Codex-first zijn, zitten in de honderden of duizenden sterren. Dat is geen probleem zolang je het weet: het betekent dat je voor Codex meer waarde haalt uit de officiele catalogus en uit je eigen skills dan uit de community-lijsten.

Zakelijk

Skills voor zakelijk werk, per afdeling

De officiele catalogus is niet alleen voor ontwikkelaars. Van de 180 plugins hebben er 72 een skills/-map, en een flink deel daarvan gaat over kantoorwerk: inbox, agenda, CRM, documenten en rapportages. Hieronder de skillnamen zoals ze letterlijk in de repo staan, zodat je weet wat je krijgt voordat je installeert.

Het gat voor Nederlandse bedrijven, concreet gemaakt

Dit moet je weten voordat je de catalogus op je administratie loslaat: in de 180 plugins zit geen enkele Nederlandse koppeling. We hebben er gericht op gezocht. Geen Moneybird, geen Exact, geen e-Boekhouden, geen Twinfield, geen AFAS, geen Yuki, geen SnelStart, geen Visma, geen Nmbrs. Ook geen Mollie en geen Adyen. Wat er wel is aan financiele koppelingen: QuickBooks, Stripe, Brex, Carta, Razorpay en Zoho. De praktische omweg is een eigen MCP-server voor je boekhoudpakket, of je pakket via een tussenlaag ontsluiten. Hoe je zo'n server aanhangt staat op Functies van Codex.

Waar je zelf het meeste rendement haalt

De skills hierboven zijn generiek gebouwd. Wat ze niet weten, is hoe jullie het doen: welke toon in een klantmail, welke velden in jullie CRM verplicht zijn, hoe een offerte bij jullie is opgebouwd, welke klantgroepen anders benaderd worden. Dat is precies wat je in een eigen skill zet. Het patroon dat in Nederlandse mkb-teams het snelst rendeert: een skill voor de opvolgmail na een offerte, een voor de maandrapportage aan een klant, en een voor de standaardstructuur van een projectvoorstel. Die drie kosten je een middag en besparen daarna elke week tijd. De volgende sectie geeft er een compleet uitgewerkt voorbeeld van.

Een verstandige volgorde

Begin niet met tien skills tegelijk. De beginlijst in Codex heeft een budget van 2 procent van het contextvenster, en bij overloop worden beschrijvingen ingekort of skills weggelaten. Start met drie afgebakende skills die je zelf schrijft, kijk na twee weken welke daadwerkelijk aanslaan, en breid daarna uit. Installeer plugins uit de catalogus pas als je een concreet systeem hebt waar je werk echt in zit; een plugin voor een tool die je twee keer per jaar opent, kost je elke sessie context.

Zelf bouwen

Zelf een skill maken: een compleet voorbeeld om te kopieren

Je hebt geen programmeerkennis nodig. Wat je nodig hebt is het vermogen om je eigen werkwijze op te schrijven zoals je die aan een nieuwe collega zou uitleggen. Hieronder staat een compleet SKILL.md voor een scenario dat in vrijwel elk Nederlands B2B-bedrijf voorkomt: de opvolgmail na een verstuurde offerte.

De twee velden die moeten kloppen

Het veld name is de identiteit van je skill; houd hem gelijk aan de mapnaam en gebruik kleine letters met koppeltekens. De plugin-scaffolder normaliseert namen naar lowercase met koppeltekens en hanteert een maximum van 64 tekens, dus dat is een veilige bovengrens. Kies een naam die zegt wat er gebeurt (offerte-opvolgmail, maandrapportage-klant) en niet iets vaags als helper of tools. Belangrijk detail uit de documentatie: hebben twee skills dezelfde name, dan voegt Codex ze niet samen en kunnen ze allebei in de selectors verschijnen. Kies dus unieke namen, zeker als je zowel persoonlijke als repo-skills gebruikt.

Het veld description bepaalt of je skill ooit uit zichzelf aanslaat. Zet er drie dingen in: wat de skill doet, wanneer hij moet triggeren, en wanneer hij juist niet moet triggeren. Front-load de triggerwoorden, want bij veel geinstalleerde skills kort Codex beschrijvingen in en dan verdwijnt de staart eerst.

Compleet SKILL.md voor een Nederlandse offerte-opvolging

---
name: offerte-opvolgmail
description: Schrijft de Nederlandse opvolgmail na een verstuurde offerte, met het bezwaar uit het gesprek en een concrete vervolgstap. Gebruik bij offerte opvolgen, nabellen, follow-up en salesnotities. Niet gebruiken voor koude acquisitie of voor de offerte zelf.
---

Je schrijft de mail die wij sturen nadat een offerte is verstuurd en het eerste gesprek is geweest.

Vraag eerst om deze vier dingen als ze er niet zijn. Verzin ze nooit:
1. De naam van het bedrijf en van de contactpersoon.
2. Wat er in de offerte staat: dienst, prijs, looptijd.
3. De notities of het transcript van het gesprek.
4. De afgesproken vervolgstap, als die er is.

Vaste opbouw, altijd in deze volgorde:
1. Een openingszin die verwijst naar iets concreets uit het gesprek. Geen "leuk je te spreken".
2. Een zin die de offerte samenvat in hun woorden, niet in de onze.
3. Het belangrijkste bezwaar uit het gesprek, letterlijk benoemd, met ons antwoord erop in maximaal drie zinnen.
4. Een vervolgstap met een datum en een tijd, als voorstel geformuleerd.
5. Ondertekening volgens assets/handtekening.md.

Regels voor de toon:
- Je-vorm. Korte zinnen. Geen superlatieven en geen uitroeptekens.
- Nooit "ik hoor graag van je" als afsluiting. Zet er een concreet voorstel neer.
- Noem de prijs alleen opnieuw als de klant er in het gesprek zelf over begon.
- Maximaal 180 woorden. Wordt het langer, schrap dan punt 3 tot een enkele zin.

Regels voor bezwaren:
- Herhaal het bezwaar eerst in hun eigen bewoording voordat je erop reageert.
- Is het bezwaar prijs, gebruik dan references/prijsbezwaren.md.
- Is het bezwaar timing, stel dan een concrete datum voor waarop je terugkomt.
- Staat er geen bezwaar in de notities, sla punt 3 dan over en meld dat erbij.

Lever de mail als platte tekst, met een onderwerpregel erboven. Geef daarnaast in een zin aan welke informatie je miste.

De mapstructuur eromheen

De skill uit het voorbeeld is een map, geen los bestand:

~/.agents/skills/offerte-opvolgmail/
SKILL.md
references/prijsbezwaren.md
assets/handtekening.md

references/ is voor achtergrondinformatie die Codex er op verzoek bij pakt, assets/ voor sjablonen en bronbestanden, en scripts/ voor uitvoerbare code. Verwijs vanuit SKILL.md altijd expliciet naar die bestanden, anders weet Codex niet wanneer hij ze moet openen. Wil je de skill ook nog een eigen naam en icoon geven in de desktop-app, dan voeg je agents/openai.yaml toe met interface.display_name en interface.icon_small.

Het advies dat OpenAI zelf geeft over de body

Vier regels staan er letterlijk in de documentatie. Houd elke skill op een taak gericht. Kies instructies boven scripts, tenzij je deterministisch gedrag nodig hebt of externe tooling moet aanroepen. Schrijf gebiedende stappen met expliciete invoer en uitvoer, dus niet "denk aan de toon" maar "gebruik de je-vorm en maximaal 180 woorden". En test prompts tegen de description om te bevestigen dat het triggergedrag klopt. Die laatste is de stap die de meeste mensen overslaan, en het is de enige die je vertelt of de skill in de praktijk gevonden wordt.

Laat Codex het schrijven

Je hoeft dit niet met de hand te doen. Typ $skill-creator in de CLI (of @skill-creator in ChatGPT Work) en beschrijf in gewone taal wat je doet. De creator vraagt wat de skill doet, wanneer hij moet triggeren en of hij instructie-only blijft of scripts krijgt; instructie-only is de standaard. Je krijgt een correct opgebouwde SKILL.md terug die je daarna nog aanpast. Voor het scaffolden van een hele plugin doe je hetzelfde met $plugin-creator, die het manifest .codex-plugin/plugin.json neerzet en desgevraagd meteen een marketplace-entry aanmaakt.

Het Codex-specifieke bestand: agents/openai.yaml

Dit bestand kent geen tegenhanger in de kale specificatie en is de moeite waard zodra je skill door meer mensen gebruikt wordt. Onder interface zet je display_name, short_description, icon_small, icon_large, brand_color en default_prompt (een standaardprompt die bij de skill hoort). Onder policy staat allow_implicit_invocation, standaard true. Onder dependencies declareer je de tools die de skill nodig heeft, bijvoorbeeld een MCP-server met type, value, description, transport en url. Dat laatste maakt het verschil tussen een skill die vastloopt omdat er iets ontbreekt, en een skill die netjes meldt wat er eerst geregeld moet worden.

Opnemen

Record & Replay: een skill maken door het voor te doen

Er is een tweede route naar een skill die niets met schrijven te maken heeft. Je doet de werkwijze een keer voor op je Mac, en ChatGPT of Codex bouwt daar een herbruikbare skill van. Handig wanneer de stappen makkelijker te tonen dan te beschrijven zijn.

Wat je terugkrijgt

Na het stoppen inspecteert ChatGPT of Codex de opgenomen werkwijze en schrijft een skill die vier dingen vastlegt: wanneer je de werkwijze gebruikt, welke invoer hij nodig heeft, welke stappen je volgt, en hoe je controleert of het resultaat klopt. Daarna vraag je gewoon om verfijningen. Afspelen doe je in een nieuwe chat: je vraagt om de skill te gebruiken en geeft de waarden die deze keer anders zijn, zoals het bestand dat geupload moet worden of de periode van het rapport.

De beperkingen, en die zijn strak

Record & Replay werkt alleen op macOS. De initiele beschikbaarheid sluit de Europese Economische Ruimte, het Verenigd Koninkrijk en Zwitserland uit. Voor Nederlandse gebruikers betekent dat: op de peildatum niet beschikbaar. Daarnaast moet Computer Use beschikbaar en aangezet zijn, en beheert je organisatie Codex met requirements.toml, dan zet de instelling features.computer_use = false ook Record & Replay uit. Zie je de functie niet, dan is dat vrijwel altijd een van deze drie oorzaken en niet een fout in je installatie.

De tips die het verschil maken

Kies een werkwijze die je al beheerst en waarvan de stappen stabiel zijn. Zeg voordat je begint wat je doel is en welke invoer per keer verschilt. Gebruik realistische invoer maar geen wachtwoorden of persoonsgegevens, want de opname legt vast wat er op je scherm staat. Stop de opname zodra de werkwijze af is, dus niet doorlopen in opruimwerk dat er niet bij hoort. En scherp de skill daarna nog aan met de voorkeuren die je niet hebt uitgesproken: naamconventies, standaardwaarden van velden, en de momenten waarop je een keuze maakt.

Debuggen

Waarom slaat mijn skill niet aan?

Bijna alle klachten over skills vallen in zes bakjes. De eerste vier zijn saai en snel op te lossen. Loop ze in deze volgorde af, want elke volgende stap kost meer tijd dan de vorige.

De gereedschapskist

Vier plekken brengen je in vrijwel alle gevallen bij de oorzaak. /skills in de CLI of de IDE-extensie laat zien welke skills op dit moment geladen zijn. /plugins laat zien welke plugins geinstalleerd en actief zijn; met de spatiebalk zet je er een aan of uit. codex doctor genereert een lokaal diagnoserapport dat installatie, configuratie, authenticatie, runtime, Git, terminal, app-server en de thread-inventaris nakijkt. En in de desktop-app opent Skills in de zijbalk het overzicht van alles wat er in je projecten aan skills bestaat.

De verborgen oorzaak: je beschrijving is afgekapt

Dit is de oorzaak die bijna niemand kent, en hij is bij Codex gedocumenteerd terwijl je hem nergens ziet gebeuren. De lijst met alle skillnamen en beschrijvingen mag maximaal 2 procent van het contextvenster in beslag nemen, of 8.000 tekens als het contextvenster onbekend is. Loopt dat over, dan kort Codex eerst de beschrijvingen in. Precies de sleutelwoorden waarop je skill zou moeten aanslaan, kunnen dan aan het eind zijn afgeknipt. Bij nog grotere sets laat Codex skills helemaal weg uit de beginlijst en toont hij een waarschuwing. De praktische les: zet je belangrijkste toepassing vooraan in de beschrijving en houd het aantal actieve skills beperkt.

Een skill uitzetten zonder hem te verwijderen

Wil je ruimte maken zonder mappen weg te gooien, dan gebruik je een [[skills.config]]-entry in ~/.codex/config.toml:

[[skills.config]]
path = "/pad/naar/skill/SKILL.md"
enabled = false

Herstart Codex na die wijziging. In de configuratiereferentie staan de drie sleutels als skills.config, skills.config.<index>.path (het pad naar de skillmap met SKILL.md) en skills.config.<index>.enabled. Dit is meteen de manier om een skill uit een gedeelde repo lokaal uit te zetten zonder de repo aan te passen.

Het scriptje van je skill vraagt om goedkeuring

Heeft je skill een scripts/-map en hangt hij op het moment dat hij die wil draaien, dan is dat geen bug maar het goedkeuringsbeleid. Codex kent een aparte categorie skill_approval in de granulaire approval policy. In config.toml ziet dat er zo uit:

approval_policy = { granular = { sandbox_approval = true, rules = true, mcp_elicitations = true, request_permissions = false, skill_approval = false } }

Staat skill_approval op false, dan worden goedkeuringsvragen voor skill-scripts automatisch afgewezen in plaats van aan jou voorgelegd. Zet hem op true als je wilt dat je de vraag wel krijgt. De rest van het sandbox- en goedkeuringsverhaal staat op Codex en privacy.

Delen

Skills delen met je team of hele organisatie

Er zijn vier manieren om een skill bij anderen te krijgen, en welke je kiest hangt af van waar je collega's werken en hoe strak het beheerd moet zijn. Ze sluiten elkaar niet uit.

Een minimale plugin bestaat uit twee bestanden

Verpakken is minder werk dan het klinkt. Je hebt een manifest nodig en minstens een skill:

mijn-eerste-plugin/
.codex-plugin/plugin.json
skills/offerte-opvolgmail/SKILL.md

En dit is de hele plugin.json:

{
"name": "mijn-eerste-plugin",
"version": "1.0.0",
"description": "Herbruikbare werkwijzen voor sales",
"skills": "./skills/"
}

Houd de name in kebab-case en stabiel, want plugin hosts gebruiken hem als identiteit en als namespace voor de onderdelen. Alleen plugin.json hoort in .codex-plugin/; skills/, hooks/, assets/, .mcp.json en .app.json staan in de root van de plugin. Paden in het manifest beginnen met ./ en blijven binnen de pluginmap.

Een marketplace voor je team

Zet in je repo een bestand op .agents/plugins/marketplace.json met de plugins die je wilt aanbieden. Per plugin geef je name, source (met een pad relatief aan de marketplace-root, beginnend met ./), policy.installation, policy.authentication en category. De waarden die de documentatie voor policy.installation noemt zijn AVAILABLE, INSTALLED_BY_DEFAULT en NOT_AVAILABLE; met policy.authentication bepaal je of authenticatie bij de installatie gebeurt of pas bij het eerste gebruik. Met interface.displayName bepaal je hoe de marketplace in de picker heet. Je hebt geen aparte marketplace per plugin nodig: begin met een, en laat hem groeien tot je interne catalogus.

Delen binnen je werkruimte, en wat de grens is

Deel je een lokale plugin via de desktop-app, dan vinden collega's hem terug onder Shared with you in de Plugins Directory. Belangrijk voor je informatiebeveiliging: dat publiceert hem niet in de publieke universele directory. Gedeelde plugins blijven binnen je werkruimte en organisatiegrens, en accounts die niet in die werkruimte zitten kunnen er niet bij. Gebruik groepen wanneer een heel team of een rol dezelfde toegang moet krijgen. Wil je juist repo- of CLI-distributie, dan gebruik je een marketplace; wil je dat specifieke collega's hem uit de app kunnen installeren, dan gebruik je werkruimtedelen.

Wat een beheerder kan afdwingen

In requirements.toml kan een beheerder drie dingen doen die hier direct op ingrijpen. Plugins helemaal uitzetten met features.plugins = false, wat ook geldt voor gebruikers die met een API-sleutel inloggen. Werkruimtedelen uitzetten met features.plugin_sharing = false. En marketplacebronnen beperken met restrict_to_allowed_sources = true plus een lijst toegestane bronnen: een exacte Git-URL met optionele ref, een host_pattern als reguliere expressie op de Git-host, of een absoluut lokaal pad. Marketplace-toevoegingen, plugin-installaties en Git-verversingen die niet matchen worden geweigerd; de door Codex beheerde OpenAI-marketplaces blijven wel beschikbaar. Die beperkingen gelden alleen waar plugins bestaan: ChatGPT Work en Codex in de desktop-app, en de Codex CLI.

Skills centraal klaarzetten op een machine

Naast de repo- en pluginroute is er nog een vierde: de ADMIN-scope op /etc/codex/skills. Skills die daar staan zijn beschikbaar voor elke gebruiker op die machine of in die container. Dat is de aangewezen plek voor SDK-scripts, automatisering en standaard bedrijfsskills op beheerde werkplekken of in CI-images. Je rolt de bestanden zelf uit met je gebruikelijke beheertooling; Codex leest ze alleen.

Veiligheid

Wat een skill mag, en waar je op let bij skills van derden

Behandel het installeren van een skill als het installeren van software, niet als het aanpassen van een instelling. Een skill is tekst die in de instructies van een agent belandt, en een skill met een scripts/-map is code die op jouw machine draait. Bij Codex is de bescherming daaromheen wel steviger geregeld dan bij veel andere agents, en het is nuttig om te weten waar die bescherming ophoudt.

Het punt waar de meeste risico zit: prompt injection via instructies

Een skill is in de kern tekst die het model gaat volgen. Een kwaadaardige of slordige skill kan de agent vragen dingen te doen die niet bij het beschreven doel horen. De sandbox houdt tegen dat er buiten je werkmap geschreven wordt en dat er zomaar netwerkverkeer ontstaat, maar hij leest niet mee met de bedoeling van de instructies. Voordat je een skill van derden uitrolt: open SKILL.md en lees hem echt. Let op instructies die vragen om veiligheidsregels te negeren, om acties te verbergen, om data ergens naartoe te sturen, of om je anders te gedragen bij bepaalde invoer. Kijk in scripts/ naar netwerkpatronen (curl, fetch, requests, urllib) en naar hardgecodeerde inloggegevens.

Plugin-hooks zijn de scherpste rand

Dit staat letterlijk in de documentatie en het is het nuttigste veiligheidsfeit op deze pagina: het installeren of aanzetten van een plugin vertrouwt zijn hooks niet automatisch. Plugin-hooks zijn niet-beheerde hooks, en Codex slaat ze over totdat je de huidige hookdefinitie hebt gereviewd en vertrouwd. Hooks krijgen wel de omgevingsvariabelen PLUGIN_ROOT en PLUGIN_DATA mee, en Codex zet daarnaast CLAUDE_PLUGIN_ROOT en CLAUDE_PLUGIN_DATA voor compatibiliteit met bestaande plugin-hooks uit het Claude-ecosysteem. Een beheerder die dit dicht wil zetten, gebruikt allow_managed_hooks_only = true: dan draaien alleen hooks uit de beheerde configuratie en worden hooks uit gebruiker, project, sessie en plugins overgeslagen.

Vier signalen bij community-skills

Kijk voordat je installeert naar vier dingen. De structuur: een repo die zegt voor Codex te zijn maar alleen .claude-plugin/marketplace.json heeft, is een Claude-repo. De licentie: verschillende populaire repo's hebben er geen, en dat betekent juridisch alle rechten voorbehouden, dus formeel geen toestemming om te kopieren of aan te passen. De datum van de laatste push: een repo die maanden stil ligt, krijgt geen fixes meer als het formaat verandert, en dat gebeurt in dit ecosysteem regelmatig. En de scripts: instructie-only skills zijn een orde van grootte minder riskant dan skills met uitvoerbare code erin.

Persoonsgegevens en de AVG

Twee dingen om in je verwerkingsregister mee te nemen. Een skill die klantgegevens verwerkt, stuurt die gegevens naar het model; dat is een verwerking en die hoort in je register. En stuurt een plugin data via een gebundelde connector naar een externe dienst, dan gelden de voorwaarden en het privacybeleid van die dienst, niet die van OpenAI. Bij een opgenomen skill via Record & Replay komt daar nog iets bij: de opname legt vast wat er op je scherm staat, dus doe geen werkwijze voor met echte persoonsgegevens in beeld. Het volledige kader staat op Codex en privacy.

Kiezen

Skill, plugin, app of MCP: wat pak je wanneer?

Vier begrippen die op elkaar lijken en in de praktijk constant door elkaar worden gehaald. Het scherpste onderscheid komt uit de documentatie zelf: een skill is de auteursvorm voor een herbruikbare werkwijze, een plugin is de distributievorm, een app of connector is een verbinding met een externe dienst, en een MCP-server is de techniek die die verbinding levert. Je gebruikt ze meestal samen, niet in plaats van elkaar.

Skill of plugin?

Een plugin is geen alternatief voor een skill maar een doos eromheen. De documentatie is expliciet over wanneer je overstapt: gebruik losse skillmappen voor lokaal auteurschap en repo-gebonden werkwijzen, en verpak ze als plugin zodra je een herbruikbare skill wilt distribueren, twee of meer skills wilt bundelen, of een skill samen met een connector wilt uitleveren. Praktisch merk je het verschil aan waar het bestand staat: een losse skill in .agents/skills, een pluginskill in de cachemap onder ~/.codex/plugins/cache.

App of MCP-server?

Dit onderscheid is bij Codex subtieler dan het lijkt, en de documentatie zegt het zelf: de bestandsnaam .app.json is een compatibiliteitsaanduiding, en de onderliggende bouwsteen is de MCP-server. Een app is dus geen aparte technologie maar een geregistreerde MCP-serververbinding met een nette naam en een pictogram. In de CLI blader je apps met /apps en voeg je er een in met $app-slug; MCP-servers die je zelf hebt geconfigureerd bekijk je met /mcp. Wil je bij een dienst waarvoor geen app bestaat, dan bouw of installeer je zelf een MCP-server.

De Claude-tegenhanger, en waar het uiteenloopt

Het formaat is gedeeld: SKILL.md met name en description werkt in beide werelden, want beide bouwen op dezelfde open standaard. Wat niet gedeeld is: de scanlocaties (.agents/skills bij Codex, .claude/skills bij Claude Code), het metadatabestand (agents/openai.yaml is Codex-specifiek), de aanroepsyntax ($ bij Codex, / en automatisch laden bij Claude) en het manifest (.codex-plugin/plugin.json tegenover .claude-plugin/plugin.json). Codex leest wel het oude marketplacepad .claude-plugin/marketplace.json en zet CLAUDE_PLUGIN_ROOT voor hooks, dus veel Claude-plugins werken met minimale aanpassing. De volledige Claude-kant staat op Claude skills.

Waar de ChatGPT-kant staat

Deze pagina gaat over Codex. Werk je vooral in ChatGPT zelf, met @-aanroepen, de Plugins Directory op het web en het delen binnen een werkruimte, dan staat dat uitgewerkt op Plugins en skills. Voor de volledige commandoreferentie van de CLI, inclusief /skills, /plugins, /apps en /mcp, is Codex-commands de plek.

Onderhoud

Skills bijwerken, opruimen en beheersbaar houden

Skills zijn goedkoop om te maken en daardoor makkelijk te laten verslonzen. Wat je nu vastlegt over eigenaarschap en versies, scheelt over een halfjaar de vraag wie deze skill ook alweer heeft geschreven en of hij nog klopt.

Er is geen versieveld voor losse skills

Dit verrast mensen: een losse skill kent geen versienummer. Alleen een plugin heeft een version-veld in .codex-plugin/plugin.json, met semantische versienummering. Wil je losse skills versiebeheren, dan is Git de bron van waarheid: historie, review via pull requests en terugrollen doe je daar. Dat is meteen het argument om teamskills in de repo te zetten in plaats van in ieders persoonlijke ~/.agents/skills.

Wat je per skill vastlegt

Houd een eenvoudig intern overzicht bij met vijf kolommen: het doel van de skill, de eigenaar (persoon of team), de laatste wijziging, de afhankelijkheden (MCP-servers, scripts, externe diensten) en de laatste keer dat iemand hem getest heeft. Dat is geen bureaucratie maar noodzaak, want er is geen ingebouwde rapportage die je vertelt welke skill hoe vaak is aangeslagen. Wil je dat weten, dan moet je het zelf bijhouden of het uit je eigen logging halen.

Opruimen levert context op

Elke actieve skill neemt ruimte in de beginlijst in, en die lijst heeft een budget van 2 procent van het contextvenster. Met tientallen skills gaat dat ten koste van de herkenning van de skills die je wel gebruikt, want bij overloop worden beschrijvingen ingekort en kunnen skills wegvallen. Loop een keer per kwartaal je /skills-lijst langs en zet wat je niet gebruikt uit met [[skills.config]]. Doe hetzelfde met plugins: in de CLI zet je een geinstalleerde plugin met de spatiebalk aan of uit, en die aan-uitstand wordt bewaard in ~/.codex/config.toml.

Marketplaces bijwerken

Een marketplace die je uit Git haalt, blijft op de opgehaalde snapshot staan tot je hem ververst. Dat doe je met codex plugin marketplace upgrade voor alles, of met de naam erachter voor een specifieke bron. Heb je met --ref een Git-ref vastgepind, dan blijf je op die ref. Voor productieomgevingen is dat de verstandige route: pin op een ref of een sha, ververs bewust, en behandel een update als een nieuwe uitrol die opnieuw gereviewd wordt, niet als een tekstwijziging.

Twee instellingen die je een keer moet bekijken

In de configuratiereferentie staan twee vlaggen die met skills te maken hebben en die je waarschijnlijk nooit hoeft aan te raken, maar wel moet kennen. features.skill_mcp_dependency_install is stabiel en staat standaard aan: hiermee mag Codex vragen om ontbrekende MCP-afhankelijkheden van een skill te installeren. En approval_policy.granular.skill_approval bepaalt of goedkeuringsvragen voor skill-scripts aan jou worden voorgelegd. Zet je het eerste uit in een strak beheerde omgeving, dan falen skills met een MCP-afhankelijkheid met een duidelijker foutmelding dan wanneer je het aan laat staan en de installatie geblokkeerd wordt.

De onderhoudsritme die werkt

Zet een halfjaarlijkse herinnering en kijk dan naar drie dingen per skill die je van buiten hebt gehaald: is de repo nog niet gearchiveerd, is er sinds je installatie iets gewijzigd dat je moet herlezen, en klopt de licentie nog met hoe je hem gebruikt. Doe dat ook voor je eigen skills, maar dan met een andere vraag: klopt de werkwijze nog met hoe jullie het nu doen? Een skill die een oude procedure vastlegt, is schadelijker dan geen skill, want hij wordt wel gevolgd.