GPT-6 Astra Prompt for Long, Tool-Heavy Work

Copy, then replace the variables.

Prompt v1.1

Work on one bounded deliverable using the brief below as the working contract.

OUTCOME
{{Describe the decision, artifact, or change that must exist when the work is done.}}

SOURCE OF TRUTH
{{List the files, records, URLs, screenshots, or rules that may support the work, in priority order. State what to do if a required source is missing or conflicts with another source.}}

DELIVERABLES
{{List each required output, its format, destination, and intended reader.}}

BOUNDARIES
- In scope: {{included work}}
- Out of scope: {{excluded work}}
- May do without asking: {{read-only checks and reversible actions}}
- Requires separate approval: {{publication, external messages, purchases, destructive actions, production changes, or other consequential actions}}

BUDGET AND STOP RULES
- Tool, time, cost, retry, or source-volume limit: {{use only limits relevant to this task}}
- Stop and return a partial handoff when: {{missing evidence, repeated failure, conflicting authority, exhausted budget, or another concrete condition}}
- When close to the limit: {{prioritize the exact deliverable and its highest-risk verification}}

QUALITY BAR
{{Define the factual, functional, editorial, visual, privacy, or accessibility checks connected to real failure risks.}}

Before acting, return a short Brief receipt with the understood outcome, deliverables, source boundary, permitted actions, approval gates, budget, stop conditions, and unresolved questions. Ask a question when the missing answer would materially change the deliverable, authority, or an irreversible outcome. Otherwise state a narrow assumption and proceed.

While working:
1. Keep claims tied to supplied or verified evidence. Mark a gap rather than filling it.
2. Inspect the actual artifact or runtime state before changing it, and preserve unrelated work.
3. For long work, checkpoint after discovery, before a consequential action, and before completion. State what changed, what remains, and what evidence exists.
4. If a requirement changes, return a Change receipt with PRESERVE, STOP, CHANGE, NEXT, and NEED. Treat cleanup and cancellation of already-started work as separate application responsibilities.
5. Stay within the budget and stop rules. When a limit is reached, return the safest useful partial result and the evidence needed to resume.

Before saying complete, verify the deliverables against the quality bar. End with:
- Delivered: exact artifacts or decisions
- Verified: checks actually run and their results
- Not verified: checks not run and why
- Decisions needed: unresolved approvals or choices
- Evidence: source locations, test records, or runtime readback

Use accurate state labels: a draft is not published; a local check is not a production check; a syntax check is not a behavior test; an accepted or queued action is not completed.

Expected output: A brief receipt, the requested work, useful checkpoints, and an evidence-based completion or partial-handoff summary.

Use this brief when one deliverable takes long enough to accumulate sources, tool state, approvals, and changed requirements. It gives GPT-6 Astra a working boundary and gives the reviewer a concrete way to tell whether the task finished, paused, or ran out of budget.

Choose the right brief

Need	Use
Turn supplied facts into one short draft with unknowns preserved	Reusable Work Brief Prompt
Run a long task across several sources or tools, with checkpoints, a budget, approvals, and possible requirement changes	This GPT-6 Astra End-to-End Work Brief
Design approval logic in an application rather than tell a model how to report it	Human approval gates guide

For a rewrite, extraction, or single response, the shorter brief is easier to use. This longer contract earns its space only when the work can diverge while it is running.

A filled example

Suppose build B-17 passed 42 unit tests and deployed to staging, but its keyboard check has not run and nobody authorized production. The high-value fields are concrete:

OUTCOME
Return a release decision for build B-17 and a list of remaining gates.

SOURCE OF TRUTH
1. ci/build-B-17.json for test status
2. staging/deploy-B-17.json for staging state
3. release-policy.md for required checks
Missing required evidence means HOLD.

DELIVERABLES
A Markdown decision note for the release owner. No deployment.

BOUNDARIES
May inspect supplied records. Requires separate approval for production.

BUDGET AND STOP RULES
Use only the supplied files. Stop after the decision note. Stop immediately
if a required record is missing or the sources conflict.

QUALITY BAR
Name every required check as passed, failed, or unrun; keep staging and
production status separate.

Version 1.0 of the prompt was run once against that frozen scenario. Astra returned HOLD, preserved the unrun keyboard check, and did not turn staging evidence into a production claim. Version 1.1 adds the budget-and-stop section after editorial review; that revised text is structure-checked but has not been rerun as a model-behavior test.

How to fill the six fields

Outcome: name the artifact or decision that must exist, not a feeling such as “make this professional.”
Source of truth: list exact files or records in priority order and say what happens when one is missing or conflicts.
Deliverables: separate a draft, changed file, test result, deployment, and public readback. They are different outcomes.
Boundaries: distinguish read-only or reversible local work from publication, messages, purchases, deletion, and production changes.
Budget and stop rules: set relevant limits on tool calls, elapsed time, spend, retries, or source volume. Name conditions that should produce a useful partial handoff instead of another attempt.
Quality bar: connect each check to a real failure risk, such as recalculation, keyboard use, source coverage, or destination readback.

What the prompt returns

The first reply is a brief receipt: the model's reading of the outcome, sources, deliverables, permissions, budget, and unresolved decisions. Correct a material misunderstanding there. During longer work, checkpoints appear after discovery, before consequential action, and before completion. If a requirement changes, the model reports what remains valid, what should stop, the replacement requirement, the next safe step, and any cleanup it cannot infer.

The closing handoff separates delivered artifacts, checks actually run, unverified items, approvals still needed, and evidence. These reporting instructions make errors easier to see; the host still needs real permissions, cancellation, idempotency, and audit controls.

Adapt it to the risk

Remove irrelevant examples and replace them with domain-specific gates. A spreadsheet may need recalculation and formula-error scans; a browser flow may need keyboard checks and destination state; a publication task needs a public readback. Move stable team rules into project instructions or a Skill, leaving task facts in the brief.

A large context window is not a reason to paste unrelated or unapproved material. Keep confidential data within the account and workflow approved for it, pass only the sources the task needs, and stop when the stated budget or evidence boundary is reached.

GPT-6 Astra End-to-End Work Brief

Best for

Do not rely on it for

Copy, then replace the variables.

Choose the right brief

A filled example

How to fill the six fields

What the prompt returns

Adapt it to the risk

Use this prompt with its tested guide.

A Practical GPT-6 Astra Prompting Guide for Long, Tool-Heavy Work

How to Change Requirements While GPT-6 Astra Is Working

How to Add Human Approval Gates to AI Agent Tool Calls