Skip to main content
RapidDev - Software Development Agency
cursor-tutorial

How to Generate CI/CD Configs with Cursor

Generate CI/CD pipeline configurations with Cursor by referencing your project's package.json, Dockerfile, and test scripts as @file context. Use .cursorrules to specify your CI platform (GitHub Actions, Azure DevOps, GitLab CI), and prompt Composer to create complete YAML pipelines with build, test, lint, and deploy stages.

What you'll learn

  • How to prompt Cursor to generate complete CI/CD pipeline YAML files
  • How to reference project config files for accurate pipeline generation
  • How to create .cursorrules that enforce your CI/CD platform conventions
  • How to iterate on pipeline failures using Cursor's agent mode
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Intermediate8 min read15-20 minCursor Pro+, GitHub Actions / Azure DevOps / GitLab CIMarch 2026RapidDev Engineering Team
TL;DR

Generate CI/CD pipeline configurations with Cursor by referencing your project's package.json, Dockerfile, and test scripts as @file context. Use .cursorrules to specify your CI platform (GitHub Actions, Azure DevOps, GitLab CI), and prompt Composer to create complete YAML pipelines with build, test, lint, and deploy stages.

Why Cursor Excels at CI/CD Configuration

CI/CD pipeline configuration is repetitive YAML that follows predictable patterns, making it ideal for AI generation. Cursor can generate complete pipeline files for GitHub Actions, Azure DevOps, GitLab CI, and other platforms when given the right project context. The key is referencing your package.json, Dockerfile, and test configuration so Cursor knows your exact build commands, dependencies, and deployment targets. This tutorial covers the complete workflow from initial generation through debugging pipeline failures.

Prerequisites

  • Cursor installed (Pro recommended for agent mode)
  • A project with a package.json or equivalent build config
  • A target CI/CD platform (GitHub Actions, Azure DevOps, or GitLab CI)
  • Basic understanding of CI/CD pipeline concepts

Step-by-step guide

1

Add CI/CD rules to your project

Create a .cursor/rules/cicd.mdc file that specifies your CI/CD platform, deployment targets, and pipeline conventions. This ensures Cursor generates valid YAML for your specific platform and follows your team's conventions for stage naming, caching, and secrets management.

.cursor/rules/cicd.mdc
1---
2description: CI/CD pipeline generation rules
3globs: ".github/workflows/**, azure-pipelines.yml, .gitlab-ci.yml"
4alwaysApply: false
5---
6
7- CI platform: GitHub Actions
8- Node.js version: 22
9- Package manager: pnpm (use pnpm/action-setup@v4)
10- Always cache node_modules using actions/cache
11- Run in this order: install lint typecheck test build deploy
12- Use matrix strategy for Node 20 and 22
13- Secrets are in GitHub Settings, reference with ${{ secrets.NAME }}
14- Never hardcode secrets in YAML
15- Add step-level comments explaining what each step does
16- Use concurrency groups to cancel redundant runs

Pro tip: If you use Azure DevOps instead of GitHub Actions, change the platform line and Cursor will switch to azure-pipelines.yml syntax with pool, stages, and tasks instead of jobs and steps.

Expected result: CI/CD rules auto-attach whenever you edit pipeline configuration files.

2

Generate a complete pipeline with Composer

Open Composer with Cmd+I and reference your project configuration files. Ask Cursor to generate a complete pipeline. The more context files you reference, the more accurate the generated YAML will be. Always include package.json for build commands and any Dockerfile for containerized deployments.

Cursor Composer prompt
1// Prompt to type in Cursor Composer (Cmd+I):
2// @package.json @Dockerfile @tsconfig.json @vitest.config.ts
3// Generate a GitHub Actions CI/CD workflow at .github/workflows/ci.yml
4// Requirements:
5// - Trigger on push to main and pull requests
6// - Install deps with pnpm, cache node_modules
7// - Run: pnpm lint, pnpm typecheck, pnpm test -- --coverage
8// - Build: pnpm build
9// - Deploy to Vercel on main branch only (use VERCEL_TOKEN secret)
10// - Cancel in-progress runs for the same branch
11// - Add comments explaining each step

Pro tip: Reference @vitest.config.ts or @jest.config.js so Cursor knows the exact test command and can add proper coverage reporting steps.

Expected result: Cursor generates a complete .github/workflows/ci.yml file with all specified stages and proper caching.

3

Review and refine the generated pipeline

Open Chat with Cmd+L and ask Cursor to review the generated pipeline for common issues. Reference the generated YAML file. Cursor will identify missing caching, incorrect action versions, redundant steps, and security issues like exposed secrets.

Cursor Chat prompt
1// Prompt to type in Cursor Chat (Cmd+L):
2// @.github/workflows/ci.yml
3// Review this GitHub Actions workflow for:
4// 1. Outdated action versions (should use latest stable)
5// 2. Missing cache configuration
6// 3. Security issues (hardcoded secrets, excessive permissions)
7// 4. Missing concurrency controls
8// 5. Unnecessary steps that slow down the pipeline
9// List each issue with the fix.

Expected result: Cursor identifies specific issues in the pipeline YAML with line-by-line recommendations.

4

Generate an Azure DevOps pipeline variant

If your team uses Azure DevOps, use Cmd+K to convert the GitHub Actions workflow to Azure Pipelines syntax. Select the entire YAML file, press Cmd+K, and ask for the conversion. Cursor understands the mapping between platforms.

Cmd+K inline prompt
1// Select the entire .github/workflows/ci.yml content,
2// then press Cmd+K and type:
3// Convert this GitHub Actions workflow to Azure DevOps
4// azure-pipelines.yml format. Use:
5// - vmImage: 'ubuntu-latest'
6// - task: NodeTool@0 for Node.js setup
7// - script steps for pnpm commands
8// - stages: Build, Test, Deploy
9// - condition: succeeded() for deployment gate

Pro tip: You can also ask Cursor to generate GitLab CI (.gitlab-ci.yml) using the same conversion approach. Just specify the target platform.

Expected result: The GitHub Actions YAML is converted to valid Azure DevOps pipeline syntax with equivalent stages.

5

Debug pipeline failures with Cursor

When a pipeline fails, copy the error output from your CI/CD dashboard and paste it into Cursor Chat. Reference the pipeline YAML file and ask Cursor to diagnose and fix the issue. Cursor is particularly effective at fixing YAML syntax errors and missing dependency issues.

Cursor Chat prompt
1// Prompt to type in Cursor Chat (Cmd+L):
2// @.github/workflows/ci.yml
3// My CI pipeline failed with this error:
4// [paste the full error output from GitHub Actions]
5// Diagnose the root cause and provide the exact fix.
6// Show me the corrected YAML for the failing step.

Pro tip: Use the @web context to have Cursor search for the specific error message online. Type: '@web [error message] GitHub Actions fix' for the latest solutions.

Expected result: Cursor identifies the pipeline failure cause and provides the corrected YAML configuration.

Complete working example

.github/workflows/ci.yml
1name: CI/CD Pipeline
2
3on:
4 push:
5 branches: [main]
6 pull_request:
7 branches: [main]
8
9concurrency:
10 group: ${{ github.workflow }}-${{ github.ref }}
11 cancel-in-progress: true
12
13jobs:
14 build-and-test:
15 runs-on: ubuntu-latest
16 strategy:
17 matrix:
18 node-version: [20, 22]
19
20 steps:
21 # Checkout repository code
22 - uses: actions/checkout@v4
23
24 # Install pnpm package manager
25 - uses: pnpm/action-setup@v4
26 with:
27 version: 9
28
29 # Setup Node.js with caching
30 - uses: actions/setup-node@v4
31 with:
32 node-version: ${{ matrix.node-version }}
33 cache: 'pnpm'
34
35 # Install dependencies
36 - run: pnpm install --frozen-lockfile
37
38 # Run linting checks
39 - run: pnpm lint
40
41 # Run TypeScript type checking
42 - run: pnpm typecheck
43
44 # Run tests with coverage
45 - run: pnpm test -- --coverage
46
47 # Build the project
48 - run: pnpm build
49
50 # Upload coverage report
51 - uses: actions/upload-artifact@v4
52 if: matrix.node-version == 22
53 with:
54 name: coverage-report
55 path: coverage/
56
57 deploy:
58 needs: build-and-test
59 runs-on: ubuntu-latest
60 if: github.ref == 'refs/heads/main' && github.event_name == 'push'
61
62 steps:
63 - uses: actions/checkout@v4
64
65 - name: Deploy to Vercel
66 uses: amondnet/vercel-action@v25
67 with:
68 vercel-token: ${{ secrets.VERCEL_TOKEN }}
69 vercel-org-id: ${{ secrets.VERCEL_ORG_ID }}
70 vercel-project-id: ${{ secrets.VERCEL_PROJECT_ID }}
71 vercel-args: '--prod'

Common mistakes when generating CI/CD Configs with Cursor

Why it's a problem: Not referencing package.json when generating pipeline YAML

How to avoid: Always include @package.json in your pipeline generation prompt so Cursor uses your exact script names and package manager.

Why it's a problem: Hardcoding secret values in generated YAML

How to avoid: Add a .cursorrules entry: 'Never hardcode secrets in YAML — always use ${{ secrets.NAME }} syntax.' Review all generated YAML for hardcoded values before committing.

Why it's a problem: Using outdated GitHub Action versions

How to avoid: Add a rule specifying current action versions: 'Use actions/checkout@v4, actions/setup-node@v4, actions/cache@v4.'

Why it's a problem: Missing cache configuration in generated pipelines

How to avoid: Explicitly request caching in your prompt and verify the cache key includes the lockfile hash.

Best practices

  • Reference package.json, Dockerfile, and test config files when generating pipeline YAML
  • Create a .cursor/rules/cicd.mdc with auto-attaching globs for workflow files
  • Specify exact CI/CD platform and action versions in your rules to prevent outdated syntax
  • Use concurrency groups to cancel in-progress runs when new commits push to the same branch
  • Add step-level comments in pipeline YAML so future developers understand each stage
  • Test pipeline changes in a feature branch before merging to main
  • Use Cursor Chat to debug pipeline failures by pasting CI error output directly into the prompt

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

Generate a GitHub Actions CI/CD workflow for a Node.js project using pnpm. Include: dependency caching, linting, type checking, testing with coverage, building, and deploying to Vercel on main branch. Use Node.js 22, cancel in-progress runs, and add comments for each step.

Cursor Prompt

@package.json @Dockerfile @tsconfig.json Generate a complete GitHub Actions workflow at .github/workflows/ci.yml. Install with pnpm, cache dependencies, run lint + typecheck + test with coverage + build. Deploy to Vercel on main branch push only. Use concurrency groups and add step comments. Reference secrets with ${{ secrets.NAME }}.

Frequently asked questions

Can Cursor deploy my application directly?

No. Cursor generates and edits pipeline configuration files but does not execute deployments. The generated YAML runs in your CI/CD platform (GitHub Actions, Azure DevOps, etc.) which handles the actual deployment.

How do I set up CI/CD for a Cursor project?

Open Composer (Cmd+I), reference @package.json and other config files, and prompt Cursor to generate a workflow file for your CI platform. Commit the generated YAML and configure secrets in your CI platform's settings dashboard.

Can Cursor fix a failing pipeline automatically?

Yes, with the MCP GitHub integration, Cursor can push fixes and iterate through build cycles. Without MCP, paste the CI error output into Chat (Cmd+L) with the pipeline YAML referenced, and Cursor will provide the fix to apply manually.

Does Cursor support Azure DevOps pipelines?

Yes. Specify 'Azure DevOps' in your .cursorrules or prompt, and Cursor generates azure-pipelines.yml with proper stages, pools, tasks, and conditions. You can also convert existing GitHub Actions workflows to Azure format.

How do I handle secrets in Cursor-generated pipelines?

Cursor cannot access or create CI secrets. It generates references like ${{ secrets.VERCEL_TOKEN }} in YAML. You must manually configure the actual secret values in your CI platform's settings. Add a rule requiring secrets syntax in .cursorrules.

Can Cursor generate multi-stage Docker builds for CI?

Yes. Reference @Dockerfile and @package.json and ask Cursor to generate a multi-stage Dockerfile with separate build and production stages. Then generate a CI pipeline that builds and pushes the Docker image.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.