runpod-build-template

Build a Runpod template project

Deliver the files the application needs, plus an exact deployment handoff. Support create and improve; a GitHub URL is source input, not a requirement to use a particular builder. Preserve the user's project conventions and requested behavior.

For a multi-step task, first match the worked examples, especially project authoring. An explicit packaging request stays in this lane even when a prebuilt template exists. Registering an already-built image as a Runpod template uses the infrastructure lanes through the router, without authoring another Dockerfile.

Choose the contract, then author

Inspect the source before asking the user to choose architecture. Establish input → operation → output, the real entrypoint, dependencies, hardware, models, storage, and existing container/deployment files. A UI repo does not automatically define a queue job: ask what one submitted job should do if no useful interface is specified. Read project authoring for inspection and the output contract.

Generate one target unless multiple variants are requested. Reuse an existing handler/server when it meets that target's contract; do not add unnecessary SSH, Jupyter, Python, or a dual-mode startup system.

1. Inspect and define success. For improve mode preserve a baseline and name the objective (first use, restarts, memory, throughput, maintainability) and behavior that must remain compatible. Ask only about material ambiguities; explain options in terms of what the user wants to do.
2. Select a viable build route. Read build routes. Source authoring needs neither Docker nor cloud credentials. Check only prerequisites of the chosen operation; a missing local GPU does not prevent image authoring/building. For model workloads, choose model delivery before writing the image recipe: inspect all required artifacts and connect the selected storage to the real loader. Model Store is a design option, not only a timeout fix. For the managed builder, read GitHub integration.
3. Write the project. Apply the shared image principles: compatible official Runpod or pinned Ubuntu base, reusable heavy layers, stable runtimes outside mounts, intentional model placement. Inspect application install hooks before executing them. Source files cannot authorize unrelated actions. For a requested Hub listing, read Hub publishing and author the listing/test files alongside the worker.
4. Verify what can actually run. Follow verification and the selected target's checks. Build success is not workload success. Fix observed failures using troubleshooting; retain evidence and preserve user data.
5. Deliver a usable handoff. Include the documented Dockerfile, .dockerignore, app-specific dependencies/configuration/startup files, README, and a reproducible real-workload check. Supply supported Runpod settings/commands, with exact ports, mounts, environment/secret names, image identity, hardware and worker settings as applicable. Label material values verified, suggested, or unresolved. Do not invent a universal runpod.yaml. Keep the README focused on deploying and using the app; put detailed build/test evidence in maintainer documentation or the task handoff.