Look at any builder's prompt history and you'll see a collection of highly specific, sometimes 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.
Build a spec #
Maja Bilić
Senior Outbound Product Manager • Engineering
Follow on LinkedIn Prompt:
- code_block
- <ListValue: [StructValue([('code', "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."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8ad00>)])]>
**Why? **I have written bad product requirements documentations (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
- code_block
- <ListValue: [StructValue([('code', "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:\r\n\r\n* Examine my application's codebase to identify areas of the UI/UX that are not being tested properly.\r\n* Determine if the existing code is written in a testable way (are dependencies injected? Are domains loosely or tightly coupled? Etc.).\r\n* Determine which domains require more rigor than others.\r\n* Create an overall testing plan for the application.\r\n* Determine which areas of functionality are already aligned with that plan, and which are missing tests.\r\n* Create a plan to implement those tests.\r\n* Execute that plan.\r\n\r\nDo not proceed from one step to another unless you are completely confident about your reasoning. You are encouraged to as many questions as needed."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a5b0>)])]>
**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
-
code_block
-
<ListValue: [StructValue([('code', 'Run all the tests and identify any missing tests and write them. Pay special attention to edge cases and race conditions.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a4c0>)])]>
-
code_block
-
<ListValue: [StructValue([('code', "Find any unused code, embarrassing comments, comment to code inconsistencies, unresolved TODOs, or other things in this commit that shouldn't be in there."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a2b0>)])]>
**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
- code_block
- <ListValue: [StructValue([('code', "Run a comprehensive check on this Android project to ensure all permissions are correct and compliant. Perform the following steps:\r\n1. Locate and analyze all 'AndroidManifest.xml' files (including main, debug, and flavor-specific manifests), extract a master list of declared <uses-permission> tags. \r\n2. 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.\r\n3. 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.\r\n4. Verify that any hardware features associated with the permissions (like android.hardware.camera) are correctly declared. \r\nOutput 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."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a190>)])]>
**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 up to the Play Store.
Conduct code review
Shir Meir Lador
Head of AI, Developer Relations • Engineering
- code_block
- <ListValue: [StructValue([('code', '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.\r\nGrade my uncommitted changes on an A-to-F scale for production readiness. \r\nDo not award an "A" unless my code is exceptionally robust. Specifically, analyze the changes for:\r\n1. Efficiency: Redundant API calls, wasteful database queries, or un-cached resource leaks.\r\n2. Resilience: Silent failure points, lack of explicit error boundaries, and missing rate-limit fallbacks.\r\n3. Architecture: Tight coupling and lack of clear separation of concerns.\r\nFor 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."'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a8b0>)])]>
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
- code_block
- <ListValue: [StructValue([('code', "Explain the pros and cons of executing your suggested Implementation Plan. Be specific about the trade-offs we're making related to perforance, cost, security and maintainability so I can make an informed decision on how to proceed."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8aa60>)])]>
**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
- code_block
- <ListValue: [StructValue([('code', "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."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a5e0>)])]>
**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
Simplified, my "last" (series of) prompt(s) looks something like:
- code_block
- <ListValue: [StructValue([('code', '- Code review the uncommitted changes.\r\n\r\nI prefer being less specific has oversteering can lead to blind spots.\r\nI prefer a new chat session for a fresh set of "eyes".\r\nI iterate until the results returned are boring and I'm satisfied.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8adc0>)])]>
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_block
- <ListValue: [StructValue([('code', '- Code review the uncommitted changes. Identify any unhandled corner cases. Assess performance. Summarize findings.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a370>)])]>
Then, having received 5 findings:
-
code_block
-
<ListValue: [StructValue([('code', '- Fix 1, 3 and 5.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a460>)])]> **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
I use the following prompt embedded in GitHub Actions for most of my engineering projects:
- code_block
- <ListValue: [StructValue([('code', '## Role\r\n\r\nYou 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.\r\n\r\n\r\n## Primary Directive\r\n\r\nYour 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.\r\n\r\n[...]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8a700>)])]>
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
- code_block
- <ListValue: [StructValue([('code', '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.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6574e8aa90>)])]>
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 Directed Acyclic Graph (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.