GPT-6 Astra: Update Skills, Prompts and Project Rules

GPT-6 Astra gives teams a reason to revisit the instructions they carry from project to project. Start by identifying which rules protect a real requirement, which belong to a specific workflow, and which describe habits you no longer need. Then test a small revision on representative work. A shorter instruction file is useful only if the agent still delivers the right result and respects the project's boundaries.

OpenAI published Eric Provencher's Rethinking skills and prompts for GPT-6 Astra on September 11, 2026. Its advice is to narrow skill descriptions, load supporting guidance when relevant, revisit compulsory reading and repeated testing instructions, and make task completion explicit. OpenAI also notes that Astra can stop earlier than a user intends. Those are vendor observations, not measured gains in our projects. The audit method, examples and rollout worksheet below are Digital Applied's proposed implementation.

Imagine a coding agent asked to correct a broken link. Before editing it, the agent reads a deployment manual, a database guide and an entire architecture document. It then runs a broad test suite twice and asks whether it may open the local result. Each action may follow a well-intended rule. Together, they turn a small repair into a process that the user never needed.

The first audit question is concrete: what bad outcome does this instruction prevent? A rule that preserves customer data has a clear answer. A rule that requires every document to be read before every change may have been added after one difficult incident. Its useful part could be the connection between a certain kind of change and the relevant document.

Collect the active project entry point, the documents it references, relevant skill files and the task prompts the team reuses. Read package scripts to establish which checks actually exist. Record conflicting rules alongside their paths. Do not silently decide that the longest document, the newest-looking comment or the strongest wording wins.

For each instruction, choose one of five actions:

• Keep: it states an enduring requirement or a verified project constraint.
• Narrow: it is useful for a defined class of changes but currently triggers too broadly.
• Move: it belongs in a workflow reference, a nested project document or a task prompt.
• Automate: a formatter, validator or test can enforce it more reliably.
• Remove: it duplicates another source or describes an obsolete workflow, with evidence for that conclusion.

Give every proposed removal a reason. An instruction about a previous outage might still encode an architectural limit even when its original explanation looks dated. The goal is to make relevant constraints easier to find, not to achieve a target word count.

A skill description is a selection aid. The official skill documentation explains that the name and description are available before the full instructions load. Codex may shorten descriptions when the initial skill list is crowded. Put the actual job near the beginning, and give a clear trigger rather than a long catalogue of loosely associated topics.

Consider an illustrative skill for reviewing article sources. This description is too broad: “Use for writing, websites, marketing, research and content.” A narrower version tells the agent what work justifies loading it:

name: article-source-review
description: Check factual claims and citations in a draft article before editorial approval.

Its root document can route the reader to the relevant material:

# Article source review

For a new draft, use references/new-article.md.
For a factual update, use references/update-review.md.
Use scripts/check-links.mjs to check citation destinations.
Return unsupported claims with their locations and proposed corrections.

These paths are examples: create and verify the referenced resources before adopting them. The router should carry any boundary that applies throughout the workflow. Detailed instructions about a particular source type can live in its reference file. Executable checks belong in scripts when the result is deterministic.

Test selection with neighboring requests. A request to verify article claims should select this skill. A request to change a footer color should not select it merely because the project is a website. A narrowly written description that fails to activate for its intended task also needs revision.

For repositories used by multiple agents, keep the outcome and project constraints shared. Add model-specific procedure only where a test shows it is needed. OpenAI's Astra article cautions that instructions useful for Sol or Luna can constrain Astra; it does not establish that every workflow should lose its detailed instructions. Our existing coding-tool instruction reference helps separate file discovery from the content of those files.

Project instructions should answer questions the repository itself cannot make obvious: which commands are authoritative, which behavior must survive an edit, and where specialized decisions are documented. They should also make the source of authority clear when several tools use different entry files.

For example, Digital Applied's repository uses an AGENTS.md entry point that directs readers to CLAUDE.md. That is a local convention. OpenAI's AGENTS.md documentation describes an instruction chain from global guidance through the project path to the current working directory, with nearer instructions taking precedence. It also documents override and fallback filenames. A randomly named document does not become active simply because it exists in the repository.

When auditing another project, establish its actual entry point instead of copying our filenames. Then use a compact routing section, such as this illustrative example:

Use docs/architecture.md for changes to service boundaries.
Use docs/data-model.md for schema or persistence changes.
Use docs/release.md when preparing a release.

The formatter defines code style.
The release checklist defines the required release checks.

For this site's blog, static rendering, canonical metadata and the enforced article frame are meaningful constraints. An Astra cleanup should preserve those contracts and the repository's required validation. A migration guide that simply deletes every line containing “always” or “never” could remove the instruction preventing a costly rendering regression.

Move repeatable style rules into tooling where practical. Keep an explanation when it prevents a non-obvious mistake. A useful root file lets the agent find the correct procedure while leaving the procedure in one maintained place.

“Improve this page” can mean writing a draft, changing the code, checking the browser or releasing it. A task prompt should identify the intended finished state. Our recommendation is to name the deliverable, the evidence needed to accept it, and the first action outside the current authorization.

For a local page repair, a prompt could say:

Fix the reported layout issue in the current project.
Complete the implementation, run the required checks that apply,
open the local page, and correct problems caused by your change.
Keep working until those checks pass or a specific blocker remains.
Report the changed files, observed result and unresolved limitations.
This task ends with a verified local change; production release is separate.

If release is already authorized, name the target and the release evidence instead. Do not reintroduce a review stop that contradicts the user's request. Conversely, a request for an audit should not silently become authorization to change every project it discovers.

Distinguish repeated permission prompts from substantive boundaries. A team can authorize edits and test reruns against a confirmed disposable fixture environment while retaining a separate decision for changing live records. Before writing that permission into a shared file, verify that the test commands really are isolated. A sentence in a prompt cannot make a production-connected environment disposable.

Use runtime permissions, account scope and service-side authorization to enforce access. Natural-language instructions help the agent choose actions; they are not an access-control mechanism. Keep specific publication, customer-communication and production-data boundaries where the workflow requires them.

This extends the acceptance-criteria approach in our guide to defining done. The Astra-specific task is to review old stopping rules alongside the completion criteria, so the two agree.

The reusable unit is a decision record, not a universal AGENTS.md. A marketing site, an authenticated business application and a document workflow can share an audit method while requiring different checks and permissions. Keep project-specific facts in the project that owns them.

Use this proposed worksheet to make an instruction change reviewable. The examples describe decisions to investigate; they are not findings about uninspected repositories.

Add the file path, current wording, replacement, owner and a rollback reference to each row in your working copy. That makes disagreements specific. A reviewer can approve narrowing a trigger while rejecting removal of a required check.

For a site, use a small content change to test discovery and rendering constraints. For a business application, choose an isolated change with an authorization check. For a file workflow, test the exported artifact in the application that will consume it. These are suggested pilot categories; choose actual tasks from each project's recent work.

OpenAI's prompt-engineering guidance recommends evaluating prompt behavior as prompts and models change. Apply that principle to repository instructions. Save a baseline and change a coherent part of the guidance first, so a regression has an identifiable cause.

Our proposed pilot uses a typo repair, a bounded bug fix, an ambiguous request and a task that reaches a real permission boundary. Keep the starting code, prompt, model, effort setting and tool access comparable. Run the old and revised instructions in fresh sessions. Repeat cases where outcomes vary; one successful run is insufficient to establish reliability.

Record whether the task met its acceptance criteria, which irrelevant documents or skills loaded, how many unnecessary user interruptions occurred, and whether required checks and boundaries held. Record elapsed time and token usage where available. Do not present fewer tool calls or a smaller instruction file as proof of better work.

In multi-model projects, include the models the team actually uses. If a smaller model regresses, investigate the missing guidance and restore it at the narrowest useful scope. Our model-switch testing guide explains why representative work matters more than a generic score.

Adopt the revision in one project, observe normal work, and then repeat the audit elsewhere. Retain a versioned rollback. This article provides an implementation plan; it does not claim that Digital Applied has already completed this rollout or measured performance improvements across its projects.

Use this prompt for a bounded first pass. It asks for concrete replacements and an evaluation plan before any instruction file is changed:

Audit this project's active agent instructions and relevant skills
against OpenAI's September 11, 2026 GPT-6 Astra guidance.

Identify the instruction entry points and conflicting sources.
For each proposed change, show the path, current wording,
replacement, reason, preserved constraint and validation case.
Check broad skill triggers, compulsory reading, duplicate rules,
unnecessary test repetition, approval pauses and early stopping.

Verify commands and environment assumptions from this project.
Preserve required checks, authorization and release boundaries.
Account for other models used by contributors.
Do not modify files during this audit.
Finish with a prioritized patch proposal and a small pilot plan.

After review, a separate implementation request can authorize the selected edits and pilot checks. For teams ready to apply this across several repositories, our AI transformation service can help define the acceptance criteria and project-specific rollout.