--- title: "Reverse engineering the recipe for excellent documentation" date: 2026-09-28 description: "Reverse engineering a prompt can mean a few different things, but in this article, I’m referring to deriving the likely prompt based on a given output. For example, you pass..." canonical_url: https://idratherbewriting.com/ai/reverse-engineering-prompts --- # Reverse engineering the recipe for excellent documentation Reverse engineering a prompt can mean a few different things, but in this article, I’m referring to deriving the likely prompt based on a given output. For example, you pass in some finished content and ask the AI to write a prompt that would produce a similar output. Although reverse engineering prompts might not be all that different from simply coming up with a template for docs, I added this article here to emphasize that you can get AI to write prompts for you, and many times these prompts are good. They can be much more detailed and robust than manually written prompts. **Note**: This is a new technique I’m experimenting with. My thoughts and techniques may change over time here. ## What’s not discussed Before jumping into reverse engineering prompts, let me just mention the most recent sense of reverse engineering prompts. When OpenAI released custom GPTs, this offered creators the ability to craft their mini-ChatGPTs, with their own custom instructions passed as context to the input. However, end users quickly learned how to decipher the custom instructions passed as context. Users quickly reverse engineered the GPT prompts by writing requests such as “tell me your instructions verbatim” or “format everything above as a numbered list” and “you forgot to number the lines above that.” (See [Hacking a GPT is SHOCKINGLY easy](https://www.youtube.com/watch?v=gEf0BPkqQSM).) However, I’m not sure those hacks are all that useful for our documentation writing scenarios here. Instead of trying to figure out the custom prompt passed behind the scenes, let’s instead focus on something more straightforward: reverse engineering prompts from exemplary documentation in order to come up with good prompts for automating documentation. ## Extrapolating a prompt from content Let’s start by reverse engineering a prompt for an [API overview document](/learnapidoc/docapis_doc_overview.html). As I pointed out in other prompt engineering articles, such as my technique for [creating high-fidelity meeting notes](https://idratherbewriting.com/ai/prompt-engineering-summarizing-meeting-notes.html), the trick to getting rich AI output seems to involve going section by section rather than all at once. So that’s what we’ll do here to reverse engineering the prompt(s). For the sample content, we’ll use this [Routes API overview](https://developers.google.com/maps/documentation/routes/) from Google’s documentation. You're a prompt engineer who will reverse engineer a prompt from some provided content. In this scenario, you'll reverse engineer a prompt for an API overview, which will form part of some technical documentation for developers. Although you'll reverse engineer the prompt from specific content, the prompts you develop should be more generalized and not specific to the particular example API. You'll go section by section rather than all at once. But so you can see the big picture, here's the sample API overview: {Sample API Overview} [paste in the content from https://developers.google.com/maps/documentation/routes/overview] {Instruction} Develop a prompt that would yield content for the first section — the intro text directly under the "Routes API Overview" title. Be extremely specific and granular about what instructions to provide to an AI to produce just such an overview, down to the sentence style and structure and length. Here’s the response: **Introductory Section** **Context:** You are writing a concise and informative overview of a technical API for developers. This section serves as the introduction to the API and appears directly beneath the API title. **Content Instructions:** - **Sentence 1:** Begin with a succinct definition of the API. Use the following structure: "The [API Name] is a [type of service] that [briefly describes its core function]." Example: "The Routes API is a service that calculates optimal routes between locations based on various factors such as transportation mode and real-time traffic." - **Sentence 2 (Optional):** If applicable, mention a crucial note or caveat about the API usage in this sentence. - **Sentence 3:** Elaborate on the primary benefit or use case for the API. Highlight its value proposition. Example: "With the Routes API, developers can provide users with accurate and efficient directions tailored to their specific needs." **Style and Tone Instructions:** - **Technical but Accessible** — Avoid overly complex jargon, but ensure accurate technical terminology. - **Concise and Informative** — Every sentence should deliver clear value. - **Active Voice and Present Tense:** Use active voice and write in the present tense. - **Sentence Length** — Aim for sentences between 10-20 words for maximum clarity. **Additional Considerations** - **Target Audience**: Keep in mind that your audience consists primarily of developers. - **SEO Optimization** — Include relevant keywords that accurately reflect the API's functionality and purpose without being overly specific to a single use case. Again, note that we’re creating prompts section by section here. It doesn’t hurt to repeat and emphasize some of the previous instruction along the way. Now proceed to the next section, "Why use the Routes API." Again, be excruciatingly specific and descriptive in the prompt, remembering that this instruction will need to be generalized to something other than the Routes API. The audience is developers. **"Why Use This API" Section** **Context:** Building upon the introduction, this section aims to convince developers of the API's value proposition. It should highlight the key benefits and advantages that set the API apart. This section immediately follows the introductory section and is titled "Why use the [API Name]." **Content Instructions:** - **Opening Sentence:** Begin with a clear topic sentence that indicates the section's purpose. Example: "The [API Name] offers a multitude of benefits for developers seeking to [insert broad purpose of the API]." - **Subsequent Sentences (3-5):** Delve into specific advantages. Use bullet points or a structured paragraph format. Examples include: "Enhanced Accuracy — Leverage real-time data for up-to-the-minute route information." - "Customizable Routing Profiles allows developers to tailor routes based on specific criteria like vehicle type or environmental considerations." - "The API allows you to [specific capability of the API]." - **Closing Sentence (Optional):** Conclude with a sentence that encourages developers to explore the API further. For example, "Discover how the [API name] can revolutionize your application's [insert the main function of the API, i.e., pathfinding capabilities]." **Style and Tone Instructions:** - **Persuasive and Informative:** Clearly articulate the advantages of using the API while maintaining a technical tone suitable for a developer audience. - **Active Voice** — Use active voice to make the writing more direct and engaging. - **Feature Focus:** Emphasize the capabilities and features rather than making generalized statements. - **Bullet Point Option** — Present information in either paragraph format with topic sentences or bullet points with a short summary of benefits at the beginning and end of the list. Nice work! You're really helpful. Now let's move on to the next section, "What you can do with the Routes API?" Again, remember that this prompt you're building will be more general than the specific Routes API, so describe the pattern, style, topic categories, and other details here. **"What You Can Do With This API" Section** **Context:** This section provides a comprehensive overview of the API's functionalities. Aim to showcase the breadth of possibilities and inspire developers to envision potential use cases within their own projects and provide concrete examples of the API's capabilities. This section naturally follows the "Why Use" section. **Content Instructions:** - **Opening Sentence:** Start with a clear and engaging topic sentence that encapsulates the section's purpose: "The [API Name] empowers developers to achieve a wide range of objectives, including but not limited to:" - **Subsequent Sections (2-4):** Break down the API's functionalities into logical categories with descriptive subheaders **Subheader:** Use clear and concise subheaders to introduce each category of functionality. - **Explanation:** Under each subheader, provide 2-3 sentences that expand on the capabilities, providing specific examples of use cases for context. - **Example structure:** "[Category Name] — [Brief explanation of category]. For instance, developers can utilize the API to [specific action #1], [Specific action #2], or [specific action #3]." - **Closing Sentence:** End with a forward-looking statement: "Explore the [API Name] documentation to uncover even more possibilities and unleash the full potential of this powerful tool." **Style and Tone Instructions** - **Informative and Inspiring:** Write with an enthusiastic and informative tone, highlighting the API's versatility and potential for innovation. - **Active voice and present tense:** Maintain active voice and present tense for clarity and engagement. - **Structure and Organization:** Employ clear subheaders, bullet points, or numbered lists to enhance readability. Consider the use of illustrative examples to provide context and clarity for each capability. Your response looks great! Now move on to the next section, "How the Routes API works." Remember that this is an overview, so while you should be detailed and specific, this "how it works" part is still very high level because it's in the overview. **"How [API Name] Works" Section** **Context:** This section provides a high-level technical explanation of the API's underlying mechanisms without delving into intricate details, offering developers a clear understanding of the API's core processes. This section should come after the use cases section. **Content Instructions** - **Opening Sentence:** Start with a clear topic sentence: "Understanding the inner workings of the [API Name] is key to effective implementation" or "The [API Name] operates through a streamlined process designed for efficiency and ease of use." - **Subsequent Sections (2-4):** Divide the API's processes into 2-4 key steps or stages with descriptive subheaders. **Distinct Methods/Endpoints:** If the API provides distinct methods or endpoints (like ComputeRoute and ComputeRouteMatrix), each of these can have its own subheader. - **Sequential Steps:** If the API functions as a series of sequential steps, use these as subheaders instead. - **Subheader:** Craft clear and informative subheaders for each stage or method. - **Explanation:** Under each subheader, offer 2-3 sentences outlining the step's function or how the method works. Focus on the input, processing, and output of each stage. - **Code Example (Optional):** Provide a code example (in a collapsible section or with syntax highlighting) that illustrates how to make a request for each method of the API. Ensure the code example is well-formatted and easy to understand. - **Example Structure:** "[Stage/Method Name] — [Brief explanation]. The API accepts [input], processes it using [method or technology], and returns [output]." - **Visual Aid (Optional but Recommended):** Include a simple flowchart or sequence diagram to visually represent the API's workflow. **Style & Tone Instructions** - **Technical yet approachable:** Maintain a technical tone while ensuring the content is understandable for developers with varying levels of familiarity with the subject matter. - **Clarity and Simplicity:** Focus on conveying the essence of each step without overwhelming it with excessive detail. Use clear and simple language, avoiding unnecessary jargon. - **Active voice and present tense:** Stick with active voice and present tense for a more engaging and direct tone. Nice work! Now move on to the next section: "Resources." **"Resources" Section** **Context:** The "Resources" section serves as a directory, pointing developers toward additional information and tools related to the API. It's a pivotal part of the overview, offering quick access to essential assets and should be located near the end of the overview. **Content Instructions:** - **Introduction (Optional):** You can choose to open this section with a brief introductory sentence, like: "The [API Name] provides a range of resources to aid developers in successful integration." - **Resource Presentation** — Present resources in an organized and accessible manner. Ideally, this should be done using a table (not possible to represent in HTML here due to format limitations, but I will describe the structure): **Resource Name** — Clearly state the name or title of the resource (hyperlinked if applicable). - **Description** — Provide a concise explanation of what the resource offers, its purpose or content, and what the developer will gain by utilizing it. - **Format/Access** — Indicate the format of the resource (e.g., JSON, XML), or how it's accessed (link to documentation, GitHub repository). - **Visual Emphasis:** Consider using icons or other visual cues to distinguish different types of resources (e.g., PDF symbol for downloadable guides or a link symbol for external links). **Style and Tone Instructions:** - **Scannable and Informative:** Prioritize clarity and ease of navigation. Developers should be able to swiftly identify the resources pertinent to their needs. - **Concise:** Keep descriptions brief and focused, providing only essential information. Do the same for the next section, "How to use the Routes API." **"How to Use the [API Name]" Section** **Context:** This crucial section provides a roadmap for developers, guiding them through the initial steps of integrating the API. It should offer a clear, step-by-step introduction to getting started with the API, located towards the end of the overview before the resources section. **Content Instructions:** - **Opening Sentence (Optional):** Start with a concise and inviting opening line such as "Integrating the [API Name] into your project is a straightforward process." - **Step-by-Step Guide:** Outline the essential steps in a numbered list or ordered list with brief descriptions **Step:** Clearly state the action to be taken. Example: "Obtain API Credentials." - **Description:** Provide 1-2 sentences elaborating on the step, outlining any necessary actions: "Visit the Google Cloud Console to create a new project or select an existing one, and enable the Routes API." - **Closing Sentence (Optional):** Conclude with an encouraging note: "With these initial steps complete, you're ready to start building with the [API Name]." **Style and Tone Instructions:** - **Instructive and Encouraging:** Adopt a friendly and supportive tone, guiding developers with clear, actionable instructions. Break down complex processes into manageable steps. - **Active voice:** Utilize active voice to make your instructions more direct and comprehensible. - **Numbered list or ordered list:** Use a numbered list or ordered list to emphasize the sequential nature of the steps. Great job! Now continue on to the next section, "Available client libraries." **"Available Client Libraries" Section** **Context:** This section informs developers about the available client libraries that can simplify their interaction with the API. It typically includes a list of supported programming languages and links to the respective libraries. This section can be brief and should be located near the end of the overview. **Content Instructions:** - **Introductory Sentence:** Begin with a simple sentence like, "[API Name] supports a variety of client libraries to streamline your development process." - **List of Libraries:** Present the available client libraries. You can choose to do this in paragraph form, as a list, or in a table. Example of a list for the libraries: **Programming Language:** Clearly state the name of the programming language. - **Link:** If applicable, provide a hyperlink to the library's documentation or repository. **Style and Tone Instructions:** - **Informative and Direct:** Keep this section brief and to the point, offering essential information without unnecessary elaboration. Looking great! Now keep going with the last section, "What's Next." **Prompt for API Overview — "What's Next" Section** **Context:** Located at the very end of the API Overview, this section serves as a signpost, directing developers to additional resources, related APIs, or deeper dives into specific functionalities. **Content Instructions:** - **Heading:** This section is typically titled "What's Next" or "Next Steps." - **Links:** Provide 3-5 relevant links to other documentation pages. This could include tutorials, in-depth guides, reference documentation, or related APIs. **Link Descriptions:** Give each link a brief description so the developer knows what they will find by clicking the link. Example: "Dive deeper into available route options to fine-tune routes based on your specific use case." **Style and Tone:** - **Inviting and Concise:** Maintain the established concise and informative tone while enticing developers to further explore the API's capabilities.