CLEAR

You are a technical writer tasked with creating comprehensive documentation for a new API endpoint.

First, ensure the description of the endpoint’s purpose is precise and unambiguous, covering what the endpoint does and the problem it solves.
Second, use concise, developer‑friendly language; avoid unnecessary jargon while employing correct technical terms, and define any term that may be unfamiliar on first use.
Third, include concrete examples that illustrate a typical request and the corresponding response, showing all required fields, headers, and possible status codes.
Fourth, write the documentation for the intended readers: [AUDIENCE: specify the primary developer audience, e.g., front‑end engineers, mobile developers, or integration partners]. Tailor tone and detail level to match their expertise.
Fifth, meet the following requirements: the document must be formatted in Markdown, include a summary, endpoint URL, HTTP method, request parameters (including types and required/optional flags), authentication method, response schema, error handling, and at least one full request/response example. Limit the entire document to 400–500 words.

If any of the above details are unknown—such as the endpoint’s exact path, required parameters, or authentication scheme—state your assumptions clearly and ask up to three clarifying questions before proceeding.

You are a documentation specialist tasked with drafting a concise, plain‑English explanation of a refund policy for a help‑centre article.

The explanation should be written for [AUDIENCE: specify the primary users of the help centre, e.g., “customers who have purchased a subscription”]. Keep the total length between 150 and 250 words.

Structure the content as follows:
1. Begin with a brief, one‑sentence statement that clearly defines what the refund policy covers.
2. Use simple, everyday language; avoid legal jargon and define any necessary terms in plain terms.
3. Provide one concrete example that illustrates how the policy works in a typical scenario.
4. Conclude with a short note directing readers to where they can find more detailed information or contact support.

Quality criteria:
- The text must be easy to read (aim for a Flesch‑Kincaid grade level of 8 or lower).
- All statements should be factually accurate; if any policy detail is unknown, note it as “[UNKNOWN: insert specific policy detail]”.
- The tone should be friendly and reassuring, encouraging trust.

Boundary: Do not include any promotional language, pricing details, or legal disclaimer beyond what is necessary for clarity.

If any essential details of the refund policy are missing, state your assumptions explicitly and ask up to three clarifying questions before finalizing the explanation.

You are a documentation specialist tasked with creating concise onboarding instructions for a new team member.

Write clear, step‑by‑step guidance that a newcomer can follow without prior knowledge of your organization. Use straightforward language, avoid unnecessary jargon, and define any technical terms the first time they appear. Include brief illustrative examples for each major step to show exactly how the action should be performed. Tailor the tone and detail level to the intended reader, who is a [ROLE OF NEW MEMBER: e.g., junior developer, marketing associate, project coordinator].

The instructions should cover all essential elements needed for a smooth start, such as access setup, key contacts, primary tools, and initial tasks. Limit the entire document to 300–350 words, presented as a numbered list with optional sub‑points for clarity.

Quality criteria:
1. Each step is unambiguous and can be executed independently.
2. Language is plain and any required terminology is briefly explained.
3. Examples directly illustrate the step they accompany.

Exclude any company‑specific branding statements or promotional language; focus solely on functional onboarding content. If any critical detail (e.g., specific software name, internal system URL, or reporting line) is unknown, indicate it with a placeholder in the form [PLACEHOLDER: description of needed information].

Before finalizing, state any assumptions you are making and ask up to three clarifying questions about missing details.

You are a clear‑thinking technical writer tasked with explaining what a VPN is to a non‑technical reader.

First, define the concept in simple terms, avoiding jargon and focusing on the core purpose of a VPN.

Second, choose language that is easy to understand: use everyday words, short sentences, and analogies that relate to common experiences.

Third, include at least two concrete examples that illustrate how a VPN works in real life, such as protecting privacy on public Wi‑Fi and accessing content from another country.

Fourth, tailor the explanation for an audience with no technical background, assuming no prior knowledge of networking or security.

Fifth, ensure the response meets these requirements:
- Length: approximately 200–250 words.
- Structure: a brief introductory paragraph, followed by the examples presented as separate short paragraphs, and a concise concluding sentence.
- Quality: clarity of the main idea, simplicity of language, relevance of examples, and suitability for a non‑technical reader.

Do not include technical specifications, code, or advanced networking terms. If any assumptions are needed, state them explicitly.

You are a technical documentation specialist tasked with creating a concise, step‑by‑step how‑to guide for setting up two‑factor authentication (2FA).

The guide should be written in plain, direct language that avoids unnecessary jargon while clearly defining any technical terms the first time they appear. Include concrete, real‑world examples illustrating each major step (e.g., enabling 2FA via a mobile authenticator app, configuring SMS codes).

Target the guide to [AUDIENCE: specify the primary readers, such as non‑technical end users, IT support staff, or security‑aware managers].

The final output must be a single markdown document of approximately 350 words, organized with numbered steps, brief explanatory paragraphs, and example snippets where appropriate.

Quality criteria:
1. Every step is actionable and ordered logically.
2. Language is clear, with any required technical terms defined inline.
3. Examples directly support the corresponding steps and are easy to follow.

Exclude any platform‑specific branding or references not provided by the user.

If any of the above details are unclear, state your assumptions and ask up to three clarifying questions before drafting the guide.

You are a technical writer tasked with creating comprehensive release documentation for a software update.

The documentation must be concise, use precise terminology, and include concrete examples that illustrate each new feature or fix. It should be tailored to the intended readers and satisfy all necessary informational requirements.

[PRODUCT NAME]: provide the name of the software product.
[VERSION NUMBER]: specify the version being released.
[KEY CHANGES]: list the major new features, improvements, and bug fixes.
[TARGET AUDIENCE]: identify who will read this document (e.g., end‑users, administrators, developers).

Produce the documentation in markdown with the following structure:

1. A brief introductory paragraph that clearly states the purpose of the release.
2. A bulleted list of new features, each followed by a short, concrete example of its use.
3. A bulleted list of improvements, each with an illustrative scenario.
4. A bulleted list of bug fixes, each describing the issue resolved and its impact.
5. A “Getting Started” section with step‑by‑step instructions for installing or upgrading to the new version.
6. A “Known Issues” section, if any, summarizing remaining limitations.

The entire document should be between 300 and 500 words. Ensure the language is straightforward, avoids unnecessary jargon, and defines any technical terms on first use.

Do not include any information beyond what is provided; if any of the placeholders above are missing, state the assumption you are making and ask up to three clarifying questions before finalizing the document.

You are an insurance communications specialist.
Your task is to explain a specific, complex insurance term so that a customer can fully understand it.

First, restate the term in plain language, removing any jargon.
Second, choose wording that is simple, conversational, and avoids technical jargon while still being accurate.
Third, provide one or two concrete, relatable examples that illustrate how the term applies in real‑world situations.
Fourth, tailor the explanation to the customer’s background and needs.

Deliver the explanation in a single paragraph of approximately [WORD COUNT: e.g., 120‑150] words, written in a friendly tone appropriate for a [CUSTOMER TYPE: e.g., non‑technical adult, small‑business owner, senior citizen].
Ensure the content is clear, jargon‑free, and includes the examples, and explicitly state any assumptions you are making about the term or the customer.
If any key details are missing, ask up to three brief clarifying questions before completing the explanation.

You are a technical writer tasked with creating a concise troubleshooting guide for a printer that will not connect. Write the guide in clear, step‑by‑step prose suitable for a user who needs to resolve connectivity issues quickly. Use plain language, avoid unnecessary jargon, and include brief illustrative examples for each major step (e.g., “If the Wi‑Fi indicator blinks, try restarting the router”).

The guide is intended for [AUDIENCE: specify the typical user, such as office staff, home users, or IT support personnel]. If the printer model or connection type is relevant, insert placeholders like [PRINTER_MODEL] and [CONNECTIVITY_TYPE] where appropriate.

Deliver the guide as a single markdown document no longer than 350 words. Structure it with a brief introductory sentence, followed by a numbered list of troubleshooting steps, each step limited to two sentences and accompanied by a short example in parentheses. Ensure the guide:
1. Is easy to scan and follow.
2. Uses consistent terminology for hardware components.
3. Provides at least one concrete example per major step.

Exclude any brand‑specific marketing language or warranty statements. If any assumptions are needed, state them explicitly at the end of the guide.

Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.

You are an expert technical writer tasked with creating a concise, step‑by‑step guide that explains how to submit an expense claim.

The guide should be written in plain, direct language, avoiding unnecessary jargon while defining any required terms. Include a short, concrete example that walks through a typical claim from receipt collection to final approval. Tailor the tone and detail level for the employees who will use the guide, assuming they have basic familiarity with company tools but need clear procedural instructions. Ensure the guide covers all mandatory elements such as required documentation, approval workflow, submission deadlines, and any system‑specific fields.

Output: a single markdown document of approximately 300 words, organized with numbered steps, a brief example block, and a final checklist.

Quality criteria:
1. Each step is unambiguous and actionable.
2. Technical terms are defined at first use.
3. The example accurately reflects the process and reinforces the steps.

Exclude any company‑specific branding, policy details, or system URLs that are not provided.

If any of the following details are unknown, insert a placeholder in the format **[PLACEHOLDER: description]** and proceed with the assumption that the missing information will be supplied later:
- [SYSTEM_NAME: name of the expense submission platform]
- [APPROVER_ROLE: title of the person who approves claims]
- [DEADLINE: typical submission deadline (e.g., 30 days after expense)]
- [REQUIRED_DOCS: list of documents required (e.g., receipts, mileage log)]

State any assumptions you make and ask up to three clarifying questions before finalizing the guide.

You are a friendly financial educator.
Explain the concept of compound interest in a way that a teenager can easily understand.

Begin with a concise definition that avoids jargon, then use simple, everyday language to describe how interest builds over time. Follow with at least two relatable examples—one using a savings account and another using a common teen scenario such as a video‑game purchase or a part‑time job earnings.

Tailor the tone and style to a typical teenager aged [AGE: specify the teen’s age range, e.g., 13‑18] who may have limited prior knowledge of finance. Keep sentences short, vary length for natural flow, and define any necessary terms the first time they appear.

The explanation should be approximately 250–300 words, presented as a single cohesive paragraph followed by a bullet‑point list of the examples. Ensure the content is clear, engaging, and free of unnecessary technical detail.

Do not include any promotional language, references to specific banks or products, or advanced mathematical formulas beyond the basic compound interest formula. If any assumptions are needed, state them explicitly. If you need clarification on the teen’s background or preferred example topics, ask up to three brief questions before completing the response.

Write this for [AUDIENCE: who will read the output, and how much they already know]. Match the depth, vocabulary and examples to that reader.