Look at any builder's prompt history and you'll see a collection of highly specific, chaotic, one-off prompts. We use AI to debug a single error message, refactor a messy email, or generate a quick boilerplate.
If you sit down with people who consistently ship high-quality work, you'll find something interesting. They aren't just improvising. They have a set of go-to prompts they have tweaked and improved over time and used on nearly every project.
I asked some of my peers and leaders a simple question: "What prompt do you use most often, and why?"
What they shared wasn't just a list of arbitrary commands. Here's the unfiltered look at the prompts our team refuses to ship without, and more importantly why they use them.
Listed in alphabetical order.
Build a spec
Maja Bilić
Senior Outbound Product Manager • Engineering
Follow on LinkedIn
The prompt:
Act as a cynical Principal Architect and Technical PM. I want to
build a [product] that allows [user] to do [action]. Do not write
code. Analyze this concept and list the top 5 technical, UX and
architectural considerations. Then ask me key questions for each of
the 5 considerations so we can work together on building the spec.
Once you have all the answers, create a PRD doc and implementation
plan. Don't over engineer or over simplify the design or
implementation plan.
Why? I have written bad PRDs and I have read many bad PRDs. This prompt ensures I use the persona of a cynical Architect / PM who helps distill the idea, critique the approach and concept, and collaborate on defining the most important pieces. This way I make sure I work through the plan with an agent's help while also developing the product design idea further. I also love the guardrail of not over engineering or over simplifying things - AI tends to do that sometimes, especially when writing product design docs.
Widget tests
Andrew Brogdon
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn
The prompt:
I'd like to partner with you on increasing the robustness of this
project by creating widget tests. If you haven't already, please
read the Flutter team's skill for creating widget tests
(https://github.com/flutter/skills/tree/main/skills/flutter-add-
widget-test).
Then, let's do these things:
* Examine my application's codebase to identify areas of the UI/UX
that are not being tested properly.
* Determine if the existing code is written in a testable way (are
dependencies injected? Are domains loosely or tightly coupled?
Etc.).
* Determine which domains require more rigor than others.
* Create an overall testing plan for the application.
* Determine which areas of functionality are already aligned with
that plan, and which are missing tests.
* Create a plan to implement those tests.* Execute that plan.Do
not proceed from one step to another unless you are completely
confident about your reasoning.
You are encouraged to as many questions as needed.
Why? My favorite use of agentic coding tools is to actually do all the things I used to feel guilty about not doing in my projects. Proper testing is definitely on that list. The official skills from the Dart/Flutter team do a great job of instructing agents on what good widget tests look like, so combining it with this prompt (which essentially just fits those steps into my own coding workflow) helps me reduce the toil required to maintain reliable, guilt-free codebases.
Find all the tests / Clean-up commit
Aja Hammerly
Director of Builder Relations • Engineering
Follow on X, LinkedIn
The prompt:
Run all the tests and identify any missing tests and write them.
Pay special attention to edge cases and race conditions.
Find any unused code, embarrassing comments, comment to code
inconsistencies, unresolved TODOs, or other things in this commit
that shouldn't be in there.
Why?
I find that when I'm working on code I'll often get extremely focused on the "happy path", the main path I want a user to take through the code. While I'm focused on that I'll put in TODO or FIX comments on edge cases I don't want to think about yet. I'll also forget to update comments and leave debugging comments in sometimes. And while I try to follow test driven development, I don't always get tests in on all the edge cases. I run these two prompts, usually in a new conversation without the development context as a first round of code review before submitting to an AI or human reviewer for the next step. This ensures that what I've built is in good shape for others to review and use.
Check for correct and compliant permissions
Rich Hyndman
Head of Antigravity Developer Relations • Engineering
Follow on X, LinkedIn
The prompt:
Run a comprehensive check on this Android project to ensure all
permissions are correct and compliant. Perform the following steps:
1. Locate and analyze all 'AndroidManifest.xml' files (including
main, debug, and flavor-specific manifests), extract a master
list of declared '<uses-permission>' tags.
2. Cross-reference these declared permissions against the codebase
to verify where they are actually used. Identify any bloatware
or unused permissions that can be safely removed.
3. Check the Kotlin/Java source files to ensure that all runtime
permissions implement the dynamic runtime permission request
flow 'checkSelfPermission','onRequestPermissionsResult' or the
Activity Result API.
4. Verify that any hardware features associated with the
permissions (like android.hardware.camera) are correctly
declared. Output your findings as a Markdown report. Provide
file paths and suggested code diffs for any fixes. Do not make
any file edits until I approve the plan.
Why? Antigravity, with Gemini 3.5 Flash and the Android plugin is an excellent Android development partner! Checking for the correct permissions can keep your app running smoothly and help avoid delays when uploading to the Play Store.
Conduct code review
Shir Meir Lador
Head of AI, Developer Relations • Engineering
Follow on X, LinkedIn
The prompt:
Act as a strict, highly analytical Principal Engineer conducting a
pre-production code review. You have incredibly high standards and
zero tolerance for fragile, "happy-path" code. Your goal is to
guide me to write bulletproof, production-ready systems.
Grade my uncommitted changes on an A-to-F scale for production
readiness.
Do not award an "A" unless my code is exceptionally robust.
Specifically, analyze the changes for:
1. Efficiency: Redundant API calls, wasteful database queries, or
un-cached resource leaks.
2. Resilience: Silent failure points, lack of explicit error
boundaries, and missing rate-limit fallbacks.
3. Architecture: Tight coupling and lack of clear separation of
concerns.
For every issue, explain pragmatically where the code is vulnerable
to real-world production failures. Then, provide the exact git
diffs needed to upgrade my code and earn that "A."
Why?
If you ask an LLM to review your code, it almost always defaults to being polite. It tells you your naming is clean, suggests a few docstrings, and hands you a green checkmark. But polite reviews don't prevent production outages. I like this prompt because it completely cuts through that AI fluff. By forcing the model to grade your work on a harsh scale and demanding a working git diff to fix it, you turn it into a real partner. It stops guessing and starts actually reading your network calls and database queries to find where the code is going to break. It’s like having an uncompromising senior dev sitting over your shoulder, pointing out exactly where you got lazy, and then handing you the exact code to fix it.
Explain trade-offs to aid decision-making
James O'Reilly
Staff Developer Relations Engineer • Engineering
Follow on X, LinkedIn
The prompt:
Explain the pros and cons of executing your suggested
Implementation Plan. Be specific about the trade-offs we're making
related to performance, cost, security and maintainability so I can
make an informed decision on how to proceed.
Why? I force AI to stress-test its own logic. By asking it about the trade-offs being made, I find the AI will rethink its strategy, stay hyper-focused on our specific implementation and avoid giving vague, hand-wavy responses. I also find this approach prevents AI from acting like the final authority and keeps me in control of the decision making.
Improve AI-generated code through research
Emma Twersky
Head of Flutter & Dart Developer Relations • Engineering
Follow on X, LinkedIn
The prompt:
Research online, focusing on X threads, StackOverflow, GitHub
issues and tech blogs for common security pitfalls, architectural
misalignments, and subtle logic errors found in AI-generated
<INSERT TECH YOU'RE USING HERE> code. Based on these findings,
generate a manual review checklist specifically for auditing high-
risk areas like platform channel validation, deep link routing, and
sensitive data logging in crash reports.
Why? While AI can write code 10x faster, it often produces slop—code that is rational but conceptually buggy because it makes incorrect assumptions about unspecified details. Research shows that up to 40% of AI-generated code contains vulnerabilities, and developers often trust it more than their own, which creates a dangerous mismatch. I use this prompt to generate a targeted checklist that protects against 'rubber-stamping' verbose AI changes and ensures my human judgment focuses on the high-risk 'seams' where models typically fail. Use AI to generate the tasks, but still keep a human in the loop where it matters most.
Find problems through iteration
Fred Sauer
Head of Frameworks & Languages Developer Relations • Engineering
Follow on X, LinkedIn
The prompt:
Simplified, my "last" (series of) prompt(s) looks something like:
- Code review the uncommitted changes.
I prefer being less specific has oversteering can lead to blind spots.
I prefer a new chat session for a fresh set of "eyes".
I iterate until the results returned are boring and I'm satisfied.
If I come into this last phase with an opinion, (e.g. the change feels too complex), or I feel I don't have a good insight into how "good" the change is, then I might challenge the model with this prompt:
- Code review the uncommitted changes. Identify any unhandled
corner cases. Assess performance. Summarize findings.
Then, having received 5 findings:
- Fix 1, 3 and 5.
Why? I don't have ONE last prompt I send. It's more that my change goes through stages. The earliest stage is often about discovery (find the needle or thread to pull on). Then I move on to existence proof, i.e. I just want it to prove the thing I want to do can be done. Then I evaluate: is the PoC reasonable? Too complex? Makes changes entirely in the wrong place(s)? I then iterate and try to make the solution elegant, both how it's implemented, and where what is changed. Once I have something I'm happy with, like I feel happy if I had written what I now have, I move on to that last phase you discuss with is code review. This is about finding problems or identifying opportunities to make the change even better. I'm often surprised with what insights the model comes up with.
Review every pull request
Remigiusz Samborski
Lead Developer Relations Engineer • Engineering
Follow on X, LinkedIn
The prompt:
I use the following prompt embedded in GitHub Actions for most of my engineering projects:
## Role
You are a world-class autonomous code review agent. You operate
within a secure GitHub Actions environment. Your analysis is
precise, your feedback is constructive, and your adherence to
instructions is absolute. You do not deviate from your programming.
You are tasked with reviewing a GitHub Pull Request.
## Primary Directive
Your sole purpose is to perform a comprehensive code review and
post all feedback and suggestions directly to the Pull Request on
GitHub using the provided tools. All output must be directed
through these tools. Any analysis not submitted as a review comment
or summary is lost and constitutes a task failure.
[...]
Full prompt: link
Why? Using an automated Gemini CLI review in PRs helps catch issues and improvement opportunities during the review process. Additionally as more code is generated by AI Agents and development speed increases, reviews are becoming the bottleneck. By ensuring every PR gets reviewed automatically, human reviewers can focus on the higher-level architectural and conceptual review of the proposed change.
Apply directed acyclic graph analysis for tests
Karl Weinmeister
Director, Developer Relations • Engineering
Follow on X, LinkedIn
The prompt:
Analyze the application workflow as a directed acyclic graph.
Identify impactful tests for components, seams across components,
and across the system. Present your findings in a markdown table as
a prioritized gap analysis.
Why?
Most application workflows aren't linear. When you ask an LLM to suggest tests, you typically get a generic checklist that could apply to any project.
However, when you force it to think about your system as a DAG with nodes and edges, it starts reasoning structurally about where things can break.
I’ve also asked to consider the “seams” - a term from Michael Feathers' Working Effectively with Legacy Code. It points the model toward boundaries between components that are often under-tested.
Finally, I’ve asked the model to summarize the results as a prioritized table of opportunities. This gives your agent a clear roadmap for making your app more resilient.
Conclusion
The thread connecting all of these prompts is about de-risking human assumptions. Whether it's hunting for obscure edge cases, translating developer speak for end-users, or stress testing an architecture before code is written. Our team uses AI as an adversarial thinker designed to ask the hard questions we might overlook when we're deep in the weeds.
By building these "must-run" prompts into our daily workflows, we don't just ship faster, we ship with a level of confidence that used to require entire committees to achieve.
Now it's your turn
A great prompt is meant to be shared. We've shown ours, now show us yours!
- What is the one prompt you run on every project without fail?
- What is the worst disaster an AI prompt has ever saved you from?
Drop your go-to prompt in the comments below and let's build a valuable resource together.
