# Cursor rules for SAP ABAP: a setup guide

> How to set up Cursor project rules (.cursor/rules/*.mdc) for SAP ABAP: which rule types to use, glob patterns for ABAP files, what to put in an always-on rule, and how to test that the rules work.

By ABAP for Agents · Updated 2026-10-22 · https://abapforagents.com/guides/cursor-rules-sap-abap/

## TL;DR

- Cursor project rules live in .cursor/rules as .mdc files. Plain .md files in that folder are ignored.
- Use alwaysApply: true for a short core rule (target release, no invented SAP objects) and globs: **/*.abap for topic rules like ABAP SQL.
- Glob rules only fire when ABAP source files are in context, so work in an abapGit repo or an ADT for VS Code project with local files.
- Use either .cursor/rules or AGENTS.md, not both, or Cursor loads the same instructions twice.
- Test with a release-specific prompt and check that the agent declares targets, guards FOR ALL ENTRIES and names the SAP objects it uses.

Cursor's agent doesn't know which SAP system you work on, which release it runs, or which objects exist in it. Project rules are how you tell it once instead of in every prompt. This guide shows a setup that works well for ABAP, based on Cursor's rules documentation and the structure of our free rules.

## Where Cursor rules live

Project rules are files in `.cursor/rules/` at the root of the folder you open in Cursor. Each rule is an `.mdc` file: Markdown with a short frontmatter block. Cursor's documentation is clear that a plain `.md` file in that folder is ignored by the rules system. If you'd rather use plain Markdown, use `AGENTS.md` in the project root instead.

For ABAP, "the folder you open" is usually one of these:

- an **abapGit repository** cloned locally, with files like `zcl_sales_order.clas.abap`
- a project in SAP's **ABAP development tools for VS Code**, which stores ABAP sources as local files

If your ABAP code only lives in the SAP system and there are no local files, rules scoped by file pattern have nothing to match. In that case rely on always-on rules.

## The four ways a rule is applied

Three frontmatter fields decide when Cursor includes a rule:

| Frontmatter | Behavior |
|---|---|
| `alwaysApply: true` | Included in every chat session |
| `alwaysApply: false` + `globs` | Attached when a matching file is in context |
| `alwaysApply: false` + `description`, no globs | The agent reads the description and pulls the rule in when relevant |
| `alwaysApply: false`, no description, no globs | Only when you @-mention the rule |

For ABAP, a good split is:

- **Always on:** a short core rule and a self-check list.
- **Glob-scoped:** detailed topic rules (syntax by release, ABAP SQL, obsolete statements) that only matter when ABAP files are open.
- **Description only:** task rules, such as a code review checklist, that the agent pulls in when you ask for that task, or that you @-mention.

## A practical layout

This is the structure of our free lite rules for Cursor:

```text
.cursor/rules/
  00-core.mdc                     alwaysApply: true
  10-release-syntax.mdc           globs: **/*.abap
  20-abap-sql.mdc                 globs: **/*.abap
  60-obsolete.mdc                 globs: **/*.abap
  90-llm-pitfalls.mdc             alwaysApply: true
  task-abap-clean-core-review.mdc description only
```

A glob-scoped rule starts like this:

```markdown
---
description: Correct ABAP SQL syntax, strict mode, FOR ALL ENTRIES traps.
globs: **/*.abap
alwaysApply: false
---
# ABAP SQL
- Escape every host variable with @ and separate lists with commas.
- FOR ALL ENTRIES with an empty driver table ignores the whole
  WHERE clause. Always guard: IF itab IS NOT INITIAL.
- SELECT SINGLE is for a full primary key.
```

If you also edit CDS or behavior definitions as local files, add their extensions to the globs. Cursor accepts several patterns separated by commas. Which extensions you need depends on your tool: the ABAP file format used by ADT for VS Code and abapGit use different ones, so check the files in your own project.

## What belongs in the always-on core rule

Keep the core rule short. It's sent with every request, and long instruction files are followed less reliably. These points pay off the most:

```markdown
---
description: Core guardrails for any ABAP work.
alwaysApply: true
---
# ABAP core
- Before writing code, establish: language version (ABAP Cloud or
  Standard ABAP), product (S/4HANA or ECC) and SAP_BASIS release.
  If unknown, assume the lowest plausible release.
- Never mix syntax from different releases in one answer.
- Never invent function modules, BAPIs, classes, CDS views or tables.
  Name every SAP object you rely on and flag the ones to verify.
- State your release assumption in one line at the top of the answer.
```

Then add what only your team knows. A house rule is often the most useful file in the folder:

```markdown
---
description: Our team's ABAP conventions.
alwaysApply: true
---
- System: S/4HANA 2022 on-premise, Standard ABAP.
- Customer namespace: Z, package prefix ZSD_.
- Keep the existing lv_/lt_ prefixes in legacy objects.
- Prefer released CDS views over direct table reads.
```

Replace these lines with your own facts. The release line alone removes most wrong-syntax answers.

## Rules or AGENTS.md, not both

Cursor also reads `AGENTS.md` in the project root and in subdirectories. That's convenient if your team uses several tools, but if you keep both `.cursor/rules/` and an `AGENTS.md` with the same content, the agent gets the instructions twice. Pick one per repository. If colleagues use Claude Code, Codex or Copilot too, `AGENTS.md` is the shared option (see [Claude Code and AGENTS.md for ABAP](https://abapforagents.com/guides/claude-code-agents-md-abap/)).

## Test that the rules work

Open an ABAP file so the glob rules attach, then ask something release-specific:

```text
Write ABAP for SAP_BASIS 7.40 SP05 that reads VBAK for a list
of sales order numbers in an internal table.
```

With working rules, look for these in the answer:

- a one-line statement of the assumed release
- a declared target table instead of `INTO TABLE @DATA(...)`, which needs 7.40 SP08
- `IF keys IS NOT INITIAL.` around the FOR ALL ENTRIES
- `@` in front of every host variable, with comma-separated field lists

If the answer ignores the release, check the rule's frontmatter first: a rule with `alwaysApply: false` and no matching file in context is simply not loaded. Cursor's Customize panel shows which rules exist and how each one is applied.

## Keep rules honest

Rules are guidance, not enforcement. The agent can still drift, especially in long sessions. Keep the syntax check, ATC and ABAP Unit as the gate, and when the agent repeats a mistake, add one precise line to the rule that covers it rather than a paragraph. For a list of mistakes worth covering, see [ABAP mistakes AI coding assistants make](https://abapforagents.com/guides/ai-abap-mistakes/).

## Get the rules

Start with the free rules: ABAP for Agents Lite (MIT), for Cursor, Claude Code, GitHub Copilot, Windsurf and AGENTS.md: https://github.com/abapforagents/abap-for-agents-lite (ZIP: https://github.com/abapforagents/abap-for-agents-lite/releases/latest/download/abap-for-agents-lite.zip).

The full Rules Pack (v1.1) has 300+ rules across 20 topics (adding performance, security, RAP, CDS, OData and Fiori, ABAP Cloud and clean core, LUW and locks, BAPIs, ABAP Unit and S/4HANA migration) plus 8 agent skills, with free updates: 19 € at launch (29 € after), https://abapforagents.com/#pricing