GitLab CI prompts need more than a failed command. Pipeline creation rules, included configuration, runner capabilities and job dependencies all influence the outcome. A job may never appear because its rule did not match, or it may run without the artifact it expected. The prompts here help explain that behavior before proposing a repair, with separate workflows for rules, dependency flow and failed jobs.
Establish which configuration actually runs
Give the agent the root CI file, local includes and relevant external include versions. State the GitLab version and whether the runner is shared or managed by your team. Include the pipeline source and relevant variable names, without values that contain credentials. This lets the agent reason about the compiled pipeline rather than an isolated YAML fragment.
The GitLab CI YAML reference defines workflow, job and dependency configuration and points to CI Lint. Use it to verify version-specific syntax. Treat a proposed pipeline graph as an explanation to validate, rather than proof that a configuration has been accepted by your instance.
Explain why a pipeline or job appears
Rules should be reviewed as a set of scenarios. A project may need branch checks and merge request checks without duplicating deployment work. Ask the agent to show which rule matches first for each scenario and what remains excluded. A clear table is easier to review than a long Boolean expression.
Explain pipeline creation for {{ci_file}} and its includes.
For {{pipeline_scenarios}}, show whether the pipeline exists, which jobs
appear and which rule determined each result. Identify duplicate work or
unintended deployment paths. Propose the smallest rule change and a
scenario table for validation in our GitLab version. Keep protected
release conditions intact.
Trace required outputs between jobs
An artifact needed by a test job should not be treated as an optional acceleration. Ask the agent to draw the dependency sequence in words and identify where each output originates. Include expiry, branch scope and parallel job names. This is particularly useful after introducing a faster job graph that bypasses earlier stages.
Review output flow in {{ci_file}}.
List each produced artifact and each job that consumes it. Separate
required build outputs from optional cache contents. Inspect needs,
artifact download behavior and expiry. Reproduce {{missing_output_error}}
from the configuration, then propose a minimal dependency repair and a
clean-run check that does not rely on an existing cache.
Diagnose the job in its runner environment
A command may behave differently in a container, shell runner or local terminal. Provide the executor and image information before asking the agent to alter application code. Require the diagnosis to separate tool installation, file permissions, network dependencies and actual test failures. A runner issue should have evidence beyond a passing local run.
Investigate this GitLab job failure: {{job_log}}.
Context: {{runner_details}} and {{pipeline_source}}.
Find the earliest failing step and compare it with {{local_command}}.
List one testable hypothesis at a time. Suggest a focused fix and report
what can be verified locally versus what needs a fresh GitLab pipeline.
Retain a useful pipeline explanation
Review the final configuration with an empty cache and a new branch in mind. Check that test results remain visible when a command fails, that required outputs reach their consumers and that deployments still need the intended conditions. Keep a brief scenario table beside the change so a reviewer can reproduce the important cases.
Save your GitLab review prompt in Kipt with blanks for pipeline source, includes and runner details. Use the monorepo prompts when the harder question is which projects should be affected by a change.