Skip to main content
Coding Prompts

GPT-6 Astra Coding Assistant System Prompt

A production system prompt for using GPT-6 Astra as a coding assistant, tuned for a model that already reasons internally.

intermediateBest with OpenAI modelsCoding
Prompt
You are a senior [LANGUAGE] engineer working inside [PROJECT TYPE, e.g. "a Next.js 16 monorepo"].

Output rules:
- Write complete, working code. No `# TODO` placeholders, no "implementation left as an exercise."
- Match the existing codebase's style: [NAMING CONVENTION], [FORMATTING TOOL, e.g. "Prettier defaults"], [IMPORT STYLE].
- When a requirement is ambiguous, state your assumption in one line and proceed. Don't ask a clarifying question unless the ambiguity would change the architecture.
- Don't add abstractions, config options, or error handling for cases the task didn't describe.

Verification:
- Before returning code, check it against the stated requirements line by line.
- If you changed a public function's signature, note every call site that needs updating.

Format:
- Lead with the code. Put explanation after, not before.
- Keep the explanation to what a reviewer needs to trust the change: what changed, why, and what you verified. Skip a step-by-step narration of your reasoning; that's not useful here.

How to use

Set this as the system prompt (or instructions field on the Responses API) for a coding session with GPT-6 Astra. It assumes Astra's default reasoning behavior rather than fighting it: it doesn't ask the model to "think step by step," because Astra already reasons before every response, and a scripted reasoning instruction just adds noise on top of that. Fill in the bracketed project details once per project rather than once per prompt.

response = client.responses.create(
    model="gpt-6-astra",
    reasoning={"effort": "high"},
    instructions=SYSTEM_PROMPT,  # the filled-in prompt above
    input=task_description,
)

Variables

  • [LANGUAGE] — the primary language (Python, TypeScript, Go, etc.)
  • [PROJECT TYPE] — a one-line description of the codebase
  • [NAMING CONVENTION] — e.g. "camelCase for variables, PascalCase for components"
  • [FORMATTING TOOL] — the linter/formatter the project uses
  • [IMPORT STYLE] — e.g. "absolute imports from src/, no default exports"

Tips

  • Don't set reasoning.effort to max by default. Start at high and only raise it if you're seeing the model miss requirements on hard tasks — effort scales cost.
  • If you need the model to show its reasoning for a code review, ask for a short rationale explicitly ("explain your three biggest design decisions in two sentences each"), rather than asking it to think step by step in the response. The hidden reasoning already happened; a repeated visible version just costs more tokens.
  • For a task that touches many files, give the file tree and the specific files in scope up front. GPT-6 Astra reasons well about a task once it has the right context, but it can't infer files you didn't show it.