mcpField
S
sap-transport-review

sap-transport-review

github.com/arc-mcpテスト・品質239237 回インストール2 日前に更新
リポジトリ

sap-transport-review について

sap-transport-reviewは、SAPトランスポートや未アクティブの作業について、オブジェクトごとの差分レポートとリスク項目を作成します。開発者やレビュアー、リリース前の確認向けで、比較対象のバージョン範囲やソース差分に対応しないオブジェクトも明示します。

主な機能

  1. 01オブジェクトごとの統一差分を作成
  2. 02影響と品質のリスクを提示
  3. 03保留中のドラフトとリリース済み版を区別
  4. 04ソース差分に非対応のオブジェクトを識別
  5. 05大規模レビューの範囲を制限

活用シーン

  1. 01アクティベート前の変更を確認
  2. 02同僚のトランスポートリクエストをレビュー
  3. 03リリース引き継ぎや監査記録を作成
  4. 04前回リリース以降のコード変更を確認

MCP 対応

ARC-1のSAPTransportでトランスポート内容を取得し、SAPReadのdiff操作でソース差分を読み取ります。必要に応じてSAPContext、SAPDiagnose、SAPLintによる影響・品質確認も行えます。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/arc-mcp/arc-1 --skill sap-transport-review

インストール後、Claude Code で/sap-transport-reviewを入力して読み込まれたか確認します。

詳細

SAP トランスポート/変更レビュー

トランスポート、または現在作業中の(未有効化の)変更について、「実際に何が変わったのか」をレビュー可能なレポートとして回答します。オブジェクトごとの unified diff とリスクフラグを示し、ソース全体を延々と表示することはありません。

トークン消費の少ない ARC-1 のプリミティブを 2 つ活用するため、30 オブジェクトのトランスポートをレビューする場合も、ソース全体を 60 回読み込む代わりに、少量の diff をいくつか確認するだけで済みます。

  • SAPTransport(action="list", summary=true) — 多数の未クローズのトランスポートを低コストでスキャンします(オブジェクトは省略され、objectCount は保持されます)。その後、1 つを詳しく確認します。
  • SAPRead(action="diff", from=…, to=…) — オブジェクトごとの unified diff をサーバー側で生成します。応答には差分のハンクのみが含まれます。

explain-abap-code(単一オブジェクトの詳細な理解)および sap-object-documenter(パッケージの文書作成)を補完します。このスキルが扱うのは差分、つまり 2 つの時点の間で何が変わったかです。コードレビュー、引き継ぎ、リリース前のゲートに利用できます。

モードを選択する(誰からの依頼か)

あなたは…対象範囲スキルの動作
トランスポートをレビューしている(シニア開発者/承認者)1 つのトランスポート ID安全に解決できるすべてのソースオブジェクトを diff し、バージョンの網羅範囲を示します。影響/品質チェックは、依頼があった場合またはリスクが検出された場合にのみ追加します。Eclipse ADT 3.6 の「オブジェクトの変更」タブに相当する、チャット/トランスポート全体版です(ソース差分の網羅範囲は同じです)。
最近の自分の作業を確認している(開発者)自分が変更可能なトランスポート「最後のリリース以降、何を変更したか?」を確認します。各オブジェクトの最終リリース版 → 現在の版を diff します。軽量モードでは、依頼がない限り影響分析/ATC を省略します。

すべての未クローズのトランスポートをシステム全体で一覧表示する場合(基盤チーム向け:誰が何を未クローズにしているか、規模、競合など。diff はありません)は、別の作業になります → sap-transport-overview。

スマートデフォルト(暗黙に適用し、質問しない)

設定デフォルト理由
トランスポートの対象範囲現在のユーザー、変更可能(status="D")作業中の内容を対象とし、リリース済みの履歴は対象外にします
先に概要を表示一覧表示時に summary=trueオブジェクト一覧をすべて取得する前に、低コストでスキャンします
diff の方向(作業中)from="active"、to="inactive"未処理の未有効化ソースのみを正確に比較します。オープンリクエスト内ですでに有効化された変更は再構成しません
diff 対応タイプPROG、CLAS、INTF、FUNC、FUGR、INCL、DDLS、DCLS、BDEF、SRVD、DDLX、TABLaction="diff" が対応するプレーンテキストのソースタイプです
オブジェクト diff の上限約 40それを超える場合は件数を要約し、どのオブジェクトを展開するか尋ねます
影響分析リスク重視のレビューで、変更された CDS/RAP オブジェクトに対して有効化。それ以外はオプトイン依存関係のリスクがある箇所に追加の読み取りを絞ります
ATCオプトイン(+atc)または明確なリスクがある場合に実行。変更オブジェクトに限定ATC は負荷が発生するため、大規模なリクエスト全体に暗黙のうちに展開してはなりません

入力

ユーザーは次のいずれかを指定します。

  • トランスポート ID(例:A4HK900123)— そのリクエスト内のすべてをレビューします。
  • 「自分の保留中の変更」/「有効化する前に」 — 未有効化のドラフトをレビューします(active → inactive)。
  • オブジェクト一覧またはパッケージ — それらのオブジェクトの保留中の変更をレビューします。
  • 具体的な指定なし(「何が変わった?」)— ユーザーの変更可能なトランスポートを概要表示し、どれを対象にするか尋ねます。あるいは保留中のドラフトをデフォルトで対象にします。

任意指定:+impact(変更された CDS/RAP を利用する対象)、+atc(新しい品質指摘)、Markdown ファイルの出力先パス。

対象範囲のガード: 選択された diff 対応オブジェクトが約 40 を超える場合は、+/- 件数のみを含むオブジェクト表を表示し、完全な diff に展開するオブジェクト(またはタスク)を尋ねます。誰にも読まれないレビューは、レビューしないよりも悪い結果を招きます。

ステップ 1:対象範囲を特定する

  • トランスポート ID が指定されている場合 → SAPTransport(action="get", id="<id>") → tasks[].objects[] リスト。
  • 「何が変更されたか」/トランスポートを選ぶ場合 → SAPTransport(action="list", summary=true) → 簡潔なテーブル (id、description、owner、status、objectCount)。表示してユーザーに選んでもらい、そのトランスポートに対して get を実行します。
  • 保留中の変更/パッケージの場合 → ユーザーが変更したオブジェクトを列挙します(トランスポートのオブジェクト一覧、または指定されたパッケージ内のオブジェクト)。差分の取得自体にトランスポート ID は不要です。

ステップ 2:CTS エントリーを正規化してから分類する

SAPTransport get が返すのは CTS ID であり、必ずしも SAPRead の入力として使えるとは限りません。各エントリーには pgmid、CTS の type、name、wbtype が含まれます。実際のトランスポートには、LIMU/METH、LIMU/REPS、言語エントリー、パッケージ/メタデータエントリーなどのサブオブジェクトも含まれることがあります。

差分を取得する前に:

  1. tasks[].objects[] をフラット化しますが、レポート用にタスク ID と元の CTS キーは保持します。
  2. サポート対象の R3TR エントリー(R3TR/CLAS、R3TR/DDLS、…)は、リポジトリーオブジェクトとして直接扱い、完全に重複するエントリーは除外します。
  3. pgmid(LIMU、LANG)、CTS サブタイプ(METH、REPS)、または wbtype(CLAS/OM、PROG/I、…)を SAPRead(type=…) に渡さないでください。
  4. サブオブジェクトを直接の親エントリーにまとめるのは、親が一意に特定できる場合に限ります。応答にサブオブジェクトしか示されていない場合は、クラス名やインクルード名を推測せず、parent resolution unavailable と報告します。これは網羅性の制限であり、変更が何もないことを示すものではありません。
  5. 生の CTS エントリー数と、解決された一意のリポジトリーオブジェクト数の両方を数えます。エントリー数を一意なオブジェクト数として提示しないでください。

次に、解決されたリポジトリーオブジェクトを次のように分類します。

  • 差分取得可能(上記のソースタイプ)→ ステップ 3 で実際の差分を取得します。
  • メタデータのみ(SRVB、G4BA、SUSH、DOMA、DTEL、MSAG、VIEW、ENHO、AUTH、DEVC、サーバー側で制御されるもの、…)→ action="diff" は「not supported」を返します(これらの読み取り結果はプレーンテキストのソースではなく、解析済みメタデータ/XML です)。 これは SAP 独自の Eclipse ADT 3.6「Object Changes」とまったく同じ適用範囲の境界です — これらと同じタイプ(例:SRVB)に対して、"Feature not supported for object …" と表示されます。差分を取得しようとしないでください。 詳細にレビューする場合は、オブジェクトのメタデータも読み込みます(例:SAPRead(type="SRVB", name=…))。そうすれば、ソース差分なしでも、レポートにオブジェクトの種類と変更セットに含まれていることを記載できます。

ステップ 3:各オブジェクトの差分を確認する — 意図に応じて from/to を選択する

これらを並列で実行します(それぞれ差分のハンクのみを返します)。

SAPRead(type="<type>", name="<name>", action="diff", from="<from>", to="<to>")

ユーザーが何を確認しているかに応じて、比較元と比較先を選択します。

意図from → to備考
保留中のドラフト(「これから有効化するもの」)active → inactive保留中のソースを正確に比較します。ドラフトがない場合は「保留中のソースなし」であり、「開いているトランスポートでは変更なし」ではありません。
最新リリース済みスナップショット以降<latest released revision id> → active(ドラフトのままなら inactive)そのリリース以降のすべての変更を取得します。複数のオープンリクエストが含まれる場合があるため、そのように明記する必要があります。フィードの順序を鵜呑みにせず、リビジョンの順序/タイムスタンプを確認してください。
リリース済みトランスポート(「この TR で何が変わったか」)<revision immediately before TR> → <revision tagged with TR>今日の active ソースではなく、そのトランスポート自体のリリース済みスナップショットを比較します。該当するスナップショットやその直前のリビジョンが不明確、または存在しない場合は、ベースラインの欠落を報告してください。
特定のリビジョン<id|uri> → <id|uri|active>VERSIONS レスポンスから選択します。

スナップショットが疎であるという現実(重要): ABAP では、トランスポートが リリースされたときにのみバージョンスナップショットが作成されます。そのため、オープン/未リリースのトランスポートでは、オブジェクトに存在するのは通常、active バージョン(および場合によっては inactive のドラフト)のみであり、差分を取るための「変更前」のリビジョンはありません。正直に対処してください。

  1. 解決されたオブジェクトごとに、対応している場合は SAPRead(type="VERSIONS", name=…, objectType=…) を照会します。
  2. リリース済みリクエストの場合は、そのリクエストがタグ付けされたリビジョンと、その直前のリビジョンを特定します。 どちらかを確定できない場合、古いトランスポートの代わりに現在の active ソースを使用しないでください。
  3. オープンリクエストの場合、保留中の部分には active → inactive のみを使用します。以前のリリース済みリビジョン → active の比較も有用ですが、「リリース済みスナップショット以降」と明記してください。ほかのオープンリクエストの変更が含まれる可能性があります。
  4. inactive の差分がなく、信頼できるスナップショットの組み合わせもない場合は、baseline unavailable と報告します。独立したオブジェクトメタデータによって、このリクエストでの作成が証明されない限り、追加と呼ばないでください。

レポートには、対象範囲として pending draft、released snapshot、since released snapshot (may span requests)、または baseline unavailable のいずれかを明記してください。

ステップ 4(任意):影響分析と品質チェック — 要求された場合、または変更にリスクがある場合のみ

  • 影響分析(変更された DDLS/BDEF/SRVD は利用側に影響する可能性があります):SAPContext(action="impact", type="DDLS", name="<view>") → プロジェクションビュー、BDEF、サービス定義/バインディング、および依存する ABAP 利用側。
  • 品質チェック:ユーザーが +atc を要求した場合、またはリスクに応じて、範囲を限定した変更対象のみを対象に SAPDiagnose(action="atc", ...) を実行します。より低コストなローカルチェックには SAPLint(action="lint", name=…) を使用します。
  • リリース前の妥当性確認:未有効化の作業には、読み取り専用の SAPDiagnose action="syntax" チェックを使用します。 SAPActivate はシステム状態を変更します。ユーザーが有効化を明示的に求めた場合のみ実行してください。

ステップ 5:レポートを作成する

# Change review — <transport id or "pending drafts"> on <SID>

_<owner> · <status> · <description>_

_Coverage: <pending draft | released snapshot | since released snapshot | baseline unavailable>_

## Summary

| Object | Type | Change | +/− | Flags |
|---|---|---|---|---|
| ZCL_ORDER | CLAS | changed | +12 −3 | |
| ZI_ORDER  | DDLS | changed | +4 −0  | impacts 3 consumers |
| ZNEW_REPORT | PROG | unknown | —     | baseline unavailable |
| ZSTATUS   | DOMA | changed | —      | metadata — no source diff |
| <CTS subobject> | LIMU/METH | unresolved | — | parent resolution unavailable |

## Diffs

### ZCL_ORDER (CLAS)  active → inactive  (+12 −3)
```diff
<the unified-diff hunks from SAPRead action="diff">

…差分を取得できるオブジェクトごとに 1 ブロック…

リスクの警告

  • ⚠ ZI_ORDER(DDLS)には下流の利用側が 3 つあります — 有効化の順序が重要です(影響分析を参照)。
  • ⚠ ZCL_BP は、明示的に展開された 2 つのリクエストマニフェストに登場しています。現在のロック保持者は A4HK900123 です。
  • ⚠ A4HK900123 には移送先がありません — これはローカルリクエストであり、さらに先へインポートできません。

結論

<2~3 行:この変更セットの内容、最初に確認すべき点、リスクがあるもの/まだ有効化されていないもの。>


Write to disk (default `docs/reviews/transport-<id>-<date>.md`) only if asked; otherwise return inline.

## Error Handling

| Error | Cause | Fix |
|---|---|---|
| `action="diff"` → "not supported for type X" | Metadata type (DOMA/DTEL/MSAG/SRVB/VIEW/…) | Expected — list it as "metadata — no source diff", don't diff |
| "No differences between active and inactive" | No unactivated draft for that object | Report "no pending source"; do not infer that the open request made no activated changes |
| "Revision-id diff is not available for type X" | FUGR/DDLX have no revisions feed | Use `active`/`inactive` or a full `/sap/bc/adt/` URI instead of a bare id |
| VERSIONS returns 1 revision | Snapshot only cut on release (sparsity) | Use active→inactive only for a real pending draft; otherwise report `baseline unavailable` |
| Transport entry is `LIMU/*`, `LANG/*`, or only has a slash `wbtype` | CTS identity is not a `SAPRead` type | Fold into an unambiguous parent entry or report `parent resolution unavailable`; never guess |
| Transport `get` 404 | Wrong id / already deleted | Re-list with `summary=true` and confirm the id |
| >40 objects in scope | Review too large to read | Show the `+/-` table, ask which task/objects to expand |

## When to use this skill

- Pre-release / pre-activation gate — "show me everything I'm about to ship."
- Code review of a colleague's transport without leaving the chat — the headless / pasteable / whole-transport-at-once counterpart to Eclipse ADT 3.6's "Object Changes" tab (same per-object diffs, same coverage boundary).
- Hand-off / audit — a written delta of a change set.
- "What changed after my last request / since my last release?" (since-last-release mode).
- "I've been editing for an hour — what have I actually changed?" (pending-drafts mode).

## When NOT to use this skill

- **System-wide inventory of every open transport** (basis: who has what open, sizes, conflicts — no diffs) → [sap-transport-overview](../sap-transport-overview/SKILL.md). This skill is depth-on-one-transport; that one is breadth-across-the-system.
- **Understanding one object deeply** → [explain-abap-code](../explain-abap-code/SKILL.md).
- **Documenting a whole package** (not a delta) → [sap-object-documenter](../sap-object-documenter/SKILL.md).
- **Across multiple systems** (DEV vs QAS source compare) → out of scope here: ARC-1 binds to one system
  per instance. Do a cross-system review by running the ARC-1 CLI against each system (`arc1-cli call
  SAPRead … --url <sys>`) and diffing the two outputs — a separate orchestration, not this skill.

## Follow-up Options

- "Activate / release this once it looks right?" → `SAPActivate`, then `SAPTransport(action="release")`.
- "Who breaks if I change this CDS?" → `SAPContext(action="impact")` (or re-run with `+impact`).
- "Document these objects properly?" → [sap-object-documenter](../sap-object-documenter/SKILL.md).
- "Clean-core readiness of the changed objects?" → [sap-clean-core-atc](../sap-clean-core-atc/SKILL.md).

コメント