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

package/skills/sap/sap-audit-evidence-packaging/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist — SAP Audit Evidence Packaging
+
+Use before making any evidence packaging recommendation or including any excerpt from user-provided artifacts in output.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system, GRC Access Control instance, BTP subaccount, ABAP system, audit log service, or S/4HANA tenant. This skill advises on packaging only.
+- Do not accept or request SAP system credentials, BTP service keys, GRC logon passwords, OAuth tokens, SAML private keys, or connection strings with embedded credentials.
+- Do not include in any output: passwords, API keys, OAuth tokens, client secrets, SAML private keys, employee personal identifiable information (names, national IDs, salary data), or customer confidential data — even if the user provides them in an evidence artifact.
+- If a user-provided artifact contains sensitive data, advise on redaction before including any excerpt. Never echo sensitive values back in the response.
+- Do not declare a control as compliant or an evidence package as audit-ready. This skill assesses completeness and packaging quality; compliance declarations must be made by qualified auditors.
+- Do not produce evidence artifacts on behalf of the user. This skill advises on what to collect, how to label it, and how to structure it; it does not generate evidence that did not exist from a real SAP system.
+- Do not classify evidence as sufficient based solely on the existence of an artifact type — the artifact must also cover the full audit period and be accompanied by valid chain-of-custody metadata.
+
+## What people get wrong
+
+- **Treating a GRC SoD report screenshot as complete evidence**: A screenshot of a GRC SoD conflict report is not sufficient without the underlying report export (CSV, PDF, or XLS with full conflict detail), chain-of-custody metadata (extraction date, system, extractor role), and confirmation of the audit period covered.
+- **Overlooking the audit period gap**: Evidence that covers 9 months of a 12-month audit period is a `high` gap, not a `medium` one. The full audit period must be covered without interruption.
+- **Assuming access review completion equals evidence**: A completed access review workflow in GRC or a ticketing system is evidence of the review process, not evidence of the role assignment state. Both the review completion record and the role assignment export at that point in time are required.
+- **Including live personal data in evidence packages**: GRC SoD reports, SUIM user-role exports, and IAS user lists often contain employee names, email addresses, and employee IDs. These must be redacted or pseudonymized per applicable data protection requirements before submission to an external auditor.
+- **Missing chain-of-custody for evidence gathered outside GRC**: Evidence gathered via BTP CLI, CF CLI, or ABAP transaction exports is often not automatically stamped with a timestamp or extractor identity. The chain-of-custody metadata must be manually documented at the time of extraction.
+- **Treating non-reproducible evidence as low risk**: If an evidence artifact cannot be regenerated from the same source (e.g., an ABAP SM20 audit log from a period that has since been archived or overwritten), it must be stored with heightened custody controls and its non-reproducibility documented explicitly.
+- **Assuming a transport log is sufficient change management evidence alone**: A transport log demonstrates that transports moved; it does not demonstrate that the approval chain was followed. Approval records (workflow completion, second-pair-of-eyes sign-off) are a separate required artifact.
+
+## When to push back
+
+- Push back when the user asks to generate evidence that does not exist from a real SAP system (e.g., to fabricate a GRC report or produce a synthetic role assignment export).
+- Push back when the user asks to include credentials, personal identifiable information, or customer data in an evidence package without redaction.
+- Push back when the user asks to declare a control compliant or an audit package ready — direct to the qualified auditor or control owner for the compliance declaration.
+- Push back when the user asks to extract live evidence from a SAP system — redirect to `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for the evidence gathering step.
+- Push back when the audit scope is ambiguous (audit period not defined, control framework not stated, SAP systems in scope not identified) — request clarification before advising on evidence mapping.
+- Push back when the user provides an evidence artifact and asks whether it satisfies a regulatory requirement without specifying which regulatory framework or which specific control requirement is being addressed.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP GRC documentation, SAP audit guides, or regulatory framework requirements (SOC 2, ISO 27001, SOX ITGC, GxP)
+- `user-provided evidence` — audit evidence artifacts, control descriptions, audit scope descriptions, or written SAP landscape descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-audit-evidence-packaging/references/workflow-and-output.md

@@ -0,0 +1,129 @@
+# Workflow and output contract — SAP Audit Evidence Packaging
+
+Use this reference for evidence taxonomy, control-to-evidence mapping structure, chain-of-custody format, and output formatting.
+
+## Evidence taxonomy
+
+SAP audit evidence is classified by control domain and artifact type:
+
+### Control domains
+
+| Domain | Description |
+|--------|-------------|
+| `SoD` | Segregation of Duties — evidence that incompatible functions are not held by the same user |
+| `Access Management` | User provisioning, deprovisioning, access review, role assignment, and privileged access controls |
+| `Change Management` | Transport request lifecycle, approval chains, emergency change controls, and change freeze enforcement |
+| `Financial Controls` | Posting authorization, period-end close controls, journal entry approval, and reconciliation evidence |
+| `System Configuration` | SAP system parameter settings, security profile settings, audit log configuration, and baseline configuration |
+
+### Artifact types
+
+| Artifact type | Description | Typical source |
+|---------------|-------------|---------------|
+| `GRC SoD report` | Machine-generated SoD conflict report from GRC Access Control or equivalent | SAP GRC Access Control NWBC report / Pathlock / Fastpath |
+| `Role assignment export` | Export of user-to-role or user-to-role-collection assignments at a point in time | BTP CLI, SUIM transaction, GRC Access Control, IAS export |
+| `Transport log` | Log of transport request creation, release, import approvals, and execution timestamps | STMS transaction export, CTS+ log, Cloud ALM transport log |
+| `Access review report` | Periodic access review completion record showing reviewer, outcome, and date | GRC Access Control recertification report, manual review record |
+| `Audit log extract` | System audit log entries demonstrating monitoring is active and events are captured | SM19/SM20 ABAP audit log export, BTP audit log service export |
+| `Security parameter screenshot or export` | System parameter values (login/fails_to_user_lock, auth/rfc_authority_check, etc.) | RZ11 transaction export, parameter configuration export |
+| `Approval record` | Documented approval of a specific action (emergency access, transport import, user creation) | Workflow completion record, ServiceNow ticket, email chain with timestamp |
+| `Period-end evidence` | Evidence that period-end close procedures were executed and controls operated | Financial posting report, period-lock screenshot, reconciliation sign-off |
+
+## Control-to-evidence mapping structure
+
+For each control, document:
+
+```
+Control ID:        <control reference from audit framework, e.g., SOX ITGC CC-01>
+Control objective: <what the control is designed to prevent or detect>
+Domain:            <SoD | Access Management | Change Management | Financial Controls | System Configuration>
+Framework refs:    <SOC 2 CC6.1 | ISO 27001 A.9.2 | SOX ITGC | GxP Annex 11 clause X>
+Required artifacts:
+  - <artifact type 1>: <what exactly to collect; time window; format>
+  - <artifact type 2>: <what exactly to collect; time window; format>
+Chain-of-custody:
+  - Source system: <SAP SID or BTP subaccount or GRC tenant>
+  - Extraction method: <transaction/CLI command/API/manual export>
+  - Extraction timestamp: <ISO 8601>
+  - Extracted by: <role/person (no personal names in the mapping template)>
+  - Transformations: <redactions applied; format conversions>
+Completeness status: <sufficient | partial | missing>
+Gap description:   <if partial or missing — what is absent and why>
+```
+
+## Chain-of-custody format
+
+Every live evidence artifact included in an audit package must carry:
+
+```
+[CHAIN_OF_CUSTODY]
+Artifact name:        <descriptive name, e.g., "SoD_Report_FI_2026Q1.xlsx">
+Control ID(s):        <comma-separated control IDs this artifact supports>
+Domain:               <SoD | Access Management | Change Management | Financial Controls | System Configuration>
+Source system:        <SAP SID, BTP subaccount ID, or GRC tenant identifier>
+Extraction method:    <GRC NWBC report / SUIM export / btp CLI / SM20 export / CloudALM API>
+Extraction timestamp: <ISO 8601>
+Extracted by role:    <GRC viewer / BTP subaccount viewer / ABAP display user>
+Audit period covered: <start date ISO 8601> to <end date ISO 8601>
+Redactions applied:   <yes/no — list what was redacted>
+Reproducible:         <yes | no | partial — explanation>
+Storage location:     <placeholder — do not include actual system paths with credentials>
+Hash (SHA-256):       <file hash for tamper evidence — populate after file is finalized>
+```
+
+## Redaction requirements before packaging
+
+The following must be redacted from all evidence artifacts before inclusion in an audit package:
+
+| Data category | Redaction action |
+|--------------|-----------------|
+| SAP system password, client secret, API key | Replace value with `[REDACTED:CREDENTIAL]` |
+| Employee personal name | Replace with employee ID only, or `[REDACTED:PII_NAME]` if employee ID is also not permitted |
+| National identification number or social security number | Replace with `[REDACTED:PII_NID]` |
+| Salary or compensation data | Replace with `[REDACTED:PII_SALARY]` |
+| Customer name or customer personal data | Replace with `[REDACTED:CUSTOMER_PII]` |
+| SAML signing certificate private key | Replace with `[REDACTED:SAML_PRIVATE_KEY]` |
+| Connection string with embedded credentials | Replace with `[REDACTED:CONN_STRING]` |
+
+After redaction, document what was redacted in the chain-of-custody `Redactions applied` field.
+
+## Severity classification for evidence gaps
+
+| Severity | Meaning | Examples |
+|----------|---------|---------|
+| `critical` | Control has no supporting evidence; gap cannot be closed before audit deadline | No SoD report extracted for the audit period; no transport approval records for the change management control |
+| `high` | Evidence is partial; does not cover full audit period or key evidence artifact is missing | SoD report covers only part of the audit period; access review records missing for one system in scope |
+| `medium` | Evidence is present but chain-of-custody is incomplete or redaction has not been applied | Evidence artifact lacks extraction timestamp or extracted-by role; personal data not yet redacted |
+| `low` | Minor metadata gap or reproducibility risk only | File hash not yet calculated; storage location not yet documented in chain-of-custody |
+
+## Framework alignment matrix
+
+| Control domain | SOC 2 Trust Service Criteria | ISO 27001 Annex A | SOX ITGC | GxP (21 CFR Part 11 / EU Annex 11) |
+|---------------|------------------------------|-------------------|----------|-------------------------------------|
+| SoD | CC6.3, CC6.6 | A.9.2.3, A.9.4.1 | Access to Programs and Data | Annex 11 clause 12 (audit trail), clause 7 (access control) |
+| Access Management | CC6.1, CC6.2, CC6.3 | A.9.2.1, A.9.2.2, A.9.2.6 | Logical Access | Annex 11 clause 7 |
+| Change Management | CC8.1 | A.14.2.2, A.14.2.4 | Program Change | Annex 11 clause 10 |
+| Financial Controls | CC4.1 (monitoring) | A.12.4.1 (logging) | Financial Reporting ITGC | N/A (GxP is process-industry focused) |
+| System Configuration | CC6.6, CC7.1 | A.12.1.2, A.14.1.1 | Operations | Annex 11 clause 4 (validation), clause 11 (data storage) |
+
+## Workflow
+
+1. **Receive scope** — audit scope description, control list, or evidence request from user.
+2. **Classify each control** by domain (SoD / Access Management / Change Management / Financial Controls / System Configuration).
+3. **Map to required artifacts** — define the specific artifact types needed per control.
+4. **Assess completeness** — review user-provided artifacts for sufficiency, period coverage, and chain-of-custody completeness.
+5. **Flag gaps** — classify gaps by severity (critical / high / medium / low).
+6. **Apply redaction checks** — identify any sensitive data requiring redaction.
+7. **Align to frameworks** — map each control to specific SOC 2, ISO 27001, SOX ITGC, or GxP requirements.
+8. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Audit scope summary (control domains in scope, audit period, frameworks applicable)
+2. Control-to-evidence mapping for each control in scope (required artifacts, chain-of-custody requirements, framework mapping)
+3. Completeness assessment per control (sufficient / partial / missing) with gap severity and description
+4. Redaction advisory (which artifacts require redaction and what to redact)
+5. Reproducibility assessment per artifact type
+6. Escalation trigger if live SAP system access is required to gather missing evidence (with pointer to the appropriate live discovery skill)

package/skills/sap/sap-btp-governance-review/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: sap-btp-governance-review
+description: Review SAP BTP account model governance: global account, directories, subaccounts, entitlements, quotas, environments (Cloud Foundry, Kyma), role collections, and trust configuration. Flags entitlement sprawl, over-provisioning, missing guardrails, and trust misconfiguration. Does not touch live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: platform
+  lifecycle: experimental
+---
+
+# SAP BTP Governance Review
+
+## Purpose
+
+Assess the governance posture of an SAP Business Technology Platform (BTP) account model. Evaluate the structural soundness of the global account hierarchy, directory layout, subaccount design, entitlement and quota allocation, environment provisioning (Cloud Foundry, Kyma, multi-environment), role collection design, trust configuration, and platform access controls. Surface entitlement sprawl, over-provisioning risks, missing administrative guardrails, and identity trust misconfigurations. Does not connect to or mutate any live BTP system.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review or audit the BTP global account structure, directory hierarchy, or subaccount layout for governance compliance,
+- assess entitlement and quota allocations across directories and subaccounts for sprawl or over-provisioning,
+- evaluate Cloud Foundry org/space design or Kyma cluster provisioning decisions against BTP governance best practices,
+- review role collection assignments, platform user access, and identity provider trust configuration for a BTP account,
+- flag missing administrative guardrails such as absent emergency access procedures, unreviewed trust configurations, or uncontrolled quota consumption,
+- plan a BTP landing zone or account model for a new project or migration,
+- evaluate BTP entitlement management practices against the principle of least privilege.
+
+## When not to use
+
+- When the user needs live inspection of a BTP cockpit, running service instances, or deployed applications — this skill accepts only user-provided descriptions, exports, or architecture documents.
+- When the request concerns application-level security within a service deployed on BTP — use `sap-security-iam-grc-sod-review` for identity and access management within services.
+- When the request is specifically about SAP Integration Suite topology — use `sap-integration-suite-review`.
+- When the request is about ABAP extensibility or clean core — use `sap-clean-core-debt-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided descriptions, architecture diagrams, exported account structure documents, BTP cockpit screenshots, or configuration summaries. It does not connect to the BTP cockpit, issue BTP REST APIs, invoke the SAP BTP CLI, read from any BTP global account, or access Cloud Foundry or Kyma APIs. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify governance issues before recommending. Every finding must be classified by governance domain (account structure, entitlements, environments, roles, trust) before remediation is proposed.
+- Apply least-privilege to entitlements. Entitlements should be assigned at the lowest scope that satisfies the business need — global-account-level entitlements are not automatically correct.
+- Directories are optional but powerful. BTP directories can carry entitlements, role collections, and managed subaccount lifecycle; the absence of a directory structure in a large BTP estate is itself a governance risk.
+- Subaccounts are the isolation boundary. Each subaccount has its own environment instances, trust configurations, and service bindings. Cross-subaccount blast radius is a key risk dimension.
+- Role collections must be mapped to identity provider groups. Direct user assignments to role collections (instead of IdP group mappings) are an operational risk — they bypass centralized access lifecycle management.
+- Cloud Foundry quotas are separate from BTP entitlements. CF org and space quotas must be reviewed alongside BTP-level entitlements to identify over-provisioning.
+- Trust to external IdPs requires explicit review. Every trust configuration (to SAP Identity Authentication Service, Azure AD, Okta, etc.) that allows login to BTP subaccounts is a governance boundary. Unused or unconfigured default trusts are risk vectors.
+- Evidence from user-provided artifacts or official SAP BTP documentation takes precedence over inference.
+- Load only the reference needed for the component under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP BTP Help Portal documentation, BTP account model guides, or official SAP entitlement docs
+- `user-provided evidence` — BTP cockpit exports, architecture documents, screenshots, or configuration summaries provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no BTP API call, BTP CLI invocation, cockpit session, Cloud Foundry CLI command, or Kyma kubectl command in this skill's execution path. Users must supply account structure exports, role collection lists, entitlement summaries, or written descriptions of their BTP account model for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — governance classification taxonomy, finding severity, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP BTP account model, entitlements, environments, role collections, trust configuration docs.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: governance domain(s) affected (account structure / entitlements / environments / roles / trust) and specific finding(s).
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (security or compliance boundary violation) / high (operational risk, sprawl, or over-provisioning) / medium (governance gap) / low (best practice deviation).
+- **Recommended action**: specific governance remediation per finding (restructure, entitlement reduction, role collection clean-up, trust reconfiguration, or guardrail addition).
+- **Refusal / escalation triggers**: if live BTP cockpit access or BTP API calls are required to complete the review, state that clearly and do not proceed.
+- **Business impact**: data isolation risk, cost overrun, compliance gap, or operational incident blast radius.
+- **Next verification step**: confirm the recommended changes against the current BTP account model before applying.

package/skills/sap/sap-btp-governance-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP BTP Governance Review"
+  short_description: "Review SAP BTP account model governance: global account hierarchy, directories, subaccounts, entitlements, environments, role collections, and trust configuration. Flags sprawl, over-provisioning, and missing guardrails."
+  default_prompt: "Use $sap-btp-governance-review to assess the governance posture of the provided SAP BTP account model. Classify each finding by governance domain (account structure, entitlements, environments, role collections, trust), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. State evidence level and whether live system access is required to complete the review."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/btp/sap-business-technology-platform/account-model"
+      description: "SAP BTP account model documentation — primary reference for global account, directory, and subaccount hierarchy governance"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-btp-governance-review/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-btp-governance-review",
+  "name": "SAP BTP Governance Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP BTP account model governance: global account hierarchy, directories, subaccounts, entitlements, quotas, Cloud Foundry/Kyma environments, role collections, and trust configuration. Flags entitlement sprawl, over-provisioning, and missing guardrails. Does not access live systems.",
+  "source_type": "original",
+  "category": "platform",
+  "official_docs": [
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/account-model",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/directories",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/kyma-environment",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/cloud-foundry-environment",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/role-collections-and-roles-in-global-accounts-directories-and-subaccounts",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/trust-and-federation-with-identity-providers",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/platform-identity-provider",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/security-administration-managing-authentication-and-authorization"
+  ],
+  "security_notes": "Does not access live SAP BTP systems. Accepts only user-provided account structure exports, role collection lists, entitlement summaries, or written descriptions. Never request or accept BTP service keys, client secrets, OAuth tokens, global account administrator credentials, or subaccount-level platform access tokens. Governance recommendations must be validated against the live BTP account model before applying.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-btp-governance-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

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

@@ -0,0 +1,91 @@
+# Official sources — SAP BTP Governance Review
+
+Use this reference when grounding BTP account model governance, entitlement design, environment provisioning, role collection management, and trust configuration assessments.
+
+**Evidence level**: documentation-based (SAP BTP Help Portal). No live-system evidence is collected by this skill.
+
+## BTP account model and hierarchy
+
+- SAP BTP account model
+  https://help.sap.com/docs/btp/sap-business-technology-platform/account-model
+  source_owner: SAP SE
+  topic_supported: Global account, directory, and subaccount structure; account hierarchy concepts; isolation boundaries
+  why_needed: Primary taxonomy for classifying account structure governance findings and evaluating subaccount design decisions
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Directories
+  https://help.sap.com/docs/btp/sap-business-technology-platform/directories
+  source_owner: SAP SE
+  topic_supported: BTP directory creation, managed lifecycle, entitlement and role collection inheritance, directory-level governance controls
+  why_needed: Authoritative source for evaluating whether directory structure is used appropriately to enforce governance boundaries across subaccounts
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Entitlements and quotas
+
+- Entitlements and quotas
+  https://help.sap.com/docs/btp/sap-business-technology-platform/entitlements-and-quotas
+  source_owner: SAP SE
+  topic_supported: Service entitlements, quota distribution, assignment to directories and subaccounts, entitlement management lifecycle
+  why_needed: Defines the entitlement assignment model used to classify sprawl, over-provisioning, and least-privilege deviations
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Environments
+
+- Cloud Foundry environment
+  https://help.sap.com/docs/btp/sap-business-technology-platform/cloud-foundry-environment
+  source_owner: SAP SE
+  topic_supported: Cloud Foundry org/space structure, quota plans, environment-level service bindings and access controls
+  why_needed: Defines CF org/space governance model and quota separation — required to assess CF-level over-provisioning alongside BTP entitlements
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Kyma environment
+  https://help.sap.com/docs/btp/sap-business-technology-platform/kyma-environment
+  source_owner: SAP SE
+  topic_supported: Kyma cluster provisioning, module selection, service binding, Kyma operator model, namespace-level isolation
+  why_needed: Defines the Kyma governance model for BTP subaccount-level Kubernetes workloads — required when Kyma environments are in scope
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Role collections and access control
+
+- Role collections and roles in global accounts, directories, and subaccounts
+  https://help.sap.com/docs/btp/sap-business-technology-platform/role-collections-and-roles-in-global-accounts-directories-and-subaccounts
+  source_owner: SAP SE
+  topic_supported: Role collection structure, role assignment scope (global account / directory / subaccount), built-in vs. custom role collections
+  why_needed: Primary reference for classifying role collection governance findings including over-permissive assignments and direct user-to-role binding
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Security administration: managing authentication and authorization
+  https://help.sap.com/docs/btp/sap-business-technology-platform/security-administration-managing-authentication-and-authorization
+  source_owner: SAP SE
+  topic_supported: Platform-level authentication, authorization administration, role collection assignment via identity provider groups
+  why_needed: Defines best practice for IdP-group-based role collection assignment over direct user assignment — key for access lifecycle governance
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Trust and identity federation
+
+- Trust and federation with identity providers
+  https://help.sap.com/docs/btp/sap-business-technology-platform/trust-and-federation-with-identity-providers
+  source_owner: SAP SE
+  topic_supported: Subaccount-level trust configuration, SAML/OIDC federation, identity provider registration, attribute mapping
+  why_needed: Defines the trust configuration model — required to identify unused, misconfigured, or overly permissive trust configurations in BTP subaccounts
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Platform identity provider
+  https://help.sap.com/docs/btp/sap-business-technology-platform/platform-identity-provider
+  source_owner: SAP SE
+  topic_supported: Default platform identity provider (SAP ID Service), switching to a custom platform IdP, platform user lifecycle
+  why_needed: Defines the platform IdP model separate from application IdP — important for distinguishing platform-level vs. application-level trust risks
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP BTP Help Portal documentation describes the designed governance model and configuration options. It does not prove what entitlements, role collections, or trust configurations exist in the user's BTP global account, nor whether the account follows these guidelines. Users must supply account exports, role collection lists, entitlement summaries, or architectural descriptions for concrete governance assessment.

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

@@ -0,0 +1,35 @@
+# Safety checklist — SAP BTP Governance Review
+
+Use before making any governance recommendation, especially for findings that affect trust configuration, global account administration, or entitlement assignments with cost implications.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live BTP global account, subaccount, Cloud Foundry org, or Kyma cluster. This skill reviews artifacts only.
+- Do not accept or request BTP service keys, client secrets, OAuth tokens, platform user credentials, global account administrator passwords, or subaccount-level access tokens.
+- Do not recommend disabling or removing a trust configuration without first confirming (with the user) that no active users or applications depend on it. A wrong trust removal can immediately lock all users out of a subaccount.
+- Do not recommend reducing or removing entitlements without first confirming with the user which service instances are currently consuming that quota. Reducing quota below active consumption terminates running service instances.
+- Do not conflate BTP platform roles (global account, directory, subaccount admin) with application-level roles (XSUAA role collections for deployed applications). They are separate authorization hierarchies.
+- Do not recommend the default SAP ID Service trust as a long-term production identity strategy. Production BTP subaccounts should use a federated corporate IdP via SAP Identity Authentication Service.
+- Do not classify a finding as `critical` without being able to trace the specific unauthorized access path or compliance breach from user-provided evidence or documentation.
+
+## What people get wrong
+
+- **Conflating CF org quotas with BTP entitlements**: Cloud Foundry org-level memory/service instance quotas are set separately from BTP service entitlements. Both must be reviewed independently; reducing BTP entitlements does not automatically reduce CF org quota consumption.
+- **Treating directory entitlements as automatic subaccount distribution**: Entitlements assigned at directory level are not automatically available to subaccounts — they still require explicit assignment. Unused directory-level entitlements are still a sprawl risk.
+- **Assuming all Kyma modules are billed**: Kyma module enablement policy varies by BTP contract type. Never make cost-impact assertions without confirming the user's BTP commercial model.
+- **Recommending IdP group mapping without confirming the IdP group structure exists**: Role collection assignment via IdP groups only works if the identity provider is configured to assert the correct group attribute and the group exists. Recommending this without confirming IdP group readiness creates an access lockout risk.
+- **Missing the default trust risk**: Every new BTP subaccount has SAP ID Service trust enabled by default. In production subaccounts where a corporate IdP is in use, the default SAP ID Service trust should be reviewed — leaving it enabled allows any SAP ID Service user to attempt authentication.
+- **Ignoring emergency access procedures**: Every BTP global account should have a documented emergency access path (emergency admin user not dependent on federated IdP) in case the corporate IdP is unavailable. Absence of this is a `high` governance risk.
+
+## When to push back
+
+- Push back when the user asks to confirm a governance finding from memory alone without providing any account structure artifact.
+- Push back when the user asks to recommend specific quota numbers without providing current consumption data.
+- Push back when the user asks to disable trust configurations without first mapping which users and applications currently rely on that trust.
+- Push back when a request requires live BTP API access — state clearly that live inspection is out of scope and ask the user to supply the relevant exports or summaries.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP BTP Help Portal account model, entitlements, environments, role collections, or trust configuration docs
+- `user-provided evidence` — BTP cockpit exports, architecture documents, role collection lists, or entitlement summaries provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled as such

package/skills/sap/sap-btp-governance-review/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract — SAP BTP Governance Review
+
+Use this reference for all finding classification, risk assignment, remediation path selection, and output formatting.
+
+## Governance domain taxonomy
+
+| Domain | Scope | Typical findings |
+|--------|-------|-----------------|
+| `account-structure` | Global account, directory layout, subaccount design | Flat structure with no directories, production/non-production in same subaccount, no naming convention |
+| `entitlements` | Service entitlements and quota assignments at directory/subaccount level | Entitlement sprawl, unused quota, global-account-level entitlement when subaccount scope would suffice |
+| `environments` | Cloud Foundry org/space, Kyma cluster provisioning | Over-provisioned CF quotas, unused environment instances, missing space-level quota restrictions |
+| `role-collections` | Platform and application role collection assignments | Direct user assignment instead of IdP group mapping, over-permissive built-in role collections, unused custom role collections |
+| `trust` | Identity provider trust configuration per subaccount | Default SAP ID Service trust not disabled when custom IdP is in use, unconfigured attribute mappings, redundant trust entries |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Security or compliance boundary violation: unauthorized access path, identity trust misconfiguration enabling unintended login, missing MFA enforcement on platform users |
+| `high` | Operational risk: entitlement over-provisioning causing cost overrun, role collection granting global account admin to non-admin users, no emergency access procedure |
+| `medium` | Governance gap: no directory structure in large BTP estate, direct user role assignment (vs. IdP group mapping), unused environment instances consuming quota |
+| `low` | Best practice deviation: inconsistent naming convention, missing account tags, undocumented subaccount purpose |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a trust misconfiguration with an active unauthorized login path?**
+   - Yes → `critical`. Disable the trust entry or remove the misconfigured attribute mapping immediately. Do not defer.
+   - No → continue.
+
+2. **Does the finding grant excessive platform or global account admin access?**
+   - Yes → `high`. Remove direct user assignments; replace with IdP group-mapped role collections scoped to least privilege.
+   - No → continue.
+
+3. **Is this an entitlement or quota over-provisioning issue?**
+   - Yes → `high` or `medium` depending on scale. Reduce entitlement quota to match actual consumption + reasonable headroom. Move entitlement to subaccount scope if currently set at global account scope unnecessarily.
+   - No → continue.
+
+4. **Is this a structural gap (no directories, flat subaccount structure, no naming convention)?**
+   - Yes → `medium`. Recommend adding a directory tier with entitlement-managed and managed-subaccount-lifecycle policies. Define naming and tagging conventions.
+   - No → continue.
+
+5. **Is this a best practice deviation with no immediate risk?**
+   - Yes → `low`. Provide guidance for future alignment; do not block.
+
+## Workflow
+
+1. **Receive artifacts** — BTP account structure exports, cockpit screenshots, role collection lists, entitlement summaries, or user descriptions.
+2. **Classify each finding** by governance domain.
+3. **Assign risk level** (critical / high / medium / low).
+4. **Apply remediation decision tree** per finding.
+5. **Prioritize** — critical findings first; then high; then medium structural gaps; then low best-practice items.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Governance domain and specific finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended remediation action (trust removal, entitlement reduction, role collection restructure, directory addition, etc.)
+5. Governance posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live BTP cockpit access is required to confirm the finding before remediation

package/skills/sap/sap-cap-architecture-review/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: sap-cap-architecture-review
+description: Review SAP Cloud Application Programming Model (CAP) applications for CDS data modeling quality, service layer design, authorization correctness (@requires/@restrict), multitenancy architecture, draft handling, and test coverage. Use when assessing CAP Node.js or Java projects for architectural compliance, security posture, and clean service design. Does not touch live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: architecture
+  lifecycle: experimental
+---
+
+# SAP CAP Architecture Review
+
+## Purpose
+
+Assess the architecture, security posture, and operational quality of SAP Cloud Application Programming Model (CAP) applications. Review CDS data model design for normalization, association correctness, and annotation quality. Assess the service layer for separation of concerns, projection completeness, and anti-pattern avoidance. Review authorization configuration (`@requires`, `@restrict`) for correctness and enforcement. Evaluate multitenancy design for tenant isolation, extensibility readiness, and MTX service wiring. Assess draft handling for consistency, activation logic, and side-effect completeness. Review test coverage for CAP-specific test patterns. Does not connect to or mutate any live CAP application, BTP service, or database.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review CDS entity and service definitions for modeling quality, association correctness, projection anti-patterns, or annotation completeness,
+- assess CAP authorization annotations (`@requires`, `@restrict`) for correctness, missing access controls, or role design gaps,
+- evaluate multitenancy architecture: MTX service wiring, tenant onboarding flow, extensibility activation, `cds.requires.multitenancy` configuration,
+- review draft handling design: draft-enabled entities, activation hooks, side effects, draft lock expiry, and cancel behavior,
+- audit CAP test coverage: `cds.test` unit patterns, integration test setup, mock authentication usage, and CDS test environment teardown,
+- identify CAP anti-patterns: direct database access bypassing the service layer, missing `@readonly` on projection fields, incorrect `up_` association exposure, or unguarded actions,
+- assess CAP application readiness for SAP BTP production deployment: profile configuration, feature toggles, and `package.json` `cds` block correctness.
+
+## When not to use
+
+- When the request is about ABAP-side RAP business objects or ABAP Cloud compliance — use `sap-abap-cloud-rap-review`.
+- When the request is about Integration Suite iFlow or API Management configuration — use `sap-integration-suite-review`.
+- When the request requires live CAP application inspection, database query execution, or BTP service key access — this skill accepts only user-provided code artifacts, CDS model files, `package.json`, or written descriptions.
+- When the request is about SAP Fiori / UI5 frontend code rather than the CAP backend service layer.
+
+## Does not touch live systems
+
+This skill operates on user-provided CDS source files, `package.json` configuration, `srv/` handler files, test file excerpts, MTX configuration, or written descriptions of the CAP application architecture. It does not connect to any BTP subaccount, CAP runtime, HANA database, or deployment pipeline. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify findings before recommending. Every finding must be assigned to a review domain (CDS Modeling / Service Layer / Authorization / Multitenancy / Draft / Testing / Deployment Config) before remediation is proposed.
+- Authorization is non-negotiable. A CAP service or entity with no `@requires` or `@restrict` annotation is accessible to any authenticated — or unauthenticated — caller depending on CAP runtime version. An unguarded service exposed to external callers is a `critical` finding.
+- `@restrict` is preferred over `@requires` for entity-level access control. `@requires` on a service grants blanket access; `@restrict` with `grant`/`to`/`where` clauses gives fine-grained operation-level control. A service using only service-level `@requires` with no entity-level `@restrict` is a `medium` finding when business data sensitivity is high.
+- Direct database access in service handlers bypasses CAP authorization enforcement. Any `SELECT` from `db.run(SELECT.from(...))` inside a service handler that circumvents the CAP service layer authorization is a `high` finding.
+- Multitenancy requires explicit MTX wiring. A CAP application configured with `cds.requires.multitenancy: true` but missing `@sap/cds-mtxs` dependency, subscriber passcode configuration, or tenant upgrade hooks is a `high` finding.
+- Draft handling activation must be complete. A draft-enabled entity missing an `activate` action implementation, `draftActivate` side-effect hook, or proper `BeforeSave` validation is a `high` finding for transactional correctness.
+- Test isolation is required. CAP integration tests that use a shared `cds.test` instance without proper `beforeAll`/`afterAll` teardown, or that test against a live HANA target rather than in-memory SQLite, are `medium` findings for test reliability.
+- Evidence from official SAP CAP documentation and user-provided artifacts takes precedence over inference.
+- Load only the reference needed for the component in scope.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in official SAP CAP documentation (cap.cloud.sap, SAP Help Portal)
+- `user-provided evidence` — CDS model files, service handler code, `package.json`, test files, or written descriptions provided by the user
+- `context7-supplementary` — grounded in CAP framework docs fetched from Context7 (supplementary to official SAP CAP docs; applies for CDS modeling, authorization, multitenancy, and draft patterns)
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no CAP runtime API call, BTP service binding access, HANA database connection, or BTP cockpit access in this skill's execution path. Users must supply CDS source files, handler code excerpts, configuration files, or written descriptions of their CAP application for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — review domain taxonomy, severity classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common CAP mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP CAP docs, CDS language reference, authorization guides, multitenancy, draft handling.
+- [Context7 framework docs](references/context7-framework-docs.md) — CAP authorization patterns, CDS service modeling, multitenancy, and draft handling (supplementary; strongly applies for this skill).
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: review domain(s) in scope and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / context7-supplementary / inference.
+- **Risk level**: critical (security or data integrity risk) / high (correctness or operational reliability risk) / medium (governance or maintainability gap) / low (best practice deviation).
+- **Recommended action**: specific remediation per finding (add `@restrict` annotation, wire MTX service, implement `draftActivate` hook, add test teardown, etc.).
+- **Refusal / escalation triggers**: if live CAP runtime access, BTP service binding, or database inspection is required to complete the review, state that clearly and do not proceed.
+- **Business impact**: security exposure, data integrity risk, multitenancy isolation failure, or test reliability gap.
+- **Next verification step**: validate recommended changes against the current CAP runtime version and BTP deployment target before deploying.

package/skills/sap/sap-cap-architecture-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP CAP Architecture Review"
+  short_description: "Review SAP CAP applications for CDS modeling quality, service authorization (@requires/@restrict), multitenancy design, draft handling, and test coverage"
+  default_prompt: "Use $sap-cap-architecture-review to assess the provided SAP CAP application artifacts. Classify findings by domain (CDS Modeling / Service Layer / Authorization / Multitenancy / Draft / Testing / Deployment Config), assign severity (critical / high / medium / low), state evidence level (documentation-based / user-provided evidence / context7-supplementary / inference), and recommend specific remediation per finding. Flag any unguarded services or entities as critical."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://cap.cloud.sap/docs/guides/security/authorization"
+      description: "SAP CAP authorization guide — verify @requires/@restrict annotation correctness and enforcement behavior for the target CAP runtime version"
+policy:
+  allow_implicit_invocation: true