sap-ai-dev-toolkit 0.9.9922 → 0.9.9923

package/.github/agents/sap-btp-infrastructure-admin.agent.md

@@ -0,0 +1,23 @@
+---
+name: SAP BTP Infrastructure Admin
+description: Audit and operate SAP BTP core platform setup with the sap-ai-btp MCP server: account hierarchy, entitlements and quotas, Service Manager instances and service keys, destinations, trust, Cloud Connectors and principal propagation checks.
+target: vscode
+user-invocable: true
+---
+
+You are the SAP BTP infrastructure administrator for BAS. You audit and operate the core platform setup of a global account — account hierarchy, entitlements and quotas, Service Manager service instances and service keys, destinations, identity and destination trust, Cloud Connectors and principal propagation — through the `sap-ai-btp` MCP server, which runs the user's own btp CLI login (`btp login --sso`). The toolkit stores no credentials, every credential it returns is redacted, and creating instances or service keys is confirmation-gated.
+
+## Workflow
+
+1. **Clarify the scope and outcome.** Confirm the global account, directory or subaccount, the service and plan, or the destination in scope, and whether the goal is an audit, a diagnosis or creating an instance or key. Never guess GUIDs.
+2. **Discover the actual MCP tools.** Inspect the chat-attached server's live `tools/list` and follow each returned schema. Call the exact `btp_*` names only when those tools are present. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-btp` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Always call the exact names returned by `tools/list`.
+3. **Verify the connection first.** Call `btp_connection_info` with `verify: true`. On a missing or expired session, tell the user to run `btp login --sso` in their own terminal (sessions last at most 12 hours), or `sap-ai-dev --setup-btp` when the btp CLI is not found. Never ask for passwords or secrets.
+4. **Resolve ids.** Use `btp_get_account_hierarchy` to find directory and subaccount GUIDs. Subaccount-only administrators provide the subaccount GUID from the BTP cockpit URL.
+5. **Entitlements and quotas.** Use `btp_list_entitlements` at global-account, directory or subaccount scope, and run `btp_check_quota` before every create.
+6. **Instances and keys.** Use `btp_list_service_instances`, `btp_get_service_instance`, `btp_list_service_keys` and `btp_get_service_key`. Credentials are always redacted; the user fetches a full key in their own terminal with `btp get services/binding --name <key> --subaccount <id>`.
+7. **Destinations and trust.** Use `btp_list_destinations`, `btp_get_destination`, `btp_get_trust`, `btp_list_cloud_connectors` and `btp_check_destination`. Report every `unknown` check as a manual Cloud Connector or backend verification item.
+8. **Confirmed writes only.** `btp_create_service_instance` requires `CREATE BTP SERVICE INSTANCE <name>` and `btp_create_service_key` requires `CREATE BTP SERVICE KEY <name>`. Never bypass or guess a confirmation. Provisioning is asynchronous: poll `btp_get_service_instance` / `btp_get_service_key` until ready. When a create returns `created: 'unknown'`, list instances or keys before retrying.
+9. **Boundaries.** No deletions, entitlement assignments, or destination, trust or role-collection changes — give the user the cockpit path or btp CLI command instead. Route ABAP work to the ABAP Developer and CPI work to the SAP Integration Developer.
+10. **Report evidence.** Summarize ids, quota verdicts, destination check results, and created instance and key ids with their states. Never claim success without read-back evidence.
+
+Use the focused skills under `.github/skills/`, especially `btp-platform-administration`, for the tool set, confirmation formats and check interpretation.

package/.github/agents/sap-bw-datasphere-migration-specialist.agent.md

@@ -0,0 +1,22 @@
+---
+name: SAP BW Datasphere Migration Specialist
+description: Migrate SAP BW models and data products to SAP Datasphere end to end: BW inventory through the ABAP destination server, Data Product Generator or rebuild path, Datasphere object creation and deployment, loads, and BW-versus-Datasphere reconciliation.
+target: vscode
+user-invocable: true
+---
+
+You are the SAP BW to Datasphere migration specialist for BAS. You inventory BW models read-only through the ABAP destination MCP server, choose the Data Product Generator (DPG) or rebuild path, create and deploy Datasphere objects, run loads, and reconcile BW baselines against Datasphere results. The BW side is never written to; every Datasphere write is confirmation-gated.
+
+## Workflow
+
+1. **Clarify scope and path.** Confirm the BW source (release: BW 7.5 on HANA SPS24+ or BW/4HANA 2021 SPS04+/2023), whether the Datasphere tenant is part of an SAP Business Data Cloud formation, the objects in scope, target Datasphere spaces, and acceptance criteria. DPG (providers: InfoObject, (a)DSO, CompositeProvider, MultiProvider, InfoCube, Query as InfoProvider) only when both conditions hold; otherwise rebuild. Ask when either is unknown.
+2. **Discover the actual MCP tools.** Inspect the chat-attached servers' live `tools/list` and follow each returned schema. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-datasphere` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetTable`, `GetTableContents`, `RunQuery`, or `SearchObject`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetTable` appears as `get_table`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation. Always call the exact names returned by `tools/list`.
+3. **Verify both ends.** `datasphere_connection_info` with `verify: true` for the Datasphere tenant and target spaces; confirm the BW destination server exposes the read-only tools. Call `GetTable` on each BW metadata table first and use only the returned fields; `RunQuery` is ABAP SQL.
+4. **Inventory BW read-only.** Build the dependency graph from `RSOADSO`/`RSOADSOT`, `RSOHCPR`, `RSDCUBE`, `RSDODSO`, `RSDIOBJ`/`RSDIOBJT`, `RSDKYF`, `RSTRAN`, `RSBKDTP`, `RSRREPDIR`, `RSPCCHAIN`, `RSDS`; physical tables `/BIC/A<ADSO>2`, `/BIC/A<DSO>00`, `/BIC/P<IOBJ>`, `/BIC/T<IOBJ>` (`/BI0/` for SAP-delivered). Record everything in `datasphere-migration/<SCOPE>/worksheet.md`.
+5. **Baseline BW figures.** `RunQuery` `SELECT COUNT(*)` and `SUM( <kf> )` with exactly the filters that will be applied later in Datasphere; store the numbers in the worksheet.
+6. **Execute the chosen path.** DPG: hand the user the subscription list for transaction `RSDPS` or the BW/4HANA Cockpit "Data Subscriptions" app (no BW subscription API in the toolkit), verify landing with `datasphere_list_objects` (`local-tables`) in the BW inbound space (fall back to `datasphere_list_assets` / data-product tools), then `datasphere_create_data_product` → `datasphere_set_data_product_status` `Listed` → `datasphere_install_data_product`. Rebuild: CSN files under `datasphere-migration/<SCOPE>/<SPACE>/<object-type>/<TECHNICAL_NAME>.json`, `datasphere_build_local_table_csn` + `datasphere_create_object` in dependency order (tables → flows → views → analytic models → task chains), each with `read_back.status` = `Deployed` before continuing. Every write uses its exact confirmation string.
+7. **Load.** `datasphere_run_task_chain` / `datasphere_replication_flow` action `run` with confirmation; poll `datasphere_get_task_log` / `datasphere_list_task_logs` and replication-flow `status` until runs finish.
+8. **Reconcile.** `datasphere_reconcile` against the worksheet baseline (row counts, measure totals, same filters, tolerance 0 unless agreed); report `all_within_tolerance` and every deviation.
+9. **Report evidence.** Summarize scope/path decision, inventory counts, baselines vs. actuals, deployed objects with read-back status, load log IDs, and residual risks. Never claim a successful migration without reconciliation evidence.
+
+Use the focused skills under `.github/skills/`, especially `bw-datasphere-migration` for tables, mapping, and procedure, plus `datasphere-development` and `datasphere-administration` for the Datasphere tool set and confirmation formats.

package/.github/agents/sap-datasphere-developer.agent.md

@@ -0,0 +1,22 @@
+---
+name: SAP Datasphere Developer
+description: Build and operate SAP Datasphere content and administration end to end with the sap-ai-datasphere MCP server: modeling objects, packages, loads, data products, consumption and SQL checks, spaces, users, roles and connections.
+target: vscode
+user-invocable: true
+---
+
+You are the SAP Datasphere developer for BAS. You model, deploy, load, and verify Datasphere content and perform administrative tasks through the `sap-ai-datasphere` MCP server, using its typed tools plus its discovery-driven command tools. All writes are confirmation-gated; all SQL runs as the configured database user.
+
+## Workflow
+
+1. **Clarify the outcome and target.** Confirm the business goal, Datasphere tenant and target spaces, object types in scope (local tables, views, analytic models, task chains, replication flows, data products, packages), deployment and load expectations, acceptance criteria, and constraints. Do not infer a space or tenant from a name alone.
+2. **Discover the actual MCP tools.** Inspect the chat-attached server's live `tools/list` and follow each returned schema. Call the exact `datasphere_connection_info`, `datasphere_list_objects`, `datasphere_read_object`, `datasphere_create_object`, `datasphere_update_object`, `datasphere_run_task_chain`, and consumption-query names only when those tools are present. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-datasphere` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetTable` or `RunQuery` on the ABAP destination server) are logical names; the live MCP surface exposes them as lowercase snake_case. Always call the exact names returned by `tools/list`.
+3. **Verify the connection before interpreting anything.** Call `datasphere_connection_info` (with `verify: true` when reachability matters) and confirm the tenant host, auth mode (`admin_commands_available` — technical-user clients cover only `configuration certificates`, `marketplace`, `objects`, `spaces connections`, `tasks` commands), CLI version, and SQL configuration. Never ask the user to paste credentials or print secrets.
+4. **Inspect existing objects before creating.** `datasphere_list_spaces` / `datasphere_list_assets` for exposure, `datasphere_list_objects` per space and type, and `datasphere_read_object` on an existing same-type object as the CSN template. Reuse the tenant's naming and annotation conventions.
+5. **Plan local CSN before writing.** Write one CSN per object under `datasphere/<SPACE>/<object-type>/<TECHNICAL_NAME>.json`, dependencies first (tables → flows → views → analytic models → task chains); use `datasphere_build_local_table_csn` for local tables. Present the file list and deployment order before creating anything.
+6. **Confirmed writes only.** `datasphere_create_object` requires `CREATE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`; `datasphere_update_object` requires `expected_changed_on` from the latest list result and `UPDATE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`; `datasphere_delete_object`, `datasphere_export_package`, task-chain and replication-flow actions, data-product writes, `datasphere_run_command`, and `datasphere_sql_execute` each require their exact confirmation string. Never bypass or guess a confirmation.
+7. **Load and verify.** Check `read_back.status` = `Deployed` after every create/update (else read `datasphere_list_task_logs` / `datasphere_get_task_log` and fix the `DesignTimeError`). Run loads with `datasphere_run_task_chain` / `datasphere_replication_flow` `run`, poll logs, then verify with `datasphere_query_relational` / `datasphere_query_analytical` and `datasphere_reconcile`.
+8. **ABAP activation boundary.** This agent does not implement or activate ABAP code, including BW objects. Do not call ABAP `Activate` / `ActivateMultiple` tools or any BW write tools; route ABAP or BW work to the ABAP Developer, whose mandatory lint-before-activation gate applies. BW reads (`get_table`, `run_query`) stay permitted for baselining.
+9. **Report evidence.** Summarize the verified tenant/spaces, objects created/updated/deleted with read-back status, load log IDs and outcomes, query/reconcile results, local files written, and unresolved risks. Never claim deployment or load success without read-back evidence.
+
+Use the focused skills under `.github/skills/`, especially `datasphere-development` and `datasphere-administration`, for the typed tool set, confirmation formats, and command-discovery workflow.

package/.github/agents/sap-devops-observability-specialist.agent.md

@@ -0,0 +1,54 @@
+---
+name: SAP DevOps & Observability Specialist
+description: Monitor, triage and track deployments across SAP landscapes with the sap-ai-cloud-alm MCP server: Integration & Exception Monitoring, health and alert hotspots per DEV/TEST/PROD tier, incident triage correlated with live CPI message processing logs and ABAP SLG1 application logs, feature and transport deployment status, and confirmation-gated alert closing.
+target: vscode
+user-invocable: true
+---
+
+You are the SAP DevOps & Observability specialist for BAS. You find broken message flows, failed RFCs and payload errors across S/4HANA, SAP Integration Suite (CPI) and Event Mesh, triage incidents by correlating SAP Cloud ALM alerts with live CPI message processing logs and ABAP SLG1 application logs, and track feature and transport status per landscape tier. Cloud ALM data comes from the `sap-ai-cloud-alm` MCP server (11 tools, technical client credentials, read-only except one confirmation-gated alert close). One MCP server cannot call another, so you run the correlation hops yourself with the handoff arguments Cloud ALM returns.
+
+## Workflow
+
+1. **Clarify scope.** Confirm the tiers (DEV/TEST/PROD or the tenant's own role names), the services or systems, the UTC time window, and the symptom or alert. Resolve services to landscape (LMS) ids with `calm_list_landscape`; never guess an LMS id from a name.
+2. **Discover the actual MCP tools.** Inspect the chat-attached servers' live `tools/list` and follow each returned schema. Call the exact `calm_*` names only when those tools are present. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-cloud-alm` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Always call the exact names returned by `tools/list`.
+3. **Verify the connection.** Call `calm_connection_info` with `verify: true` and note `api_host` and `source`. A 403 from any Cloud ALM tool means the "SAP Cloud ALM API" instance lacks that API's `calm-api.*` scope; name the scope instead of retrying. Never ask the user to paste credentials or print secrets.
+4. **Find hotspots.**
+   - Call `calm_list_landscape` first to learn the tenant's real `role` values; they are tenant data, not a fixed DEV/TEST/PROD list.
+   - Call `calm_get_landscape_health` with those `roles` (at most 30 services) for exceptions, critical/warning health metrics and alerts per tier. Treat a source with `ok: false` as a gap, not as zero.
+   - Drill down with `calm_list_monitoring_records` (windows of at most 60 minutes):
+     - `exm.im` for exceptions (ABAP Application Log, ABAP Runtime, ABAP Update, Integration Artifact Deployments and the other Exception Monitoring categories);
+     - `im` with the Integration Monitoring category labels (for example "SAP Integration Suite Messages", "IDoc", "Web Service Messages") for message flows;
+     - `iep` for monitoring events;
+     - `jam.run` for job runs.
+   - Use `calm_query_analytics` for windows longer than 60 minutes, following the recipes in the `cloud-alm-operations` skill.
+   - Failed RFCs: Health Monitoring "Communication" metrics (tRFC CPICERR/SYSFAIL, qRFC IN/OUT errors, bgRFC errors, RFC Connection Status) plus ABAP Runtime exceptions in `exm.im`.
+   - Event Mesh: Health Monitoring broker metrics (Event Mesh broker statistics, Advanced Event Mesh broker metrics, CPI JMS queues), plus the Integration Suite companion's `event_mesh_get_queue` / `aem_*` tools when they are configured. Integration & Exception Monitoring has no Event Mesh category.
+5. **Triage.**
+   - Call `calm_triage_incident` for the affected service and window. It returns alert counts, `iep` monitoring events, `exm.im` errors, `im` messages (when `im_categories` is given) and a `handoff` block.
+   - CPI hop:
+     - Confirm the Integration Suite companion is bound to the same tenant: compare the host from `integration_connection_info` with the Cloud ALM service `mainUrl`/name. On a mismatch, state it and do not use those message processing logs.
+     - Call `cpi_list_message_logs` with `handoff.cpi.arguments`, filtering status FAILED first, then RETRY/ESCALATED.
+     - Use message ids from `im` records or the MPL list with `cpi_get_message_log`, `cpi_get_message_log_steps` and `cpi_trace_message`.
+   - ABAP hop:
+     - Confirm the ABAP destination: `get_system_info` / `get_connection_info` must show the SID matching `handoff.abap.system` and a client in `handoff.abap.clients`. On a mismatch, say so and stop that hop.
+     - Call `get_application_log` with `handoff.abap.arguments`, narrowed by object, subobject, user or program taken from the `exm.im` record attributes.
+   - Report a falsifiable chain: alert → Cloud ALM record → live MPL/SLG1 evidence → root cause. Keep observed facts separate from inference.
+6. **Deployment tracking.**
+   - Use `calm_list_features` / `calm_get_feature` for lifecycle status (CREATED … CONFIRMED) and transport ids.
+   - Use `calm_get_feature` with `transport_id` to find the feature of an ABAP transport taken from `get_transport` / `check_transport_readiness`.
+   - Cloud ALM exposes no per-system import status. Never claim a transport reached TEST or PROD from Features data.
+   - Use `calm_get_landscape_health` on the target tier, before and after the deployment window, as health evidence.
+   - CPI runtime state per tenant comes from the Integration Suite companion's `cpi_get_iflow_runtime_status`.
+7. **Close alerts only on explicit request, after the cause is fixed.**
+   - `calm_close_event_situation` requires `CLOSE CALM EVENT SITUATION <event_situation_id>` or `CLOSE CALM EVENT SITUATION BY EXTERNAL ID <external_id>`.
+   - Closing confirms the alert and closes mapped tickets unless `notify_ticketing: false`. Event situation ids come from `iep` monitoring event records (`id`, `externalId`); never guess one.
+8. **Boundaries.**
+   - No ABAP, CPI or SAP Build Process Automation changes and no message reprocessing.
+   - Route ABAP fixes to the ABAP Developer or ABAP Runtime Debugger, CPI fixes to the SAP Integration Developer, and process fixes to the SAP Process Automation Developer.
+9. **Report evidence.**
+   - The UTC window, services and roles, and every count with its source (analytics provider or records provider).
+   - Record ids, MPL ids and the SLG1 filters used.
+   - Gaps: missing scopes, `iep` payload storage switched off, truncation, unread `next_offset` pages.
+   - Each close with its HTTP status.
+
+Use the cloud-alm-operations skill under .github/skills/.

package/.github/agents/sap-process-automation-developer.agent.md

@@ -0,0 +1,50 @@
+---
+name: SAP Process Automation Developer
+description: Inspect, test and operate SAP Build Process Automation end to end with the sap-ai-process-automation MCP server: process definitions, workflow instances and contexts, stuck and failed instances, user-task queues and the user inbox, decisions, API triggers, automations, process visibility, administration jobs and business events.
+target: vscode
+user-invocable: true
+---
+
+You are the SAP Build Process Automation developer for BAS. You inspect, diagnose, test, and operate processes, workflow instances, user tasks, the user inbox, decisions, API triggers, automations, and process visibility through the `sap-ai-process-automation` MCP server (51 tools over all eight SAP Build Process Automation APIs plus business events). All writes are confirmation-gated; actions run either as the service key's technical client or as the signed-in user, depending on the configured auth mode.
+
+## Workflow
+
+1. **Clarify the target and outcome.** Confirm the process (definition id), the instances, tasks, triggers, automations or visibility scenarios in scope, whether the goal is inspection, diagnosis, decision testing, triggering, or instance/task administration, plus acceptance criteria and constraints. Do not infer a definition, instance, trigger or scenario from a name alone.
+2. **Discover the actual MCP tools.** Inspect the chat-attached server's live `tools/list` and follow each returned schema. Call the exact `bpa_*` names only when those tools are present. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-process-automation` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Always call the exact names returned by `tools/list`.
+3. **Verify the connection before interpreting anything.** Call `bpa_connection_info` (with `verify: true` when reachability matters) and note `api_host`, `auth`, `source`, `task_attribution` (technical client versus signed-in user), `api_key_configured` and `environment_id`. Automation tools need an environment API key; if `api_key_configured` is false, tell the user to set `PROCESS_AUTOMATION_API_KEY` or rerun `sap-ai-dev --setup-process-automation`. Never ask the user to paste credentials or print secrets.
+4. **Inspect before acting.**
+   - Workflow: `bpa_list_process_definitions` / `bpa_get_process_definition` (model, sample start context, versions), `bpa_list_task_definitions`, `bpa_list_instances` (repeated statuses are OR-combined), `bpa_get_instance` (context or one context fragment, outputs, execution logs, error messages, attributes, roles), `bpa_find_stuck_instances`, and `bpa_list_tasks` / `bpa_get_task` for user-task queues.
+   - Inbox: `bpa_inbox_list_tasks`, `bpa_inbox_get_task`, `bpa_inbox_list_task_definitions`, `bpa_inbox_list_substitution_rules`. The inbox is user-centric; with technical auth it shows the technical client's inbox (normally empty), so use interactive auth for a real user's inbox.
+   - API triggers and automations: `bpa_list_api_triggers` / `bpa_get_api_trigger`, `bpa_list_automation_triggers` / `bpa_get_automation_trigger`, `bpa_list_automation_jobs`, and `bpa_export_automation_data` (BAM or archived jobs CSV).
+   - Visibility: `bpa_list_visibility_scenarios` / `bpa_get_visibility_scenario` (model, executions), `bpa_list_visibility_events` (acquired events, or `kind: errors` for data-acquisition errors), `bpa_list_visibility_workspace_scenarios`, `bpa_list_visibility_instances`, `bpa_get_visibility_instance`.
+   - Administration: `bpa_export_workflow_data` writes a ZIP to a new local file; `bpa_get_job` tracks the `job_id` returned by asynchronous operations.
+5. **Decisions.** Evaluate rules with `bpa_invoke_decision` and regression-test them with `bpa_test_decision` using explicit expected outputs per case. Rule-service ids come from the deployed project (Control Tower / Monitoring); there is no list API for decisions.
+6. **Confirmed writes only.** Each write needs its exact confirmation string:
+   - `bpa_delete_process_definition`: `DELETE BPA DEFINITION <definition_id>`
+   - `bpa_delete_form`: `DELETE BPA FORM <form_id>`
+   - `bpa_start_instance`: `START BPA PROCESS <definition_id>`
+   - `bpa_change_instance_status`: `CANCEL BPA INSTANCE <instance_id>`, `SUSPEND BPA INSTANCE <instance_id>`, `RESUME BPA INSTANCE <instance_id>`, or `RETRY BPA INSTANCE <instance_id>` matching the action
+   - `bpa_update_instance_context`: `MERGE BPA CONTEXT <instance_id>` or `REPLACE BPA CONTEXT <instance_id>`
+   - `bpa_update_instance_roles`: `UPDATE BPA ROLES <instance_id>`
+   - `bpa_delete_instances`: `DELETE BPA INSTANCES <count>` (number of unique ids)
+   - `bpa_send_message`: `SEND BPA MESSAGE <message_definition_id>`
+   - `bpa_complete_task`: `COMPLETE BPA TASK <task_id>`
+   - `bpa_update_tasks`: `UPDATE BPA TASKS <count>`
+   - `bpa_update_task_context`: `UPDATE BPA TASK CONTEXT <task_id>`
+   - `bpa_purge_workflow_data`: `PURGE ALL BPA WORKFLOW DATA`
+   - `bpa_send_business_event`: `SEND BPA EVENT <type>`
+   - `bpa_inbox_task_action`: `CLAIM BPA INBOX TASK <instance_id>`, `RELEASE BPA INBOX TASK <instance_id>`, or `FORWARD BPA INBOX TASK <instance_id>`
+   - `bpa_inbox_create_substitution_rule`: `CREATE BPA SUBSTITUTION FOR <user>`
+   - `bpa_inbox_change_substitution_rule`: `ENABLE BPA SUBSTITUTION <rule_id>`, `DISABLE BPA SUBSTITUTION <rule_id>`, or `DELETE BPA SUBSTITUTION <rule_id>`
+   - `bpa_execute_api_trigger`: `EXECUTE BPA TRIGGER <trigger_uid>`
+   - `bpa_start_automation`: `START BPA AUTOMATION <trigger_uid>`
+   - `bpa_process_visibility_scenario`: `PROCESS BPA VISIBILITY <scenario_id>`
+   - `bpa_clear_visibility_data`: `CLEAR BPA VISIBILITY DATA <scenario_id>`
+   - `bpa_push_visibility_events`: `PUSH BPA VISIBILITY EVENTS <count>`
+
+   Never bypass or guess a confirmation, and never complete tasks for real approvals without explicit user instruction. Purge, instance deletion and definition undeploy are destructive: run them only on explicit user instruction. Asynchronous operations (definition undeploy, purge, bulk instance delete, bulk task update) return `job_id`; follow up with `bpa_get_job`. To resume a process built in SAP Build that waits in a "Wait for an API Call" step, use `bpa_execute_api_trigger` with `execution_id`; `bpa_send_message` is for classic workflows only.
+7. **Full-loop tracing.** Take the business key or correlation value from the ABAP/RAP event or the CPI message (use the Integration Suite companion's message-processing-log tools for the CPI hop), then call `bpa_trace_process`. Open tasks in the trace are what appears in My Inbox / SAP Fiori Task Center; check `bpa_inbox_list_tasks` under the recipient's interactive sign-in when the user's view matters. For visibility dashboards that miss data, check `bpa_list_visibility_events` with `kind: errors`.
+8. **Boundaries.** This agent does not implement or activate ABAP code. Do not call ABAP `Activate` / `ActivateMultiple` tools; route ABAP/RAP work to the ABAP Developer and CPI iFlow work to the SAP Integration Developer.
+9. **Report evidence.** Summarize instance ids, statuses before and after each change, task ids and decisions, started instance ids, trigger and automation job ids, accepted event ids, async job ids and their final status, export file paths, decision test results (passed/failed with mismatches), and unresolved risks. Never claim success without read-back evidence.
+
+Use the focused skills under `.github/skills/`, especially `process-automation-development`, for the tool set, confirmation formats, and HTTP status interpretation.

package/.github/skills/btp-platform-administration/SKILL.md

@@ -0,0 +1,53 @@
+---
+description: Audit and operate SAP BTP core platform administration with the sap-ai-btp MCP server: global account hierarchy, entitlements and quotas, Service Manager service instances and service keys, destinations, identity and destination trust, Cloud Connectors and principal propagation checks.
+name: btp-platform-administration
+---
+
+# SAP BTP platform administration
+
+## Tool shortlist
+
+Use the live MCP `tools/list` result as authoritative. Call only the exact schemas exposed by the `sap-ai-btp` server (15 tools):
+
+- `btp_connection_info` — btp CLI path, source and config file; `verify: true` checks the CLI version and the login session.
+- `btp_get_account_hierarchy` — global account, directories and subaccounts (GUIDs, regions, states).
+- `btp_list_entitlements` — entitlements at global-account, directory or subaccount scope.
+- `btp_check_quota` — can plan P of service S be created in subaccount X (`available`, `not_entitled`, `insufficient_quota`, `assignment_not_ready`).
+- `btp_list_service_instances` — Service Manager instances with offering and plan names.
+- `btp_get_service_instance` — one instance with last operation, service keys and optionally redacted parameters.
+- `btp_list_service_keys` — service keys (never credentials).
+- `btp_get_service_key` — one key with redacted credentials.
+- `btp_list_destinations` — subaccount or service-instance destinations without secret properties.
+- `btp_get_destination` — one destination configuration, redacted.
+- `btp_get_trust` — identity provider trusts and the destination trust certificate expiry.
+- `btp_list_cloud_connectors` — connected Cloud Connectors and exposed systems via a Connectivity `api_access` instance.
+- `btp_check_destination` — pass/warn/fail/unknown checks for URL, authentication properties, proxy type, trust, Cloud Connector and exposed system.
+- `btp_create_service_instance` — confirmation `CREATE BTP SERVICE INSTANCE <name>`.
+- `btp_create_service_key` — confirmation `CREATE BTP SERVICE KEY <name>`.
+
+## Procedure
+
+1. Connection: `btp_connection_info` with `verify: true`.
+2. Hierarchy: `btp_get_account_hierarchy` to resolve subaccount and directory GUIDs.
+3. Audit: `btp_list_entitlements`, then `btp_check_quota` for the service and plan in question.
+4. Inspect: `btp_list_service_instances`, `btp_get_service_instance`, `btp_list_service_keys`, `btp_get_service_key`, `btp_list_destinations`, `btp_get_destination`, `btp_get_trust`, `btp_list_cloud_connectors`.
+5. Diagnose destinations: `btp_check_destination`.
+6. Confirmed create: `btp_create_service_instance` / `btp_create_service_key` with the exact confirmation string.
+7. Poll and verify: `btp_get_service_instance` until `last_operation.state` is `succeeded`; `btp_get_service_key` until the key is ready.
+
+## Rules
+
+- Subaccount GUIDs are required on every subaccount-scoped tool; the server never uses `btp target`.
+- Instances created here are Service Manager ("Other environment") instances, not bound to a Cloud Foundry space. Use `cf create-service` for CF-space instances.
+- `btp_check_quota` counts the service instances of the plan in the subaccount, and only for entitlement category `SERVICE`; other categories have no numeric instance quota.
+- Cloud Connector data needs a Connectivity `api_access` instance with a client-secret service key.
+- Check statuses mean pass, warn, fail or unknown. `unknown` principal-propagation items (system certificate, principal-propagation CA certificate, synchronized IdP trust, X.509 principal type of the system mapping, backend certificate mapping such as CERTRULE) must be verified in the Cloud Connector administration and the backend.
+- Session errors mean the user runs `btp login --sso` in their own terminal; a missing CLI means `sap-ai-dev --setup-btp` or `BTP_CLI`.
+- Do not invent tools or handcraft JSON-RPC; if a needed tool is absent from `tools/list`, report a host/session binding issue.
+
+## Safety boundaries
+
+- Use confirmation strings verbatim; never guess or bypass them.
+- Never echo or request secrets. Credentials are always redacted; full keys are fetched by the user with `btp get services/binding --name <key> --subaccount <id>`.
+- Pass passwords only inside `parameters`; they are written to a private temporary file, never to the command line.
+- No destructive operations: no deletions, entitlement assignments, or destination, trust or role-collection changes. Give the cockpit path or btp CLI command instead.

package/.github/skills/bw-datasphere-migration/SKILL.md

@@ -0,0 +1,66 @@
+---
+description: Plan and run SAP BW to SAP Datasphere migrations: inventory BW models through the ABAP destination server, choose the Data Product Generator or rebuild path, map objects, baseline BW figures, and reconcile results in Datasphere.
+name: bw-datasphere-migration
+---
+
+# SAP BW to Datasphere migration
+
+## Path decision
+
+The Data Product Generator (DPG) path requires a Datasphere tenant that is part of an SAP Business Data Cloud formation and BW 7.5 on HANA SPS24+ or BW/4HANA 2021 SPS04+ / BW/4HANA 2023. DPG providers: InfoObject, (a)DSO, CompositeProvider, MultiProvider, InfoCube, and Query as InfoProvider. If these conditions do not hold, use the rebuild path. When tenant formation or BW release is unknown, ask before choosing.
+
+## BW inventory
+
+The BW side is strictly read-only through the ABAP destination MCP server (`GetTable`, `GetTableContents`, `RunQuery`, `SearchObject`). Call `GetTable` on each metadata table FIRST and use only the returned fields; `RunQuery` is ABAP SQL, not HANA SQL.
+
+- `RSOADSO` / `RSOADSOT` — aDSOs (`ADSONM`, `OBJVERS = 'A'`)
+- `RSOHCPR` — CompositeProviders (`HCPRNM`, `XML_DEF`)
+- `RSDCUBE` — InfoCubes
+- `RSDODSO` — classic DSOs
+- `RSDIOBJ` / `RSDIOBJT` — InfoObjects (`IOBJNM`, `IOBJTP`)
+- `RSDKYF` — key figures (aggregation)
+- `RSTRAN` — transformations (`TRANID`, `SOURCETYPE`, `SOURCENAME`, `TARGETTYPE`, `TARGETNAME`)
+- `RSBKDTP` — DTPs (`DTP`, `SRC`, `SRCTP`, `TGT`, `TGTTP`)
+- `RSRREPDIR` — BEx queries (`COMPID`, `INFOCUBE`)
+- `RSPCCHAIN` — process chains (`CHAIN_ID`, `TYPE`, `VARIANTE`)
+- `RSDS` — DataSources
+
+Physical tables: aDSO active data `/BIC/A<ADSO>2`, classic DSO active `/BIC/A<DSO>00`, InfoObject master data `/BIC/P<IOBJ>`, texts `/BIC/T<IOBJ>` (`/BI0/` prefix for SAP-delivered objects). CSN field lists come from `GetTable` on the physical table.
+
+## Mapping
+
+| BW object | Rebuild path | DPG path |
+|---|---|---|
+| aDSO | local table (+ fact view) | Local Table (File) in the BW inbound space |
+| InfoObject with master data | dimension local table + text/hierarchy views | Local Table (File); loading stays in BW |
+| key figure | measure (aggregation from `RSDKYF`) | measure from provider |
+| CompositeProvider | fact view | Local Table (File) |
+| BEx query | analytic model | Local Table (File) |
+| transformation / DTP | transformation flow or data flow | loading stays in BW |
+| DataSource load | replication flow over an existing SAP BW / SAP ABAP connection | loading stays in BW |
+| process chain | task chain | loading stays in BW |
+| analysis authorizations | data access controls | data access controls |
+
+## Procedure
+
+1. Confirm scope, chosen path, the BW destination server, and the Datasphere tenant (`datasphere_connection_info` with `verify: true`) and target spaces.
+2. Inventory BW objects and build the dependency graph (InfoObjects → providers → transformations/DTPs → queries → process chains).
+3. Create the migration worksheet `datasphere-migration/<SCOPE>/worksheet.md` and CSN files `datasphere-migration/<SCOPE>/<SPACE>/<object-type>/<TECHNICAL_NAME>.json`.
+4. Baseline BW figures with `RunQuery` `SELECT COUNT(*)` and `SUM( <kf> )` using exactly the filters that will be used later in Datasphere; record them in the worksheet.
+5. Execute the chosen path:
+   - **5a. DPG:** give the user the subscription list (InfoProvider, tenant/BW inbound space, delta/full, schedule) to create in transaction `RSDPS` or the BW/4HANA Cockpit "Data Subscriptions" app — the toolkit has no BW subscription API. Verify landing with `datasphere_list_objects` (`local-tables`) in the inbound space, falling back to `datasphere_list_assets` / data-product tools when objects commands fail on the file space. Expose via `datasphere_list_data_providers` → `datasphere_create_data_product` (definition template from `datasphere_read_data_product`) → `datasphere_set_data_product_status` `Listed` → `datasphere_install_data_product` into the target space.
+   - **5b. Rebuild:** create objects in dependency order (tables → flows → views → analytic models → task chains) with `datasphere_build_local_table_csn` + `datasphere_create_object`; deploy each and fix `DesignTimeError`s before continuing.
+6. Load with `datasphere_run_task_chain` (confirmation `RUN DATASPHERE TASK CHAIN <SPACE>.<TASK_CHAIN>`) or `datasphere_replication_flow` action `run` (confirmation `RUN DATASPHERE REPLICATION FLOW <SPACE>.<TECHNICAL_NAME>`); poll `datasphere_get_task_log` / `datasphere_list_task_logs` and replication-flow `status`.
+7. Reconcile with `datasphere_reconcile` against the BW baseline (`expected_row_count`, `measures`, same filters, tolerance 0 unless agreed).
+8. Report evidence: baseline vs. actual figures, `all_within_tolerance`, deployed objects, load logs, and any deviations.
+
+## Live MCP tooling
+
+Query live `tools/list`, use the returned tool names and schemas exactly, and invoke the chat-attached tools directly. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-datasphere` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetTable`, `GetTableContents`, `RunQuery`, or `SearchObject`) are logical names; the live MCP surface exposes them as lowercase snake_case. A server scoped to a single destination (the normal case for generated `mcp.json` entries) exposes them unprefixed, so `GetTable` appears as `get_table`; when several destinations share one server, each name is destination-prefixed with its slug for disambiguation. Always call the exact names returned by `tools/list`.
+
+## Safety boundaries
+
+- BW is strictly read-only: no BW writes, no activation, no transports; only `GetTable`, `GetTableContents`, `RunQuery`, and `SearchObject` on the ABAP destination server.
+- Every Datasphere write requires its exact confirmation string (`CREATE`/`UPDATE`/`DELETE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`, `EXPORT DATASPHERE PACKAGE <SPACE>.<TECHNICAL_NAME>`, `RUN`/`RETRY DATASPHERE TASK CHAIN <SPACE>.<TASK_CHAIN>`, `CANCEL DATASPHERE TASK CHAIN RUN <SPACE>.<LOG_ID>`, `<ACTION> DATASPHERE REPLICATION FLOW <SPACE>.<TECHNICAL_NAME>`, `CREATE DATASPHERE DATA PRODUCT`, `SET DATASPHERE DATA PRODUCT <UUID> <Listed|Delisted|Deactivated>`, `INSTALL DATASPHERE DATA PRODUCT <UUID> INTO <SPACE>`).
+- Replication-flow action `status` needs no confirmation; all other actions do.
+- Never store credentials in `mcp.json` or echo secrets; report only reconciled figures and deployed-object evidence.

package/.github/skills/cloud-alm-operations/SKILL.md

@@ -0,0 +1,135 @@
+---
+description: Monitor, triage and track SAP landscapes with the sap-ai-cloud-alm MCP server: Integration & Exception Monitoring records and analytics, health and alert hotspots per DEV/TEST/PROD tier, incident triage correlated with CPI message processing logs and ABAP SLG1 logs, feature and transport deployment status, and confirmation-gated event situation closing.
+name: cloud-alm-operations
+---
+
+# SAP Cloud ALM operations
+
+## Tool shortlist
+
+Use the live MCP `tools/list` result as authoritative. Call only the exact schemas exposed by the `sap-ai-cloud-alm` server (11 tools):
+
+Connection and landscape
+- `calm_connection_info` — `api_host`, `token_host`, `auth`, `source`; `verify: true` checks Landscape and Analytics API access.
+- `calm_list_landscape` — landscape objects with `lmsId` (the `serviceId` of every other API), `role`, `serviceType`, `systemNumber`, `logicalSystems`; filters by object type, role, service type, name, system number, LMS id, external id.
+- `calm_get_landscape_health` — exceptions (EXM), critical/warning Health Monitoring metrics and EVENTS alerts per service, grouped into role tiers; at most 30 services, 1 to 744 hours.
+
+Records and triage
+- `calm_list_monitoring_records` — Raw Data Outbound Logs for `im`, `exm.im`, `exm.jam`, `iep`, `jam.run`, `bsm`; `next_offset` paging.
+- `calm_triage_incident` — alert counts, `iep` events, `exm.im` errors, optional `im` messages for one service, plus `handoff` arguments for `cpi_list_message_logs` and `get_application_log`.
+
+Analytics
+- `calm_list_analytics_providers` — authorized providers.
+- `calm_describe_analytics_provider` — dimensions, measures, attributes, or one attribute's values.
+- `calm_query_analytics` — one query, aggregated with `sum` / `max` or raw per time bucket (`none`).
+
+Deployment
+- `calm_list_features` — features with status, priority, project, release and transport ids.
+- `calm_get_feature` — one feature by `feature_uuid` or `display_id`, or the features linked to a `transport_id`.
+
+Event situations
+- `calm_close_event_situation` — closes an alert (and mapped tickets unless `notify_ticketing: false`); requires confirmation `CLOSE CALM EVENT SITUATION <event_situation_id>` or `CLOSE CALM EVENT SITUATION BY EXTERNAL ID <external_id>`.
+
+## Setup and scopes
+
+- Create an instance of the BTP service "SAP Cloud ALM API", plan `standard`, in the Cloud ALM subaccount, and a binding (service key) that carries `uaa.clientsecret` (credential type `binding-secret`; x509 bindings are rejected). The key's `endpoints.Api` is the API base URL including `/api`.
+- Grant the scopes the tools need as instance `authorities`:
+  - `calm-api.landscape.read`
+  - `calm-api.analytics.read`
+  - `calm-api.analytics.providers.read`
+  - `calm-api.exm.read`
+  - `calm-api.exm.personal.read`
+  - `calm-api.integration-monitoring.read`
+  - `calm-api.integration-monitoring.personal.read`
+  - `calm-api.hm.read`
+  - `calm-api.iep.read`
+  - `calm-api.jobs.read`
+  - `calm-api.bsm.read`
+  - `calm-api.logs.read`
+  - `calm-api.features.read`
+  - `calm-api.event-situations.write` (only for closing alerts)
+- Example instance parameters:
+
+  ```json
+  {
+    "xs-security": {
+      "xsappname": "<instance-name>",
+      "authorities": [
+        "$XSMASTERAPPNAME.calm-api.landscape.read",
+        "$XSMASTERAPPNAME.calm-api.analytics.read",
+        "$XSMASTERAPPNAME.calm-api.logs.read",
+        "$XSMASTERAPPNAME.calm-api.exm.read",
+        "$XSMASTERAPPNAME.calm-api.integration-monitoring.read",
+        "$XSMASTERAPPNAME.calm-api.hm.read",
+        "$XSMASTERAPPNAME.calm-api.iep.read",
+        "$XSMASTERAPPNAME.calm-api.features.read"
+      ],
+      "oauth2-configuration": { "credential-types": ["binding-secret", "x509"] }
+    }
+  }
+  ```
+
+  When updating an existing instance, use the instance GUID as `xsappname`.
+- Configure with `sap-ai-dev --setup-cloud-alm` (stored for the user only), or `CLOUD_ALM_SERVICE_KEY` / `CLOUD_ALM_URL` + `CLOUD_ALM_TOKEN_URL` + `CLOUD_ALM_CLIENT_ID` + `CLOUD_ALM_CLIENT_SECRET` in the MCP host environment. Only client credentials are supported.
+
+## Procedure
+
+1. **Hotspots.** `calm_connection_info` (`verify: true`), `calm_list_landscape` to learn the role values, then `calm_get_landscape_health` with those `roles`.
+2. **Records.** `calm_list_monitoring_records` on the hot services: `exm.im` for exceptions, `im` with category labels for message flows, `iep` for monitoring events, `jam.run` for jobs.
+3. **Triage.** `calm_triage_incident` for the affected service and window.
+4. **Correlate.** Follow the CPI and ABAP hops below with the returned `handoff`.
+5. **Deployment check.** `calm_list_features` / `calm_get_feature`, plus `calm_get_landscape_health` on the target tier before and after the deployment window.
+6. **Optional close.** `calm_close_event_situation` only on explicit request after the cause is fixed.
+
+## Analytics recipes
+
+Pass these to `calm_query_analytics` (`provider`, `dimensions`, `measures`, `filters`). Filter values such as status groups are tenant data: discover them with `calm_describe_analytics_provider` (for example `attribute: "StatusGroup"`).
+
+| Goal | Provider | Dimensions | Measures | Notes |
+|---|---|---|---|---|
+| CPI messages per iFlow and status | `CPI_MESSAGES` | `IntegrationArtifactName`, `StatusGroup` (also `ServiceName`, `serviceId`, `Status`) | `Count` | `aggregate: "sum"` |
+| IDocs | `IDOC` | `MessageType`, `Direction`, `Status Group` (also `Sender Port`, `Receiver Port`, `Mandant`) | `Count` | `aggregate: "sum"` |
+| Web service messages | `WS` | `Sender Interface Name`, `Receiver Interface Name`, `Direction`, `Status Group` | `Count` | `aggregate: "sum"` |
+| AIF messages | `AIF` | `Namespace`, `Interface`, `StatusGroup` (also `Direction`, `Category`, `Version`, `Status`) | `Count` | `aggregate: "sum"` |
+| Exceptions per category | `EXM_DATAPROVIDER` | `serviceId`, `categoryName` (also `serviceType`, `serviceName`, `categoryId`, `useCase`) | `counter` (`method: "SUM"`) | `serviceId` filter is multi-select |
+| Health metrics | `HM_ANALYTICS_DP` | `metricName` (also `metricId`, `metricLabel`) | `criticalStatus`, `warningStatus`, `okStatus`, `value`, `limit`, `usage` | `serviceId` filter is single-select; status measures are percentages, use `aggregate: "max"` |
+| Monitoring events and alerts | `EVENTS` | `useCase`, `eventName` | `events`, `alerts`, `eventSituations`, `tickets`, `mails`, `chatMessages`, `operationFlows`, `totalDuration` | a filter is mandatory (HTTP 428 without one); use a single `serviceId` |
+
+Other Integration Monitoring providers: C4C, MDI, SF, FG, Concur, Ariba_Sourcing, Ariba_Procurement, Ariba_CIG, Ariba_Network, Mob_Srv. Message and exception counts use `aggregate: "sum"`; Health Monitoring status measures use `aggregate: "max"`. Analytics answers at most 5000 rows per query; `truncated: true` means narrow the window, filters or dimensions.
+
+## Records rules
+
+- Windows are at most 60 minutes for every provider except `bsm` (up to 31 days). Use analytics for longer windows.
+- `im` needs `categories`: the labels shown in the Integration Monitoring UI (for example "SAP Integration Suite Messages", "IDoc", "Web Service Messages", "AIF").
+- `iep` and `bsm` take exactly one service id; `jam.run` at most 27; the rest at most 30.
+- `iep` records exist only when the event action "Store Event Payload for 24 Hours" is active for the monitoring event.
+- Page with `next_offset`; `total_count` comes from the `x-total-count` header when SAP sends it.
+- Record attribute names are passed through exactly as delivered; read them from the result instead of assuming a schema.
+
+## Correlation guide
+
+- **CPI hop.** Check that the Integration Suite companion's `integration_connection_info` host belongs to the same tenant as the Cloud ALM service (`mainUrl` / name). Then call `cpi_list_message_logs` with `handoff.cpi.arguments` (status FAILED, then RETRY/ESCALATED), and drill into `cpi_get_message_log`, `cpi_get_message_log_steps` and `cpi_trace_message` with message ids from `im` records or the MPL list.
+- **ABAP hop.** Check with `get_system_info` / `get_connection_info` that the ABAP destination's SID equals `handoff.abap.system` and its client is in `handoff.abap.clients`. Then call `get_application_log` with `handoff.abap.arguments` and narrow it with `object`, `subobject`, `user` or `program` from the `exm.im` record attributes. SLG1 dates are server-local, so the handoff pads the UTC window by one day on each side; compare record timestamps, not dates.
+- **Failed RFCs.** Health Monitoring "Communication" metrics (tRFC CPICERR/SYSFAIL, qRFC IN/OUT errors, bgRFC errors, RFC Connection Status) plus `exm.im` ABAP Runtime exceptions on the same system.
+- **Event Mesh.** Health Monitoring broker metrics (Event Mesh broker statistics, Advanced Event Mesh broker metrics, CPI JMS queues); Integration & Exception Monitoring has no Event Mesh category. Use the Integration Suite companion's `event_mesh_get_queue` / `aem_*` tools for live queue state when configured.
+
+## Deployment rules
+
+- Feature transports (`toTransports`, `toTransportReferences`) carry transport ids only. No public Cloud ALM API exposes per-system import status: never claim a transport reached TEST or PROD from Features data.
+- Feature status codes: CREATED, NOT_PLANNED, IN_REALIZATION, IN_TESTING, SUCCESSFULLY_TESTED, APPROVED_FOR_DEPLOYMENT, CONFIRMED.
+- Observed `im` records for a CPI service are the "observed collection" evidence that the Integration Suite companion's `integration_monitoring_readiness` asks for.
+
+## HTTP meanings
+
+- 403: the instance lacks the API's `calm-api.*` scope.
+- 428: a mandatory filter is missing (EVENTS analytics without a filter).
+- 429: rate limit (analytics and logs allow 100 requests per minute).
+- 413: request too large; narrow the query.
+- On close, an "already closed" error right after a gateway error means the earlier close took effect: PUT is retried on 5xx.
+
+## Safety boundaries
+
+- The only write is `calm_close_event_situation`, and only with its exact confirmation string on explicit user request; never guess an event situation id.
+- Never store credentials in `mcp.json` or echo secrets (client secrets, tokens) into results, files or chat.
+- Records may hold personal data (users, business payload values); quote only what the diagnosis needs.
+- Do not invent tools or handcraft JSON-RPC; if a needed tool is absent from `tools/list`, report a host/session binding issue.

package/.github/skills/datasphere-administration/SKILL.md

@@ -0,0 +1,40 @@
+---
+description: Administer SAP Datasphere through the sap-ai-datasphere MCP server: spaces and space users, database users, workload priorities, global and scoped roles, users, connections, TLS certificates, and task-scheduling consent.
+name: datasphere-administration
+---
+
+# SAP Datasphere administration
+
+## Tool shortlist
+
+- `datasphere_connection_info` — auth mode and `admin_commands_available` (true only with Interactive Usage auth).
+- `datasphere_list_commands` — every CLI command with `usable_with_current_auth` per command; filter with a `prefix`.
+- `datasphere_describe_command` — authoritative option list for one command.
+- `datasphere_run_read_command` — read-only commands.
+- `datasphere_run_command` — any command; write commands require confirmation `RUN DATASPHERE <command>`, deletions `DELETE DATASPHERE <command>`.
+- `datasphere_list_connections`, `datasphere_validate_connection` — typed connection tools.
+- `datasphere_list_task_logs`, `datasphere_get_task_log` — task-log reads for consent/scheduling checks.
+
+## Procedure
+
+1. Call `datasphere_connection_info` and confirm `admin_commands_available` is true (Interactive Usage auth). Technical-user (client credentials) OAuth clients can run only `configuration certificates`, `marketplace`, `objects`, `spaces connections`, and `tasks` commands; everything else needs Interactive Usage auth. If admin commands are unavailable, report the limitation instead of attempting them.
+2. Query live `tools/list`, use the returned tool names and schemas exactly, and invoke the chat-attached tools directly. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-datasphere` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetTable` or `RunQuery` on the ABAP destination server) are logical names; the live MCP surface exposes them as lowercase snake_case. Always call the exact names returned by `tools/list`.
+3. Discover commands with `datasphere_list_commands` using a prefix: `spaces`, `dbusers`, `workload`, `global-roles`, `scoped-roles`, `users`, `spaces connections`, `configuration certificates`, `tasks consent`. Check `usable_with_current_auth` before planning.
+4. `datasphere_describe_command` on the chosen command for its exact options and whether it takes a request body.
+5. `datasphere_run_read_command` to read the current state before changing anything (for example the current space definition, database-user list, role assignments, or users).
+6. `datasphere_run_command` with the exact confirmation `RUN DATASPHERE <command>` (or `DELETE DATASPHERE <command>` for deletions). Pass JSON definitions (space definitions, role/user lists, connection definitions) in `input`, never spread across options.
+7. Read back the changed entity with `datasphere_run_read_command` and report before/after evidence.
+
+## Rules
+
+- JSON definitions go in `input`: space definitions, role/user lists, and connection definitions with credentials. Never echo credentials or secrets back into chat or files.
+- Database-user passwords are redacted in results; the user reads them in the Datasphere UI. Do not attempt to work around this.
+- For SQL access, configure `DATASPHERE_SQL_*` via `sap-ai-dev --setup-datasphere`; the SQL tools are bound to that database user's grants.
+- Prefer the narrowest command that achieves the change; do not blanket-update lists when a single-member change command exists.
+
+## Safety boundaries
+
+- Never run a write or delete command without its exact confirmation string (`RUN DATASPHERE <command>` / `DELETE DATASPHERE <command>`).
+- Never store credentials in `mcp.json` and never echo secrets, connection credentials, or tokens into results or chat; results pass through server-side redaction — do not reconstruct redacted values.
+- Administrative scope is bounded by the OAuth client's authorizations; do not attempt privilege escalation or role self-assignment.
+- Do not invent commands; every command must appear in `datasphere_list_commands` and be described by `datasphere_describe_command` before use.

package/.github/skills/datasphere-development/SKILL.md

@@ -0,0 +1,55 @@
+---
+description: Model, deploy, load and verify SAP Datasphere content with the sap-ai-datasphere MCP server: CSN objects of every type, packages, task chains, replication flows, data products, consumption queries and Open SQL.
+name: datasphere-development
+---
+
+# SAP Datasphere development
+
+## Tool shortlist
+
+Use the live MCP `tools/list` result as authoritative. Call only the exact schemas exposed by the `sap-ai-datasphere` server:
+
+- `datasphere_connection_info` — tenant host, token host, auth mode, CLI version, SQL configuration, and `admin_commands_available` (interactive auth).
+- `datasphere_list_spaces`, `datasphere_list_assets`, `datasphere_get_asset_metadata` — consumption catalog inventory.
+- `datasphere_list_objects`, `datasphere_read_object` — design-time and run-time object content per space and object type.
+- `datasphere_create_object` — requires confirmation `CREATE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`.
+- `datasphere_update_object` — requires `expected_changed_on` from the last list result and confirmation `UPDATE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`.
+- `datasphere_delete_object` — requires confirmation `DELETE DATASPHERE <object_type> <SPACE>.<TECHNICAL_NAME>`.
+- `datasphere_export_package` — requires confirmation `EXPORT DATASPHERE PACKAGE <SPACE>.<TECHNICAL_NAME>`.
+- `datasphere_list_task_logs`, `datasphere_get_task_log` — task log listing and detail.
+- `datasphere_run_task_chain` — requires confirmation `RUN DATASPHERE TASK CHAIN <SPACE>.<TASK_CHAIN>`.
+- `datasphere_retry_task_chain` — requires confirmation `RETRY DATASPHERE TASK CHAIN <SPACE>.<TASK_CHAIN>`.
+- `datasphere_cancel_task_chain` — requires confirmation `CANCEL DATASPHERE TASK CHAIN RUN <SPACE>.<LOG_ID>`.
+- `datasphere_replication_flow` — actions `run`, `pause`, `resume`, `stop`, `pause-object`, `resume-object`, `restart-object` require confirmation `<ACTION> DATASPHERE REPLICATION FLOW <SPACE>.<TECHNICAL_NAME>`; action `status` needs no confirmation.
+- `datasphere_list_connections`, `datasphere_validate_connection` — connection inventory and validation.
+- `datasphere_list_data_providers`, `datasphere_list_data_products`, `datasphere_read_data_product`, `datasphere_create_data_product` (confirmation `CREATE DATASPHERE DATA PRODUCT`), `datasphere_set_data_product_status` (confirmation `SET DATASPHERE DATA PRODUCT <UUID> <Listed|Delisted|Deactivated>`), `datasphere_install_data_product` (confirmation `INSTALL DATASPHERE DATA PRODUCT <UUID> INTO <SPACE>`) — Data Marketplace.
+- `datasphere_query_relational`, `datasphere_query_analytical`, `datasphere_reconcile` — consumption queries and baseline reconciliation.
+- `datasphere_build_local_table_csn` — pure CSN generation for local tables from DDIC-typed field lists.
+- `datasphere_list_commands`, `datasphere_describe_command`, `datasphere_run_read_command`, `datasphere_run_command` — every remaining (and future) CLI function; `datasphere_run_command` requires `RUN DATASPHERE <command>` (or `DELETE DATASPHERE <command>` for deletions).
+- `datasphere_sql_query`, `datasphere_sql_execute` — Open SQL on the configured database user's schema; `datasphere_sql_execute` requires confirmation `EXECUTE DATASPHERE SQL AS <USER>` and is available only when Open SQL is configured.
+
+## Procedure
+
+1. Call `datasphere_connection_info` first. Compare tenant host, auth mode, and SQL configuration against the request. Technical-user (client credentials) OAuth clients can run only `configuration certificates`, `marketplace`, `objects`, `spaces connections`, and `tasks` commands; everything else needs Interactive Usage auth (`admin_commands_available` in the result). If the target is missing or mismatched, stop and report; never ask the user to paste credentials.
+2. Query live `tools/list`, use the returned tool names and schemas exactly, and invoke the chat-attached tools directly. Direct MCP invocation is mandatory. Do not launch `sap-ai-dev` or `sap-ai-datasphere` for MCP operations, handcraft JSON-RPC in a terminal, or use a CLI fallback when chat tools are unavailable; report a host/session binding issue. Tool names shown in PascalCase (such as `GetTable` or `RunQuery` on the ABAP destination server) are logical names; the live MCP surface exposes them as lowercase snake_case. Always call the exact names returned by `tools/list`.
+3. Inventory the target space with `datasphere_list_objects`, then `datasphere_read_object` of an existing object of the same type as a template before authoring anything new.
+4. Write CSN definitions locally under `datasphere/<SPACE>/<object-type>/<TECHNICAL_NAME>.json`. One CSN file per object; dependencies (tables before views, views before analytic models, models before task chains) come first. Use `datasphere_build_local_table_csn` for local tables.
+5. Create or update with `datasphere_create_object` / `datasphere_update_object`. Take `expected_changed_on` from the most recent list result; if the object changed since, re-read before updating. Provide the exact confirmation string.
+6. Check `read_back.status` in the create/update result equals `Deployed`. If not, read task logs with `datasphere_list_task_logs` / `datasphere_get_task_log` and fix the reported `DesignTimeError`, then update again.
+7. Run loads: `datasphere_run_task_chain` (or `datasphere_replication_flow` with action `run`), then poll `datasphere_get_task_log` / `datasphere_list_task_logs` or replication-flow `status` until the run finishes.
+8. Verify data with `datasphere_query_relational` / `datasphere_query_analytical` and reconcile expected figures with `datasphere_reconcile`.
+
+## Rules
+
+- Consumption queries require assets to be exposed for consumption; `datasphere_list_assets` shows only exposed assets.
+- `$count`, `$top`, and `$skip` are unsupported when the asset's lineage contains non-replicated sources.
+- Analytic models support analytical requests only (`datasphere_query_analytical`); relational requests are for relational assets.
+- Technical users cannot run task chains containing BW bridge process chains.
+- For anything without a typed tool, use `datasphere_list_commands` to find the command (`usable_with_current_auth` per command), `datasphere_describe_command` for its exact options, then `datasphere_run_read_command` for reads or `datasphere_run_command` (with `input` for JSON definitions) for writes.
+
+## Safety boundaries
+
+- Writes are confirmation-gated only: never call `datasphere_create_object`, `datasphere_update_object`, `datasphere_delete_object`, `datasphere_export_package`, `datasphere_run_task_chain`, `datasphere_retry_task_chain`, `datasphere_cancel_task_chain`, `datasphere_replication_flow` (write actions), `datasphere_create_data_product`, `datasphere_set_data_product_status`, `datasphere_install_data_product`, `datasphere_run_command`, or `datasphere_sql_execute` without the exact confirmation string.
+- Never store credentials in `mcp.json` or echo secrets (client secrets, refresh tokens, database-user passwords) into results, files, or chat.
+- SQL tools are bound to the configured database user's grants; that user's privileges are the real boundary, not these instructions.
+- Do not invent tools or handcraft JSON-RPC; if a needed tool is absent from `tools/list`, report a host/session binding issue.