Initial commit: ABAP playbook skill

SKILL.md

@@ -0,0 +1,100 @@
+---
+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.