@raishin/vanguard-frontier-agentic 3.0.0-alpha.7 → 3.0.0

package/skills/sap/sap-integration-suite-review/references/context7-framework-docs.md

@@ -0,0 +1,76 @@
+# Context7 framework docs — SAP Integration Suite Review
+
+**Role**: supplementary. Official SAP Integration Suite documentation (SAP Help Portal: Cloud Integration, API Management, Event Mesh) is the primary source for all integration review guidance. Context7-sourced CAP documentation supplements guidance specifically for OData service exposure and event handling patterns when a CAP-based application is an upstream or downstream integration partner.
+
+**Library used**: SAP Cloud Application Programming Model (CAP)
+Context7 library ID: `/websites/cap_cloud_sap`
+Lookup target: OData service exposure, OpenAPI integration, event handling, error handling in CAP services consumed via Integration Suite
+Skill: `sap-integration-suite-review`
+Classification: supplementary
+
+---
+
+## CAP OData service exposure (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+CAP exposes services as OData V4 endpoints by default. When a CAP service is consumed by a Cloud Integration iFlow or proxied by an API Management proxy, the OData metadata contract is defined by the CDS service definition. CAP-generated OData V4 services use OASIS OData V4 metadata conventions. Mismatches between the CDS service definition and the API Management API spec are a common source of `odata-spec-mismatch` findings.
+
+Example of exposing a remote OData entity as a CAP projection (relevant when a CAP application re-exposes an SAP S/4HANA OData service via Integration Suite):
+
+```cds
+using { API_BUSINESS_PARTNER as bupa } from '../srv/external/API_BUSINESS_PARTNER';
+
+extend service RiskService with {
+  entity BusinessPartners as projection on bupa.A_BusinessPartner;
+}
+```
+
+**Relevance to Integration Suite review**: When an API Management proxy fronts a CAP OData V4 service, the proxy spec must match the CDS-generated metadata. Discrepancies between the CDS model and the API spec file registered in API Management are flagged as `odata-spec-mismatch` findings.
+
+## CAP event handling and error responses (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+CAP event handlers that throw exceptions abort the current event's processing and roll back any active transaction. The OData V4 protocol adapter converts exceptions into OData error responses with HTTP error codes. When a Cloud Integration iFlow calls a CAP OData endpoint and receives an error response, the iFlow exception subprocess must handle OData-format error payloads.
+
+Example OData error response from a CAP service:
+
+```xml
+<error xmlns="https://docs.oasis-open.org/odata/ns/metadata">
+  <code>500</code>
+  <message>Processing failed: no such entity</message>
+</error>
+```
+
+**Relevance**: iFlow exception subprocesses that call CAP OData endpoints must parse OData-format error responses (XML or JSON, depending on Content-Type negotiation). Generic HTTP error handling that assumes plain-text error bodies will silently miss error detail from CAP services. This supplements the Cloud Integration exception subprocess guidance from official SAP docs.
+
+## CAP event declaration for S/4HANA integration (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+
+When a CAP application consumes SAP Event Mesh events from S/4HANA, events that are not present in the imported API spec must be declared explicitly in CDS:
+
+```cds
+using { API_BUSINESS_PARTNER as S4 } from './API_BUSINESS_PARTNER';
+extend service S4 with {
+  event BusinessPartner.Created @(topic:'sap.s4.beh.businesspartner.v1.BusinessPartner.Created.v1') {
+    BusinessPartner : String
+  }
+}
+```
+
+**Relevance**: When reviewing an Integration Suite topology where a CAP application subscribes to Event Mesh topics from S/4HANA, the topic name declared in the CAP event definition must match the Event Mesh topic namespace configured in the Event Mesh service instance. Mismatches cause silent event delivery failures. This supplements the Event Mesh topic design guidance from official SAP docs.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 CAP documentation applies **only** when a CAP-based application is the upstream or downstream integration partner in the scope of an Integration Suite review. It does not apply to:
+
+- Native Cloud Integration adapter behavior (HTTP, SOAP, IDoc, AS2, JMS) — use SAP Help Portal Cloud Integration docs
+- API Management policy language (JavaScript, ExtractVariables, OAuthV2) — use SAP Help Portal API Management docs
+- SAP Advanced Event Mesh broker configuration — use SAP Help Portal Event Mesh docs
+- Security material management (keystore, credential store) — use SAP Help Portal Cloud Integration security docs
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses.

package/skills/sap/sap-integration-suite-review/references/official-sources.md

@@ -0,0 +1,79 @@
+# Official sources — SAP Integration Suite Review
+
+Use this reference when grounding Cloud Integration iFlow design, API Management policy assessment, Event Mesh configuration review, security material evaluation, and monitoring posture assessment.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Integration Suite documentation). No live-system evidence is collected by this skill.
+
+## Cloud Integration (SAP Cloud Integration / CPI)
+
+- SAP Cloud Integration overview
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/sap-cloud-integration
+  source_owner: SAP SE
+  topic_supported: Cloud Integration capabilities, iFlow design concepts, adapter catalog, message processing model
+  why_needed: Primary entry point for Cloud Integration documentation; establishes the iFlow design model used to classify integration findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Define exception subprocess
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/define-exception-subprocess
+  source_owner: SAP SE
+  topic_supported: Exception subprocess design, error boundary definition, failed message routing from exception subprocesses
+  why_needed: Authoritative reference for the mandatory error handling pattern — any iFlow without an exception subprocess fails the error handling non-negotiable
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Idempotent process call handles duplicates
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/idempotent-process-call-handles-duplicates
+  source_owner: SAP SE
+  topic_supported: Idempotent receiver pattern in Cloud Integration, duplicate detection using message IDs, JMS retry idempotency
+  why_needed: Defines the idempotent process call pattern — required to assess whether retry-capable iFlows implement duplicate protection
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Managing security material
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/managing-security-material
+  source_owner: SAP SE
+  topic_supported: Credential store, keystore, OAuth credential management, certificate-based adapter authentication
+  why_needed: Defines the secure credential storage model — required to flag plaintext credentials in iFlow properties as critical findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Message monitoring
+  https://help.sap.com/docs/cloud-integration/sap-cloud-integration/message-monitoring
+  source_owner: SAP SE
+  topic_supported: Cloud Integration message monitoring, processing log levels, alerting, retry state visibility
+  why_needed: Defines the operational monitoring model — required to assess whether iFlows provide adequate observability for production operations
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## API Management
+
+- SAP API Management overview
+  https://help.sap.com/docs/sap-api-management/sap-api-management/sap-api-management
+  source_owner: SAP SE
+  topic_supported: API Management architecture, API proxy design, API product and plan model, developer portal
+  why_needed: Primary reference for API Management design model used to classify API proxy governance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- OAuth V2.0 policy (API Management)
+  https://help.sap.com/docs/sap-api-management/sap-api-management/oauth-v2-0
+  source_owner: SAP SE
+  topic_supported: OAuth 2.0 policy enforcement in API Management proxies, grant type support, token validation configuration
+  why_needed: Defines the OAuth policy model — required to classify API proxies without inbound OAuth enforcement as critical security findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Advanced Event Mesh / Event Mesh
+
+- What is SAP Advanced Event Mesh
+  https://help.sap.com/docs/sap-advanced-event-mesh/sap-advanced-event-mesh/what-is-sap-advanced-event-mesh
+  source_owner: SAP SE
+  topic_supported: Event broker topology, topic design, queue configuration, consumer group model, access control
+  why_needed: Defines the Event Mesh architecture model — required to classify topic namespace design, queue binding, and consumer isolation findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Integration Suite documentation describes the designed behavior of iFlow components, API Management policies, and Event Mesh configuration options. It does not prove which iFlows are deployed in the user's tenant, whether policies are correctly configured, or whether monitoring alerts are active. Users must supply iFlow exports, API proxy descriptors, Event Mesh configuration exports, or written descriptions for concrete assessment.

package/skills/sap/sap-integration-suite-review/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist — SAP Integration Suite Review
+
+Use before making any remediation recommendation, especially for findings that affect iFlow deployment, API proxy policies, or Event Mesh consumer access.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live Integration Suite tenant, Cloud Integration API, API Management admin portal, or Event Mesh namespace. This skill reviews artifacts only.
+- Do not accept or request tenant OAuth tokens, service keys, credential store values, keystore passwords, API Management admin credentials, or Event Mesh management credentials.
+- Do not recommend deploying or modifying iFlows or API proxies in a production tenant based on review alone. All recommendations must be tested in a development or QA tenant first.
+- Do not classify a finding as `critical` without a traceable path to the specific security exposure or data loss scenario from user-provided artifacts or official documentation.
+- Do not recommend removing exception subprocess error suppression without first confirming how the failed message will be handled (dead-letter queue, alert, or manual reprocess).
+- Do not treat synchronous and asynchronous integration patterns interchangeably. Idempotency recommendations differ between synchronous request-reply and asynchronous JMS/event-based patterns.
+- Do not assert that an OData V4 or OpenAPI spec mismatch exists without user-provided spec content to compare against. Spec mismatch findings require both the declared spec and the deployed implementation for assessment.
+
+## What people get wrong
+
+- **Assuming all retry = idempotency needed**: Simple synchronous adapter retries (HTTP retry on connection failure before any processing) do not create duplicate-processing risk. Only retries that re-submit a message that may have already been partially processed (JMS, AS2, polling) require idempotency controls.
+- **Recommending API Management policies for Cloud Integration adapter security**: API Management policies apply only to API proxy flows. Adapter-level security in Cloud Integration (e.g., HTTPS sender adapter with client certificate) is configured separately in the iFlow adapter parameters, not in API Management.
+- **Conflating SAP Advanced Event Mesh with the legacy SAP Event Mesh service**: SAP Advanced Event Mesh (AEM) and the SAP Event Mesh service (BTP) have different topic hierarchy conventions, access control models, and monitoring tools. Confirm which product is in scope before applying documentation.
+- **Missing the Secure Parameter store syntax**: Referencing credentials in iFlow properties uses `{{secparam.alias}}` syntax. If the user's iFlow uses a hardcoded value in the property field rather than this reference syntax, it is a `critical` plaintext credential finding regardless of whether the property is visible in the UI.
+- **Ignoring dead-letter behavior on unbounded retry**: An iFlow with JMS retry configured to `Max. Retry Count: -1` (unlimited) and no dead-letter destination will retry poison messages indefinitely, consuming broker resources and masking other message failures.
+- **Treating context7-supplementary CAP OData guidance as Cloud Integration guidance**: Context7 CAP documentation describes OData service exposure from CAP applications — it does not describe how Cloud Integration OData sender or receiver adapters work. Apply Context7 guidance only when a CAP-based service is the upstream or downstream partner in the integration.
+
+## When to push back
+
+- Push back when the user asks to confirm an iFlow security finding from a description alone without providing the iFlow export or configuration details.
+- Push back when the user asks to recommend specific retry counts or timeout values without providing message volume and SLA data.
+- Push back when the user asks to modify a production iFlow or API proxy directly — redirect to test tenant first.
+- Push back when a request requires live tenant API access, iFlow deployment, or API proxy deployment — state clearly that live mutation is out of scope.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Cloud Integration, API Management, or Event Mesh Help Portal documentation
+- `user-provided evidence` — iFlow exports, API proxy descriptors, Event Mesh config exports, monitoring screenshots, or descriptions provided by the user
+- `context7-supplementary` — CAP OData service or event handling patterns from Context7 (supplementary; applies only when a CAP-based upstream or downstream service is in scope)
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-integration-suite-review/references/workflow-and-output.md

@@ -0,0 +1,78 @@
+# Workflow and output contract — SAP Integration Suite Review
+
+Use this reference for all finding classification, risk assignment, remediation path selection, and output formatting.
+
+## Integration issue taxonomy
+
+| Component domain | Finding class | Description |
+|-----------------|--------------|-------------|
+| `cloud-integration` | `missing-exception-subprocess` | iFlow has no exception subprocess; errors silently discard messages |
+| `cloud-integration` | `missing-idempotency` | Retry-capable iFlow (JMS, polling, webhook) has no duplicate check or idempotent receiver |
+| `cloud-integration` | `plaintext-credential` | Credential (password, API key, client secret) hardcoded in iFlow property or mapping |
+| `cloud-integration` | `missing-correlation-id` | iFlow does not propagate SAP-MessageId or business key across adapter boundaries |
+| `cloud-integration` | `unbounded-retry` | JMS or adapter retry configured with no maximum retry count or dead-letter routing |
+| `cloud-integration` | `missing-receiver-determination` | Dynamic routing iFlow has no default receiver path; unmatched messages are silently dropped |
+| `api-management` | `missing-oauth-policy` | API proxy inbound step has no OAuth 2.0 or API key enforcement policy |
+| `api-management` | `missing-rate-limit` | API proxy has no spike arrest or quota policy; susceptible to abuse or overload |
+| `api-management` | `missing-threat-protection` | API proxy has no JSON/XML threat protection policy on inbound payloads |
+| `api-management` | `basic-auth-inbound` | API proxy inbound step uses Basic Auth — not acceptable for production endpoints |
+| `api-management` | `odata-spec-mismatch` | OData V4 service exposed via API Management does not match declared metadata or violates OData V4 conventions |
+| `event-mesh` | `shared-service-key` | Multiple consumers share a single Event Mesh service key — violates isolation principle |
+| `event-mesh` | `missing-dead-letter-queue` | Queue has no dead-letter destination; poison messages cause indefinite retry loops |
+| `event-mesh` | `missing-consumer-group-isolation` | Consumer groups not isolated per application — one consumer can read another application's messages |
+| `security` | `missing-certificate-rotation` | Adapter certificate-based auth uses certificates without documented rotation schedule |
+| `monitoring` | `no-alert-rules` | Cloud Integration tenant has no configured alert rules for failed message processing |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Direct security exposure or data loss: no inbound OAuth/API key enforcement, plaintext credential in iFlow property |
+| `high` | Operational reliability failure: missing exception subprocess, missing idempotency on retry-capable iFlow, unbounded retry with no dead-letter |
+| `medium` | Governance or observability gap: missing correlation ID propagation, no monitoring alert rules, shared Event Mesh service key |
+| `low` | Best practice deviation: inconsistent naming, undocumented adapter parameter choices, missing rate limiting on internal-only APIs |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a missing inbound security policy (OAuth, API key)?**
+   - Yes → `critical`. Add an OAuth V2.0 VerifyAccessToken policy as the first step in the API proxy PreFlow before any target invocation. Do not proceed with deployment without it.
+   - No → continue.
+
+2. **Is this a plaintext credential in iFlow configuration?**
+   - Yes → `critical`. Move the credential to the Integration Suite Secure Parameter store (credential store). Reference via `{{secparam.credential-alias}}` syntax. Redeploy the iFlow.
+   - No → continue.
+
+3. **Is this a missing exception subprocess?**
+   - Yes → `high`. Add an exception subprocess that at minimum: (a) logs the error context, (b) sends a failure notification or writes to an error queue, (c) does not silently swallow the exception.
+   - No → continue.
+
+4. **Is this a missing idempotency control on a retry-capable iFlow?**
+   - Yes → `high`. Add an Idempotent Process Call step using the message's SAP-MessageId or a business key. Configure the idempotency repository (in-memory or persistence store depending on the retry window).
+   - No → continue.
+
+5. **Is this a governance or observability gap?**
+   - Yes → `medium`. Implement correlation ID header propagation (map SAP-MessageId at iFlow entry), configure Cloud Integration alert rules for FAILED status, or isolate Event Mesh service keys per consumer application.
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — iFlow export bundles, API proxy descriptors, Event Mesh config exports, or user descriptions.
+2. **Classify each finding** by component domain and finding class.
+3. **Assign risk level** (critical / high / medium / low).
+4. **Apply remediation decision tree** per finding.
+5. **Prioritize** — critical security findings first; then high operational reliability findings; then medium governance gaps; then low best-practice items.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Component domain and specific finding class
+2. Evidence label (documentation-based / user-provided evidence / context7-supplementary / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended remediation action with specific implementation guidance
+5. Integration posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live Integration Suite tenant access is required to confirm or apply the finding

package/skills/sap/sap-joule-governance-adoption-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: sap-joule-governance-adoption-review
+description: Review SAP Joule generative AI copilot governance and adoption risk: scope grounding and boundary configuration, data access boundaries per business role, prompt and response auditability, role-aware answer configuration, hallucination and over-trust risk, and change management and adoption readiness. Does not access live Joule sessions or production data.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: ai
+  lifecycle: experimental
+---
+
+# SAP Joule Governance and Adoption Review
+
+## Purpose
+
+Assess the governance posture and adoption risk of SAP Joule, the generative AI copilot embedded across SAP S/4HANA Cloud, SAP SuccessFactors, SAP Ariba, SAP BTP, and other SAP solutions. Review Joule scope grounding and boundary configuration: whether Joule's skill and action scope is restricted to approved business processes, whether unapproved or overly broad skill activations exist, and whether the grounding sources for Joule responses are controlled and classified. Assess data access boundaries per business role: whether Joule respects the underlying SAP role and authorization model when surfacing data, whether it can expose data beyond what the user is authorized to see in the underlying application, and whether cross-application data access via Joule is governed. Review prompt and response auditability: whether Joule interactions are logged, whether log access is role-restricted, and whether logs provide sufficient audit trail for compliance. Assess role-aware answer configuration: whether Joule delivers contextually appropriate answers based on the user's business role and whether misconfigured role context can cause over-disclosure of business data. Evaluate hallucination and over-trust risk: whether users are trained to validate Joule outputs, whether Joule is used in decision flows that require human verification, and whether outputs for regulated processes carry appropriate disclaimers. Review change management and adoption readiness: governance policies for Joule rollout, user training coverage, acceptable-use policy existence, and feedback and monitoring mechanisms. Does not access live Joule sessions, execute Joule skills, or process production business data.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review Joule skill activation scope: which Joule skills and actions have been enabled for each connected SAP solution, whether skill scope aligns with approved business processes, and whether any enabled skills allow write-back or state-mutation actions without an additional confirmation step,
+- assess Joule data access boundary governance: whether Joule enforces the underlying SAP authorization model (S/4HANA authorization objects, SuccessFactors RBP, Ariba permission groups) when responding to data queries, and whether cross-application Joule capabilities expose data across systems beyond what the user is authorized to see in each system individually,
+- evaluate Joule prompt and response audit log configuration: whether Joule interaction logs are enabled, where logs are stored, what data is captured (prompt text, response text, user context, timestamp, session ID), who can access logs, and whether log retention meets the organization's audit and compliance requirements,
+- review role-aware Joule answer configuration: whether Joule's context-setting for business role is correctly configured for each connected SAP solution, whether role misconfiguration can cause over-disclosure of sensitive business data (financial positions, headcount data, procurement prices), and whether role-aware configuration has been tested,
+- assess hallucination and over-trust risk: whether Joule is used in decision flows (financial approvals, procurement decisions, hiring recommendations) without a human verification step, whether Joule outputs are presented with source attribution or confidence indicators, whether users are aware that Joule outputs require validation before actioning, and whether regulated workflows (financial close, legal, HR) have explicit policies on Joule output use,
+- review change management and adoption readiness: whether an acceptable-use policy exists for Joule, whether user training covers Joule output validation, whether a rollout governance process defines which Joule capabilities are approved for which user populations, and whether a feedback and monitoring mechanism is in place to detect misuse or over-reliance,
+- assess Joule integration with BTP AI services: whether Joule's underlying AI foundation model access is governed per the SAP AI Core resource group model, and whether Joule's grounding pipeline respects data classification and residency requirements.
+
+## When not to use
+
+- When the request requires accessing a live Joule session, executing Joule skills in a connected SAP system, or reviewing actual Joule interaction logs — this skill reviews configuration documentation, governance policies, training materials, and written descriptions only.
+- When the request is about SAP AI Core or Generative AI Hub governance for custom AI pipelines built by the organization rather than the Joule copilot product — use `sap-ai-core-generative-ai-hub-governance`.
+- When the request is about the underlying SAP S/4HANA or SuccessFactors authorization model in isolation, not in the context of Joule data access boundaries — use `sap-security-iam-grc-sod-review` or `sap-successfactors-hr-process-risk-review`.
+- When the request is about BTP account-level governance unrelated to Joule capability activation — use `sap-btp-governance-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided Joule configuration documentation, skill activation lists, data access boundary descriptions, audit log configuration summaries, acceptable-use policy documents, training material descriptions, and written governance posture descriptions. It does not access any live Joule session, execute Joule skills, query Joule interaction logs, or connect to any underlying SAP system (S/4HANA, SuccessFactors, Ariba, BTP). All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify governance findings by domain before recommending. Every finding must be assigned to a governance domain (Scope Grounding / Data Access Boundary / Auditability / Role-Aware Configuration / Hallucination and Over-Trust Risk / Change Management) before remediation is proposed.
+- Write-back and mutation skills require explicit confirmation steps. Any Joule skill or action that can create, update, or delete records in an underlying SAP system (purchase orders, employee data, financial postings) without an explicit user confirmation step is a `high` governance finding. Automated mutation without confirmation creates audit trail gaps and irreversible state changes.
+- Joule must not bypass the underlying authorization model. If Joule can surface data that the user is not authorized to see in the underlying SAP application, this is a `critical` data access boundary finding. Joule's responses must be constrained by the user's authorization context in the connected system.
+- Cross-application data access requires explicit governance. Joule capabilities that aggregate data across multiple connected SAP systems (e.g., surfacing both HR and Finance data in a single response) must be explicitly authorized per the user's cross-system access rights. Unreviewed cross-application data aggregation is a `high` finding.
+- Audit logging of Joule interactions is required for compliance-sensitive deployments. Deployments of Joule in regulated business processes (financial close, HR decisions, procurement approvals) without Joule interaction logging are a `high` auditability finding.
+- Hallucination risk in regulated workflows requires compensating controls. Joule use in financial, legal, or HR decision workflows without documented human verification requirements and an acceptable-use policy is a `high` over-trust risk finding.
+- Acceptable-use policy is a prerequisite for production rollout. Deploying Joule to end users without a documented acceptable-use policy covering output validation, prohibited uses, and escalation paths is a `medium` change management finding.
+- Evidence from official SAP Joule documentation, SAP BTP Trust Center, or user-provided governance artifacts takes precedence over inference.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in official SAP Joule, SAP BTP, or SAP AI documentation (help.sap.com or SAP Trust Center)
+- `user-provided evidence` — Joule configuration documentation, skill activation lists, data access boundary descriptions, audit log configuration summaries, acceptable-use policy documents, or written governance posture descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no Joule session access, Joule skill execution, Joule interaction log query, or connection to any underlying SAP system (S/4HANA, SuccessFactors, Ariba, BTP) in this skill's execution path. Users must supply configuration documentation, governance policy descriptions, or written assessments of the Joule deployment for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — Joule governance domain taxonomy, risk classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common Joule governance mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Joule product documentation, SAP BTP AI governance, and SAP Trust Center references.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: governance domain(s) in scope (Scope Grounding / Data Access Boundary / Auditability / Role-Aware Configuration / Hallucination and Over-Trust Risk / Change Management) and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (Joule bypasses underlying authorization, confirmed data boundary breach) / high (write-back without confirmation, cross-application unreviewed aggregation, no audit log for regulated workflow, over-trust in regulated decision flow) / medium (missing acceptable-use policy, untested role-aware configuration, no feedback mechanism) / low (best practice deviation in adoption materials or monitoring).
+- **Recommended action**: specific governance control per finding (restrict skill scope, enforce confirmation step for mutation actions, enable interaction logging, define role-aware context configuration, implement human verification requirement for regulated workflows, create acceptable-use policy, etc.).
+- **Refusal / escalation triggers**: if live Joule session access, interaction log review, or skill execution is required to complete the governance assessment, state that clearly and do not proceed. If a data access boundary breach is confirmed, escalate to the security and data protection team before continuing.
+- **Business impact**: regulatory exposure (GDPR, SOX, local data protection), audit trail gap, financial or HR decision error risk from hallucinated outputs, reputational risk from misuse of AI-generated content.
+- **Next verification step**: validate governance control recommendations against current SAP Joule configuration documentation and the organization's AI governance policy before deploying changes to the Joule rollout.

package/skills/sap/sap-joule-governance-adoption-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Joule Governance and Adoption Review"
+  short_description: "Review SAP Joule generative AI copilot governance and adoption risk: scope grounding, data access boundaries, prompt and response auditability, role-aware configuration, hallucination and over-trust risk, and change management readiness."
+  default_prompt: "Use $sap-joule-governance-adoption-review to assess the provided SAP Joule governance artifacts. Classify findings by governance domain (Scope Grounding / Data Access Boundary / Auditability / Role-Aware Configuration / Hallucination and Over-Trust Risk / Change Management), assign a risk level (critical/high/medium/low), state evidence level (documentation-based / user-provided evidence / inference), and recommend specific governance controls per finding. Do not access live Joule sessions, execute Joule skills, or accept actual Joule interaction logs or production business data."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/joule/serviceguide/security"
+      description: "SAP Joule security guide — primary reference for Joule data access boundary governance, authorization model integration, and audit log configuration"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-joule-governance-adoption-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-joule-governance-adoption-review",
+  "name": "SAP Joule Governance and Adoption Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Joule generative AI copilot governance and adoption risk: scope grounding and boundary configuration, data access boundaries per business role, prompt and response auditability, role-aware answer configuration, hallucination and over-trust risk, and change management and adoption readiness. Does not access live Joule sessions or production data.",
+  "source_type": "original",
+  "category": "ai",
+  "official_docs": [
+    "https://help.sap.com/docs/joule/serviceguide/what-is-joule",
+    "https://help.sap.com/docs/joule/serviceguide/joule-capabilities",
+    "https://help.sap.com/docs/joule/serviceguide/security",
+    "https://help.sap.com/docs/joule/serviceguide/data-protection-and-privacy",
+    "https://help.sap.com/docs/joule/serviceguide/administration",
+    "https://help.sap.com/docs/joule/serviceguide/roles-and-authorizations",
+    "https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/security-and-data-protection",
+    "https://www.sap.com/about/trust-center/ai.html"
+  ],
+  "security_notes": "Does not access live SAP Joule sessions, execute Joule skills, query Joule interaction logs, or connect to any underlying SAP system (S/4HANA, SuccessFactors, Ariba, BTP). Accepts only Joule configuration documentation, skill activation lists, data access boundary descriptions, audit log configuration summaries, acceptable-use policy documents, or written governance posture descriptions. Never accept actual Joule interaction logs, production business data surfaced by Joule, user prompt history, or SAP system credentials. If a confirmed Joule data access boundary breach is found, escalate to the security and data protection team before continuing.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-joule-governance-adoption-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-joule-governance-adoption-review/references/official-sources.md

@@ -0,0 +1,83 @@
+# Official sources — SAP Joule Governance and Adoption Review
+
+Use this reference when grounding Joule scope grounding assessment, data access boundary review, audit log configuration evaluation, role-aware answer assessment, hallucination and over-trust risk evaluation, and change management readiness review.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Joule service guide, SAP Trust Center). No live-system evidence is collected by this skill.
+
+## SAP Joule — Product Overview
+
+- What is Joule
+  https://help.sap.com/docs/joule/serviceguide/what-is-joule
+  source_owner: SAP SE
+  topic_supported: Joule copilot product overview, supported SAP solution integrations (S/4HANA Cloud, SuccessFactors, Ariba, BTP), skill and action model, natural language interaction model
+  why_needed: Primary reference for Joule scope and capability model — defines which SAP solutions Joule connects to, what skill types exist (query, action, navigation), and the foundational product boundaries used to assess scope grounding findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Joule Capabilities
+  https://help.sap.com/docs/joule/serviceguide/joule-capabilities
+  source_owner: SAP SE
+  topic_supported: Joule skill catalog per connected SAP solution, capability activation model, action types (read-only versus write-back), cross-application capability scope
+  why_needed: Required to assess skill activation scope — defines which capabilities are available per SAP solution and which capabilities include write-back or state-mutation actions that require explicit governance controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Joule — Security and Data Access
+
+- Joule Security
+  https://help.sap.com/docs/joule/serviceguide/security
+  source_owner: SAP SE
+  topic_supported: Joule authorization model, data access boundary enforcement, integration with underlying SAP system authorization (S/4HANA objects, SuccessFactors RBP), session security, audit logging configuration
+  why_needed: Primary reference for Joule data access boundary governance — defines how Joule enforces the underlying SAP authorization model and what audit logging capabilities are available
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Joule Data Protection and Privacy
+  https://help.sap.com/docs/joule/serviceguide/data-protection-and-privacy
+  source_owner: SAP SE
+  topic_supported: Data residency for Joule interaction data, prompt and response data handling, cross-border transfer controls for Joule interaction logs, personal data processed by Joule
+  why_needed: Required to assess data privacy compliance for Joule interaction logging — defines where Joule interaction data is stored, what personal data may be included in prompts or responses, and data residency constraints
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Joule — Administration and Roles
+
+- Joule Administration
+  https://help.sap.com/docs/joule/serviceguide/administration
+  source_owner: SAP SE
+  topic_supported: Joule tenant configuration, skill and capability activation, connected system registration, rollout scope configuration, administrator responsibilities
+  why_needed: Required to assess Joule capability activation governance — defines the administrative model for controlling which skills are activated, which connected systems are in scope, and which user populations have access to Joule
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Joule Roles and Authorizations
+  https://help.sap.com/docs/joule/serviceguide/roles-and-authorizations
+  source_owner: SAP SE
+  topic_supported: BTP role collections required for Joule access, role-aware context configuration per SAP solution, administrator versus end-user role separation
+  why_needed: Defines the BTP role model for Joule access and role-aware answer context — required to assess whether role-aware configuration is correctly set up and whether role misconfiguration can cause over-disclosure of business data
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP AI Core — Security (Joule foundation)
+
+- SAP AI Core Security and Data Protection
+  https://help.sap.com/docs/sap-ai-core/sap-ai-core-service-guide/security-and-data-protection
+  source_owner: SAP SE
+  topic_supported: AI Core resource group isolation, data residency, security controls for AI model inference underlying Joule, data protection for AI-generated content
+  why_needed: Joule is built on SAP AI Core infrastructure. This reference is required to assess the governance of Joule's underlying AI model access, resource group isolation, and data residency compliance at the AI infrastructure layer
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Trust Center — AI Ethics and Responsible Use
+
+- SAP AI Trust Center
+  https://www.sap.com/about/trust-center/ai.html
+  source_owner: SAP SE
+  topic_supported: SAP AI ethics principles, responsible AI framework, human oversight requirements, AI use policy guidance for SAP AI-powered products including Joule
+  why_needed: Reference for assessing Joule adoption governance against SAP's responsible AI framework — defines SAP's stated human oversight requirements and AI ethics principles, which inform acceptable-use policy and over-trust risk assessment
+  evidence_level: supplementary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal documentation and the SAP Trust Center describe the designed Joule capability model, authorization integration, data protection framework, and responsible AI principles. They do not prove which Joule skills are currently activated in the user's tenant, whether role-aware configuration is correctly implemented, or whether an acceptable-use policy has been adopted. Users must supply Joule configuration documentation, skill activation lists, data access boundary descriptions, audit log configuration summaries, acceptable-use policy documents, or written governance posture descriptions for concrete assessment.

package/skills/sap/sap-joule-governance-adoption-review/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist — SAP Joule Governance and Adoption Review
+
+Use before making any Joule governance finding or remediation recommendation, especially for findings involving data access boundaries, write-back capabilities, audit logging, or regulated workflow use.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP Joule session, Joule interaction log store, connected SAP system (S/4HANA, SuccessFactors, Ariba, BTP), or Joule administration console. This skill reviews governance artifacts only.
+- Do not accept or process actual Joule interaction logs, user prompt history, AI-generated response content from production Joule sessions, or production business data surfaced by Joule (financial figures, employee data, procurement prices).
+- Do not accept SAP system credentials, BTP service keys, OAuth tokens, or Joule integration certificates.
+- Do not recommend enabling additional Joule write-back skills without first confirming that a user confirmation step is in place and that the skill activation has been through the organization's rollout governance process.
+- Do not recommend disabling Joule interaction logging as a performance or privacy optimization in a deployment used for regulated business processes.
+- Do not validate the Joule authorization boundary from memory alone. Joule's enforcement of the underlying SAP authorization model is configuration-dependent. Direct the user to verify the current authorization boundary behavior against SAP Joule security documentation and sandbox testing before production deployment.
+- Do not assess hallucination risk by generating or evaluating actual Joule responses. Hallucination and over-trust risk assessment is based on governance policy coverage, verification requirements, and training documentation — not on testing the model.
+
+## What people get wrong
+
+- **Assuming Joule inherits authorizations automatically**: Joule's integration with the underlying SAP authorization model (S/4HANA authorization objects, SuccessFactors RBP) requires correct configuration at the connected system level. Joule does not automatically enforce the narrowest possible authorization boundary — misconfigured connections can expose broader data than the user is authorized to see in the native UI.
+- **Treating Joule read capabilities as risk-free**: Even read-only Joule skills can expose sensitive business data (compensation data from SuccessFactors, financial positions from S/4HANA, supplier prices from Ariba) if role-aware configuration is incorrect or if cross-application aggregation is not governed. Read-only does not mean governance-free.
+- **Overlooking cross-application data aggregation risk**: Joule can surface data from multiple connected SAP solutions in a single response. A user who is authorized to see a subset of data in each system individually may see an unauthorized combined view when Joule aggregates across systems. Cross-application scope requires explicit cross-system access rights governance.
+- **Confusing Joule interaction logging with SAP system audit logs**: Joule interaction logging (capturing prompts and responses in Joule) is separate from the audit logs in the underlying SAP systems (S/4HANA change documents, SuccessFactors audit trail, Ariba audit log). Both are needed for a complete compliance audit trail. Missing Joule interaction logs means there is no record of what the user asked or what Joule responded, even if the underlying system recorded the data access.
+- **Assuming acceptable-use policy covers AI outputs automatically**: Most organizational IT or data policies do not address generative AI output validation, prohibited uses of AI-generated content in regulated decisions, or escalation paths when Joule produces incorrect or harmful responses. An AI-specific acceptable-use policy for Joule is a separate governance requirement.
+- **Treating Joule rollout as a one-time event**: SAP Joule capabilities expand with each SAP solution release. New skills and action types may be automatically available in connected systems after a product update. Without a rollout governance process for new capability activation, the organization's approved Joule scope can expand without review.
+
+## When to push back
+
+- Push back immediately if a confirmed Joule data access boundary breach is identified — suspend the affected capability and escalate to the security and data protection team before any other recommendation is made.
+- Push back when the user requests assessment of actual Joule interaction logs or production AI-generated response content — request anonymized or aggregated governance summaries instead.
+- Push back when the user proposes to enable a Joule write-back skill without a confirmation step and without a rollout governance review.
+- Push back when the user proposes to disable Joule interaction logging in a regulated business process deployment.
+- Push back when the request requires live Joule session access, Joule skill execution, or connected SAP system inspection — state that live inspection is out of scope and ask the user to supply the relevant configuration documentation.
+- Push back when the user asks to confirm that Joule's authorization boundary is correctly enforced based on this advisory review alone — require sandbox testing against the current SAP Joule security documentation before production sign-off.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP Joule service guide, SAP BTP documentation, SAP AI Core documentation, or SAP Trust Center AI guidance (help.sap.com or sap.com/trust-center)
+- `user-provided evidence` — Joule configuration documentation, skill activation lists, data access boundary descriptions, audit log configuration summaries, acceptable-use policy documents, or written governance posture descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such