Dockerized Quickstart Environment Prompt Template

This prompt is for platform engineers and DevRel teams who need to generate a reproducible, containerized quickstart environment. Use it when onboarding developers to an API, SDK, or service where local dependency conflicts—such as mismatched language versions, system libraries, or database drivers—are a known source of first-time friction. The ideal user has an existing API specification, SDK package, or sample application that they want to containerize, and they need to produce a complete Dockerfile, a docker-compose.yml for dependent infrastructure, and a README section with build, run, and verification commands. The core job-to-be-done is eliminating the 'works on my machine' problem before it reaches the new developer, compressing time-to-first-success by providing a single-command bootstrap.

Before using this prompt, you must have concrete technical context ready: the target runtime and its exact version, the list of system-level dependencies, the ports the service exposes, any required environment variables, and the verification command that proves the environment is functional. The prompt template expects placeholders like [RUNTIME_BASE_IMAGE], [DEPENDENCIES], [EXPOSED_PORTS], and [VERIFICATION_COMMAND] to be filled with real values. Do not use this prompt for production deployment configurations, security-hardened images, or multi-service orchestration beyond a simple quickstart context—it intentionally omits non-root users, image scanning, secret management, and resource limits to keep the quickstart simple and fast. If you need a production-grade container, start with this output as a reference but apply your organization's hardening checklist separately.

The output of this prompt should be treated as a first draft that requires validation. After generation, you should build the Dockerfile on a clean machine, run the verification command inside the container, and measure startup time and image size against your quickstart SLAs. Common failure modes include missing OS-level packages that the prompt assumed were in the base image, port conflicts with the host, and verification commands that pass in the container but don't actually prove the service is responding correctly. If your quickstart requires authentication credentials or secrets, the prompt should generate instructions for mounting them via environment variables or a local .env file—never hardcode secrets into the image. For high-risk or compliance-sensitive environments, add a human review step before publishing the generated quickstart to external developers.

This prompt template instructs the model to produce a self-contained, containerized quickstart environment. The goal is to eliminate local dependency conflicts for a new developer by providing a Dockerfile, a compose configuration, and a set of run instructions that bootstrap the entire integration environment. Use this when you need to generate a reproducible, cross-platform onboarding artifact for a specific API, service, or tool. Do not use this for generating production-grade deployment configurations; the output is optimized for a fast, local, first-success experience.

markdownCopy
You are a platform engineer creating a Dockerized quickstart environment for a new developer. Your output must allow a developer to go from zero to a working integration with zero local dependency conflicts.

Generate the following, using the provided context:

**Context:**
- Service/API Name: [SERVICE_NAME]
- Primary Language & Version: [LANGUAGE_RUNTIME]
- Required Environment Variables: [ENV_VARIABLES]
- Core Integration Task: [TASK_DESCRIPTION]
- Base Image Constraints: [BASE_IMAGE_CONSTRAINTS]

**Output Requirements:**
1.  **Dockerfile:** A multi-stage build if beneficial, otherwise a single optimized stage. It must install all OS-level and language-level dependencies. Pin base image digests and package versions for reproducibility.
2.  **docker-compose.yml:** A configuration that builds the Dockerfile, maps a local source directory as a volume for live code editing, and sets the required environment variables from a `.env.example` file.
3.  **.env.example:** A template for all required environment variables with placeholder values.
4.  **run.sh:** A bash script that performs pre-flight checks (Docker/Docker Compose installed), builds the image, starts the container, and tails the logs.
5.  **README.md:** A concise guide with prerequisites, a "Quick Start" section using `run.sh`, a "What Just Happened?" explanation, and a "Common Issues" section.

**Constraints:**
- The total uncompressed image size must be under [MAX_IMAGE_SIZE].
- The container must start and be ready to accept work in under [MAX_STARTUP_TIME] seconds.
- The configuration must be compatible with both Linux and macOS (Docker Desktop).
- All scripts must be idempotent and safe to run multiple times.
- Do not include any production server configurations, daemons, or multi-replica setups.

To adapt this template, replace the square-bracket placeholders with your specific context. For [BASE_IMAGE_CONSTRAINTS], specify requirements like python:3.11-slim or node:20-alpine. For [TASK_DESCRIPTION], be concrete, such as "Make an authenticated GET request to the /users endpoint and print the response." After generating the output, validate it by running docker build and docker compose up in a clean environment. The primary failure mode is an image that builds successfully but fails at runtime due to a missing system dependency; always test the full run.sh flow.

This prompt is designed to be called programmatically from a documentation build pipeline or a developer portal's 'Generate Quickstart' feature. The primary input is a structured specification object—typically derived from an OpenAPI spec, a docker-compose.yml prototype, or a product requirements document—that defines the service's dependencies, exposed ports, environment variables, and the minimal 'hello world' command. The application layer is responsible for assembling this [INPUT_SPEC] before invoking the model. The prompt's output is not just a block of markdown; it is a structured payload containing a Dockerfile, a docker-compose.yml, and a README.md section, which your harness must parse and write to a temporary directory for validation.

The implementation harness must execute a hard validation loop before the generated artifact is shown to a user or committed to a repository. After parsing the model's structured output, the harness should write the Dockerfile and docker-compose.yml to disk and immediately run docker compose config --quiet to check for syntax validity. If this fails, the harness should enter a retry recovery flow: the validation error message is fed back into the prompt's [PREVIOUS_ERROR] placeholder, and the model is asked to repair the configuration. A maximum of three retries should be enforced before the harness surfaces the failure for human review. This prevents an endless loop of invalid YAML generation.

For runtime validation, the harness should attempt a docker compose up --detach and then execute the generated 'first successful call' command (e.g., a curl command against the container) to verify the environment actually works. The harness must enforce a strict startup timeout (e.g., 30 seconds) and capture both the exit code and the response body. If the health check fails, the harness should run docker compose logs and feed the tail of the logs back into the prompt as [RUNTIME_ERROR_CONTEXT] for a targeted repair attempt. This step is critical because a syntactically valid Dockerfile can still fail at runtime due to missing dependencies or incorrect entrypoints. The final output should only be surfaced to the user after passing both the static config check and the live runtime smoke test.

When integrating this into a CI/CD pipeline for documentation, treat the generated quickstart as a testable artifact. The harness should log the model version, prompt template version, input spec hash, and all validation results as structured metadata. This creates an audit trail that allows you to trace a broken quickstart back to a specific model behavior change or spec drift. Avoid wiring this directly into a production developer portal without a human-in-the-loop approval step for the first generated artifact of a new service; once the pattern is proven for a service, subsequent regenerations (e.g., after an API version bump) can be automated with tighter validation thresholds. The primary failure mode to monitor is the model hallucinating a curl command against a port or path that doesn't exist in the actual running container, which the runtime smoke test is designed to catch.