OpenAI is telling developers that the guardrails they wrote for earlier coding models have become the problem. In new guidance on Codex skills and repository instructions, Eric Provancher argues that GPT-6 Astra does better with short skill descriptions, documentation read selectively rather than on every change, and permissions granted in advance — and that the detailed step-by-step procedures teams wrote for previous generations now slow the model down. The advice extends the prompting recommendations OpenAI published for Astra recently.
Skills here are prompts saved as Markdown files, which can also carry resources and scripts. Provancher says they work best for a specific workflow or application. Their names and descriptions are loaded into the model's context so that Codex can pick the right one for a task, and that is where the failure starts: once a repository accumulates too many skills, Codex has to shorten the descriptions and loses the information it needs to choose correctly. Contradictory descriptions and overly broad scope do the reverse damage, pulling instructions the model does not need into context.
His fix is to keep scope descriptions short and exact. A skill for Postgres schema migrations should fire only when a migration is being created or changed, or when its deployment is being verified. If a skill genuinely spans several workflows, its main document should briefly route the model to the supplementary docs and scripts it needs, so the model reads only those — every extra document spends context and moves the model closer to summarizing.
Detailed step-by-step sequences can also slow newer models down, because they handle nuance and ambiguity better on their own. Shared skills complicate that, since they apply to every team member's agent: what suits Sol or Luna may be too rigid for someone working with Astra.
Repository rules in AGENTS.md need the same periodic review. Requiring the model to read several documents or a full project overview before every change is excessive when the change is a typo fix, and Provancher's position is that Astra can work out for itself what it needs. Rather than forcing architecture.md, database.md and deployment.md on every edit, he suggests conditioning them: architecture when service boundaries change, database documentation when schemas change, deployment notes when changes ship. The documents also have to stay current.
Explicit permissions cut down repeated confirmation requests for safe operations. For local tests running on temporary data with no access to production, AGENTS.md can simply state that the agent may run tests, fix errors caused by the requested change, and re-run the affected tests without asking the user again.
The same applies to the strict approval rules developers introduced because earlier models behaved unpredictably. OpenAI's position is that Astra judges situations better, but that it may follow those old constraints too literally and stop where the developer expected it to keep going. Known-safe workflows should be permitted explicitly.
Then there is the line worth sitting with. Even with no extra constraints in place, Astra can stop earlier than GPT-5.6 Sol. Provancher's remedy is to define "done" in advance: if the agent is supposed to implement a change, run it, check the result and fix what breaks, all four have to be named in the prompt, because asking for a report right after the first implementation sets the stopping point there.
That is a behavior change described as a prompting problem, and the framing is doing work. A model that halts earlier than its predecessor on identical instructions is a regression from the developer's seat, whatever it looks like from the lab's. The guidance is accurate advice for living with it; it is not an explanation of it.
The broader read is that prompt scaffolding is a depreciating asset. Every AGENTS.md rule, every skill, every approval gate in a repository was written against one model's specific failure modes, and the next model arrives with different ones. The advice is sound and close to unactionable at scale, because it asks teams to audit prose that no tooling audits, hunting for rules that are not wrong so much as expired.
Notably absent from the guidance is any mechanism for the problem it raises itself. It acknowledges that a shared skill hits every team member's agent and that what fits Sol or Luna may be too rigid on Astra, then offers nothing for scoping a skill per model. A team in the middle of a migration has to decide which generation its repository is written for, and everyone still on the older model pays for that decision.
The trade in an agent that reads your repository is that your repository becomes part of the model's behavior. Which means the instructions shaping GPT-6 Astra today were mostly written by people optimizing against a system that no longer exists.