agentleFS
williamcorrea23williamcorrea23/sap-router-skill/.agents/skills/abap/SKILL.md

abap

Skill1 starsChanged 4 months agoMITView on GitHub

Check and improve ABAP code quality using abaplint and Clean ABAP principles. Use this skill when users ask to check, lint, validate, review, or analyze ABAP code for syntax errors, clean code compliance, code quality, best practices, or adherence to Clean ABAP guidelines. Also use when users ask to set up abaplint, configure abaplint.json, or run abaplint on their ABAP project. Triggers include requests like "check this ABAP code", "lint my ABAP", "run abaplint", "configure abaplint", "is this clean ABAP", "review my ABAP", or "analyze ABAP code quality".

  • Installs packages

2 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

24 rules. About 0 are common, 13 are distinctive, and 11 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 11

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check and improve ABAP code quality using two complementary approaches:

    line 8
  2. Distinctive:

    If the user asks to lint, run abaplint, or check syntax: use abaplint

    line 16
  3. Distinctive:

    If the user asks for clean code review, best practices, or code quality: use Clean ABAP review

    line 17
  4. Distinctive:

    If unclear or the user asks for a full check: use both

    line 18
  5. Very specific:

    Verify abaplint is installed (npx @abaplint/cli --version or abaplint --version)

    line 21
  6. Very specific:

    If not installed, install with: npm install @abaplint/cli -g

    line 22
  7. Very specific:

    Check if abaplint.json exists in the project root

    line 23
  8. Very specific:

    If no config exists, help the user create one (see starter configs in references/abaplint.md)

    line 24
  9. Very specific:

    Run abaplint in the project root directory

    line 25
  10. Distinctive:

    Read the ABAP code provided by the user

    line 29
  11. Distinctive:

    Check against Clean ABAP categories: Names, Language, Constants, Variables, Tables, Strings, Booleans, Conditions, Ifs, Classes, Methods, …

    line 30
  12. Distinctive:

    Run in project root:

    line 37
  13. Distinctive:

    Use descriptive names, snake*case, no Hungarian notation (iv*, lv*, lt*)

    line 55
  14. Distinctive:

    Prefer OO over procedural, functional over imperative

    line 60
  15. Distinctive:

    Use modern syntax: NEW, inline declarations, table expressions

    line 61
  16. Distinctive:

    No magic numbers, use ENUM or grouped constants

    line 65
  17. Distinctive:

    Prefer inline declarations, no chained DATA

    line 69
  18. Very specific:

    No DEFAULT KEY, use INSERT INTO TABLE, LINE_EXISTS, WHERE clauses

    line 73
  19. Very specific:

    Use ABAP_BOOL, ABAP_TRUE/ABAP_FALSE, XSDBOOL

    line 81
  20. Distinctive:

    No empty IF branches, CASE over ELSE IF, nesting depth <= 3

    line 89
  21. Very specific:

    abaplint config & setup: Read references/abaplint.md for installation, configuration options, and starter configs

    line 145
  22. Very specific:

    Complete Clean ABAP guide: Read references/CleanABAP.md for full style guide with rationale and examples

    line 146
  23. Very specific:

    Quick patterns: Read references/quick-reference.md for condensed good/bad code examples

    line 147
  24. Very specific:

    Review checklist: Read references/checklist.md for systematic review checklist

    line 148

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

ABAP

Check and improve ABAP code quality using two complementary approaches:

  • abaplint: Automated static analysis via CLI, checking syntax, types, and configurable rules
  • Clean ABAP: Manual review against Clean ABAP style guide principles

Workflow

  1. Determine check type based on user request:
    • If the user asks to lint, run abaplint, or check syntax: use abaplint
    • If the user asks for clean code review, best practices, or code quality: use Clean ABAP review
    • If unclear or the user asks for a full check: use both
  2. For abaplint checks:
    • Verify abaplint is installed (npx @abaplint/cli --version or abaplint --version)
    • If not installed, install with: npm install @abaplint/cli -g
    • Check if abaplint.json exists in the project root
    • If no config exists, help the user create one (see starter configs in references/abaplint.md)
    • Run abaplint in the project root directory
    • Parse and present findings to the user
  3. For Clean ABAP reviews:
    • Read the ABAP code provided by the user
    • Check against Clean ABAP categories: Names, Language, Constants, Variables, Tables, Strings, Booleans, Conditions, Ifs, Classes, Methods, Error Handling, Comments, Formatting, Testing
    • Identify violations with specific line references
    • Provide actionable recommendations with code examples
    • Prioritize issues by impact (critical, major, minor)

abaplint Quick Start

Run in project root:

abaplint

Generate default config (all rules):

abaplint -d > abaplint.json

For detailed abaplint configuration including starter configs for On-Premise, Steampunk/BTP, and HANA compatibility, read references/abaplint.md.

Clean ABAP Check Categories

Names

  • Use descriptive names, snakecase, no Hungarian notation (iv, lv*, lt*)
  • Nouns for classes, verbs for methods, no noise words

Language

  • Prefer OO over procedural, functional over imperative
  • Use modern syntax: NEW, inline declarations, table expressions

Constants

  • No magic numbers, use ENUM or grouped constants

Variables

  • Prefer inline declarations, no chained DATA

Tables

  • No DEFAULT KEY, use INSERT INTO TABLE, LINE_EXISTS, WHERE clauses

Strings

  • Backticks for literals, pipes for string templates

Booleans

  • Use ABAP_BOOL, ABAP_TRUE/ABAP_FALSE, XSDBOOL

Conditions

  • Positive conditions, IS NOT over NOT IS, predicative method calls

Ifs

  • No empty IF branches, CASE over ELSE IF, nesting depth <= 3

Methods

  • Instance over static, RETURNING over EXPORTING, <= 3 parameters, <= 20 lines

Error Handling

  • Exceptions over return codes, class-based exceptions, no catching CX_ROOT

Comments

  • Explain why not what, " over *, no commented-out code

Formatting

  • One statement per line, <= 120 chars, consistent indentation

Testing

  • Given-when-then structure, focused assertions, dependency injection

Output Format

Structure analysis results as:

# ABAP Check Results

## abaplint Findings
[abaplint output, grouped by severity]

## Clean ABAP Review

### Summary
- Total Issues: [count]
- Critical: [count] | Major: [count] | Minor: [count]

### Critical Issues
#### [Category] - [Issue Title]
**Location:** Line [X] / Method [name]
**Problem:** [description]
**Recommendation:** [how to fix]

### Major Issues
[Same format]

### Minor Issues
[Same format]

### Positive Observations
- [Things done well]

References

  • abaplint config & setup: Read references/abaplint.md for installation, configuration options, and starter configs
  • Complete Clean ABAP guide: Read references/CleanABAP.md for full style guide with rationale and examples
  • Quick patterns: Read references/quick-reference.md for condensed good/bad code examples
  • Review checklist: Read references/checklist.md for systematic review checklist

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.