101 lines
3.9 KiB
Markdown
101 lines
3.9 KiB
Markdown
---
|
|
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.
|