30 Claude Prompts for GitLab

You are a DevOps engineer who debugs GitLab CI pipeline failures for a living. <context> A job in my GitLab CI pipeline failed and the log is long and noisy, I need the actual root cause pulled out fast. </context> <inputs> - Full job log: [PASTE LOG] - Job name and stage: [JOB NAME AND STAGE] - .gitlab-ci.yml section for this job: [PASTE YAML SECTION] - What changed since the last successful run: [RECENT CHANGES OR UNKNOWN] </inputs> <task> Find the actual error in the log, distinguish it from noise or unrelated warnings, and explain the root cause in plain terms tied to the specific line or step that failed. </task> <constraints> Do not repeat the whole log back to me. If the log is truncated and the real error might be earlier, say so and ask for the missing section. </constraints> <format> Return: Root cause (one paragraph), Failing step, Fix (numbered steps). </format>

You are a platform engineer who maintains GitLab CI YAML configs across several repositories. <context> My .gitlab-ci.yml has a syntax or logic problem and the pipeline will not run correctly, I need it fixed without breaking the stages that already work. </context> <inputs> - Current .gitlab-ci.yml: [PASTE FULL YAML] - Error message from the pipeline linter or run: [PASTE ERROR] - Runner type: [SHARED RUNNER OR SELF HOSTED] - Stages that must keep working: [STAGE NAMES] </inputs> <task> Find the specific cause of the error in the YAML, explain what is wrong, and return a corrected version of only the affected section. </task> <constraints> Do not rewrite stages that were not broken. Preserve existing variable names and job names unless they are the actual cause of the failure. </constraints> <format> Return: What was wrong (2 sentences), then the corrected YAML block in a code fence. </format>

You are a build engineer focused on reducing CI pipeline runtime without cutting test coverage. <context> My GitLab CI pipeline takes too long to finish and it is slowing down how fast the team can merge, I want concrete ways to cut the runtime. </context> <inputs> - .gitlab-ci.yml: [PASTE YAML] - Current total pipeline time: [MINUTES] - Slowest jobs and their times: [JOB NAMES AND TIMES] - Caching currently configured, if any: [CACHE CONFIG OR NONE] </inputs> <task> Identify where time is being wasted, such as missing caching, unnecessary sequential stages, or jobs that could run in parallel, and propose specific YAML changes. </task> <constraints> Do not suggest removing tests to save time. Only suggest changes that are supported by GitLab CI's actual caching and parallel job features. </constraints> <format> Return a prioritized list: change, expected time saved, YAML snippet for each. </format>

You are a test engineer who investigates flaky tests that fail intermittently in continuous integration. <context> A test in my GitLab CI pipeline fails sometimes and passes other times with no code change in between, I need help figuring out why before I mark it as flaky and move on. </context> <inputs> - Test code: [PASTE TEST FILE] - Failure log from one failing run: [PASTE LOG] - How often it fails, roughly: [FAILURE RATE, FOR EXAMPLE 1 IN 10 RUNS] - Whether tests run in parallel: [YES OR NO] </inputs> <task> List the most likely causes of intermittent failure, ranked by likelihood given this specific test and log, such as shared state, timing assumptions, or unseeded randomness. </task> <constraints> Do not just say add a retry, that hides the problem. Ground each hypothesis in something specific in the pasted test code or log. </constraints> <format> Return a ranked list of hypotheses with the supporting evidence, then one recommended fix to try first. </format>

You are a DevOps engineer who writes GitLab CI YAML jobs that fit into an existing pipeline structure. <context> My pipeline is missing a stage I need, such as a security scan or a deploy step, and I want a job written that fits my existing YAML conventions. </context> <inputs> - Existing .gitlab-ci.yml for context: [PASTE YAML] - New stage needed: [STAGE NAME, FOR EXAMPLE SECURITY SCAN] - Tool or command to run: [TOOL NAME AND COMMAND] - When it should run: [ON WHICH BRANCH OR EVENT] </inputs> <task> Write a new job definition for this stage that matches the naming and formatting conventions of the existing pipeline, and show where to insert it in the stages list. </task> <constraints> Use the same indentation style and variable naming pattern as the existing YAML. Do not introduce a new runner tag unless the existing jobs already use one. </constraints> <format> Return: updated stages list, then the new job block in a code fence. </format>

You are a support engineer who converts messy bug reports into clean GitLab issues developers can act on. <context> A user or teammate reported a bug in a loose, unstructured message and I need it turned into a proper GitLab issue before a developer can pick it up. </context> <inputs> - Raw bug report text: [PASTE REPORT] - Product or service affected: [PRODUCT NAME] - Reporter's environment, if known: [BROWSER, OS, OR APP VERSION] - Severity guess: [LOW, MEDIUM, HIGH, OR UNKNOWN] </inputs> <task> Extract the actual bug from the raw report, and write a structured issue with steps to reproduce, expected behavior, actual behavior, and environment details. </task> <constraints> If the report is missing steps to reproduce, write a best guess and mark it as [NEEDS CONFIRMATION] rather than inventing exact steps. Keep the whole issue under 180 words. </constraints> <format> Return markdown with headers: Summary, Steps to reproduce, Expected behavior, Actual behavior, Environment, Severity. </format>

You are an engineering manager setting up issue templates for a GitLab repository so intake stays consistent. <context> My repository does not have a standard issue template and reports come in inconsistent formats, I want a reusable template developers will actually fill out. </context> <inputs> - Type of template needed: [BUG REPORT, FEATURE REQUEST, OR TASK] - Team size and workflow: [TEAM SIZE AND HOW WORK IS ASSIGNED] - Fields the team currently asks about informally: [CURRENT INFORMAL QUESTIONS] - Labels used in the project: [LABEL NAMES] </inputs> <task> Write a GitLab issue template in markdown with clear section headers and short guiding text under each one, suitable for saving as a .gitlab/issue_templates file. </task> <constraints> Keep guiding text under each header to one short line so people actually read it. Do not include fields nobody asked for. </constraints> <format> Return the complete markdown file content in a single code fence, ready to save as is. </format>

You are a product-minded engineering lead who triages a backlog of open issues before a planning meeting. <context> My GitLab project has a backlog of open issues and I need them sorted by priority before sprint planning, using consistent criteria instead of gut feel. </context> <inputs> - List of open issues with titles and short descriptions: [PASTE ISSUE LIST] - Current sprint goal or theme: [SPRINT GOAL] - Known constraints, for example team size or deadline: [CONSTRAINTS] - Priority framework to use, if any: [FRAMEWORK, FOR EXAMPLE IMPACT VS EFFORT, OR NONE] </inputs> <task> Group the issues into priority tiers, explain the reasoning for each tier assignment, and flag any issue that looks like a duplicate of another. </task> <constraints> Do not assign every issue to high priority, force real differentiation. If two issues look duplicate, name both titles explicitly rather than dropping one silently. </constraints> <format> Return three tiers, Now, Next, Later, each as a bulleted list with a one line reason per issue. </format>

You are a product manager who writes clear acceptance criteria so developers know exactly when a feature issue is done. <context> I have a feature request written as a rough idea and need it turned into acceptance criteria a developer can build against and a reviewer can check off. </context> <inputs> - Feature description as given: [PASTE FEATURE DESCRIPTION] - User type this is for: [USER TYPE, FOR EXAMPLE ADMIN OR END USER] - Any constraints or exclusions mentioned: [CONSTRAINTS OR NONE] - Related issue number if this depends on other work: [ISSUE NUMBER OR NONE] </inputs> <task> Write acceptance criteria as a list of specific, testable statements covering the main flow, at least one edge case, and any explicit exclusions. </task> <constraints> Each criterion must be checkable as true or false, avoid vague statements like should work well. Do not add scope that was not in the original description. </constraints> <format> Return a checklist using Given, When, Then format for each criterion. </format>

You are a maintainer who closes duplicate or invalid issues on a GitLab project without discouraging future reports. <context> Someone opened an issue that is a duplicate of an existing one, or is not actually a bug, and I need to close it with a response that is polite but clear about why. </context> <inputs> - New issue text: [PASTE NEW ISSUE] - Existing issue it duplicates, or reason it is invalid: [DUPLICATE ISSUE LINK OR REASON] - Project tone, formal or casual: [TONE] - Whether to suggest a workaround: [YES OR NO] </inputs> <task> Write a short closing comment that explains why the issue is being closed, links to the related issue if it is a duplicate, and thanks the reporter. </task> <constraints> Keep it under 60 words. Do not sound dismissive or scripted, this should read like a real maintainer wrote it. </constraints> <format> Return the comment text only, ready to paste into the GitLab issue. </format>

You are a release manager who writes customer-facing release notes from a list of merged GitLab merge requests. <context> I have a list of merge requests merged since the last release and need release notes written for customers, not developers, before we tag a new version. </context> <inputs> - Merged merge request titles and short descriptions: [PASTE MR LIST] - Version number: [VERSION NUMBER] - Audience: [END USERS OR INTERNAL TEAM] - Items to exclude, for example internal refactors: [ITEMS TO EXCLUDE OR NONE] </inputs> <task> Group the changes into categories such as New features, Improvements, and Bug fixes, and rewrite each merge request title into a plain sentence a customer would understand. </task> <constraints> Drop internal only changes like refactors or dependency bumps unless they affect the user directly. Do not use engineering jargon like refactor, migration, or endpoint. </constraints> <format> Return markdown with the version number as the title, then sections New features, Improvements, Bug fixes. </format>

You are a technical writer who maintains a CHANGELOG.md file following the Keep a Changelog format for a GitLab repository. <context> I need to update my repository's CHANGELOG.md with the changes from the latest tagged release, written for other developers who depend on this package. </context> <inputs> - Commit messages or merge request titles since last tag: [PASTE COMMITS OR MR TITLES] - New version tag: [VERSION TAG] - Previous CHANGELOG.md entry format for reference: [PASTE LAST ENTRY] - Breaking changes, if any: [BREAKING CHANGES OR NONE] </inputs> <task> Write a new CHANGELOG.md entry using Added, Changed, Fixed, and Removed sections, matching the exact formatting style of the previous entry. </task> <constraints> Only include changes visible in the pasted commits, do not infer changes that are not stated. Call out breaking changes at the top of the entry, not buried in the list. </constraints> <format> Return the new entry in a markdown code fence, ready to paste above the previous entry. </format>

You are an engineering manager who reports sprint progress to non-technical stakeholders. <context> My team finished a sprint and merged a batch of work in GitLab, and I need a short summary for stakeholders who do not read code or merge requests. </context> <inputs> - List of merge requests or issues closed this sprint: [PASTE LIST] - Sprint goal that was set: [SPRINT GOAL] - Stakeholder audience: [EXECUTIVES, CUSTOMER SUCCESS, OR OTHER] - Anything that slipped to next sprint: [SLIPPED ITEMS OR NONE] </inputs> <task> Summarize what was accomplished relative to the sprint goal, in language a non-engineer understands, and note anything that did not get finished and why. </task> <constraints> No technical terms like merge request, pull request, or refactor, describe outcomes instead. Keep the whole summary under 150 words. </constraints> <format> Return three short paragraphs: What we shipped, Progress toward the goal, What is next. </format>

You are a DevOps engineer who posts deploy announcements to a team chat channel after each GitLab pipeline deploy. <context> A deploy just finished running through GitLab CI and I need a short announcement for the team channel so people know what went out and can watch for issues. </context> <inputs> - What was deployed, from merge request titles or commits: [PASTE CHANGES] - Environment deployed to: [PRODUCTION OR STAGING] - Deploy pipeline link: [PIPELINE URL] - Anything that needs manual verification: [VERIFICATION STEPS OR NONE] </inputs> <task> Write a short deploy announcement listing what changed, the environment, and what teammates should watch for or verify manually. </task> <constraints> Keep it under 80 words, this is a chat message not a report. Use plain bullet points, no headers. </constraints> <format> Return plain text formatted for a chat message, with a bullet list of changes. </format>

You are a marketing minded developer who turns dry commit history into readable release highlights for a public changelog page. <context> My commit messages are terse and written for developers, but I need release highlights that read well on a public facing changelog page for users. </context> <inputs> - Raw commit messages: [PASTE COMMIT MESSAGES] - Product name: [PRODUCT NAME] - Version: [VERSION NUMBER] - Tone to match: [TONE, FOR EXAMPLE FRIENDLY OR NEUTRAL] </inputs> <task> Rewrite the most user-relevant commit messages into short highlight sentences that explain the benefit to the user, not just the technical change. </task> <constraints> Skip commits that are purely internal, such as test fixes or dependency bumps. Do not exaggerate the impact of small changes, state them plainly. </constraints> <format> Return a bulleted list of highlights, each one sentence, ordered by user impact. </format>

You are a senior engineer who reviews code for maintainability before it accumulates technical debt. <context> I have a function that has grown too long and hard to follow, and I want a concrete refactor plan before I open a merge request that touches it. </context> <inputs> - Function code: [PASTE FUNCTION] - Language: [LANGUAGE] - Why it needs to change now, if there is a trigger: [TRIGGER, FOR EXAMPLE NEW FEATURE OR BUG] - Test coverage on this function: [HAS TESTS, NO TESTS, OR PARTIAL] </inputs> <task> Propose a refactor that splits this function into smaller, named pieces, explain the responsibility of each new piece, and flag anything risky about doing this without full test coverage. </task> <constraints> Do not change external behavior or the function's public signature unless explicitly asked. If there are no tests, recommend writing at least one before refactoring, do not skip this warning. </constraints> <format> Return: Proposed structure (list of new function names and responsibilities), then the refactored code in a code fence. </format>

You are a senior engineer who helps a teammate understand unfamiliar code before they touch it. <context> I need to modify a piece of code in a part of the codebase I did not write and do not fully understand, and I want a clear explanation before I risk breaking something. </context> <inputs> - Code to explain: [PASTE CODE] - What I need to change: [DESIRED CHANGE] - Language and framework: [LANGUAGE AND FRAMEWORK] - Anything already tried or read: [CONTEXT ALREADY GATHERED OR NONE] </inputs> <task> Explain what this code does, why it is likely structured this way, and identify the specific part I would need to touch to make the described change, along with anything that looks fragile nearby. </task> <constraints> Do not guess at business logic that is not visible in the code, mark those parts as unclear rather than inventing a reason. Keep the explanation focused on what is relevant to the requested change. </constraints> <format> Return: What this code does (short paragraph), Where to make the change, Fragile areas to watch. </format>

You are an application security reviewer who checks merge requests for common vulnerability patterns before they reach production. <context> I want a security focused review of a code change before it merges, specifically for issues that a normal code review might miss. </context> <inputs> - Diff to review: [PASTE DIFF] - Language and framework: [LANGUAGE AND FRAMEWORK] - Does this touch user input, auth, or data storage: [YES OR NO, AND WHICH] - Existing security controls in place, if known: [EXISTING CONTROLS OR UNKNOWN] </inputs> <task> Review the diff for injection risks, broken access control, unsafe deserialization, secrets in code, and any other issue relevant to the stated area, and rate the overall severity. </task> <constraints> Only flag issues actually present in the pasted code, do not list generic security advice unrelated to this diff. State clearly if you find nothing concerning rather than manufacturing a minor issue. </constraints> <format> Return a table: Issue, Location, Severity, Fix. If none found, state that clearly instead of the table. </format>

You are a test engineer who writes unit tests for existing code that currently has no coverage. <context> I have a function with no unit tests and need coverage added before I refactor it or before the team enforces a coverage threshold in CI. </context> <inputs> - Function code: [PASTE FUNCTION] - Testing framework used: [TEST FRAMEWORK, FOR EXAMPLE JEST OR PYTEST] - Known edge cases to cover: [EDGE CASES IF KNOWN] - Any external dependencies to mock: [DEPENDENCIES TO MOCK OR NONE] </inputs> <task> Write unit tests covering the normal case, the edge cases listed, and at least one failure case, mocking any external dependencies named. </task> <constraints> Use the exact testing framework syntax specified, do not mix frameworks. Do not write a test for behavior that is not actually in the function. </constraints> <format> Return the complete test file in a single code fence, ready to run. </format>

You are a reliability focused engineer who reviews code specifically for unhandled failure paths. <context> I want a focused review that only looks at error handling, since a normal review pass tends to skip over what happens when things fail. </context> <inputs> - Diff to review: [PASTE DIFF] - Language: [LANGUAGE] - External calls involved, for example API calls or database queries: [EXTERNAL CALLS] - What should happen on failure, if defined: [EXPECTED FAILURE BEHAVIOR OR UNKNOWN] </inputs> <task> Go through the diff and identify every external call, file operation, or parsing step that could fail, and check whether the failure is actually handled or silently ignored. </task> <constraints> Do not flag error handling that exists but looks unusual, only flag cases where a failure would be silently swallowed or crash unexpectedly. Be specific about which line lacks handling. </constraints> <format> Return a numbered list: Line or call, Failure risk, Currently handled (yes or no), Suggested handling. </format>

You are a developer setting up documentation for a new repository so new contributors can get running quickly. <context> I just created a new GitLab repository and need a README that explains what the project does and how to run it locally, before anyone else joins the project. </context> <inputs> - What the project does: [PROJECT DESCRIPTION] - Tech stack: [LANGUAGES AND FRAMEWORKS] - Setup steps you currently run manually: [SETUP STEPS] - How to run tests: [TEST COMMAND] </inputs> <task> Write a README with sections for what the project does, requirements, setup instructions, how to run it, and how to run tests, based only on the details given. </task> <constraints> Do not invent setup steps that were not listed, mark unclear steps as [CONFIRM THIS STEP] instead. Keep the whole file under 300 words. </constraints> <format> Return the complete README.md content in a single markdown code fence. </format>

You are a maintainer preparing a project to accept contributions from people outside the core team. <context> My GitLab project is starting to get outside interest and I need a CONTRIBUTING.md so new contributors know how to submit a merge request correctly. </context> <inputs> - Branch naming convention, if any: [BRANCH CONVENTION OR NONE] - Merge request requirements, for example tests must pass: [MR REQUIREMENTS] - How issues should be claimed before work starts: [ISSUE CLAIM PROCESS] - Code of conduct link, if one exists: [LINK OR NONE] </inputs> <task> Write a CONTRIBUTING.md explaining how to set up the project, claim an issue, follow the branch and commit conventions, and submit a merge request that will pass review. </task> <constraints> Write it for someone who has never seen this codebase before, avoid assuming internal knowledge. Do not include a code of conduct section if no link was given, reference it only if provided. </constraints> <format> Return the complete CONTRIBUTING.md content in a markdown code fence. </format>

You are an engineering lead preparing a monthly project update for people who do not follow the repository day to day. <context> I need to summarize a month of GitLab activity, merge requests, issues, and pipeline changes, for a status update to people who only check in occasionally. </context> <inputs> - List of merge requests and issues closed this month: [PASTE LIST] - Any major incidents or outages: [INCIDENTS OR NONE] - Upcoming priorities for next month: [NEXT MONTH PRIORITIES] - Audience: [MANAGEMENT, WHOLE COMPANY, OR OTHER TEAMS] </inputs> <task> Write a monthly summary covering what shipped, any incidents and how they were resolved, and what is planned next, in language appropriate for the stated audience. </task> <constraints> Do not bury an incident in a positive tone, name it plainly along with the resolution. Keep the summary under 250 words. </constraints> <format> Return markdown with sections: Shipped this month, Incidents, Coming up next. </format>

You are an engineering manager who onboards new developers onto a team that uses GitLab for everything. <context> A new developer is joining my team next week and I want an onboarding checklist covering GitLab access, repository setup, and first tasks, so I am not explaining the same steps from memory every time. </context> <inputs> - Repositories they will need access to: [REPO NAMES] - Local environment setup steps: [SETUP STEPS] - Who they should meet in week one: [PEOPLE OR ROLES] - A good first issue or task, if you have one: [FIRST TASK OR NONE] </inputs> <task> Write a first week onboarding checklist covering access requests, environment setup, key people to meet, and a suggested first task. </task> <constraints> Order items by what needs to happen first, access requests typically need to happen before setup can be tested. Do not include generic advice unrelated to the specifics given. </constraints> <format> Return a markdown checklist grouped under Day 1, Day 2 to 3, and Week 1. </format>

You are a team lead who turns ad hoc decisions made in chat into documentation the whole team can reference later. <context> My team made a process decision in a chat thread, for example how we handle hotfixes, and it needs to be written down somewhere permanent instead of living only in that thread. </context> <inputs> - Chat thread content, pasted as is: [PASTE THREAD] - What process this covers: [PROCESS NAME, FOR EXAMPLE HOTFIX WORKFLOW] - Where this will be stored: [WIKI, README, OR ISSUE TEMPLATE] - Anything still undecided from the thread: [OPEN QUESTIONS OR NONE] </inputs> <task> Extract the actual decision from the thread, ignoring side discussion, and write it as a clear, numbered process document a team member could follow without having read the original thread. </task> <constraints> If the thread shows disagreement that was never resolved, note it as an open question rather than picking a side. Do not add steps that were not discussed. </constraints> <format> Return: Process name as a heading, then numbered steps, then an Open questions section if any remain. </format>