SAP Transport Gate Skill

AI-assisted pre-release review for SAP Transport Requests. Based on provided evidence, produces a structured Release Readiness Report and an auditable GO / CONDITIONAL_GO / NO_GO / NEED_MORE_EVIDENCE decision.

Core principle: AI does NOT log in to SAP, does NOT execute transports, and does NOT fabricate conclusions from insufficient evidence. Every finding must trace to real evidence. Every gap must be declared.

Hard Constraints (enforce at all times)

Violations of these constraints invalidate the review output. Check them before generating any decision.

Step 0 — Load References

Before reading user-provided materials, load the following references in order:

1. references/review-modes.md — Mode detection, Review Package structure, evidence completeness rules
2. references/decision-policy.md — Evidence Level rules, Finding taxonomy, Release Decision Policy
3. references/review-dimensions.md — 10 review dimensions with detailed checks
4. references/report-format.md — Markdown report template and JSON schema
5. references/abap-security-rules.md — Full SEC-_ and AUTH-_ security rule library (load for Dimension 3 and 4)
6. references/abap-quality-rules.md — Full Clean ABAP quality rule library (load for Dimension 1 and 2)

Load references/sap-connectivity.md when:

• Review mode is Online Transport Mode (TR ID provided, no pre-exported package)

Load references/human-loop.md when:

• Target stage is PRD
• Any HIGH or CRITICAL finding is present
• Functional Alignment depends on business interpretation

Load references/regression-tests.md only if asked to run regression checks or build eval cases.

Step 0.5 — Extract Transport Request ID

Scan the user's input for a Transport Request ID before proceeding. TR IDs follow the pattern: 3–4 uppercase letters + K + 6 digits (e.g., DEVK900123, ECDK943668, NPLK000045).

The TR ID is required for the report filename, the Executive Decision header, the Appendix object list, and audit traceability.

Step 1 — Identify Review Mode

Determine the review mode from the input. Full rules in references/review-modes.md §1.

Online Transport Mode — Proactive Collection Protocol:

When a TR ID is identified and no pre-assembled package exists, the SKILL must proactively attempt collection rather than waiting for the user to provide materials. Online collection is read-only and performed by the sap-adt CLI (transport collect). Offline modes never need the CLI.

Execute the following in order:

1. Check the execution environment — you need a shell that can run binaries on the user's machine. No shell → hand the user the manual command (step 4) and wait. No install permission or no network → reclassify to Offline Local Mode with an explicit declaration.
2. Check CLI readiness — run sap-adt --version.
   • Missing: diagnose first (stale PATH vs sandbox vs absent install — never reinstall blindly). After confirming absence, guide the install and ask before running anything: Node.js ≥ 18 → npx "sap-adt-cli@^1.5.0" install (the range is the compatible range from references/runtime-compatibility.json; never an unbounded @latest); no Node.js → pip install "sap-adt-cli>=1.5.0,<2.0.0" or the newest 1.x portable archive.
   • Below the compatible range: show the upgrade command and ask first.
   • Declined or unavailable → Offline Local Mode, declared.

3. Run collection:

   sap-adt transport collect {TR_ID} --output-dir reports/{TR_ID}_package/ --verbose

   • Collection succeeds → proceed as Offline Package Mode with the collected package at reports/{TR_ID}_package/. Do NOT ask the user to run the command.

   • Collection fails (HTTP 401, 403, connection refused, SSL error, timeout):

     "SAP connection failed: {error}. Proceeding with Offline Local Mode. See references/sap-connectivity.md §11 for the step-by-step manual export guide if you want a complete evidence package."

     Reclassify to Offline Local Mode and continue.

4. Shell execution not available:

   "Shell execution is not available in this environment. To use automatic collection, run:

   sap-adt transport collect {TR_ID} --output-dir reports/{TR_ID}_package/ --verbose

   Once the package is ready, provide the path and I will proceed as Offline Package Mode. Or confirm you cannot run it to proceed now with Offline Local Mode."

   Wait for user response before continuing. Do NOT fabricate materials.

5. Configuration state — never read .env files, config.json, or credential stores yourself. sap-adt status (local, non-secret) reports whether a profile is configured; unconfigured → point the user at sap-adt configure (interactive, password stays local). The old plaintext collector config (~/.sap-transport-gate/config.json) is deprecated and read only on the explicit --legacy-config path — never as an implicit fallback for a missing profile.

When falling back to Offline Local Mode at any point, reclassify mode, declare the fallback reason in the report, and continue.

Offline Package Mode is the preferred and most complete mode. Always declare the mode at the top of the report.

If mode cannot be determined from the input, ask the user one clarifying question before proceeding.

Step 1.5 — Review Scope Selection

Human confirmation required before proceeding.

Ask the user:

"I'll be reviewing Transport Request {TR_ID}.

Which review scope do you need?

(A) Code Quality Review — Covers: code quality, performance, security, authorization, transaction consistency, integration impact, transport completeness, release readiness, and evidence gaps. Assesses whether the code is well-written and safe to release. Does not evaluate whether the implementation matches business requirements.

(B) Functional + Code Quality Review — All of the above, plus Functional Alignment (Dimension 8): verifies that the code correctly implements the stated business requirements. Requires a functional specification or requirements document.

Which scope? (A or B)"

If user selects (A) — Code Quality Review:

• Exclude Dimension 8 (Functional Alignment) from the review. Mark it as N/A — excluded by user choice.
• Proceed to Step 2.

If user selects (B) — Functional + Code Quality Review:

• Check whether a functional specification or requirements document is present in the provided materials.
• Spec is present → proceed to Step 2 with all 10 dimensions active.

• Spec is absent → do not start the review. Prompt:

  "Functional + Code Quality Review requires a functional specification. Please provide one of:

  • A functional spec document (Markdown, Word, PDF, or plain text)
  • A requirements ticket, Jira issue, or user story
  • A change request or design document

  Once provided, I will include Dimension 8 (Functional Alignment) in the review."

  If the user confirms no spec exists but still wants a Functional + Code Quality review:

  • Proceed with all 10 dimensions.
  • Set Dimension 8 outcome to Inferred / Limited — no spec provided per the Hard Constraint.
  • Record an EVIDENCE_GAP finding with severity HIGH for the missing functional specification.
  • This gap will restrict Evidence Level and the final decision.

Step 2 — Evidence Intake and Completeness Check

Inventory all materials provided by the user. Required evidence varies by mode — see references/review-modes.md §2 for full checklists.

Quick reference — evidence categories:

For each category, mark: Present / Partial / Missing.

Missing evidence does not stop the review — it restricts what can be concluded. Every missing item must be flagged as an EVIDENCE_GAP finding.

Step 3 — Evidence Level

Determine Evidence Level before beginning dimensional review. Full rules in references/decision-policy.md §1.

Decision gates by Evidence Level:

• UNKNOWN → immediately output NEED_MORE_EVIDENCE; do not proceed with dimensional review
• LOW → proceed with dimensional review, but the final decision must be NEED_MORE_EVIDENCE or NO_GO; GO and CONDITIONAL_GO are forbidden

Step 4 — Multi-Dimension Review

Complete all 10 dimensions below. Never skip a dimension — if nothing was found, state "No issues found."

Full detail for each dimension in references/review-dimensions.md.

For Functional Alignment: skip if no functional spec is provided and label as Inferred / Limited — no spec provided. Do not infer requirements independently.

For Evidence Gap: always produce at least one finding per missing evidence category.

Step 5 — Findings

Each finding must include all fields. Full schema in references/decision-policy.md §2.

Required fields per finding:

• id — unique identifier within this review (e.g., F-001)
• type — one of: CODE_QUALITY, PERFORMANCE, SECURITY, AUTHORIZATION, TRANSACTION_CONSISTENCY, INTEGRATION_IMPACT, TRANSPORT_COMPLETENESS, FUNCTIONAL_ALIGNMENT, RELEASE_READINESS, EVIDENCE_GAP
• severity — INFO / LOW / MEDIUM / HIGH / CRITICAL
• confidence — HIGH (direct evidence) / MEDIUM (indirect evidence) / LOW (inferred)
• object — affected object name
• location — file, line, or section reference
• evidence — real code snippet or material excerpt (max 15 lines); never fabricated
• reasoning — why this is a risk
• impact — what can go wrong if unaddressed
• recommendation — specific, actionable fix
• requires_human_confirmation — true / false

Severity calibration (abbreviated; full rules in references/decision-policy.md §2.2):

• CRITICAL: severe data loss, security breach, production outage, unrecoverable release risk
• HIGH: significant function failure, major performance degradation, missing critical dependency, release blocker
• MEDIUM: clear risk, mitigable by fix or human confirmation
• LOW: code quality or maintainability, does not directly block release
• INFO: advisory, informational

When severity is uncertain, choose the higher level.

Step 6 — Release Decision

Derive a single decision from Evidence Level + Findings. Full policy in references/decision-policy.md §3.

Decision priority (highest wins):

NO_GO               ← CRITICAL risk or severe unmitigated HIGH risk
NEED_MORE_EVIDENCE  ← Evidence too thin for reliable judgment
CONDITIONAL_GO      ← Risk exists but mitigable before release
GO                  ← Sufficient evidence, no blocking risk

Non-negotiable rules:

1. Evidence Level LOW → GO and CONDITIONAL_GO are forbidden
2. Evidence Level UNKNOWN → always NEED_MORE_EVIDENCE
3. Any CRITICAL SECURITY / AUTHORIZATION / TRANSACTION_CONSISTENCY finding → NO_GO
4. If CRITICAL risk and evidence gap coexist → NO_GO; list evidence gap as additional risk

Step 7 — Generate Reports

Generate both outputs. Templates in references/report-format.md.

Markdown Report (primary)

Structure:

1. Executive Decision (Decision, Evidence Level, Overall Risk, Target Stage, TR ID, Review Mode, Rule Pack)
2. Scope Reviewed (what was reviewed, what was not)
3. Evidence Summary (present / missing / restricted)
4. Key Findings (by severity)
5. Review by Dimension (all active dimensions; Dimension 8 marked N/A if user selected Code Quality Review)
6. Required Actions Before Release
7. Human Confirmation Checklist
8. Decision Rationale
9. Appendix:
   • §9.1 Object List Summary (mandatory) — every TR object listed by type, name, and whether its source was reviewed
   • §9.2 Evidence References
   • §9.3 Assumptions
   • §9.4 Limitations and Unreviewed Scope
   • §9.5 Sign-off Table

Report rules:

• Every high-risk finding must have a recommendation
• Every evidence gap must explain its impact on the decision
• All inferred conclusions must be labeled [Inferred] or [Needs confirmation]
• Never write "looks fine" or "seems OK" without citing evidence
• Report language: English

File naming: TR_REVIEW_{TR_ID}_{YYYYMMDD}.md
When NO_GO: prefix NOGO_TR_REVIEW_{TR_ID}_{YYYYMMDD}.md
When NEED_MORE_EVIDENCE: prefix NME_TR_REVIEW_{TR_ID}_{YYYYMMDD}.md
Full naming table in references/report-format.md §3.

Save location — always use a TR-specific subdirectory:

Always save reports to reports/{TR_ID}_package/ regardless of review mode. Never save directly to reports/.

Create the target directory automatically. Never ask the user to create it manually.

JSON Summary (secondary)

For CI pipelines, dashboards, and audit archives. Schema in references/report-format.md §2.

References Index