@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.1

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

package/skills/sap/sap-cap-architecture-review/metadata.json

@@ -0,0 +1,34 @@
+{
+  "id": "sap-cap-architecture-review",
+  "name": "SAP CAP Architecture Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Cloud Application Programming Model (CAP) applications for CDS modeling quality, service layer design, authorization correctness (@requires/@restrict), multitenancy architecture, draft handling, and test coverage. Does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://cap.cloud.sap/docs/guides/security/authorization",
+    "https://cap.cloud.sap/docs/guides/providing-services",
+    "https://cap.cloud.sap/docs/guides/multitenancy/",
+    "https://cap.cloud.sap/docs/guides/fiori/draft-support",
+    "https://cap.cloud.sap/docs/guides/testing/",
+    "https://cap.cloud.sap/docs/cds/cdl",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/sap-cloud-application-programming-model",
+    "https://cap.cloud.sap/docs/node.js/cds-facade",
+    "https://cap.cloud.sap/docs/java/security"
+  ],
+  "security_notes": "Does not access live CAP applications, BTP subaccounts, HANA databases, or deployment pipelines. Accepts only user-provided CDS source files, service handler code, package.json, test files, or written descriptions. Never request or accept BTP service keys, HANA credentials, OAuth client secrets, or subaccount tenant IDs. Authorization findings (missing @requires/@restrict) must be validated against the deployed CAP runtime version before remediation.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-cap-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-cap-architecture-review/references/context7-framework-docs.md

@@ -0,0 +1,89 @@
+# Context7 framework docs — SAP CAP Architecture Review
+
+**Role**: supplementary. Official SAP CAP documentation at cap.cloud.sap is the primary source for all architecture guidance. Context7-sourced CAP documentation supplements with code-level examples and implementation detail for authorization, multitenancy, and draft patterns.
+
+**Library used**: SAP Cloud Application Programming Model (CAP)
+Context7 library ID: `/websites/cap_cloud_sap`
+Lookup targets: CDS service authorization (@requires/@restrict), multitenancy extensibility, CAP draft handling, CDS modeling patterns
+Skill: `sap-cap-architecture-review`
+Classification: supplementary — strongly applies for this skill
+
+---
+
+## CAP @requires — service-level authorization (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/remote-authentication
+
+The `@requires` annotation on a CDS service restricts access to callers holding a specified role. This works for both user-facing and App-2-App (technical user) flows.
+
+```cds
+using { sap.capire.flights.data as data } from './data-service';
+
+annotate data with @(requires: 'data-consumer');
+```
+
+A service with no `@requires` annotation is accessible without role restriction. In App-2-App IAS flows, the role is derived from the IAS API identifier registered with the service.
+
+**Relevance**: Use this pattern to assess whether externally exposed CAP services have role-based guards and to classify services missing `@requires` as critical or high findings depending on exposure scope.
+
+---
+
+## CAP @restrict — entity-level fine-grained access control (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/authorization
+
+`@restrict` provides operation-level, role-specific, and instance-level access control on CDS service entities and actions. It is preferred over `@requires` for entities containing sensitive business data.
+
+```cds
+service CustomerService @(requires: 'authenticated-user') {
+  entity Products @(restrict: [
+    { grant: 'READ' },
+    { grant: 'WRITE', to: 'Vendor' },
+    { grant: 'addRating', to: 'Customer'}
+  ]) {/*...*/}
+  actions {
+     action addRating (stars: Integer);
+  }
+  entity Orders @(restrict: [
+    { grant: '*', to: 'Customer', where: (CreatedBy = $user) }
+  ]) {/*...*/}
+  action monthlyBalance @(requires: 'Vendor') ();
+}
+```
+
+Key patterns:
+- `grant: 'READ'` without `to:` allows any authenticated user to read (matches service-level `@requires`).
+- `grant: 'WRITE', to: 'Vendor'` restricts write operations to the `Vendor` role.
+- `where: (CreatedBy = $user)` restricts instance access — each customer sees only their own orders.
+- CAP runtime enforces `@restrict` server-side before any resource access.
+
+**Relevance**: The central annotation model for entity-level security review. Use to assess whether `where` clauses are present for tenant-scoped or user-scoped data, whether write operations are role-restricted, and whether actions have explicit authorization guards.
+
+---
+
+## CAP default authorization stance (supplementary)
+
+Source: cap.cloud.sap (Context7 `/websites/cap_cloud_sap`)
+Reference: https://cap.cloud.sap/docs/guides/security/data-protection
+
+> By default, CAP services and entities are not authorized, requiring developers to design and test access rules.
+
+The CAP runtime guarantees server-side enforcement only after authorization annotations are explicitly declared. The absence of `@requires` or `@restrict` on a service or entity means no authorization enforcement — not a default-deny posture.
+
+**Relevance**: This is the foundational reason why missing annotations are a critical or high finding. The default is permissive, not restrictive. Every service and entity exposed to external callers must have explicit annotation coverage.
+
+---
+
+## Scope boundaries for Context7 usage
+
+Context7 CAP documentation applies to all CAP review domains in this skill:
+
+- **Authorization** (`@requires`, `@restrict`, `where` clauses): directly applicable
+- **CDS Modeling** (entity/service definitions, projection patterns): directly applicable
+- **Multitenancy** (MTX wiring, extensibility activation): applicable for `cds add extensibility` and `@sap/cds-mtxs` patterns
+- **Draft Handling**: applicable for `draftActivate` and `BeforeSave` handler patterns
+- **Testing**: applicable for `cds.test` setup and mock authentication patterns
+
+Always label Context7-sourced guidance as `context7-supplementary` in responses. For runtime version-specific behavior (e.g., `@sap/cds` 7.x vs 8.x), direct the user to verify against the official cap.cloud.sap changelog.