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

package/skills/sap/sap-clean-core-debt-review/references/workflow-and-output.md

@@ -0,0 +1,62 @@
+# Workflow and output contract — SAP Clean Core Debt Review
+
+Use this reference for all classification, remediation path selection, and output formatting.
+
+## Clean core violation taxonomy
+
+| Violation class | Description | Upgrade risk |
+|----------------|-------------|-------------|
+| `implicit-enhancement` | Implicit enhancement spots in standard SAP include programs or function groups | High — SAP may remove or rename the enhancement spot |
+| `modification` | Customer modifications of SAP standard objects (via modification assistant) | High — overwritten at upgrade unless re-applied |
+| `customer-include` | Use of customer include sections (e.g., `INCLUDE MF_xxxxFxx`) in SAP objects | High — deprecated in ABAP Cloud |
+| `user-exit` | Classic user exits via `CALL CUSTOMER FUNCTION` | Medium-High — deprecated; SAP may stop calling them |
+| `badi-classic` | Classic BAdI implementations (before ABAP Objects BAdIs) | Medium — must migrate to new BAdI concept |
+| `not-released-api` | Direct consumption of SAP internal APIs (release contract NOT_RELEASED or no contract) | High — no stability guarantee; breaks at any SAP update |
+| `z-object-unreleased-dep` | Custom Z/Y objects that transitively depend on NOT_RELEASED SAP APIs | Medium — inherited upgrade risk |
+| `z-standalone` | Custom Z/Y objects with no SAP dependency violations | Low — clean core compliant if no modification |
+| `rap-violation` | ABAP Cloud objects using forbidden language constructs (e.g., `SELECT *` on SAP tables directly) | Medium — blocks ABAP Cloud tier-2 compliance |
+
+## Remediation path decision tree
+
+For each flagged object:
+
+1. **Is there a released SAP API (C1/C2) that covers the business function?**
+   - Yes → refactor custom code to consume the released API. Validate on API Business Hub.
+   - No → continue to step 2.
+
+2. **Is there a BAdI (new ABAP Objects BAdI concept) with a released enhancement spot?**
+   - Yes → implement a new BAdI enhancement. Remove the implicit enhancement or user exit.
+   - No → continue to step 3.
+
+3. **Can the requirement be met with key-user extensibility (custom fields, custom logic, custom forms via UI adaptation)?**
+   - Yes → replace custom ABAP with key-user extensibility app configuration. No code deployment.
+   - No → continue to step 4.
+
+4. **Is the requirement a transactional extension on S/4HANA data?**
+   - Yes → build a RAP business object extension or RAP-based side-by-side app on BTP ABAP Environment.
+   - No → continue to step 5.
+
+5. **Is the requirement a process extension or integration with non-SAP systems?**
+   - Yes → build a side-by-side extension on BTP using SAP CAP (Node.js or Java) consuming released OData/API Management APIs.
+   - No → evaluate for retirement. Assess business value vs. clean core compliance cost.
+
+## Workflow
+
+1. **Receive artifacts** — ATC output, custom code migration app report, object list, or user-described code.
+2. **Classify each object** by violation class above.
+3. **Assign upgrade risk** (High / Medium / Low / None).
+4. **Apply remediation path decision tree** per object class.
+5. **Prioritize** — High upgrade-risk objects first; then non-compliant with low business value; then strategic re-architecture.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Object(s) reviewed and violation class
+2. Evidence label (documentation-based / user-provided / context7-supplementary / inference)
+3. Upgrade risk per object
+4. Recommended remediation path (with API Business Hub verification step if released API is proposed)
+5. Clean core compliance posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live system inspection is required before proceeding

package/skills/sap/sap-cloud-alm-sre-incident-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: sap-cloud-alm-sre-incident-review
+description: Review SAP Cloud ALM for SRE and operations governance: health monitoring configuration, alerting rule coverage, integration and exception monitoring, business process monitoring, incident and problem management process, root-cause analysis workflow, and SLA and service continuity controls. Does not access live Cloud ALM tenants or mutate monitoring configuration.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: observability
+  lifecycle: experimental
+---
+
+# SAP Cloud ALM SRE and Incident Review
+
+## Purpose
+
+Assess the SRE and operations governance posture of SAP Cloud ALM deployments. Review health monitoring configuration: service and system health check coverage, monitoring scope per managed system, health status threshold calibration, and gap identification for uncovered SAP cloud and on-premise services. Assess alerting rule coverage: alert threshold design, notification channel configuration, alert routing to the correct operations team, and alert fatigue risk from miscalibrated thresholds. Review integration and exception monitoring: iFlow exception alerting in SAP Integration Suite, API proxy error rate monitoring, interface error log coverage, and exception handling in integration scenarios. Evaluate business process monitoring: key figure configuration for business-critical processes (order-to-cash, procure-to-pay, financial close), step-level process health tracking, SLA breach detection for business process milestones, and business user notification coverage. Assess incident and problem management process: incident creation workflow, severity classification, escalation path configuration, problem record linkage for recurring incidents, and knowledge article coverage. Review root-cause analysis workflow: Real User Monitoring (RUM) and synthetic monitoring integration, alert-to-incident traceability, cross-system dependency mapping for root-cause investigation, and handoff between Cloud ALM and underlying system support. Assess SLA and service continuity controls: SLA definition completeness, breach threshold alerting, service continuity plan coverage for critical SAP services, and reporting configuration for SLA performance. Does not connect to live Cloud ALM tenants, mutate monitoring configuration, or access production system data.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review SAP Cloud ALM health monitoring coverage: which SAP cloud services and on-premise managed systems are registered, whether service health checks are configured for all business-critical systems, and whether monitoring gaps exist for any production service in scope,
+- assess alerting rule design and threshold calibration: whether alert thresholds are set to detect meaningful degradation before SLA breach, whether notification channels are configured for all alert types, whether alert routing correctly targets the responsible operations team, and whether alert fatigue from over-sensitive thresholds is a risk,
+- evaluate integration and exception monitoring in Cloud ALM: whether iFlow exceptions from SAP Integration Suite are surfaced in Cloud ALM, whether API proxy error rate alerts are configured, whether integration error logs feed into Cloud ALM incident creation, and whether key integration scenarios have end-to-end monitoring coverage,
+- review business process monitoring configuration: whether SAP Cloud ALM business process monitoring key figures are defined for critical business processes, whether step-level health tracking covers order-to-cash, procure-to-pay, and financial close milestones, whether SLA breach detection is configured per process milestone, and whether business users receive proactive notifications for process delays,
+- assess incident and problem management process governance: whether SAP Cloud ALM incident management is integrated with the organization's ITSM platform (ServiceNow, JIRA, etc.), whether incident severity classification aligns with business impact, whether escalation paths are defined and tested, whether problem records are created for recurring incidents, and whether root-cause analysis is completed and documented for major incidents,
+- review root-cause analysis workflow: whether SAP Cloud ALM Real User Monitoring or synthetic monitoring is configured for critical user journeys, whether alert-to-incident traceability is maintained (alerts link to incident records), whether cross-system dependency maps are available in Cloud ALM for root-cause investigation, and whether the handoff process between Cloud ALM and SAP support (or system-specific support teams) is documented,
+- assess SLA and service continuity governance: whether SLAs are formally defined in SAP Cloud ALM, whether breach threshold alerting is configured per SLA, whether SLA performance reporting is scheduled and reviewed by service management, and whether a service continuity plan exists for critical SAP services covered by Cloud ALM.
+
+## When not to use
+
+- When the request requires connecting to a live SAP Cloud ALM tenant, querying real-time health monitoring data, or inspecting production incident records — this skill reviews configuration descriptions, monitoring design documentation, process documentation, and governance artifacts only.
+- When the request is about monitoring and observability for custom-built BTP applications using non-SAP Cloud ALM tools (Dynatrace, Prometheus, Grafana) — this skill focuses on SAP Cloud ALM capabilities.
+- When the request is about SAP Solution Manager (SolMan) operations in an on-premise context as the primary monitoring tool rather than Cloud ALM.
+- When the request is about SAP Transport Management or change management governance rather than health monitoring and incident management.
+
+## Does not touch live systems
+
+This skill operates on user-provided Cloud ALM monitoring configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, and written descriptions of the operations governance posture. It does not connect to any SAP Cloud ALM tenant, query real-time health data, create or update incident records, modify alert configuration, or access any managed SAP system. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify findings by SRE governance domain before recommending. Every finding must be assigned to a domain (Health Monitoring / Alerting / Integration and Exception Monitoring / Business Process Monitoring / Incident and Problem Management / Root-Cause Analysis / SLA and Service Continuity) before a remediation path is proposed.
+- Monitoring coverage gaps for production systems are never acceptable. Any production SAP service or system not covered by SAP Cloud ALM health monitoring is a `high` finding. Blind spots in production monitoring mean service degradation can go undetected until business impact occurs.
+- Alert thresholds must be calibrated to SLA requirements. An alert threshold that fires only after an SLA breach has already occurred provides no operational value. Alert thresholds must give operations teams sufficient time to respond before breach. Miscalibrated or absent thresholds are `high` findings.
+- Incident severity must reflect business impact. An incident classification that does not account for business impact (number of affected users, revenue at risk, regulatory reporting deadline) is a governance gap. Incidents affecting critical business processes must be escalated to the highest appropriate severity.
+- Problem management is required for recurring incidents. Three or more incidents with the same root cause within a rolling 30-day period without a linked problem record and active root-cause investigation is a `medium` finding.
+- SLA definitions must exist before SLA reporting is meaningful. Generating SLA performance reports without formally defined SLAs (agreed availability targets, response time targets, resolution time targets) is a `medium` finding — the reports lack a verified baseline against which breach is measured.
+- Integration and exception monitoring must cover business-critical interfaces. Any integration scenario on the critical business process path (order-to-cash, procure-to-pay, financial close, payroll) without Cloud ALM exception monitoring and alert coverage is a `high` finding.
+- Evidence from user-provided Cloud ALM configuration documentation or official SAP Cloud ALM documentation takes precedence over inference.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in official SAP Cloud ALM documentation (help.sap.com)
+- `user-provided evidence` — Cloud ALM monitoring configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, or written operations governance 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 SAP Cloud ALM API call, real-time health data query, incident record access, alert configuration modification, or managed system connection in this skill's execution path. Users must supply Cloud ALM configuration documentation, monitoring design descriptions, process documentation, or governance artifacts for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — SRE governance domain taxonomy, risk classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common Cloud ALM operations review mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Cloud ALM health monitoring, alerting, integration monitoring, business process monitoring, and incident management documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: SRE governance domain(s) in scope (Health Monitoring / Alerting / Integration and Exception Monitoring / Business Process Monitoring / Incident and Problem Management / Root-Cause Analysis / SLA and Service Continuity) and specific finding(s) per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (production system with no monitoring coverage, complete SLA reporting absence for regulated service) / high (alert threshold miscalibration, critical integration interface with no exception monitoring, business-critical incident severity misconfiguration, missing SLA definition) / medium (problem record absence for recurring incidents, incomplete root-cause analysis, missing SLA breach alerting) / low (best practice deviation, documentation gap without immediate operational impact).
+- **Recommended action**: specific governance control per finding (add managed system to Cloud ALM monitoring scope, recalibrate alert threshold, configure integration exception monitoring, define SLA in Cloud ALM, create problem record for recurring incident pattern, implement root-cause analysis workflow, etc.).
+- **Refusal / escalation triggers**: if live Cloud ALM tenant access, real-time health data, or production incident record review is required to complete the assessment, state that clearly and do not proceed. If a production system monitoring blind spot is identified, escalate to the operations team immediately — do not defer.
+- **Business impact**: service availability risk, SLA breach risk, business process delay risk (financial close, order-to-cash, payroll), regulatory reporting risk, or mean time to detect (MTTD) and mean time to resolve (MTTR) increase from monitoring gaps.
+- **Next verification step**: validate monitoring coverage recommendations against the current SAP Cloud ALM managed system list and alert rule configuration before deploying changes to the production monitoring scope.

package/skills/sap/sap-cloud-alm-sre-incident-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Cloud ALM SRE and Incident Review"
+  short_description: "Review SAP Cloud ALM for SRE and operations governance: health monitoring coverage, alerting threshold calibration, integration and exception monitoring, business process monitoring, incident and problem management, root-cause analysis workflow, and SLA and service continuity controls."
+  default_prompt: "Use $sap-cloud-alm-sre-incident-review to assess the provided SAP Cloud ALM operations governance artifacts. Classify findings by SRE governance domain (Health Monitoring / Alerting / Integration and Exception Monitoring / Business Process Monitoring / Incident and Problem Management / Root-Cause Analysis / SLA and Service Continuity), 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 Cloud ALM tenants, modify alert configuration, or accept actual incident records containing PII."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/cloud-alm/applicationhelp/health-monitoring"
+      description: "SAP Cloud ALM health monitoring documentation — primary reference for managed system registration, health check coverage, and alert threshold configuration"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-cloud-alm-sre-incident-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-cloud-alm-sre-incident-review",
+  "name": "SAP Cloud ALM SRE and Incident Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Cloud ALM for SRE and operations governance: health monitoring configuration and coverage gaps, alerting rule calibration, integration and exception monitoring, business process monitoring key figures, incident and problem management process, root-cause analysis workflow, and SLA and service continuity controls. Does not access live Cloud ALM tenants or mutate monitoring configuration.",
+  "source_type": "original",
+  "category": "observability",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/what-is-sap-cloud-alm",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/health-monitoring",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/integration-and-exception-monitoring",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/business-process-monitoring",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/intelligent-event-processing",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/it-task-management",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/real-user-monitoring",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/synthetic-user-monitoring"
+  ],
+  "security_notes": "Does not access live SAP Cloud ALM tenants, query real-time health monitoring data, create or update incident records, modify alert configuration, or connect to any managed SAP system. Accepts only Cloud ALM monitoring configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, or written operations governance descriptions. Never accept actual incident records containing customer or employee PII, system access credentials, Cloud ALM API tokens, or managed system connection details.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-cloud-alm-sre-incident-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-cloud-alm-sre-incident-review/references/official-sources.md

@@ -0,0 +1,89 @@
+# Official sources — SAP Cloud ALM SRE and Incident Review
+
+Use this reference when grounding health monitoring coverage assessment, alert rule calibration review, integration and exception monitoring evaluation, business process monitoring review, incident and problem management process assessment, root-cause analysis workflow review, and SLA and service continuity governance assessment.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Cloud ALM application help documentation). No live-system evidence is collected by this skill.
+
+## SAP Cloud ALM — Product Overview
+
+- What is SAP Cloud ALM
+  https://help.sap.com/docs/cloud-alm/applicationhelp/what-is-sap-cloud-alm
+  source_owner: SAP SE
+  topic_supported: SAP Cloud ALM product scope, use case areas (implementation, operations, service management), supported SAP managed systems (cloud and on-premise), licensing and provisioning model
+  why_needed: Primary reference for SAP Cloud ALM capability scope — defines which SAP services and systems are supported as managed systems, which operations use cases are covered, and the product boundary used to assess monitoring coverage completeness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Health Monitoring
+
+- Health Monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/health-monitoring
+  source_owner: SAP SE
+  topic_supported: Health check configuration for SAP cloud services and on-premise systems, managed system registration, health status threshold definition, alert generation from health status degradation, monitoring scope per system type
+  why_needed: Primary reference for health monitoring coverage assessment — defines the health check model, managed system registration requirements, and health status threshold configuration used to classify monitoring gap and miscalibration findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Integration and Exception Monitoring
+
+- Integration and Exception Monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/integration-and-exception-monitoring
+  source_owner: SAP SE
+  topic_supported: Integration scenario monitoring in Cloud ALM, iFlow exception surfacing from SAP Integration Suite, API proxy error rate monitoring, interface error alert configuration, end-to-end integration scenario health
+  why_needed: Authoritative reference for integration exception monitoring assessment — defines which integration scenarios can be monitored through Cloud ALM, how iFlow exceptions are surfaced, and what alert types are available for integration failure detection
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Business Process Monitoring
+
+- Business Process Monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/business-process-monitoring
+  source_owner: SAP SE
+  topic_supported: Business process monitoring key figure configuration, step-level process health tracking, SLA breach detection for process milestones, business user notification configuration, process health dashboard
+  why_needed: Primary reference for business process monitoring assessment — defines the key figure configuration model, process milestone SLA definition capability, and notification model used to classify business process monitoring coverage and SLA breach detection findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Intelligent Event Processing (Alerting)
+
+- Intelligent Event Processing
+  https://help.sap.com/docs/cloud-alm/applicationhelp/intelligent-event-processing
+  source_owner: SAP SE
+  topic_supported: Alert rule configuration, event processing pipeline in Cloud ALM, notification channel setup, alert routing to operations teams, alert suppression and grouping, integration with ITSM platforms for alert-to-incident automation
+  why_needed: Primary reference for alerting governance assessment — defines the alert rule configuration model, notification channel types, ITSM integration for automated incident creation, and alert grouping and suppression capabilities used to classify alert threshold and routing findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — IT Task Management (Incident and Problem Management)
+
+- IT Task Management
+  https://help.sap.com/docs/cloud-alm/applicationhelp/it-task-management
+  source_owner: SAP SE
+  topic_supported: Incident and problem record management in Cloud ALM, severity classification model, escalation path configuration, ITSM platform integration, knowledge article linkage, task assignment and workflow
+  why_needed: Required to assess incident and problem management governance — defines the incident severity model, problem record linkage capability, ITSM integration patterns, and escalation workflow configuration used to classify incident management process findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Real User Monitoring
+
+- Real User Monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/real-user-monitoring
+  source_owner: SAP SE
+  topic_supported: Real user experience monitoring for SAP Fiori and browser-based SAP applications, response time tracking, error rate detection, user journey performance metrics, alert generation from performance degradation
+  why_needed: Required to assess root-cause analysis workflow completeness — defines the Real User Monitoring capability available in Cloud ALM for detecting performance degradation at the user experience layer and supporting root-cause investigation
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Synthetic User Monitoring
+
+- Synthetic User Monitoring
+  https://help.sap.com/docs/cloud-alm/applicationhelp/synthetic-user-monitoring
+  source_owner: SAP SE
+  topic_supported: Synthetic transaction monitoring for SAP Fiori applications, proactive availability and performance testing, alert generation from synthetic check failures, test scenario configuration
+  why_needed: Required to assess proactive monitoring coverage — defines the synthetic monitoring capability for detecting SAP application availability issues before real users are impacted, used to classify gaps in proactive health detection
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and SAP Cloud ALM application help documentation describe the designed monitoring model, alerting capabilities, incident management features, and integration monitoring scope. They do not prove which managed systems are registered in the user's Cloud ALM tenant, what alert thresholds are configured, whether SLAs are formally defined, or how the organization's incident management process operates. Users must supply Cloud ALM configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, or written operations governance descriptions for concrete assessment.

package/skills/sap/sap-cloud-alm-sre-incident-review/references/safety-checklist.md

@@ -0,0 +1,39 @@
+# Safety checklist — SAP Cloud ALM SRE and Incident Review
+
+Use before making any operations governance finding or remediation recommendation, especially for findings involving production monitoring gaps, incident severity classification, SLA breach risk, or integration exception monitoring.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP Cloud ALM tenant, real-time health monitoring dashboard, incident record store, alert configuration interface, or managed SAP system. This skill reviews governance artifacts only.
+- Do not accept or request actual incident records containing customer PII, employee PII, personally identifiable system user data, or production system performance data that identifies individual user behavior.
+- Do not accept SAP Cloud ALM admin credentials, API tokens, managed system connection parameters, or ITSM integration service account credentials.
+- Do not recommend changes to production alert thresholds or monitoring configuration without first testing the change in a non-production Cloud ALM environment and confirming the expected behavior with the operations team.
+- Do not recommend disabling or suppressing alerts for a production system to reduce alert fatigue without first confirming that root-cause noise reduction (threshold recalibration, alert grouping) has been attempted.
+- Do not close or recommend closing a problem record for a recurring incident pattern without confirming that a verified root-cause fix has been implemented and validated over a sufficient observation period.
+- Do not validate SLA compliance or confirm SLA adherence from memory alone. SLA performance assessment must be grounded in user-provided SLA definitions and Cloud ALM reporting documentation.
+- Do not assert that a production system is fully monitored without user-provided confirmation of the managed system registration list and configured health checks in Cloud ALM.
+
+## What people get wrong
+
+- **Confusing alert configuration with monitoring coverage**: A managed system can be registered in Cloud ALM without health checks configured, or health checks can be configured without alert rules. Registration, health check enablement, and alert rule creation are three separate steps. Missing any one of them creates a gap even if the others are in place.
+- **Treating silent alerts as working alerts**: An alert rule that fires but has no notification channel configured produces no operational value. Alert rules must be verified end-to-end — from event trigger through notification delivery to the responsible team.
+- **Assuming ITSM integration is bidirectional**: Cloud ALM integration with ServiceNow or JIRA typically pushes alert-generated incidents to the ITSM. It does not always pull incident status updates back to Cloud ALM. Incident lifecycle in Cloud ALM may diverge from the ITSM record if the integration is unidirectional. Both directions must be reviewed.
+- **Overlooking business process monitoring as an SRE concern**: Business process monitoring in Cloud ALM tracks business KPIs (order confirmation time, goods receipt posting delay, payment run completion) rather than technical infrastructure metrics. SRE teams sometimes treat business process monitoring as an application team concern and leave it unconfigured. Unconfigured business process monitoring means business-critical SLA breaches are invisible to operations.
+- **Conflating incident management with problem management**: An incident is a service disruption event; a problem is the underlying root cause. Closing incidents without creating problem records for recurring patterns means the root cause is never formally investigated and the same incident pattern repeats. Both processes must be assessed separately.
+- **Missing the alert-to-incident traceability requirement**: Regulatory and audit requirements for SAP operations (SOX IT general controls, ISO 20000) typically require an audit trail from alert detection through incident creation to resolution. Missing alert-to-incident linkage means the audit trail has a gap even if both the alert and the incident exist.
+- **Assuming Cloud ALM covers all SAP services automatically**: Cloud ALM health monitoring covers a specific list of SAP cloud services and on-premise systems. Not all SAP services are supported as managed systems. Confirm coverage against the current SAP Cloud ALM managed system catalog before asserting monitoring completeness.
+
+## When to push back
+
+- Push back immediately when a production system with no health monitoring coverage is identified — this is a critical finding requiring immediate escalation to the operations team, not a deferred remediation item.
+- Push back when the user requests assessment of actual incident records, real-time health monitoring data, or alert event streams — request anonymized configuration summaries or process documentation instead.
+- Push back when the user proposes to disable alert rules as a first response to alert fatigue without attempting threshold recalibration or alert grouping.
+- Push back when the request requires live Cloud ALM tenant access, real-time dashboard inspection, or managed system connection — state that live inspection is out of scope and ask the user to supply the relevant configuration documentation.
+- Push back when the user proposes to close a problem record for a recurring incident pattern without a verified root-cause fix and a defined observation period.
+- Push back when the user asks to confirm SLA compliance based on this advisory review alone without providing SLA definitions and Cloud ALM SLA performance reports.
+
+## Evidence labels
+
+- `documentation-based` — grounded in official SAP Cloud ALM application help documentation (help.sap.com)
+- `user-provided evidence` — Cloud ALM monitoring configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, or written operations governance 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-cloud-alm-sre-incident-review/references/workflow-and-output.md

@@ -0,0 +1,88 @@
+# Workflow and output contract — SAP Cloud ALM SRE and Incident Review
+
+Use this reference for all finding classification, risk level assignment, remediation path selection, and output formatting.
+
+## SRE governance domain taxonomy
+
+| Domain | Finding class | Description |
+|--------|--------------|-------------|
+| `health-monitoring` | `production-system-not-monitored` | Production SAP service or managed system not registered in SAP Cloud ALM health monitoring scope |
+| `health-monitoring` | `health-check-not-configured` | Managed system registered in Cloud ALM but health checks not configured or enabled for the relevant service type |
+| `health-monitoring` | `threshold-miscalibrated` | Health status threshold set too loosely — degradation is not detected until after SLA breach has already occurred |
+| `health-monitoring` | `monitoring-scope-gap` | Specific SAP service component (e.g., a dedicated integration tenant, a secondary HANA instance) missing from the monitored scope of an otherwise registered managed system |
+| `alerting` | `notification-channel-not-configured` | Alert rule exists but notification channel (email, Microsoft Teams, PagerDuty, ServiceNow) is not configured — alert fires silently |
+| `alerting` | `alert-routing-misconfigured` | Alert notification does not reach the responsible operations team for the affected system or business process |
+| `alerting` | `alert-fatigue-risk` | Alert thresholds set so sensitively that the operations team receives high volumes of low-priority alerts, reducing the signal-to-noise ratio for critical events |
+| `alerting` | `no-itsm-integration` | Cloud ALM alerts do not automatically create incidents in the organization's ITSM platform — manual incident creation introduces delay and inconsistency |
+| `integration-monitoring` | `critical-interface-not-monitored` | Integration scenario on the critical business process path (order-to-cash, procure-to-pay, financial close, payroll) has no Cloud ALM exception monitoring coverage |
+| `integration-monitoring` | `iflow-exceptions-not-surfaced` | iFlow exceptions from SAP Integration Suite are not routed to Cloud ALM integration monitoring |
+| `integration-monitoring` | `no-end-to-end-monitoring` | Integration scenario is monitored at the middleware level but not end-to-end from source to target system |
+| `business-process-monitoring` | `critical-process-key-figure-missing` | No Cloud ALM business process monitoring key figure is configured for a business-critical process milestone (order confirmation, goods receipt, payment run, payroll posting) |
+| `business-process-monitoring` | `sla-breach-detection-absent` | Business process monitoring configured but no SLA breach threshold is defined for process milestone completion time |
+| `business-process-monitoring` | `no-business-user-notification` | Business process SLA breach or exception occurs without notification to the business process owner or affected business users |
+| `incident-management` | `severity-classification-gap` | Incident severity classification does not account for business impact — critical business process disruptions may be classified at lower severity than warranted |
+| `incident-management` | `escalation-path-not-defined` | No documented or configured escalation path for high or critical severity incidents in Cloud ALM or linked ITSM |
+| `incident-management` | `no-problem-record-for-recurring-incident` | Three or more incidents with the same root cause within a 30-day window without a linked problem record and active investigation |
+| `incident-management` | `major-incident-rca-not-completed` | Major incident closed without a documented root-cause analysis or corrective action record |
+| `root-cause-analysis` | `no-rum-or-synthetic-monitoring` | No Real User Monitoring or synthetic monitoring configured for critical SAP Fiori user journeys — detection relies on user-reported issues |
+| `root-cause-analysis` | `alert-incident-traceability-gap` | Alert events are not linked to corresponding incident records — no audit trail from detection to resolution |
+| `root-cause-analysis` | `no-cross-system-dependency-map` | No cross-system dependency documentation available in Cloud ALM for root-cause investigation of incidents spanning multiple SAP systems |
+| `sla-continuity` | `sla-not-formally-defined` | No formally defined SLA (availability target, response time, resolution time) for a production SAP service covered by Cloud ALM |
+| `sla-continuity` | `sla-breach-alerting-absent` | SLA is defined but no Cloud ALM alert is configured to fire when the SLA breach threshold is approached or reached |
+| `sla-continuity` | `sla-reporting-not-scheduled` | No scheduled SLA performance report configured in Cloud ALM — SLA adherence is not reviewed by service management |
+
+## Risk classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Production system with no health monitoring coverage at all; complete loss of visibility into a business-critical SAP service; SLA reporting absent for a regulatory-reporting-relevant service with contractual SLA obligations |
+| `high` | Alert threshold miscalibration that allows SLA breach before alerting; critical integration interface with no exception monitoring; business-critical incident severity misconfiguration; absence of SLA definition for a contractually committed service; no ITSM integration causing manual incident creation delay for critical alerts |
+| `medium` | Problem record absence for recurring incidents; incomplete root-cause analysis for closed major incidents; no SLA breach alerting despite defined SLA; missing business user notification for process SLA breach; no Real User Monitoring for critical Fiori journeys |
+| `low` | Best practice deviation without immediate operational risk: missing knowledge article for known issues, suboptimal alert grouping, documentation gap for escalation path that informally exists |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a production system with no health monitoring coverage?**
+   - Yes → `critical`. Register the system as a managed system in SAP Cloud ALM immediately. Configure health checks per the SAP Cloud ALM health monitoring documentation for the relevant system type. Do not defer production monitoring gaps.
+   - No → continue.
+
+2. **Is this an alert threshold that allows SLA breach before detection, or a critical integration interface with no exception monitoring?**
+   - Yes → `high`. Recalibrate the alert threshold to give the operations team sufficient time to respond before SLA breach. Configure Cloud ALM integration and exception monitoring for the critical interface. Define notification channels and ITSM integration.
+   - No → continue.
+
+3. **Is this a business-critical incident with missing severity classification or escalation path?**
+   - Yes → `high`. Update the incident severity classification model to include business impact criteria. Define and document escalation paths for high and critical severity incidents. Test the escalation workflow.
+   - No → continue.
+
+4. **Is this a recurring incident pattern without a problem record and root-cause investigation?**
+   - Yes → `medium`. Create a problem record in Cloud ALM or the linked ITSM. Assign an owner and initiate a root-cause investigation. Set a target resolution date. Review all linked incidents for shared root cause.
+   - No → continue.
+
+5. **Is this an SLA definition gap, missing SLA breach alerting, or absent SLA reporting?**
+   - Yes → `medium` (escalating to `critical` if the SLA is contractually committed and regulatory reporting is at risk). Define the SLA formally in Cloud ALM. Configure breach threshold alerting. Schedule SLA performance reporting for service management review.
+   - No → classify as `low` and provide SRE best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — Cloud ALM monitoring configuration descriptions, alert rule lists, business process monitoring key figure definitions, incident management process documentation, SLA definitions, or written operations governance descriptions.
+2. **Classify each finding** by SRE governance domain and finding class above.
+3. **Assign risk level** per risk classification table (critical / high / medium / low).
+4. **Flag critical monitoring gaps immediately** — production systems with no health monitoring coverage must be escalated to the operations team and remediated before other findings are discussed.
+5. **Apply remediation decision tree** per finding.
+6. **Prioritize** — critical monitoring gaps first; then high alerting, integration monitoring, and incident management findings; then medium problem management and SLA gaps; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. SRE governance domain and finding class per finding
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. System or process detail (if applicable): managed system name or type, integration scenario, business process, alert rule name, or SLA definition
+5. Recommended governance control per finding (managed system registration, health check configuration, alert threshold recalibration, integration monitoring enablement, ITSM integration, problem record creation, SLA definition, SLA breach alerting, etc.)
+6. Operations posture after remediation: MTTD and MTTR impact estimate, monitoring coverage completeness, business process visibility
+7. Escalation notice for critical production monitoring gaps — explicit statement that the operations team must be alerted immediately and remediation must not be deferred
+8. Prioritized remediation sequence

package/skills/sap/sap-custom-code-remediation-review/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: sap-custom-code-remediation-review
+description: Review custom ABAP code remediation plans and ATC findings for S/4HANA readiness. Assesses SAP simplification item violations, ABAP Test Cockpit results using S/4HANA readiness check variants, custom code migration app output, deprecated API usage, replacement API mapping, and clean-core alignment of proposed remediation paths. Advisory only — does not access or modify live SAP 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 Custom Code Remediation Review
+
+## Purpose
+
+Review the remediation approach for custom ABAP code against SAP S/4HANA compatibility and clean core requirements. Assess ABAP Test Cockpit (ATC) findings using the S/4HANA readiness check variant, interpret custom code migration app output, classify deprecated API usage and its replacement path, evaluate custom code migration plans against SAP simplification item requirements, and validate that proposed remediation paths align with clean core principles. Does not access, run, or modify live SAP systems.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review ATC (ABAP Test Cockpit) findings from the S/4HANA readiness check variant (e.g., `SCI_ABAP_CLOUD_READINESS`, `SCI_S4HANA_READINESS`) and classify findings by severity and remediation action,
+- assess the output of the SAP Custom Code Migration App (transaction `SYCM`) or equivalent tooling for a set of ABAP custom objects,
+- identify which deprecated SAP APIs, function modules, tables, or structures a custom ABAP program uses and what the supported replacement is,
+- evaluate whether a proposed custom code remediation plan correctly prioritizes upgrade-blocking findings over clean-core-non-compliant findings,
+- review a custom code migration project plan for completeness: scope, tooling, testing, and timeline alignment with the S/4HANA transformation program,
+- validate that proposed replacement ABAP patterns follow ABAP Cloud programming model constraints (no SELECT on SAP internal tables, no CALL FUNCTION with deprecated FMs, no CALL SCREEN/CALL DIALOG in ABAP Cloud objects),
+- assess which custom objects should be retired versus remediated versus replaced with standard SAP functionality.
+
+## When not to use
+
+- When the user needs a broader clean core extensibility assessment (BAdIs, RAP business objects, key-user extensibility) — use `sap-clean-core-debt-review`.
+- When the user needs a transformation strategy assessment (brownfield vs greenfield, SAP Activate phase alignment) — use `sap-s4hana-transformation-architecture-review`.
+- When the user needs live system enumeration of custom objects — use `sap-live-readonly-landscape-discovery` first, then return here for advisory review.
+- When the user needs ABAP Cloud RAP modeling guidance — use `sap-abap-cloud-rap-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided ATC result exports, custom code migration app reports, ABAP program source code, object lists, or written descriptions of custom code patterns. It does not connect to any SAP ABAP system, run ATC checks, execute SE38/SE84/SYCM transactions, or access the SAP API Business Hub programmatically. All live enumeration must be provided by the user.
+
+## Lean operating rules
+
+- ATC finding classification first. Every ATC finding must be classified by check category and priority before a remediation action is recommended.
+- S/4HANA readiness variant is the authoritative ATC scope. Findings from the `SCI_S4HANA_READINESS` or `SCI_ABAP_CLOUD_READINESS` variant take precedence over generic ATC check results.
+- Upgrade-blocking findings must be resolved before conversion. ATC findings classified as `BLOCKER` or `ERROR` priority against the S/4HANA readiness variant represent conversion-blocking risks. They must be resolved or explicitly exempted before brownfield conversion can proceed.
+- Deprecated API replacement must be SAP-released. When recommending a replacement for a deprecated function module, BAPI, or table, the replacement must carry a C1 or C2 release contract. Direct users to verify on SAP API Business Hub.
+- Retire before remediate where justified. If a custom object serves a business function now covered by SAP standard S/4HANA, retirement is preferred over remediation. Assess business value vs. remediation cost.
+- Do not fabricate ATC finding counts or severity levels. Only classify findings the user has provided from their actual ATC export or custom code migration app output.
+- Evidence from official SAP sources takes precedence over memory or training data.
+- Load only the reference needed for the scope in question.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP ATC documentation, ABAP Cloud docs, S/4HANA simplification item catalog, or SAP Help Portal
+- `user-provided evidence` — ATC result exports, custom code migration app output, ABAP source code, or object lists provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no credential, API call, RFC connection, or ABAP system access in this skill's execution path. Users must supply ATC exports, SYCM output, ABAP program source, or written descriptions of custom objects for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — ATC finding taxonomy, remediation decision tree, deprecated API replacement patterns, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common remediation mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP ATC, custom code migration, S/4HANA simplification items, ABAP Cloud, deprecated API documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: ATC check variant used, finding severity distribution, and primary deprecated API or violation pattern identified.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: upgrade-blocking / clean-core-non-compliant / technically-functional-but-non-standard / compliant.
+- **Recommended action**: remediation path per finding class (replacement API, ATC exemption with justification, key-user extensibility, ABAP Cloud RAP rewrite, or retire).
+- **Refusal / escalation triggers**: if live object enumeration is required, redirect to `sap-live-readonly-landscape-discovery`; if replacement API release contract needs verification, direct to SAP API Business Hub.
+- **Business impact**: conversion timeline risk, upgrade support cost, clean core compliance posture after remediation.
+- **Next verification step**: which ATC findings or deprecated APIs to validate against current SAP API Business Hub release contracts and S/4HANA simplification item catalog before implementing the remediation plan.

package/skills/sap/sap-custom-code-remediation-review/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Custom Code Remediation Review"
+  short_description: "Review custom ABAP code remediation for S/4HANA readiness — classify ATC findings from S/4HANA readiness variants, map deprecated APIs to released replacements, validate clean-core alignment, and prioritize upgrade-blocking findings. Advisory only."
+  default_prompt: "Use $sap-custom-code-remediation-review to review the custom ABAP remediation approach. Classify ATC findings by check variant (SCI_S4HANA_READINESS or SCI_ABAP_CLOUD_READINESS preferred), identify upgrade-blocking findings requiring resolution before conversion, map deprecated APIs or function modules to their released replacement, and validate that the proposed remediation paths align with ABAP Cloud and clean core constraints. State evidence level and risk classification for each finding or pattern reviewed."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://api.sap.com/"
+      description: "SAP API Business Hub — verify C1/C2 release contracts for proposed replacement APIs and function modules before recommending them as clean-core-compliant remediation targets"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-custom-code-remediation-review/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-custom-code-remediation-review",
+  "name": "SAP Custom Code Remediation Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review custom ABAP code remediation for S/4HANA readiness: classify ATC findings from S/4HANA readiness check variants, interpret custom code migration app output, map deprecated APIs to released replacements, validate clean-core alignment of proposed remediation paths, and prioritize upgrade-blocking findings. Advisory only — does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/custom-code-migration",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/abap-test-cockpit",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/what-is-abap-cloud",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/released-apis",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/simplification-items",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/abap-cloud-restrictions",
+    "https://api.sap.com/products/SAPS4HANACloud/overview",
+    "https://help.sap.com/docs/abap-cloud/abap-cloud/atc-s4hana-readiness-checks"
+  ],
+  "security_notes": "Does not access live SAP systems. Accepts only user-provided ATC result exports, SYCM output, ABAP source code listings, and object descriptions. Never request or accept ABAP system credentials, RFC destinations, ABAP developer passwords, or BTP service keys. Deprecated API replacement recommendations must be validated against current release contracts on SAP API Business Hub before implementation. ATC exemptions require formal customer approval — this skill does not grant exemptions.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-custom-code-remediation-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}