Cursor rules for SAP ABAP: a setup guide

By ABAP for Agents · Updated 22 October 2026

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:

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:

.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:

---
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:

---
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:

---
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).

Test that the rules work

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

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.

More guides