arc-mcp/arc-1

sap-transport-overview

System-wide inventory of open transport requests — every visible modifiable request, who owns it, how big it is, and supported risk signals such as empty/local requests, explicit locks, and confirmed manifest overlaps.

Voir la source

Mode d’emploi

  1. Copiez la commande et examinez le paquet avant de l’installer dans votre environnement agent.
  2. Consultez le document original pour les outils, identifiants et environnements requis.
  3. Décrivez les entrées et le livrable souhaité ; comparez la sortie aux sources.
npx skills add https://github.com/arc-mcp/arc-1 --skill sap-transport-overview

Avant de commencer

  • L’installation n’inclut ni abonnement au modèle, ni quota API, ni accès aux fichiers.
  • Étoiles et installations reflètent l’activité, pas un test indépendant de qualité ou de sécurité.
Document Skill original

Rendu depuis le dépôt source en conservant titres, exemples, code, tableaux, liens et images.

SAP Transport Overview (system-wide)

A basis-/lead-oriented register of every open transport in the system: who owns what, how large each request is, and where the risks are — without ever pulling source or diffs. It's deliberately breadth-first and token-cheap, built on one call:

  • SAPTransport(action="list", summary=true, user="*", status="D") — every modifiable request, all

users, with objects[] omitted and an objectCount kept. (On a busy system the full object-laden list is ~25K tokens; summary cuts it to a few KB — see ARC-1 PR #448.)

This is the breadth companion to sap-transport-review (which is depth — diffs of one transport's objects). Overview answers "what's open and risky across the landscape"; review answers "what exactly changed in this one." Don't diff here.

Smart Defaults (apply silently, do NOT ask)

SettingDefaultRationale
Usersall (user="*")Basis cares about the whole system, not one developer
Statusmodifiable (status="D")Open/unreleased work; pass status="R" for released, "*" for both
Payloadsummary=trueInventory needs counts + headers, never source — keeps a 100-request list cheap
DiffsneverThat's sap-transport-review's job; this skill stays breadth-only
Groupingby ownerThe basis mental model: "whose requests, how many, how big"

Input

Optional narrowing — apply if given, else default to the whole system:

  • Owner / user — one developer's open requests.
  • Status — D (default), R (released), * (all).
  • Description / size / target filter — e.g. "matching 'migration'", "more than 20 entries", or

"without a target". The current transport payload has no age or object-package field, so do not offer age/package filtering without a separate authoritative data source.

Scope guard: the system-wide list can be hundreds of requests. Always start with summary=true. If it's still large, aggregate (counts per owner, top-N by objectCount) and offer to filter — never expand every request's object list unprompted.

Step 1: The register (cheap, always)

SAPTransport(action="list", summary=true, user="*", status="D")

Returns one row per request: id, description, owner, status, target/targetDesc, objectCount (+ per-task counts). That alone answers "what's open and how big" for the whole system.

Step 2: Expand only what matters (still no diffs)

For requests the user flags (or the suspicious ones from Step 3), pull the full object list:

SAPTransport(action="get", id="<id>")

This lists CTS entries (pgmid, type, name, wbtype, locked) — the contents, not source or package metadata. Only get the handful in focus; do not get the whole system.

Step 3: Risk / health flags (the basis value)

These are what an overview is for. Derive from the data already gathered:

  • Confirmed exact overlap — after explicitly expanding the in-scope requests, the same exact CTS

key (pgmid, type, name) occurs in two manifests. This can create import-order risk. Raw-key intersection is conservative: it can miss conceptual overlaps represented once as R3TR and once as LIMU/language subobjects, so label the result "exact CTS-key overlap", not exhaustive conflict detection.

  • Empty requests (objectCount 0) — cleanup candidates (delete or release).
  • Explicitly locked objects (locked: true from get) — may block other developers. On older

releases tm:lock_status can be absent, so locked: false does not prove that an entry is unlocked.

  • No target (target empty) — a local request that cannot be transported onward (often a mistake for work meant to ship).

SAPTransport(action="history", type=…, name=…) is current assignment status, despite the legacy action name: relatedTransports contains at most the current lock request, while candidateTransports are requests the object could be assigned to. Candidates do not contain the object and are not conflict/history evidence. Full historical membership requires E071/E070 access; the standard ADT endpoints used here do not provide it.

Do not infer $TMP from a transport manifest: CTS entries do not expose package, and local-package objects normally are not transport contents. Resolve package separately before making such a claim.

Step 4: Report

markdown
# Open transports — <SID>  (<N> requests, <M> objects, <K> owners)

## By owner
| Owner | Requests | Objects | Notable |
|---|---|---|---|
| MARIAN | 6 | 41 | 1 empty, 1 local request |
| ANNA   | 2 | 8  | |

## Register
| Request | Owner | Description | Objects | Target | Flags |
|---|---|---|---|---|---|
| A4HK900123 | MARIAN | Sales order RAP | 12 | LOCAL | ⚠ no target — won't ship |
| A4HK900200 | ANNA   | Pricing fix     | 3  | C11   | ⚠ ZCL_PRICE also in A4HK900123 |

## Needs attention
- ⚠ Exact CTS key R3TR/CLAS/ZCL_PRICE is in 2 expanded requests (A4HK900123, A4HK900200) → possible import-order conflict; sequence or consolidate.
- ⚠ A4HK900155 (MARIAN) is empty → delete or release.
- ⚠ A4HK900123 has no target → local request; confirm it is not intended for downstream import.

Write to disk only if asked; otherwise return inline.

Error Handling

ErrorCauseFix
list returns very many requestsBusy systemKeep summary=true; aggregate per owner + top-N by size; offer to filter
user="*" returns only my requestsBackend ignored the unfiltered query / scope limitsConfirm the SAP user may see others' requests (S_TRANSPRT); some systems restrict cross-user listing
get slow across many requestsExpanding too muchOnly expand the flagged/in-focus requests, never the whole system
history returns many candidatesCandidates are assignment choices, not containing requestsDo not use them as history/overlap evidence; compare explicitly expanded manifests
Need released requests tooDefault is D onlyRe-run list with status="R" or status="*"

When to use this skill

  • Basis / release manager: "what's open across the system, and what's risky to import?"
  • Team lead: "what is everyone working on right now?" / backlog and cleanup review.
  • Pre-import / pre-go-live: find object overlaps and local-only requests before a transport wave.

When NOT to use this skill

  • What exactly changed in a request (source diffs) → sap-transport-review.
  • One object's complete history ("which transports touched ZCL_X") → not available from the

standard ADT history action; use an authorized E071/E070 data workflow or an external CTS report.

  • One object's current lock/assignment status → SAPTransport(action="history", type=…, name=…).
  • Cross-system (is DEV ahead of QAS) → out of scope: ARC-1 binds one system per instance; run the CLI against each system and compare.

Follow-up Options

  • "Review the actual changes in one of these?" → sap-transport-review.
  • "Release the ready ones?" → SAPTransport(action="release") / release_recursive.
  • "Clean up the empty ones?" → SAPTransport(action="delete").

Tâches connexes

du même dépôt

Autres Skills

Tous les Skills
arc-mcp
Communauté

analyze-chat-session

Analyze the current conversation's tool calls, responses, errors, and approach to produce a structured feedback report for improving MCP tool usage with ARC-1. Use when the user asks to "analyze this session", "review my chat", "give feedback on tool usage", "how did I do", or wants a retrospective on a debugging session.

installations
1
GitHub Stars
201
Mis à jour
24 sept.
arc-mcp
Communauté

debug-slow-sql

Find the root cause of a slow ABAP SQL or Fiori-Elements OData request and propose the cheapest fix — GUI-free via ARC-1 (odataperf sap-statistics timing split, cdssql "Show SQL", SAPQuery execution metrics, ST05 SQL-trace control, ABAP profiler traces), escalating to SAP GUI / HANA only for trace records and execution plans. Use when a report, transaction, Fiori list, CDS view, or OData entity is slow, a query times out under load, or someone asks "why is this SQL/OData so slow" or "where is th

installations
1
GitHub Stars
201
Mis à jour
24 sept.
arc-mcp
Communauté

generate-analytics-star-schema

Generate a CDS analytical model (star schema — cube + dimension + text views) on top of a RAP business object or a DDIC table. Use when asked to "create a star schema", "generate an analytical cube and dimensions", "make a RAP BO analytical", "build a CDS cube from a table", or "create an analytical model".

installations
1
GitHub Stars
201
Mis à jour
24 sept.
arc-mcp
Communauté

generate-cds-analytical-query

Generate an analytical CDS query (transient projection view with PROVIDER CONTRACT ANALYTICALQUERY) on top of an existing analytical cube. Use when asked to "create an analytical query", "build a KPI query on a cube", "generate an ANALYTICALQUERY view", or "expose a cube for analytics/embedded analytics".

installations
1
GitHub Stars
201
Mis à jour
24 sept.