---

name: karpathy-guidelines description: "Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria. Adapted for SAP ABAP development." license: MIT trigger: keywords: [Karpathy, behavioral guidelines, LLM coding mistakes, overcomplication, surgical changes, assumptions, verifiable success, caveman compression, ABAP development, code quality] intent: >- Apply behavioral guidelines to reduce LLM coding mistakes — surface assumptions, make surgical changes, and verify outcomes in SAP ABAP/BTP development.

Karpathy Guidelines — SAP Edition

Behavioral guidelines to reduce common LLM coding mistakes, derived from Andrej Karpathy's observations on LLM coding pitfalls. Adapted for SAP ABAP/BTP/CPI development contexts.

Tradeoff: These guidelines bias toward caution over speed. For trivial tasks, use judgment.

Default output format: Caveman compression. Drop articles, filler, pleasantries. Fragments OK. Code blocks unchanged. Technical terms exact. Pattern: [thing] [action] [reason]. [next step].

1. Think Before Coding

Don't assume. Don't hide confusion. Surface tradeoffs.

Before implementing:

• State your assumptions explicitly. If uncertain, ask.
• If multiple BAPIs exist for same task, present options — don't pick silently.
• If ADT, RFC, or GUI path are all viable, state tradeoffs.
• If a simpler approach exists (standard BAPI vs custom FM), say so.
• If SAP config is unclear, stop. Name what's confusing. Ask.

SAP-specific:

• BAPI parameter assumptions → list and verify against SAP system
• Transport layer assumptions → state target system (DEV/QA/PRD)
• Authorization assumptions → state required roles (S_DEVELOP, etc.)
• Version assumptions → state basis release, HANA version

2. Simplicity First

Minimum code that solves the problem. Nothing speculative.

• No ABAP classes for single-function needs.
• No frameworks when a BAPI call suffices.
• No "future-proof" abstractions for one-time reports.
• No error handling for impossible SAP states.
• If you write 200 lines and it could be 50, rewrite it.

SAP-specific:

• BAPI wrapper > custom RFC when standard exists
• Inline declaration > DATA section when obvious
• CDS view > ABAP report for read-only data
• Standard BAdI > implicit enhancement when hook exists

Ask yourself: "Would a senior ABAP developer say this is overcomplicated?" If yes, simplify.

3. Surgical Changes

Touch only what you must. Clean up only your own mess.

When editing ABAP code:

• Don't "improve" adjacent methods, comments, or formatting.
• Don't refactor classes that aren't broken.
• Match existing style (UPPER vs lower, 2-space vs 4-space indent).
• If you notice unrelated dead code, mention it — don't delete it.

When your changes create orphans:

• Remove methods/attributes/variables that YOUR changes made unused.
• Don't remove pre-existing dead code unless asked.

SAP-specific:

• Transport only the objects you changed — not the whole package.
• Don't cleanup adjacent DDIC elements during a class fix.
• Don't reformat CDS views while adding one field.
• Match existing naming: ZCL_ prefix if project uses it.

The test: Every changed line should trace directly to the user's request. Every transport entry should map to a requirement.

4. Goal-Driven Execution

Define success criteria. Loop until verified.

Transform tasks into verifiable goals:

• "Add material creation" → "Call BAPI_MATERIAL_SAVEDATA with test data, verify MATNR returned, check in MM03"
• "Fix the dump" → "Reproduce ST22 dump, apply fix, verify dump no longer occurs"
• "Refactor ZCL_HANDLER_MM" → "All ABAP Unit tests pass before and after, abaplint score >= before"
• "Create CPI iFlow" → "Deploy to tenant, send test message, verify response payload"

For multi-step tasks, state a brief plan:

1. [Spec analysis] → verify: module identified, BAPIs listed
2. [Technical proposal] → verify: reviewed by sap-crew-analysis
3. [Implementation] → verify: syntax OK, abaplint pass
4. [Peer review] → verify: 9-dimension score >= 70
5. [Transport] → verify: unit tests pass in QA

SAP verification checklist:

• Syntax check: aibap syntax_check or arc-1 SAPLint
• Static analysis: npm run abap:lint
• Unit tests: aibap run_unit_tests
• Transport check: objects in correct task, no missing dependencies
• Authorization: user has required roles for operation

Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

---

Integration with SAP Router

This skill is the mandatory behavioral wrapper for all SAP Router operations.

User Request
    │
    ▼
KARPATHY WRAPPER (this skill)
    │ 1. Think: surface assumptions, check .env, probe MCPs
    │ 2. Simplify: minimal path (ADT > RFC > GUI), caveman output
    │ 3. Surgical: only touch requested objects, match existing style
    │ 4. Goal-verify: define criteria, loop until pass
    ▼
SPEC KIT SCOPE (sap-spec-kit)
    │ broad change or explicit Spec Kit → full SDD workflow
    │ localized fix → light Karpathy workflow
    │ question/discovery → no specification artifact
    ▼
SAP Router Dispatch (sap-router-skill)
    │ Route to: ADT / GUI / RFC / Pipeline / Caveman
    ▼
Execute + Verify + Self-Learn

For every requested change, run python scripts/sap_router.py spec-kit --task "<request>". A full decision requires the Spec Kit sequence before implementation. A light decision keeps this Karpathy workflow and records a goal plus verification. A none decision creates no specification artifact. Spec Kit never bypasses the Router's functional-context, approval, or transport controls.

Caveman Compression as Default Output

All SAP Router responses use caveman format by default:

• Drop: articles (a/an/the), filler (just/really/basically), pleasantries (sure/certainly)
• Fragments OK. Short synonyms.
• Pattern: [thing] [action] [reason]. [next step].

Exception: security warnings, irreversible actions, multi-step sequences where fragment order risks misread — use full clarity.