Grok Coding

Grok 4.7 Coding Prompts That Play to Its Strengths

Grok 4.7 scores 71.0% on DeepSWE v1.1 and 38.0% on Terminal-Bench 4.0. That spread tells you how to prompt it: give it bounded tasks with a clear finish line rather than open-ended sessions. These eight prompts are built around that, and they also push back on the token consumption problem several reviewers flagged at launch.

⌨️ 8 prompts 🕐 Updated Sep 21, 2026

💡 How to use these prompts: Replace everything in [BRACKETS] with your specific details before sending. Click Copy to copy any prompt to your clipboard instantly.

Bounded Bug Fix

Keeps Grok 4.7 inside the bounded-task profile it scores well on and stops scope creep that burns tokens.

Fix exactly one bug in the code below. Do not refactor anything else. Do not add comments. Do not improve naming. Before you write any code, state in one sentence what the bug is and which line causes it. If you cannot identify a single clear bug, say so and stop. Then output only the changed lines with three lines of surrounding context. CODE: [paste]

Test First, Then Implement

The explicit stop keeps a long task broken into checkpoints, which is where Grok 4.7 is most reliable.

Write failing tests for this function signature before writing any implementation. Step 1: list the edge cases you will test, numbered. Stop there and wait for me to approve the list. Do not write the implementation yet. Do not write the tests yet. Only the numbered list of cases. SIGNATURE: [paste]

Diff Review With a Budget

The five-issue cap and the triggering-input requirement cut speculative findings and reduce output tokens sharply.

Review this diff. Report at most five issues, ordered by severity. For each issue give: file and line, one sentence on what breaks, and the concrete input that triggers it. If you cannot name a triggering input, do not report the issue. Do not comment on style, formatting or naming. Do not suggest refactors. DIFF: [paste]

Single-Pass Migration

Migration is a bounded task with a clear finish line, which suits the DeepSWE profile. The NEEDS REVIEW marker avoids silent guesses.

Convert this file from [source] to [target]. Preserve every behaviour exactly, including error handling and edge-case returns. Output the complete converted file and nothing else. No explanation before or after. No notes about what you changed. If any construct has no direct equivalent, insert a comment on that line reading NEEDS REVIEW and continue. FILE: [paste]

Explain Before You Touch

Cheap first pass before an expensive one. Catches misunderstandings before the model starts editing.

Read this code and explain what it does in under 120 words. Write for a developer who has never seen this codebase. Then list any assumption the code makes that is not checked anywhere in it. Do not suggest changes. Do not write code. I will decide what to change after reading your explanation. CODE: [paste]

Terminal Task With Checkpoints

Grok 4.7 scores 38.0% on Terminal-Bench 4.0, so long unattended shell sequences are the weak spot. Forcing checkpoints works around it.

I need to [describe task] from the command line. Give me the commands one step at a time. After each command, stop and wait for me to paste the output before giving the next one. Do not chain commands with and and. Do not assume what the output will be. If a command could be destructive, say so before giving it.

Cost-Aware Refactor

Removes the planning and explanation phases that drive the high token consumption reviewers measured at launch.

Refactor this file for readability only. Do not change behaviour. Work in one pass. Do not produce a plan first. Do not explain your reasoning. Output the refactored file, then a maximum of three bullet points on what changed. If the file is already clear, say so and output nothing else. FILE: [paste]

Second Opinion on a Model Decision

Cheap verification pass. At six dollars per million output tokens this is an affordable second reviewer on expensive model output.

Another model produced the code below for this task: [describe task]. Do not rewrite it. List only what is factually wrong or will fail at runtime, with the specific input that causes each failure. If nothing will fail, reply with the single word CORRECT and stop.