Tekton Task and Pipeline YAML Prompt Template

This prompt is for CI/CD platform engineers who need to generate Tekton Task and Pipeline YAML from natural language descriptions or partial specifications. The ideal user understands Tekton's core concepts—Tasks, Pipelines, Workspaces, Parameters, and Results—but wants to accelerate manifest authoring by describing the desired behavior in plain language and receiving valid, parseable YAML in return. The prompt is designed for teams building on Tekton who want AI assistance that produces manifests ready for tkn CLI or kubectl apply without manual indentation fixes or schema corrections. You should have a clear description of the pipeline steps, inputs, outputs, and workspace requirements before invoking this prompt; vague requests like 'create a CI pipeline' will produce underspecified YAML that requires significant rework.

Use this prompt when you need valid YAML that enforces correct step ordering, workspace bindings, parameter declarations, and result passing between tasks. It is particularly effective for scaffolding new pipelines from scratch, converting existing shell-script-based CI logic into Tekton-native steps, or generating task definitions that must pass through a Tekton controller without schema rejection. The prompt includes implicit checks for common failure modes: missing image pull secrets, volume mount errors, incorrect result type declarations, and workspace binding mismatches between Pipeline and TaskRef definitions. For best results, provide the target Tekton API version (e.g., tekton.dev/v1beta1 or tekton.dev/v1), the container images for each step, and any parameter or workspace names you want to standardize across tasks.

Do not use this prompt for generating non-Tekton CI/CD configurations such as GitHub Actions workflows, GitLab CI pipelines, or Jenkinsfiles. Do not use it when the target cluster runs a Tekton version with breaking API changes not reflected in the prompt's constraints—always verify the generated YAML against your cluster's installed Tekton version with tkn version and a dry-run apply. Avoid this prompt for pipelines that require dynamic runtime resolution beyond Tekton's parameter and result system, such as conditional DAG branching based on external service state or multi-cluster fan-out that Tekton's controller cannot natively orchestrate. If your pipeline requires custom task resolution from remote catalogs, OCI bundles, or step-action injection, supplement the generated output with manual review of the resolver configuration. When in doubt, generate the scaffold with this prompt and then apply your organization's specific security context, service account bindings, and resource quota annotations as a post-generation step.

The prompt template below is designed to produce a syntactically valid Tekton YAML manifest for either a Task or a Pipeline resource. It forces the model to respect the Tekton API structure by requiring explicit fields for parameters, workspaces, steps (or tasks), and results. Use this template as the foundation for your generation workflow, replacing the square-bracket placeholders with concrete values from your CI/CD specification before sending it to the model.

textCopy
Generate a Tekton [RESOURCE_TYPE] YAML manifest that conforms to the [API_VERSION] API. The output must be valid YAML with correct indentation, no trailing whitespace, and no markdown fences unless explicitly requested.

Resource requirements:
- Name: [RESOURCE_NAME]
- Description: [RESOURCE_DESCRIPTION]
- Labels: [LABELS]
- Annotations: [ANNOTATIONS]

Parameters:
[PARAMETERS]

Workspaces:
[WORKSPACES]

Steps (for Task) or Tasks (for Pipeline):
[STEPS_OR_TASKS]

Results to expose:
[RESULTS]

Additional constraints:
- Include imagePullSecrets if [IMAGE_PULL_SECRET] is specified
- Set serviceAccountName to [SERVICE_ACCOUNT_NAME]
- Add nodeSelector and tolerations if [NODE_CONSTRAINTS] are provided
- Ensure all step `image` fields are explicit and version-pinned
- Use `#!/usr/bin/env sh` shebang for script blocks unless [SCRIPT_SHELL] overrides
- For Pipeline definitions, enforce `runAfter` ordering where [TASK_ORDER] is specified
- Validate that all `workspace` bindings in Pipeline tasks reference declared Pipeline workspaces

Output only the YAML manifest.

To adapt this template, replace each placeholder with structured data from your pipeline specification system. For [PARAMETERS] and [WORKSPACES], provide YAML-formatted lists with name, description, and optional default fields. For [STEPS_OR_TASKS], supply the full step or task definitions including name, image, and script or args. The [LABELS] and [ANNOTATIONS] placeholders expect YAML map syntax. When wiring this into an application, pre-validate that all required placeholders are populated before sending the prompt to the model. After receiving the output, run it through kubectl --dry-run=client or a Tekton-specific linter to catch indentation errors, missing workspace bindings, or invalid API version references before applying it to a cluster.

Integrate this prompt into your internal developer platform or CI/CD scaffolding service where users request new Tekton Tasks or Pipelines. The application layer should collect user intent through a form, API payload, or existing pipeline specification, then populate the prompt's placeholders—[TASK_DESCRIPTION], [PIPELINE_DESCRIPTION], [PARAMETERS], [WORKSPACES], [STEPS], and [CONSTRAINTS]—before calling the LLM. Treat the LLM as an unreliable YAML generator: its output is a draft, not a deployable artifact. The harness is responsible for extracting, validating, and persisting only correct manifests.

After receiving the model response, strip any markdown code fences (yaml ... ) to isolate the raw YAML. Run immediate structural validation using kubectl apply --dry-run=client -f generated.yaml or an equivalent Tekton-aware schema validator. If validation fails, capture the exact error message and feed it back to the model in a retry prompt that includes the original request, the invalid YAML, and the parse error. Limit retries to a maximum of three attempts. Log every generation attempt—including input variables, output YAML, validation result, and retry count—to an append-only audit store for debugging and compliance. For production deployments, enforce a mandatory human approval step on any Pipeline or Task that references securityContext, volumeMounts with host paths, or secrets. Store approved manifests in a Git repository with a commit message that references the generation request ID and the approving user.

Choose a model with strong YAML generation capabilities and low indentation error rates. If your platform supports it, use structured output modes (e.g., OpenAI's JSON mode with a YAML-as-JSON intermediate representation) to reduce syntax errors before converting to YAML. For high-risk environments, pair this prompt with a post-generation policy check that scans for missing imagePullSecrets, overly permissive securityContext settings, or workspace bindings that reference non-existent PersistentVolumeClaims. Do not apply generated manifests directly to a cluster without the dry-run and approval gates described above.