---
name: abap-playbook
description: >
  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.