Rebuilding my Codex setup for Astra

A quota reset was the trigger, but the useful result was not more quota. It was a reason to inspect how I had taught Codex to work. Instructions had accumulated across global guidance, repository files, skills, plugins, and prompts. Each addition had once solved a real problem. Together, they were starting to create another one: too much context before the actual task had even begun.

The timing mattered. An OpenAI update acknowledged several Astra quality problems, including older skills firing too often, an experimental context-management path that could stop early or respond to an older message, and misconfigured serving engines. The same update said those issues had been addressed. Tibo's public explanation was reassuring, but it also exposed the part I controlled: the quality of the instructions I was sending into the product.

The audit started with subtraction

My first instinct had been to make the agent safer and more reliable by documenting every useful behavior. That works until the instructions become a second codebase. A simple edit can then load a repository map, several workflow documents, multiple overlapping skills, and a review doctrine written for a harder task.

OpenAI's article on rethinking skills and prompts for GPT-6 Astra gave that problem a useful shape. Skill descriptions should be short and specific. Multi-workflow skills should reveal detail progressively. Repository guidance should point to documents when the current task needs them, not force every document into every task. Completion should be explicit enough that the agent knows whether a first implementation is a checkpoint or the finish line.

I applied that logic at two levels. Global guidance keeps reusable defaults and the boundaries that must follow me across workspaces. Each repository owns its local commands, constraints, and routes to deeper documentation. Repeated explanations were removed. OpenAI's own example captures the trigger rule well: “use this skill for any database work” is too broad when the actual workflow is creating or reviewing a migration.

The model lanes I kept

A community lane map from Johnny Nel captured a useful core: one model orchestrates, another applies, and a third judges. I kept the principle but made delegation conditional. Naming a lane is useful. Launching a worker for every lane is not.

The effort labels are defaults, not a routing constitution. The real rule is to use the smallest capable setup for the uncertainty that remains. Most repository work stays with one agent. Terra receives a task when implementation or verification is genuinely separable. Astra receives one bounded, read-only question when the primary pass leaves a difficult risk worth paying to resolve.

This also avoids an easy trap: using a premium reviewer on the full conversation, then asking it to rediscover the entire project. A narrow handoff carries the relevant diff, claims, constraints, and acceptance criteria. It does not carry every tool output that led there.

The prompt I no longer make users write

A five-field task frame proved useful during the cleanup. It prevents the agent from optimizing the wrong project, inventing a finish line, or treating local implementation as permission to publish. But turning it into a form the user must complete every time would add ceremony to the exact workflow I was trying to simplify.

I now treat it as an internal checklist. The agent infers what the conversation and repository already establish, and asks only when a missing field would materially change the result or the authority to act.

Objective: [the concrete result]
Scope or project: [repository, service, or artifact]
Important constraints: [safety, compatibility, time, cost]
Definition of done: [observable evidence]
External actions allowed or forbidden: [push, publish, deploy, send]

Infer any field already established by the conversation or repository.
Ask only when missing information would change the result or authority.

The distinction between “definition of done” and “external actions” matters. A finished local change can require tests and a browser check while still forbidding a push. A publication task can authorize a production deploy while leaving social posting outside the boundary.

Skills became routers, not itineraries

The largest skill in the audit mixed several workflows into one eager instruction file. It described installation, remote services, optional providers, tool discovery, generation, validation, and delegation in a single path. Most tasks needed only one of those branches.

Its root file is now a small router. It identifies the request, points to one relevant reference, and stops. Installation instructions load only for installation. Remote-service instructions load only when a remote service is requested. Optional providers do not activate because they might be useful. Subagents do not appear because a workflow happens to have several steps.

Use this skill only for: [one precise workflow].

Route the request:
- If creating: read references/create.md
- If reviewing: read references/review.md
- If publishing: read references/publish.md

Read one route by default. Load another only when the task crosses that boundary.

The same rule applies to plugins. A connector is justified by the external system it uniquely reaches, not by the chance that it could become useful later. Local inspection remains the cheapest source of truth for repository-local work.

What the Astra review still caught

After the cleanup, I asked Astra one question: review the resulting guidance read-only and find conflicts that could still make an agent waste context, stop too early, or cross an authorization boundary. The new behavior was noticeably more disciplined. It stayed inside the review, returned a small set of concrete findings, and did not try to execute the whole project.

The review was still valuable. It found instructions that were locally sensible but contradictory when combined, including a shell-scoping detail that could make nested workflow references unreliable. Bounded implementation agents applied the fixes, and a final pass checked the integration rather than repeating every earlier investigation.

That is the reviewer pattern I want to keep: ask a distinct question, preserve a read-only boundary, reconcile every finding against current evidence, and reject a finding when the evidence does not support it. A stronger model is a better critic, not an automatic authority.

Review this result read-only.

Question: [one difficult residual risk]
Scope: [exact files, diff, or artifact]
Check for: [specific failure modes]
Evidence required: cite the exact location for every finding.
Do not implement fixes or expand into unrelated review areas.
Return only actionable findings, followed by residual risk.

What I can and cannot claim

Community reports now describe Astra usage as feeling normal again, and Salio's post is one visible example. My own follow-up review also behaved much better than the sessions that triggered this audit. Those are useful signals, not a benchmark.

I do not have comparable per-agent telemetry for the old and new setups, so I cannot honestly attach a percentage to the improvement. The claims I can support are structural: fewer always-loaded instructions, narrower skill triggers, smaller handoffs, fewer duplicate reviews, bounded tool output, and explicit stopping conditions. All of those remove known ways to spend context without advancing the task.

The setup I would start with today

If I were rebuilding from zero, I would begin with one short global file, one concise repository router, and no project skill until a repeated workflow proved it deserved one. I would keep a single primary agent by default, delegate only independent work, and reserve an independent reviewer for a question whose failure cost exceeds the handoff cost.

I would also write completion in observable terms: the affected check passes, the rendered screen has been inspected, the external state has been read back, or the publication is live at a named URL. That gives a thorough model permission to continue without giving it permission to do something unrelated.

The resulting setup is less impressive on paper. It has fewer automatic tools, fewer mandatory agents, and fewer pages of doctrine. In practice, that is the point. The orchestration is visible when the task needs it and almost invisible when it does not.

I will keep sharing what survives real use on my X account.