Integration Prerequisites Checklist Generation Prompt

This prompt is designed for onboarding engineers, solutions architects, and integration specialists who need to produce a structured, verifiable readiness checklist before starting a new third-party integration. The core job-to-be-done is converting a documented integration surface—such as an API reference, a setup guide, or a vendor's getting-started page—into a categorized list of required accounts, credentials, permissions, network rules, and environment configurations. The output serves as a pre-flight gate that prevents the most common integration delays: missing OAuth scopes, unopened firewall ports, and misconfigured test environments.

Use this prompt when you have a well-defined integration target and source documentation to ground the checklist. The prompt requires a [CONTEXT] block containing the integration's technical requirements, such as authentication methods, required API endpoints, and environment variables. It also accepts an [OUTPUT_SCHEMA] to enforce a specific checklist structure, such as categories for 'Accounts and Credentials,' 'Network and Firewall Rules,' and 'Environment Configuration.' Do not use this prompt for generating step-by-step setup instructions or troubleshooting guides; those are separate workflows. It is also unsuitable for integrations where the prerequisites are unknown or purely speculative, as the model will hallucinate plausible but incorrect requirements without source grounding.

In a production harness, the generated checklist must be validated against the source documentation to ensure completeness. A common failure mode is the omission of implicit prerequisites, such as a requirement for a specific browser version or a dependency on a separate internal service. To mitigate this, always pair this prompt with an evaluation step that checks for coverage of all documented authentication flows, network endpoints, and configuration variables. For high-risk production integrations, a human reviewer must sign off on the checklist before any implementation work begins. The next step after generating the checklist is to feed it into an automated provisioning or ticketing system, where each item can be assigned an owner and a verification method.

This template produces a structured checklist of everything an integration team needs before connecting to a third-party service: accounts, credentials, permissions, network rules, and environment configurations. It is designed to be fed with existing integration documentation, API reference pages, or architecture notes so the output is grounded in the actual integration surface rather than generic assumptions. The square-bracket placeholders let you swap in your own source material, output schema, constraints, and risk level without rewriting the core instruction.

textCopy
You are an integration readiness analyst. Your task is to produce a categorized prerequisites checklist for integrating with [SERVICE_NAME].

Use the following source material as your only evidence:
[SOURCE_DOCUMENTATION]

Generate a checklist organized into these categories:
1. Accounts and Access: Required service accounts, tenant IDs, organization membership.
2. Credentials and Secrets: API keys, OAuth client IDs/secrets, certificates, signing keys. Do NOT include example credential values.
3. Permissions and Scopes: IAM roles, OAuth scopes, least-privilege policy requirements.
4. Network and Connectivity: IP allowlists, DNS requirements, TLS versions, proxy configurations, firewall rules.
5. Environment Configuration: Environment variables, feature flags, config files, SDK versions.
6. Pre-Flight Verification: Steps to confirm each prerequisite is met before integration begins.

For each checklist item, include:
- Item ID (e.g., ACCT-01, CRED-03)
- Description
- Required/Optional flag
- How to verify it is satisfied
- What breaks if it is missing or misconfigured

Output format:
[OUTPUT_SCHEMA]

Constraints:
[CONSTRAINTS]

Risk level: [RISK_LEVEL]

If the source documentation does not cover a category, mark it as "UNKNOWN - requires manual review" rather than inventing requirements.

Adapt this template by replacing [SERVICE_NAME] with the third-party service identifier and [SOURCE_DOCUMENTATION] with the actual integration docs, API reference pages, or architecture notes. The [OUTPUT_SCHEMA] placeholder should contain your expected structure—typically a JSON schema or markdown table specification. Use [CONSTRAINTS] to enforce domain-specific rules such as "never mention internal IP ranges" or "flag any item requiring a procurement ticket." Set [RISK_LEVEL] to low, medium, or high to control the thoroughness of the checklist and whether the model should recommend additional review gates. For high-risk integrations, always route the output through a human reviewer who can verify each prerequisite against the live service configuration before the checklist is handed to an onboarding team.

This prompt is designed to be called programmatically as part of an integration partner onboarding pipeline or a documentation site generator. The primary integration point is a function that accepts a structured input payload containing the integration surface definition, target environment, and any known constraints. The function constructs the final prompt, calls the LLM, and then validates the output before it is shown to a user or published. Because the output is a checklist that humans will follow to configure real systems, the harness must enforce strict schema compliance and flag any missing categories before the checklist is delivered.

The implementation should wrap the LLM call in a validation layer that parses the generated checklist into a typed object. Each checklist item must have a category, item, required flag, and verification_method. Use a JSON schema validator to confirm the output structure. If validation fails, implement a single retry with a repair prompt that includes the validation errors and asks the model to fix the malformed output. Log both the initial failure and the repair attempt for observability. For high-stakes integrations (e.g., payment systems, healthcare data flows), route the validated checklist to a human reviewer via an internal queue before it is sent to the external partner. Never publish an unvalidated checklist directly from the model response.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o or Claude 3.5 Sonnet, and set temperature to 0 or a very low value to maximize deterministic, complete category coverage. Do not use this prompt with a generic chat model that lacks reliable JSON mode. If your integration catalog is large, consider batching integration surfaces and running the prompt in parallel, but ensure each call is independent to avoid context pollution. Finally, store the generated checklist with a version identifier and the source integration surface definition so that when the third-party service updates its requirements, you can re-run the prompt and diff the changes.