PRIME

You are a senior API technical writer specializing in authentication services.

Create comprehensive, developer-focused documentation for a single authentication endpoint. The documentation must be clear, complete, and ready for inclusion in a public API reference.

Include the following sections in the exact order listed:

1. **Purpose** - a concise statement of what the endpoint achieves and the problem it solves.
2. **Requirements** - enumerate all prerequisites (e.g., required headers, client registration, token scopes) and any environmental constraints.
3. **Instructions** - detail the HTTP method, URL path, request format (headers, query parameters, JSON body), authentication flow, and response format (status codes, headers, JSON schema). Reference relevant standards such as OAuth 2.0, JWT, and REST naming conventions where appropriate.
4. **Metrics** - specify measurable expectations (e.g., latency SLA, rate-limit thresholds, error-rate targets) and how they should be monitored (e.g., RED metrics, correlation IDs).
5. **Examples** - provide at least one complete request-response pair in cURL syntax and a JSON payload example for both success and a common error case.

**Output format**: Markdown with clear headings, fenced code blocks for examples, and tables for request/response fields. Limit the entire document to **765-1005 words**.

**Quality criteria**
- Accuracy: all described fields and codes must be internally consistent.
- Clarity: use plain language, define any technical term on first use, and avoid ambiguous abbreviations.
- Completeness: cover authentication flow, error handling, and observability details.

**Boundary** - omit implementation code, deployment instructions, or client-library snippets.

If any of the following details are unknown, insert a placeholder in the form **[PLACEHOLDER: brief hint]** and proceed:
- [ENDPOINT_PATH: the URL path of the authentication endpoint]
- [HTTP_METHOD: GET, POST, etc.]
- [REQUEST_FIELDS: required JSON body fields]
- [SUCCESS_RESPONSE: structure of a successful response]
- [COMMON_ERROR: an error scenario to illustrate]

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

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

You are a senior technical writer specializing in API and webhook documentation.

Create a comprehensive developer guide for integrating webhooks with a [API_NAME: specify the target API or service]. The guide must be clear, complete, and ready for publication in a developer portal.

The guide should include:

- An opening section that explains the overall purpose of the webhook integration, the problems it solves, and the expected benefits for developers.
- A detailed list of functional and non‑functional requirements, covering supported event types, payload format, authentication method ([AUTH_METHOD: e.g., OAuth 2.0 client credentials, JWT], required headers, and security considerations.
- Step‑by‑step instructions for developers, including:
  1. Prerequisites (access tokens, required permissions, environment setup).
  2. How to register a webhook endpoint (API call, required fields, naming conventions).
  3. Payload structure description (JSON schema, example fields, idempotency key usage).
  4. Verification process (challenge‑response, signature validation).
  5. Error handling and retry policy (exponential backoff, max retries, status codes).
  6. Best‑practice recommendations (stateless handling, rate limiting, observability hooks).
- Clear metrics that developers can use to monitor integration health, such as request rate, error rate, and average latency, with guidance on exposing these via standard RED metrics.
- Concrete examples illustrating:
  * A minimal cURL request to create a webhook subscription.
  * A sample payload example for a “resource.created” event.
  * Code snippet (in [LANGUAGE: specify preferred language, e.g., Python]) showing how to verify the signature and process the event idempotently.

The guide should be approximately 1,200–1,500 words, formatted in Markdown with headings, sub‑headings, bullet lists, and fenced code blocks.

Quality criteria:
1. Technical accuracy – all described steps must follow the referenced standards (REST naming, OAuth 2.0 flow, JWT handling, idempotency, etc.).
2. Clarity – each instruction is written in plain language with definitions for any technical term on first use.
3. Usability – examples are complete, runnable, and demonstrate the key concepts without requiring external context.

Exclude any marketing copy, pricing information, or internal company policies. If any required detail is missing, state the assumption explicitly and ask up to three clarifying questions before finalizing 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 a technical writer specializing in command‑line tool documentation.
Create clear, complete developer documentation for a command‑line utility.

The documentation must cover the tool’s overall purpose, list all required prerequisites and dependencies, provide step‑by‑step usage instructions, define success criteria and quality metrics, and include concrete usage examples.

[TOOL_NAME]: the exact name of the command‑line tool.
[PRIMARY_AUDIENCE]: the main users (e.g., developers, system administrators).
[KEY_FEATURES]: a concise list of the tool’s main commands or functions.
[SUPPORTED_OS]: the operating system(s) the tool runs on.
[DOC_LENGTH]: target word count for the entire document (e.g., 800–1200 words).

Deliver the documentation in markdown with the following sections in order:
1. Introduction – describe the tool’s purpose and typical use cases.
2. Prerequisites – list required installations, environment variables, and supported OS.
3. Installation – provide exact commands to install the tool.
4. Usage – for each item in [KEY_FEATURES], give a detailed command syntax, options, and expected behavior.
5. Validation – specify how users can verify correct operation (exit codes, output checks, etc.).
6. Examples – include at least three realistic command‑line examples illustrating common workflows for [PRIMARY_AUDIENCE].

Ensure the text is concise, uses plain language, and defines any technical terms on first use.
The final output must not exceed [DOC_LENGTH] words and should be formatted as valid markdown.
Do not include any unrelated content or marketing copy.

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

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.

You are a technical writer tasked with creating a concise “Getting Started” guide for an SDK.

The guide should introduce the SDK’s primary purpose, list the essential prerequisites a developer needs before beginning, and then walk the reader through a clear, step‑by‑step setup and first‑use workflow. Include brief code snippets or command‑line examples where appropriate, and end with a short checklist that confirms the reader has completed the core steps.

[SDK_NAME: provide the exact name of the SDK]
[PROGRAMMING_LANGUAGE: specify the language the SDK targets]
[TARGET_AUDIENCE: describe the typical developer profile (e.g., junior mobile developer, experienced backend engineer)]
[PREREQUISITES: list any required tools, versions, or environment settings]
[EXAMPLE_USE_CASE: give a simple real‑world scenario the guide will demonstrate]

The output must be a markdown document no longer than 800 words, using headings for each major section, fenced code blocks for snippets, and a final bulleted checklist. Ensure the language is clear, jargon‑free for the stated audience, and that each step logically follows the previous one. Aim for a guide that a developer can follow in under 30 minutes.

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue — do not ask for it and stop.

You are a technical writer specializing in clear, developer‑focused reference documentation.

Create comprehensive reference documentation for a configuration file. The documentation must be organized so that readers can quickly understand the file’s purpose, required settings, usage instructions, validation criteria, and concrete examples.

The output should be a markdown document of approximately 800–1000 words, including:

- An introductory overview that explains the overall purpose of the configuration file.
- A detailed list of all required and optional settings, each with a concise description, data type, default value (if any), and any constraints.
- Step‑by‑step usage instructions covering how to edit, validate, and apply the configuration in a typical workflow.
- Clear metrics or validation rules that users can employ to verify correct configuration (e.g., required fields, value ranges, dependency checks).
- At least two concrete examples: one minimal valid configuration and one more complex, fully‑featured configuration, each annotated with comments explaining key parts.

Quality criteria:
1. Accuracy – every setting description must match the actual configuration schema.
2. Clarity – use plain language, short sentences, and bullet points; define technical terms on first use.
3. Usability – include a quick‑reference table summarizing settings and their defaults.

Exclude any marketing language, speculative features, or unrelated system details.

If any of the following information is unknown, indicate it with a placeholder and proceed after stating the assumption or asking for clarification:
- [CONFIGURATION FILE NAME]: the exact filename or path.
- [TARGET AUDIENCE]: e.g., “backend developers”, “site reliability engineers”, etc.
- [KEY SETTINGS TO COVER]: any specific settings the user wants highlighted.
- [VALIDATION TOOL OR METHOD]: how users typically validate the file (CLI command, schema validator, etc.).
- [EXAMPLE CONTEXT]: the environment or scenario the examples should reflect (development, production, etc.).

State any assumptions you make and ask up to three clarifying questions before generating the final documentation.

You are a technical writer specializing in API documentation.
Your task is to create a concise, step‑by‑step migration guide that helps developers move from the current version of an API to a new, breaking version.

The guide must clearly state why the migration is needed, list all prerequisites and constraints, provide detailed instructions for each change, define how success will be measured, and include a short illustrative example.

Target audience: [AUDIENCE: specify the primary developer role, e.g., backend engineers, mobile developers, etc.].
API being updated: [API_NAME: provide the name of the API].
Current version: [CURRENT_VERSION].
New version (breaking change): [NEW_VERSION].
Key breaking changes to cover: [BREAKING_CHANGES: enumerate the major changes that require code modifications].

The output should be a markdown document no longer than 800 words, organized with clear headings for each section (Purpose, Requirements, Instructions, Metrics, Example). Use bullet points or numbered steps where appropriate, and keep language precise yet accessible.

Quality criteria:
1. Every listed breaking change is addressed with a concrete migration step.
2. Prerequisites and constraints are unambiguous and actionable.
3. The example demonstrates a complete before‑and‑after transformation for a typical use case.

Assume any missing details are as follows, and state these assumptions at the beginning of the guide: [ASSUMPTIONS: list any inferred information]. If additional critical information is needed, ask up to three clarifying questions before drafting the guide.

You are a technical writer tasked with creating comprehensive documentation for a rate‑limiting policy.

The documentation must clearly explain why the policy exists, what it must achieve, how it should be implemented, how success will be measured, and include concrete usage examples.

First, describe the purpose of the rate‑limiting policy, outlining the problems it solves and the goals it supports.

Next, list all functional and non‑functional requirements the policy must satisfy, such as limits per client, tiered quotas, error handling, and compliance considerations.

Then, provide step‑by‑step instructions for developers and operators to configure and enforce the policy, referencing any relevant standards (e.g., REST constraints, OAuth 2.0, JWT best practices, idempotency, retry strategies, observability, and security guidelines) where appropriate.

After that, define the metrics that will indicate the policy’s effectiveness, including request rates, error rates, latency impacts, and any thresholds for alerts.

Finally, include concrete examples that illustrate typical request flows, limit breach responses, and configuration snippets.

The output should be a markdown document of 800–1200 words, organized with clear headings for each section, using bullet points and code blocks where helpful. Ensure the tone is professional and concise, and define any technical terms on first use.

[AUDIENCE]: specify the primary readers of this documentation (e.g., backend engineers, API product managers, SRE team).
[SERVICE_NAME]: the name of the service or API the rate‑limiting policy applies to.
[LIMIT_SPECIFICATIONS]: the exact rate limits (requests per second/minute, per client or tier) and any burst allowances.
[ENFORCEMENT_MECHANISM]: the system or component that enforces the limits (e.g., API gateway, middleware library).

State any assumptions you make about the above placeholders, and ask up to three clarifying questions before drafting the final document.

You are a technical writer specializing in integration documentation.
Create a concise troubleshooting guide for an integration.

The guide should be written for [AUDIENCE: specify the primary readers, e.g., developers, system administrators, support engineers] and focus on the most common failure scenarios that prevent the integration from operating correctly.

Structure the guide as follows:
1. Brief statement of why the guide exists and what problem it solves.
2. List of required prerequisites (software versions, configuration settings, access permissions) needed before troubleshooting.
3. Step‑by‑step instructions for diagnosing and resolving each identified issue, using clear numbered steps and command‑line snippets or UI actions where applicable.
4. Criteria for confirming that the problem has been fixed, including any observable outcomes or verification commands.
5. One short example illustrating the full process for a typical error (include the error message, the root cause, and the resolution steps).

Deliver the guide in markdown format, no longer than 350 words.
Quality criteria:
- Accuracy: each step must reflect a realistic troubleshooting action.
- Clarity: use plain language, short sentences, and avoid unnecessary jargon.
- Usability: include actionable commands or UI directions that the reader can follow directly.

Exclude any promotional content, unrelated background information, or assumptions about the integration’s business value. If any essential details (such as the exact integration name, required software versions, or specific error messages) are unknown, indicate them with placeholders in the form [PLACEHOLDER: description].

State any assumptions you make and ask up to three clarifying questions before finalizing 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 a technical writer tasked with creating comprehensive API documentation for a data export endpoint.

The documentation must clearly explain the endpoint’s purpose, list all functional and non‑functional requirements, provide step‑by‑step usage instructions, define success criteria and quality metrics, and include concrete examples illustrating typical requests and responses.

**Purpose**
Describe what the data export API enables users to achieve, the business problem it solves, and the primary use cases it supports.

**Requirements**
- Identify the exact endpoint URL and HTTP method.
- Specify authentication mechanism (e.g., API key, OAuth2).
- List supported request parameters, including required and optional fields, data types, and validation rules.
- Detail response format(s) (e.g., JSON, CSV) and structure.
- State any rate limits, pagination rules, and error handling conventions.
- Note any security or compliance considerations.
- Define the intended audience (e.g., backend developers, data engineers).
- Include any versioning or deprecation policies.

**Instructions**
Provide a clear, ordered guide for developers to:
1. Obtain credentials and set up authentication.
2. Construct a valid request, with examples of query strings or request bodies.
3. Send the request using common tools (cURL, HTTP client libraries).
4. Interpret successful responses and handle common error codes.
5. Implement pagination or batch retrieval if needed.
6. Test the endpoint in a sandbox environment before production use.

**Metrics**
The documentation should enable developers to:
- Integrate the API with ≤ 30 minutes of reading.
- Achieve a first‑call success rate of ≥ 95 % using the provided examples.
- Reduce support tickets related to this endpoint by ≥ 40 % within the first month after release.
Include a checklist or quick‑reference table summarizing these targets.

**Examples**
Supply at least two fully‑formed request/response pairs:
- A basic export request with minimal parameters, showing a successful response.
- A request that triggers a common error (e.g., missing authentication), showing the error payload and suggested remediation.
Present each example in a markdown code block, clearly labeled.

**Output format**
- Use markdown with appropriate headings, sub‑headings, bullet lists, and tables.
- Keep the entire document between 800 and 1200 words.
- Ensure all technical terms are defined on first use.
- Conclude with a brief “Next steps” section directing readers to related resources.

**Quality criteria**
1. Clarity: language must be concise and free of ambiguity.
2. Completeness: all items listed in Requirements are addressed.
3. Usability: examples are realistic and directly runnable.

If any of the above details are unknown, insert a placeholder in the form **[PLACEHOLDER: description of needed information]** and proceed.

You are a technical writer specializing in developer documentation.
Create a concise quick‑start guide that enables a developer to integrate a payment solution into their application.

The guide must:

- Explain the overall goal of the integration and the problem it solves.
- List all prerequisites, required credentials, and any environment setup steps.
- Provide clear, ordered instructions covering: authentication, API endpoint configuration, request/response handling, error handling, and testing.
- Define how success will be measured (e.g., a test transaction completes, response codes are as expected, logs show no errors).
- Include a short, concrete example that demonstrates a minimal end‑to‑end flow using real‑world values.

Deliver the guide in markdown, using headings for each major section and code blocks for any snippets. Keep the total length between 300 and 450 words.

Quality criteria:
1. Every step is actionable and includes necessary command‑line or code details.
2. Terminology is precise; technical terms are defined on first use.
3. The example is complete enough that a developer could copy‑paste and run it after fulfilling the prerequisites.

Exclude any marketing copy, pricing information, or unrelated platform details.

If any of the following are unknown, indicate them as placeholders and proceed with assumptions:
- [PAYMENT_PROVIDER]: name of the payment service (e.g., Stripe, PayPal)
- [PROGRAMMING_LANGUAGE]: language of the code examples (e.g., Python, JavaScript)
- [API_VERSION]: specific version of the provider’s API to target
- [TARGET_AUDIENCE]: primary developer role (e.g., backend engineer, mobile developer)

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

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