OpenAI’s Eric Provencher has written down what should come out of your projects when you move to GPT-6 Astra. The post is about Codex, but if you work with Claude Code, you are reading about your own CLAUDE.md.
The core claim, in one line: instructions that piled up over months either eat context or push the model to stop too early.
Skills: shorter is sharper
Skills are prompts stored as Markdown files, often bundled with resources and scripts. Their name and description go into the model’s context so it knows when to reach for them. Collect too many and you get a problem: Codex truncates the descriptions to make them fit. The model sees less of each one and picks worse.
Provencher’s example. Bad:
Create and validate Postgres schema migrations. Use when working with databases, queries, models, or persistence.
Good:
Create and validate Postgres schema migrations. Use when adding or changing a migration, or reviewing its rollout.
The first version fires at anything vaguely database-shaped. His second point is progressive disclosure: for a skill covering several workflows, the root document should be a minimal router pointing at supporting docs and scripts. Every file the model reads costs context and moves compaction closer.
Third: plenty of skills are written as step-by-step recipes. Newer models handle ambiguity better, so that level of detail can now hurt. It gets tricky with repository skills, because they also steer other people’s agents. Guidance that helps Sol or Luna may already box Astra in.
AGENTS.md: cut the required reading
Rules in AGENTS.md apply whenever the model works in your repository, so Provencher suggests revisiting each one on a schedule. A stack of docs before every edit is overkill for a typo fix — Astra can work out what it needs to read.
So instead of “before every edit, read architecture.md, database.md and deployment.md”, point selectively: architecture.md for service boundaries, database.md for schema changes, deployment.md when shipping. And keep those docs current, or the pointer is worthless.
Older models needed a nudge to run tests. Astra does it on its own, so the same instruction now produces unnecessary test runs. The reverse also holds: an explicit permission cuts down repeated confirmation requests. For a local suite using disposable fixtures with no production access — run them, fix failures caused by the requested change, rerun affected tests, no approval at each step.
Boundaries: too strict is also wrong
If you once used strong language to stop a model from acting on its own, look at those sentences again before switching. OpenAI calls Astra its most aligned model and credits it with better judgment — which means it may take an old prohibition so literally that it halts where you’d happily have let it continue.
Same theme at the end: Astra stops earlier than GPT-5.6 Sol. It reaches a first implementation and comes back for review while work is still open. Provencher’s advice is to define “done” before you start. If running it, inspecting the result and fixing what breaks are part of the job, put that in the request.
Why this is on a Claude site
Skills, a project file full of standing rules, permissions, compaction — that’s the same machinery Claude Code runs on. And the same hoarding instinct: if you’ve been tending a CLAUDE.md for a year, some of those rules were written against problems that no longer exist.
Provencher’s closing suggestion carries over directly: have the model audit your own setup instead of walking every line by hand. Convenient, and at least checkable — the proposal comes back before anything changes.
Sources: OpenAI Developers: Rethinking skills and prompts for GPT-6 Astra, The Decoder