abap-playbook-skill/SKILL.md

name, description

name

description

abap-playbook

Use this skill for ABAP development tasks that run through the EPOD ADT MCP Server. Trigger it when a task creates a new object, changes two or more objects, or must keep the current behaviour of an object (a refactoring, a correction in shared code). Do not trigger it for a small task: one method, one clear fix, no behaviour risk. The skill runs a phased playbook with gates, binds each phase to the token-efficient MCP tools, and stops for user approval before implementation.

ABAP Development Playbook

The playbook has five phases. Each phase ends with a gate. Do not start the next phase before the gate passes. If a gate fails two times, stop and ask. A third attempt costs more than a question.

When to open the playbook

Open it when at least one of these is true:

• The task creates a new repository object.
• The task changes two or more objects.
• The task must keep the current behaviour (refactoring, shared code, correction reports).

For everything else: work directly. Do not add process to a small task.

Phase 1 — Discovery

Read structure before source. In this order:

1. sap_object_members for each object in scope. Not sap_pull_source.
2. For the package pattern: sap_object_members on two or three similar objects. Do not read their bodies.
3. sap_usage_references for each object that changes.
4. Read a method body only when a gate needs it: sap_pull_source with element=<name>. A full pull needs a written reason in the playbook.

Record the results in the playbook tables (template: templates/playbook-template.md). The tables are the memory. Do not read the same object twice.

Gate A: every object in scope has a caller list, the naming convention is written down, and no open question needs a system read.

Phase 2 — Plan

Fill the template: impact table, object plan, test cases, acceptance criteria. Every object gets an exact name. Every new object gets one responsibility sentence. For a refactoring: state how the current behaviour is captured (a saved result list, a comparison run) before any change.

Gate B/C: show the filled playbook to the user and STOP. Do not start Phase 3 without an explicit approval. This gate is never skipped: if the playbook is open, the approval is required.

Phase 3 — Implementation

Rules:

• The object list in the plan is a contract. Do not touch an object that the plan does not name. If a new object becomes necessary, stop, update the plan, ask again.
• Change one method: sap_push_element. Change a signature and a body: one sap_push_element call with signature. Push a full source only for a new object, with sap_push_source.
• One object per step. Verify before the next object.
• Move logic without improving it when the task is a refactoring. A fix found on the way goes to the open-points list, not into the code.

Phase 4 — Verification

• sap_check_object after each object: syntax, ATC, unit tests in one call. Do not call the three tools separately.
• Priority 1 findings block the gate. An open priority 2 finding needs a written reason.
• Stop rule: the same finding after two fix attempts stops the phase.

Gate D: all objects active, checks clean or explained, all planned tests green, no object outside the plan changed.

Phase 5 — Close

Fill the change summary table: object, action, one line of reason. List the open points, or state that the list is empty. Confirm the transport holds the planned objects and nothing else.

Token rules (always active)

• Keep one session for the task. Do not clear the session between phases.
• Read the part, not the file. sap_object_members before source, element= before a class.
• After each phase, keep the tables and drop the raw source from the working context.
• Give the system, the object, and the scope in every sub-task you formulate. Do not grep and do not run shell commands against pulled sources when a tool answers the question.