# Development Workflow > Use when starting SAP development work, creating transports, moving objects across landscapes, structuring packages, or any task involving DEV→QAS→PRD change management. - **Type:** Skill - **Install:** `agentstack add skill-vigneshbarani24-sap-superpowers-development-workflow` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [vigneshbarani24](https://agentstack.voostack.com/s/vigneshbarani24) - **Installs:** 0 - **Category:** [Agent Skills](https://agentstack.voostack.com/c/agent-skills) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [vigneshbarani24](https://github.com/vigneshbarani24) - **Source:** https://github.com/vigneshbarani24/sap-superpowers/tree/main/skills/development/development-workflow - **Website:** https://sap-superpowers.vercel.app/ ## Install ```sh agentstack add skill-vigneshbarani24-sap-superpowers-development-workflow ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # SAP Development Workflow This skill enforces disciplined transport management and landscape governance — it makes landscape-breaking shortcuts impossible, not just inadvisable. ## Iron Laws 1. **NEVER DEVELOP IN PRODUCTION.** No exceptions. Not for "urgent fixes." Not for "just a config change." Not for "it's only a text." Production development bypasses QA, creates untraceable changes, and destroys audit trails. One violation invalidates the entire change management process. 2. **NEVER RELEASE A TRANSPORT WITHOUT TESTING.** A transport released to PRD without QAS validation is a production incident waiting to happen. "It worked in DEV" is not testing. QAS confirmation with documented test evidence is testing. 3. **NEVER MIX OBJECT TYPES IN ONE TRANSPORT.** Workbench objects and customizing objects belong in separate transports. Mixed transports create import sequence dependencies that break in production. One transport = one logical unit of change. 4. **NEVER SKIP THE NAMING CONVENTION.** Unnamed or inconsistently named objects become orphaned. When the developer leaves, no one knows what the object does, who owns it, or whether it's safe to delete. 5. **ALWAYS DOCUMENT THE TRANSPORT BEFORE RELEASE.** Description, linked ticket/change request, objects included, and reason for change. A transport with no description is a transport that will cause a production incident investigation to stall. ## Rationalization Table | Agent Will Try To... | Why It Seems Reasonable | Why It Fails | Counter | |---|---|---|---| | Suggest a direct PRD fix for "urgent" changes | "It's a 2-minute config change, the normal process takes days" | Emergency PRD changes have caused more production incidents than they've prevented. Every "urgent" shortcut bypasses regression checks. | Iron Law 1. Escalate to the emergency transport process (fast-tracked CTS), not a direct PRD change. | | Mix workbench and customizing in one transport | "These changes are related, keep them together" | Workbench objects need ABAP import; customizing needs business config import. Mixed transports fail on import sequencing across clients. | Iron Law 3. Separate transports are always required. Link them in the change request, not in the transport. | | Release to PRD without QAS sign-off | "There's no time, we need this in PRD today" | QAS exists to catch exactly the errors that "seem fine" in DEV. Skipping it means the first test is in production with real users. | Iron Law 2. If the process cannot accommodate QAS testing, the process is broken — escalate to management, don't skip QAS. | | Create objects in the wrong package | "The default package is fine for now" | Objects in wrong packages lose their transport layer assignment. They become orphaned and cannot be moved to the correct landscape via CTS. | Checklist Step 2: Package assignment is mandatory before any object creation. | | Skip transport documentation | "Everyone knows what this transport does, it's obvious" | In 6 months, "obvious" becomes "what was this for?" Transport audits, rollbacks, and incident investigations all depend on descriptions. | Iron Law 5. No transport gets released without a description referencing the change request. | | Use local objects ($TMP) for development | "I'll move them to a proper package later" | Local objects cannot be transported. "Later" becomes never. Development ends up in $TMP and can never reach production. | Checklist Step 2: Assign to a transportable package before development begins. | ## Red Flags Watch for these phrases in your own reasoning — each one signals you're about to violate an Iron Law: - "It's just a small change in production..." → Iron Law 1. Stop. There is no such thing as a safe production change outside CTS. - "We can clean up the package structure later..." → Later never comes. Package assignment happens before object creation. - "Let's put everything in one transport to keep it simple..." → Simplicity now = import failure later. Separate by object type. - "QAS is basically the same as DEV, testing there is just a formality..." → QAS exists because DEV is not DEV. Config drift, master data differences, and user permissioning make QAS essential. - "I'll add the transport description before the release..." → The release IS the deadline. If it doesn't have a description, it doesn't get released. - "The naming convention doesn't really matter for this one..." → It matters for every one. Inconsistency compounds. - "CTS+ is overkill for this change..." → CTS+ is the process. Use it. Before any development object is created or any transport is opened: confirm (1) the target package exists and is transportable, (2) the development system is DEV — not QAS or PRD, (3) a change request exists in the project tracking system, and (4) the naming convention for this customer/project is confirmed. If any of these four conditions is not met, STOP — do not create the transport. ## Checklist 1. **Confirm development system** — Verify the active system is the DEV client, not QAS or PRD. - Evidence: System ID and client number (e.g., D01/100) confirmed in SY-SYSID and SY-MANDT. - Gate: System is DEV. If not DEV, halt and escalate. 2. **Assign package before creating objects** — Check that a valid, transportable package exists for this project/module. Never use $TMP. - Evidence: Package name confirmed in SE80, package attributes show transport layer assigned. - Gate: Package exists with correct transport layer. If not, create the package before proceeding. 3. **Create the correct transport type** — Workbench changes (ABAP, Dictionary, BAdI) use Workbench Request (SE09). Customizing changes use Customizing Request (SE10). Never mix. - Evidence: Transport type shown in SE01 matches the object type being developed. - Gate: Correct transport type selected and documented. 4. **Apply naming convention** — All objects follow the customer namespace (Z/Y prefix or registered namespace). Object name includes module identifier and functional identifier per project standards. - Evidence: Object name matches the naming convention table confirmed in Step 0. - Gate: Name reviewed and approved before saving. 5. **Develop and unit test in DEV** — Implement the change. Run SE37 function module tests, write ABAP Unit tests where applicable, execute the full user scenario in DEV. - Evidence: Unit test results documented. DEV scenario walkthrough complete with screenshots or log output. - Gate: All unit tests pass. No syntax errors (SE38/SLIN). ATC checks complete with no open findings above threshold. 6. **Release transport from DEV** — Release the transport task (developer level) then the transport request (team lead level) via SE01/SE09. - Evidence: Transport status shows "Released" in SE01. Transport log shows no errors. - Gate: Transport released successfully. Request number recorded in change management ticket. 7. **Import to QAS and execute integration test** — Import the released transport to QAS via STMS. Execute the full test scenario in QAS with a test user (not an admin/basis user). - Evidence: STMS import log for QAS shows RC=0. Test execution results documented (pass/fail per test case). Tester name and date recorded. - Gate: All test cases pass in QAS. If any fail, return to DEV — do not import partial fixes directly to QAS without a new transport. 8. **Obtain PRD import approval** — Change request status updated to "QAS Approved." PRD import request submitted per the customer's change management process. - Evidence: Change request shows QAS sign-off with approver name. PRD import request created in the customer's ITSM tool. - Gate: Formal approval received. Import scheduled in the next available change window. 9. **Import to PRD and verify** — Import the transport to PRD via STMS during the approved change window. Execute smoke test in PRD immediately after import. - Evidence: STMS import log for PRD shows RC=0. PRD smoke test results documented. No production incidents raised within 24 hours. - Gate: PRD smoke test passes. Change request closed with completion date. ## Transport Naming Reference | Object Type | Transport Type | T-Code to Create | Notes | |---|---|---|---| | ABAP programs, function modules, classes | Workbench Request | SE09 | Never mix with customizing | | IMG/customizing settings | Customizing Request | SE10 | Never mix with workbench | | Transport of copies | Transport of Copies | SE01 | For corrections only — not standard development flow | | CTS+ (extended transport) | CTS+ Request | CTS_BROWSER | For non-ABAP content (Fiori, BTP, metadata) | ## Landscape Overview ``` DEV (Development) → QAS (Quality Assurance) → PRD (Production) SE09/SE10 STMS Import STMS Import (develop) (integration test) (change window) ``` Each arrow represents a formal transport import — never a direct change. ## Package Structure Template ``` Z_ — Top-level package (e.g., ZABC_FI) Z__OBJ — Dictionary objects (tables, structures, types) Z__PRG — Programs and reports Z__FC — Function groups and modules Z__CL — Classes and interfaces Z__ENH — Enhancements and BAdI implementations Z__CFG — Configuration (if workbench-transportable) ``` ## Verification This skill is complete ONLY when ALL of the following are true: - [ ] Development was performed in DEV system — never in QAS or PRD - [ ] All objects are assigned to a transportable package (not $TMP) - [ ] Naming conventions applied to every object created - [ ] Transport types are correct — workbench and customizing in separate transports - [ ] All transports have descriptions referencing a change request number - [ ] Unit tests documented with pass results in DEV - [ ] QAS import RC=0 confirmed in STMS import log - [ ] QAS test cases executed and documented with tester sign-off - [ ] PRD import approved via formal change management process - [ ] PRD import RC=0 confirmed and smoke test executed **Evidence required:** STMS import logs (DEV release + QAS import + PRD import), unit test documentation, QAS test case results with tester sign-off, change request with approval trail. ## Next Skill After completing this skill, invoke: `code-review` Conditions for handoff: Before the transport is released from DEV (after Step 5, before Step 6), trigger code review to validate the implementation against standards. ## Cross-References - Use `code-review` before releasing any transport from DEV - Use `troubleshooting` if STMS import fails at any landscape stage - Use `code-generation` when the development task involves generating new ABAP Cloud or RAP objects ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [vigneshbarani24](https://github.com/vigneshbarani24) - **Source:** [vigneshbarani24/sap-superpowers](https://github.com/vigneshbarani24/sap-superpowers) - **License:** MIT - **Homepage:** https://sap-superpowers.vercel.app/ Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-vigneshbarani24-sap-superpowers-development-workflow - Seller: https://agentstack.voostack.com/s/vigneshbarani24 - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.