@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-hana-cloud-performance-cost/references/workflow-and-output.md

@@ -0,0 +1,68 @@
+# Workflow and output contract — SAP HANA Cloud Performance and Cost Review
+
+Use this reference for all finding classification, risk assignment, remediation path selection, and output formatting.
+
+## Review domain taxonomy
+
+| Domain | Scope | Typical findings |
+|--------|-------|-----------------|
+| `sizing-and-elasticity` | vCPU and memory tier selection, scale-out node design, compute auto-scaling, scheduled scaling | Under-provisioned memory for in-memory workload, absent auto-scaling for variable load, single-node design where scale-out is warranted |
+| `data-modeling` | Column store vs. row store choice, table partitioning, index design, delta compression, sort column selection | Missing partitioning on tables over 100M rows, redundant indexes increasing DML overhead, row store table used for analytic scan workloads, missing sort column on frequently filtered column store table |
+| `query-performance` | EXPLAIN PLAN operator analysis, SQL Plan Cache findings, expensive statement trace, optimizer hints | Unexpectedly high row engine operator usage, missing column search operator, suboptimal join order, plan instability between executions, missing access path hint |
+| `sqlscript` | Cursor vs. set-based logic, tabular function design, procedure plan stability, SQLSCRIPT PLAN PROFILER findings | Cursor loop iterating over column store table (row-at-a-time anti-pattern), missing tabular function for reusable intermediate result, unstable procedure plan causing variable execution time |
+| `cost-management` | Auto-stop configuration, compute tier selection, storage auto-scaling thresholds, data tiering (hot/warm/cold) | Non-production instance without auto-stop, compute tier over-provisioned for non-peak base load, missing warm-tier configuration for infrequently accessed historical data |
+| `monitoring` | Expensive statement trace, M_EXPENSIVE_STATEMENTS, workload class definition, thread sampling, M_SQL_PLAN_CACHE | Expensive statement trace not configured, no workload class definitions, thread sampling not enabled, M_SQL_PLAN_CACHE not reviewed for plan evolution |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Production availability risk: memory under-provisioning causing OOM failures on production instance, workload resource exhaustion with no limit controls, unrecoverable performance degradation from missing partitioning on production tables at or near the 2-billion-row limit |
+| `high` | Performance bottleneck or uncontrolled cost: cursor-based SQLScript anti-pattern on large column store table causing query timeout, non-production instances without auto-stop accumulating unbounded compute cost, missing expensive statement trace making incident diagnosis impossible |
+| `medium` | Governance gap or monitoring blind spot: no workload class definitions for multi-tenant resource isolation, missing index on a high-frequency filter column, absent warm-tier configuration for historical data causing unnecessary hot-tier cost |
+| `low` | Best practice deviation: missing sort column selection on a column store table, undocumented partition key rationale, procedure without plan stability documentation |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a production instance memory under-provisioning risk or a table at or approaching the 2-billion-row limit without partitioning?**
+   - Yes → `critical`. For memory: scale up the instance to the next tier immediately; obtain M_LOAD_HISTORY_SERVICE data to confirm memory utilization trend before scaling decision. For partitioning: add range partitioning on the primary date or key dimension; plan for online partition conversion using the HANA Cloud ALTER TABLE ... PARTITION BY syntax.
+   - No → continue.
+
+2. **Is this a cursor-based SQLScript anti-pattern on a column store table causing production query timeouts?**
+   - Yes → `high`. Rewrite the cursor loop as a set-based INSERT INTO ... SELECT, CREATE TABLE AS SELECT, or tabular function. Use SQLSCRIPT PLAN PROFILER (ALTER SYSTEM START SQLSCRIPT PLAN PROFILER FOR PROCEDURE) to confirm the row engine execution path before and after rewrite.
+   - No → continue.
+
+3. **Is this a non-production instance without auto-stop causing unbounded compute cost?**
+   - Yes → `high`. Configure auto-stop via HANA Cloud Central with a daily idle timeout appropriate for the environment (for example, stop after 2 hours of inactivity for development, 4 hours for QA). Document the expected schedule and confirm with instance owners.
+   - No → continue.
+
+4. **Is this a query performance finding identified from user-provided EXPLAIN PLAN or SQL Plan Cache data?**
+   - Yes → `high` or `medium` depending on impact. For suboptimal access paths: add EXPLAIN PLAN hints (CS_ALL_COLUMNS for forced column engine, USE_HEX_PLAN for hexagonal join) and compare execution plan operators. For plan instability: check SQL Plan Cache for plan evolution history and consider UPDATE STATISTICS on the affected tables.
+   - No → continue.
+
+5. **Is this a governance, monitoring, or cost optimization gap?**
+   - Yes → `medium`. Define workload classes with resource limits for query classes (reporting, planning, ETL). Enable expensive statement trace at the threshold appropriate for the workload profile. Configure warm-tier for data older than the retention threshold. 
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — EXPLAIN PLAN output, SQL Plan Cache exports, expensive statement trace results, monitoring view query outputs, architecture documents, or user descriptions.
+2. **Classify each finding** by review domain and finding type.
+3. **Assign risk level** (critical / high / medium / low).
+4. **Apply remediation decision tree** per finding.
+5. **Prioritize** — critical availability and data loss risks first; then high performance and cost findings; then medium governance and monitoring gaps; then low best-practice items.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Review domain and specific finding type
+2. Evidence label (documentation-based / user-provided evidence / context7-supplementary / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended remediation action with specific implementation guidance (including SQL or SQLScript examples where the finding is code-level)
+5. Expected performance or cost posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live HANA Cloud instance access, SQL execution, or system view query is required to confirm or apply the finding

package/skills/sap/sap-hypercare-incident-commander-review/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: sap-hypercare-incident-commander-review
+description: Review hypercare and go-live stabilization governance for SAP S/4HANA and SAP BTP programs: severity triage model, war-room governance and decision authority, incident and problem workflow during hypercare, root-cause investigation process, business impact classification, escalation paths to SAP support and internal leadership, and exit-from-hypercare criteria. Advisory only — does not create or close incident records, escalate to SAP, or mutate any live system or ITSM configuration.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: resilience
+  lifecycle: experimental
+---
+
+# SAP Hypercare and Incident Commander Review
+
+## Purpose
+
+Assess the hypercare and go-live stabilization governance posture for SAP S/4HANA transformation and SAP BTP programs. Review the severity triage model: whether incident severity tiers are defined with objective criteria tied to business impact, whether triage roles and decision authority are named and available during the hypercare window, and whether triage SLAs are defined per severity tier. Evaluate war-room governance: whether a war room structure is established with clear decision authority, named incident commander and functional stream leads, scheduled status cadence, and escalation thresholds that trigger war room activation. Review the incident and problem workflow during hypercare: whether incident records are created for all service disruptions regardless of severity, whether incidents are linked to problem records for recurring or systemic issues, and whether the incident lifecycle (open, in-progress, resolved, closed) is enforced with documented resolution criteria. Assess the root-cause investigation process: whether root-cause analysis is initiated for severity-1 and severity-2 incidents within defined timeframes, whether root-cause evidence (transport history, system logs, business process execution records) is systematically collected, and whether corrective actions are formally tracked to completion. Review business impact classification: whether financial impact, user population affected, regulatory deadline risk, and operational disruption are factored into severity assignments, and whether business process owners are included in impact assessment. Evaluate escalation paths: whether escalation triggers to SAP Active Global Support, SAP Premium Engagement (MaxAttention/Preferred Success), and internal executive leadership are documented, tested, and reachable during hypercare hours. Assess exit-from-hypercare criteria: whether criteria are formally defined, measurable, time-bounded, and approved by a named governance authority, and whether a structured exit review process exists. This is an advisory governance review. It does not create, update, or close incident records, escalate to SAP support, or mutate any ITSM or monitoring configuration.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review the hypercare plan for an SAP S/4HANA go-live or major SAP BTP program stabilization: whether the plan covers severity triage, war-room governance, escalation paths, and exit criteria with sufficient definition,
+- assess the severity triage model: whether severity tiers (1 through 4 or equivalent) are defined with objective, measurable business impact criteria rather than subjective descriptions, and whether triage authority is clearly assigned,
+- evaluate war-room governance: whether the war-room structure has a named incident commander, named functional and technical stream leads, an activation threshold, a communication cadence, and a decision-making protocol for competing priorities during multi-stream incidents,
+- review the incident and problem workflow during the hypercare period: whether all incidents are formally recorded, whether recurring incidents trigger problem record creation, whether root-cause analysis is mandatory for severity-1 and severity-2 incidents, and whether incident resolution includes a verified fix confirmation step,
+- assess the root-cause investigation process: whether a structured root-cause analysis methodology is applied (5-Whys, fishbone, or equivalent), whether evidence collection is systematic, whether corrective actions have named owners and completion deadlines, and whether root-cause findings are shared across affected business and technical teams,
+- review business impact classification: whether revenue at risk, affected user count, regulatory deadline exposure, and business process criticality are used to classify and re-classify incident severity, and whether business process owners participate in severity assessment for business-critical incidents,
+- evaluate escalation paths: whether escalation from technical team to internal leadership (project director, CIO, executive sponsor) is documented with trigger criteria and timing, whether SAP Active Global Support or Premium Engagement escalation procedures are known and exercised, and whether escalation contacts are reachable during hypercare coverage hours including weekends and public holidays,
+- assess exit-from-hypercare criteria: whether criteria are formally agreed, include measurable thresholds for incident frequency, severity distribution, system stability, and business process throughput, and whether the exit review is conducted by a named governance body with authority to formally close the hypercare period.
+
+## When not to use
+
+- When the user wants to create, update, or close incident records in a live ITSM system, escalate an active incident to SAP, or operate a live war room — this skill does not assist with live incident operations. Incident execution requires live ITSM access and is out of scope for this advisory skill.
+- When the user needs a pre-go-live testing strategy and quality gate review — use `sap-testing-quality-gate-review`.
+- When the user needs a data migration or cutover readiness assessment before go-live — use `sap-data-migration-cutover-readiness`.
+- When the user needs release and change collision risk assessment during or after hypercare — use `sap-release-change-collision-review`.
+- When the user needs SAP Cloud ALM operations monitoring configuration review outside the hypercare context — use `sap-cloud-alm-sre-incident-review`.
+
+## Advisory-only boundary — explicitly stated
+
+**This skill does not create, update, or close incident records, escalate to SAP Active Global Support, trigger war-room activation, or mutate any ITSM, monitoring, or SAP system configuration.** It does not:
+
+- connect to any ITSM platform (ServiceNow, JIRA, SAP Cloud ALM incident management) or access live incident records,
+- escalate active incidents to SAP, internal leadership, or business stakeholders,
+- authorize rollback, transport reversal, emergency correction, or any other system change during or after an incident,
+- access SAP system logs, basis event logs, or production data to investigate live incidents,
+- assess whether a specific live incident is resolved or requires escalation.
+
+All hypercare governance assessment is based on hypercare plan documentation, incident management process descriptions, escalation procedure documents, war-room governance charters, and exit criteria documentation supplied by the user.
+
+## Lean operating rules
+
+- Severity criteria must be objective and business-grounded. Severity tiers defined only by technical indicators (system down / system slow / minor issue) without business impact dimensions (revenue at risk, regulatory deadline, affected user count) are incomplete triage criteria.
+- War-room activation threshold must be pre-agreed. A war room that is activated at the discretion of whoever is on duty lacks a consistent governance anchor. Activation criteria must be defined before go-live and known to all hypercare team members.
+- Incident commander authority must be unambiguous. When multiple escalation paths and decision-makers exist in a hypercare war room, ambiguous authority leads to delayed decisions. One named incident commander must have final say on priority and resource allocation during active incidents.
+- Root-cause analysis is mandatory for severity-1 and severity-2 incidents. Closing a major incident without initiating root-cause analysis is a governance gap. The root-cause analysis process must be triggered at incident creation for severity-1 events, not deferred to post-incident review.
+- Exit-from-hypercare criteria must be measurable and time-bounded. "The system is stable" is not a measurable exit criterion. Exit criteria must include thresholds: zero severity-1 incidents in the past N days, severity-2 incident frequency below a defined rate, business process throughput at or above a defined percentage of expected volume.
+- Coverage hours must match business criticality. A 24-hour support window for the first week after go-live that drops to business-hours-only in week two is a risk if the business operates across time zones or if month-end processing falls in week two.
+- Do not fabricate incident counts, severity distributions, or resolution time data. Only classify findings the user has provided from their actual hypercare plan, incident management process documents, or post-incident review records.
+- Evidence from official SAP Activate hypercare methodology and SAP Active Global Support documentation takes precedence over memory or training data.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Activate hypercare methodology documentation, SAP Active Global Support escalation procedures, SAP Cloud ALM incident management documentation, or SAP Help Portal
+- `user-provided evidence` — hypercare plan documents, war-room governance charters, incident management process descriptions, severity triage definitions, escalation procedure documents, exit-from-hypercare criteria documentation, or post-incident review records 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 ITSM API call, SAP system connection, incident record access, live escalation trigger, or monitoring configuration mutation in this skill's execution path. Users must supply hypercare plan documentation, incident management process descriptions, war-room governance charters, escalation procedure documents, and exit criteria documentation for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — hypercare governance domain taxonomy, severity triage model, war-room assessment criteria, root-cause analysis process evaluation, exit criteria classification, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common hypercare governance review mistakes, advisory boundary enforcement, when to push back.
+- [Official sources](references/official-sources.md) — SAP Activate hypercare methodology, SAP Active Global Support escalation procedures, SAP Cloud ALM incident management, SAP MaxAttention and Preferred Success engagement models.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: hypercare governance domains in scope (Severity Triage / War-Room Governance / Incident and Problem Workflow / Root-Cause Investigation / Business Impact Classification / Escalation Paths / Exit-from-Hypercare Criteria) and specific finding per domain.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: hypercare-critical / high / medium / low per governance domain assessed.
+- **Recommended action**: specific governance control per finding (define measurable severity criteria with business impact dimensions, name incident commander with unambiguous authority, mandate root-cause analysis for severity-1 incidents, define measurable exit criteria with thresholds, document escalation contacts and reachability for all coverage hours, etc.), grounded in SAP Activate hypercare methodology or SAP Cloud ALM incident management documentation.
+- **Refusal / escalation triggers**: refuse to assess live incident status or recommend live escalation actions; do not provide guidance on executing ITSM operations or modifying live system configuration; if hypercare plan has no exit criteria, classify as hypercare-critical and flag immediately.
+- **Business impact**: go-live stabilization risk from uncoordinated incident response, regulatory deadline risk from unresolved severity-1 incidents, financial exposure from extended hypercare without exit governance, reputational risk from unresolved business process disruptions during go-live.
+- **Next verification step**: which hypercare plan document, incident management process description, or exit criteria definition must be provided before the hypercare governance posture can be assessed as adequate.

package/skills/sap/sap-hypercare-incident-commander-review/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "SAP Hypercare and Incident Commander Review"
+  short_description: "Advisory review of hypercare and go-live stabilization governance for SAP programs: severity triage, war-room governance, incident and problem workflow, root-cause investigation, business impact classification, escalation paths, and exit-from-hypercare criteria. Does not create incident records, escalate to SAP, or mutate any live system or ITSM configuration."
+  default_prompt: "Use $sap-hypercare-incident-commander-review to assess the provided SAP hypercare governance artifacts. Classify findings by governance domain (Severity Triage / War-Room Governance / Incident and Problem Workflow / Root-Cause Investigation / Business Impact Classification / Escalation Paths / Exit-from-Hypercare Criteria), assign a risk level (hypercare-critical / high / medium / low), state evidence level (documentation-based / user-provided evidence / inference), and recommend specific governance controls per finding. Do not create incident records, escalate to SAP, or access live ITSM or SAP systems."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/f5f6e8c0c82043f3b33879ef88f26f2b.html"
+      description: "SAP Activate hypercare methodology — primary reference for hypercare plan structure, stabilization phase governance, incident command, and exit criteria standards"
+    - type: "web"
+      value: "https://support.sap.com/en/offerings-programs/support-services/active-global-support.html"
+      description: "SAP Active Global Support — reference for SAP support escalation procedures, critical situation handling, and Premium Engagement (MaxAttention/Preferred Success) escalation paths"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-hypercare-incident-commander-review/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "sap-hypercare-incident-commander-review",
+  "name": "SAP Hypercare and Incident Commander Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Advisory review of hypercare and go-live stabilization governance for SAP S/4HANA and SAP BTP programs: severity triage model, war-room governance and decision authority, incident and problem workflow, root-cause investigation process, business impact classification, escalation paths to SAP support and internal leadership, and exit-from-hypercare criteria. Does not create incident records, escalate to SAP, or mutate any live system or ITSM configuration.",
+  "source_type": "original",
+  "category": "resilience",
+  "official_docs": [
+    "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/f5f6e8c0c82043f3b33879ef88f26f2b.html",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/it-task-management",
+    "https://support.sap.com/en/my-support/product-support.html",
+    "https://support.sap.com/en/offerings-programs/support-services/active-global-support.html",
+    "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/3c3e8f1bb1e64df6a2e1f3ad1a1d9c0e.html",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/analytics-and-reporting"
+  ],
+  "security_notes": "Does not connect to any ITSM platform, access live incident records, escalate to SAP Active Global Support, or mutate any monitoring or SAP system configuration. Accepts only user-provided hypercare plan documents, war-room governance charters, incident management process descriptions, severity triage definitions, escalation procedure documents, exit-from-hypercare criteria documentation, and post-incident review records. Never accept actual incident records containing customer or employee PII, system access credentials, SAP support portal credentials, or ITSM service account credentials. Does not authorize rollback, emergency correction, or any system change during or after an incident — those decisions belong to the named incident commander and customer governance authority.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-hypercare-incident-commander-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-hypercare-incident-commander-review/references/official-sources.md

@@ -0,0 +1,63 @@
+# Official sources — SAP Hypercare and Incident Commander Review
+
+Use this reference when grounding severity triage assessment, war-room governance evaluation, incident and problem workflow review, root-cause investigation process assessment, escalation path validation, and exit-from-hypercare criteria evaluation.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Activate methodology documentation, SAP Active Global Support documentation, SAP Cloud ALM application help). No live-system evidence is collected by this skill.
+
+## SAP Activate — Hypercare and Stabilization Methodology
+
+- SAP Activate — Hypercare Plan and Run Phase Stabilization
+  https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/f5f6e8c0c82043f3b33879ef88f26f2b.html
+  source_owner: SAP SE
+  topic_supported: SAP Activate Run phase hypercare deliverables: hypercare plan structure, stabilization period governance, incident triage during go-live, war-room setup, support coverage model, handover from project to operations, exit-from-hypercare criteria and governance
+  why_needed: Primary reference for hypercare governance assessment — defines the SAP Activate-recommended hypercare plan deliverables, stabilization governance model, and exit criteria standards used to classify gaps in hypercare plan completeness and exit criteria definition
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Activate — Go-Live Readiness and Hypercare Planning in the Deploy Phase
+  https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/3c3e8f1bb1e64df6a2e1f3ad1a1d9c0e.html
+  source_owner: SAP SE
+  topic_supported: Deploy phase hypercare preparation: hypercare team structure, on-call coverage model, escalation path definition, war-room charter, go-live communication plan, Day 1 and Week 1 governance
+  why_needed: Required to assess whether hypercare preparation began in the Deploy phase — defines the pre-go-live hypercare planning deliverables, war-room charter requirements, and on-call coverage structure used to evaluate whether the hypercare model is adequately prepared before go-live
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Incident and Problem Management
+
+- IT Task Management in SAP Cloud ALM
+  https://help.sap.com/docs/cloud-alm/applicationhelp/it-task-management
+  source_owner: SAP SE
+  topic_supported: Incident and problem record management in SAP Cloud ALM, severity classification model, escalation path configuration, ITSM platform integration, knowledge article linkage, task assignment and workflow, incident lifecycle governance
+  why_needed: Required to assess Cloud ALM incident and problem management process governance during hypercare — defines the severity model, problem record linkage capability, escalation workflow, and incident lifecycle states used to classify incident management gaps in the hypercare window
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Analytics and Reporting in SAP Cloud ALM
+  https://help.sap.com/docs/cloud-alm/applicationhelp/analytics-and-reporting
+  source_owner: SAP SE
+  topic_supported: Hypercare and operations reporting in SAP Cloud ALM: incident frequency reporting, severity distribution dashboards, SLA performance reporting, business process health tracking, operations cockpit for stabilization monitoring
+  why_needed: Reference for assessing whether hypercare governance reporting is configured in SAP Cloud ALM — defines the reporting and analytics capabilities available for tracking incident frequency, severity trends, and stabilization progress used to evaluate whether exit-from-hypercare criteria can be measured objectively
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Support — Active Global Support and Escalation
+
+- SAP Support — Product Support and Incident Management
+  https://support.sap.com/en/my-support/product-support.html
+  source_owner: SAP SE
+  topic_supported: SAP support incident creation and management, priority definitions (P1 through P4), SAP support SLA by priority, escalation procedures within SAP support, SAP ONE Support Launchpad access
+  why_needed: Required to assess escalation path completeness — defines the SAP support priority model, SLA commitments per priority, and escalation procedures within SAP product support used to evaluate whether the hypercare escalation procedure correctly maps internal severity tiers to SAP support priorities
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Active Global Support — Critical Situation Handling and Premium Engagement
+  https://support.sap.com/en/offerings-programs/support-services/active-global-support.html
+  source_owner: SAP SE
+  topic_supported: SAP Active Global Support (AGS) service portfolio, Critical Situation (CritSit) procedure, SAP MaxAttention and Preferred Success engagement models, escalation to SAP product management for blocking issues, SAP Go-Live Support services
+  why_needed: Required to assess premium support escalation path completeness — defines the SAP CritSit procedure, MaxAttention and Preferred Success escalation model, and Go-Live Support services used to evaluate whether organizations with premium SAP support agreements have correctly configured and tested their escalation paths for hypercare
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal, SAP Activate methodology documentation, and SAP Active Global Support documentation describe the designed hypercare governance model, recommended incident management workflow, severity triage framework, and escalation procedure for SAP programs. They do not prove how the user's hypercare team is structured, what severity criteria the user's program has defined, whether the user's escalation contacts are reachable during hypercare hours, or whether the user's exit criteria are measurable. Users must supply hypercare plan documents, war-room governance charters, incident management process descriptions, severity triage definitions, escalation procedure documents, and exit criteria documentation for concrete governance assessment.

package/skills/sap/sap-hypercare-incident-commander-review/references/safety-checklist.md

@@ -0,0 +1,55 @@
+# Safety checklist — SAP Hypercare and Incident Commander Review
+
+Use before making any hypercare governance finding or remediation recommendation, especially for findings involving severity-1 incident triage, war-room governance gaps, root-cause investigation process, escalation path completeness, or exit-from-hypercare criteria.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live ITSM platform (ServiceNow, JIRA, SAP Cloud ALM incident management), live incident record store, SAP support portal, or any SAP production system.
+- Do not accept or request actual incident records containing customer PII, employee PII, financial transaction data, or personally identifiable system access information.
+- Do not accept SAP support portal credentials, ITSM service account credentials, Cloud ALM admin credentials, or SAP system access parameters.
+- Do not create, update, close, or recommend closing incident or problem records in any live ITSM or SAP Cloud ALM system.
+- Do not escalate active incidents to SAP Active Global Support, SAP MaxAttention or Preferred Success teams, or any internal executive contact. Live incident escalation is a live operations activity that is out of scope for this advisory skill.
+- Do not authorize, recommend, or imply authorization for system rollback, emergency transport, business process workaround, or any system change during or after an incident. Those decisions belong to the named incident commander and customer governance authority.
+- Do not assess whether a specific live incident is currently resolved, escalated, or requires immediate action — this skill reviews governance artifacts only.
+- Do not fabricate incident counts, severity distributions, mean time to resolve data, or root-cause findings. Only classify findings the user has provided from their actual hypercare plan, incident management process documents, or post-incident review records.
+
+## Advisory-only boundary enforcement
+
+If the user asks this skill to:
+- "escalate this incident to SAP,"
+- "open a P1 ticket with SAP for this issue,"
+- "tell me if we need to roll back,"
+- "help me run the war room,"
+- "authorize an emergency transport,"
+- "close the hypercare period,"
+- "tell me if the incident is resolved,"
+
+respond: This skill is an advisory hypercare governance reviewer and does not create incident records, escalate to SAP, authorize system changes, operate live incident response, or assess the status of live incidents. For live incident escalation, war-room operation, or system change authorization, the named incident commander and customer governance authority must be engaged directly.
+
+## What people get wrong
+
+- **Treating hypercare as solely a technical function**: Hypercare governance requires active involvement from business process owners, finance and operations leads, and executive sponsors — not only the technical project team. Severity-1 incidents during go-live frequently have business process dimensions that technical teams cannot assess alone. Governance structures that do not include business stream leads are incomplete.
+- **Defining severity by technical indicators only**: Severity tiers defined as "system down / system slow / minor issue" without business impact dimensions will mis-triage incidents where the system is technically functioning but a critical business process (payroll, financial close, customer order confirmation) is impaired. Severity must reflect business impact, not only technical health.
+- **Not naming a single incident commander**: War rooms with multiple co-equal decision-makers stall at critical decision points. When rollback authorization, emergency transport approval, or workaround implementation requires a governance decision under time pressure, ambiguous authority is a hypercare risk.
+- **Exiting hypercare by calendar date rather than criteria**: A hypercare period that ends on a fixed calendar date regardless of system stability or incident frequency is a governance gap. Exit must be earned by meeting measurable thresholds, not elapsed by default.
+- **Underestimating the risk of month-end close during hypercare**: If hypercare overlaps with a financial period close, the severity-1 risk surface is at its peak. Programs that plan a lean hypercare team for week three because "the go-live was smooth" and then encounter period-close processing volumes for the first time are regularly surprised. Month-end and year-end close timing must be explicitly addressed in hypercare planning.
+- **Not testing escalation paths before go-live**: An escalation path to SAP Premium Engagement or to the executive sponsor that has never been exercised — even a test call to confirm the bridge number works and the contact is reachable — is an untested dependency. All escalation paths must be verified before go-live, not assumed to work.
+- **Conflating incident closure with problem resolution**: Closing an incident when the immediate symptom is resolved does not resolve the underlying problem. If the root cause is not investigated and a corrective action is not tracked, the same incident will recur. Problem management must be explicitly separated from incident closure during hypercare governance review.
+- **Treating SAP support priority mapping as automatic**: SAP support incident priority (P1 through P4) does not automatically correspond to internal hypercare severity tiers. The mapping must be explicitly documented and communicated to the hypercare team so that incidents requiring SAP support are created with the correct SAP priority from the start.
+
+## When to push back
+
+- Push back immediately when the hypercare plan has no exit criteria or only calendar-date-based exit criteria — classify as hypercare-critical and flag to program leadership before go-live.
+- Push back when the war room has no named incident commander or when incident command authority is described as shared between co-equal leads.
+- Push back when severity criteria are subjective ("critical if it feels urgent") without objective business impact dimensions.
+- Push back when escalation paths have not been tested or verified before go-live, or when escalation contacts are not confirmed as reachable during the full coverage window including weekends and public holidays.
+- Push back when hypercare coverage hours do not align with the business operating hours or with month-end or year-end close timing.
+- Push back when root-cause analysis for severity-1 incidents is described as deferred to post-incident retrospective rather than initiated at incident creation.
+- Push back when the user asks for live incident assessment, active escalation guidance, or authorization for system changes.
+- Push back when the user provides actual incident records containing PII or financial transaction data — request anonymized process descriptions instead.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Activate hypercare methodology documentation, SAP Active Global Support escalation documentation, SAP Cloud ALM incident management documentation, or SAP Help Portal
+- `user-provided evidence` — hypercare plan documents, war-room governance charters, incident management process descriptions, severity triage definitions, escalation procedure documents, exit-from-hypercare criteria documentation, or post-incident review records 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-hypercare-incident-commander-review/references/workflow-and-output.md

@@ -0,0 +1,98 @@
+# Workflow and output contract — SAP Hypercare and Incident Commander Review
+
+Use this reference for all hypercare governance assessment, severity triage evaluation, war-room review, root-cause process classification, and output formatting.
+
+## Hypercare governance domain taxonomy
+
+| Domain | Description |
+|--------|-------------|
+| `severity-triage` | Severity tier definitions with objective business impact criteria; triage authority assignment; triage SLA per tier |
+| `war-room-governance` | War-room activation threshold; named incident commander; functional and technical stream lead assignment; communication cadence; decision-making protocol |
+| `incident-problem-workflow` | Incident record creation for all disruptions; problem record creation for recurring or systemic issues; incident lifecycle enforcement; resolution verification |
+| `root-cause-investigation` | Root-cause analysis initiation criteria; structured methodology; evidence collection process; corrective action tracking; finding distribution |
+| `business-impact-classification` | Business impact dimensions in severity assignment (revenue, user population, regulatory deadline, process criticality); business process owner involvement |
+| `escalation-paths` | Internal escalation triggers and contacts (project director, CIO, executive sponsor); SAP support escalation mapping; premium engagement escalation; coverage hours reachability |
+| `exit-from-hypercare-criteria` | Measurable exit thresholds; time-bounded criteria; formal governance body for exit review; handover to steady-state operations |
+
+## Severity triage model
+
+| Severity tier | Business impact criteria (required for objective triage) | Triage SLA | War-room trigger |
+|---------------|--------------------------------------------------------|------------|-----------------|
+| `severity-1` | Complete production outage affecting all users OR financial posting capability lost OR regulatory reporting deadline at risk within 24 hours | Triage owner acknowledged within 15 minutes; incident commander engaged within 30 minutes | Immediate war-room activation |
+| `severity-2` | Major business process disruption affecting a significant user population OR critical interface down affecting order-to-cash, procure-to-pay, or payroll OR SLA breach imminent for business-critical milestone | Triage within 30 minutes; functional lead engaged within 1 hour | War-room activation if unresolved within 2 hours |
+| `severity-3` | Partial process disruption with workaround available OR non-critical interface degradation OR reporting anomaly without operational impact | Triage within 2 hours; assigned and in progress within 4 hours | No war-room; escalate to severity-2 if workaround fails |
+| `severity-4` | Minor issue with no operational impact OR cosmetic defect OR enhancement request surfaced during hypercare | Assessed and backlogged within 1 business day | No war-room; tracked in defect backlog for post-hypercare release |
+
+## War-room governance assessment criteria
+
+A governed war room during SAP hypercare must include:
+
+- Activation threshold: objective criteria that trigger war-room activation (minimum: any severity-1 incident; optionally: concurrent severity-2 incidents above a defined count)
+- Named incident commander: one named individual with final authority on priority and resource allocation during active war room; one named backup
+- Functional stream leads: named representatives for each business process workstream in scope (finance, logistics, procurement, HR, etc.)
+- Technical stream leads: named representatives for ABAP/Basis, integration, BTP platform, and infrastructure
+- Communication cadence: defined status update frequency during active incidents (minimum: every 30 minutes for severity-1; every 60 minutes for severity-2 war room)
+- Decision-making protocol: documented escalation path for decisions that exceed incident commander authority (system rollback, emergency transport, business process workaround authorization)
+- Bridge and communication tool: defined conference bridge, collaboration channel (Microsoft Teams, SAP Cloud ALM war-room feature, etc.), and communication log
+
+## Incident and problem workflow assessment criteria
+
+A governed incident workflow during hypercare must include:
+
+- Universal incident recording: all service disruptions, regardless of severity, result in an incident record in the designated ITSM tool
+- Severity assignment at creation: severity tier assigned at incident creation time using the defined triage model — not retroactively
+- Problem record trigger: three or more incidents with the same symptoms or root cause within a 7-day window must trigger problem record creation and formal root-cause investigation
+- Resolution criteria: incident closure requires a verified fix confirmation step — confirming that the business process or system function that failed is now operating within normal parameters
+- Post-incident review: severity-1 and severity-2 incidents require a documented post-incident review with root-cause summary and corrective action list within a defined timeframe after incident closure
+
+## Root-cause investigation process criteria
+
+A governed root-cause investigation during hypercare must include:
+
+- Initiation trigger: root-cause analysis initiated at incident creation for severity-1; within 4 hours for severity-2
+- Methodology: structured root-cause analysis approach applied (5-Whys, fishbone diagram, or equivalent); method must be documented and consistent
+- Evidence collection: systematic collection of transport history, system event logs, business process execution records, and user reports relevant to the incident timeline
+- Corrective action tracking: each root cause generates a corrective action with a named owner, completion deadline, and verification method
+- Finding distribution: root-cause summary shared with technical teams, business process owners, and project leadership within a defined timeframe
+
+## Exit-from-hypercare criteria taxonomy
+
+Each criterion must be: measurable (specific numeric threshold), time-bounded (observed over a defined window), and governed (approved by a named authority before hypercare begins).
+
+| Criterion | Example measurable threshold | Risk if absent |
+|-----------|-----------------------------|--------------------|
+| `incident-frequency` | Zero severity-1 incidents in the past 7 consecutive calendar days | Hypercare exit with unresolved systemic instability |
+| `severity-distribution` | No more than two severity-2 incidents per week for two consecutive weeks | Premature exit while recurring high-severity issues persist |
+| `open-critical-defects` | Zero open severity-1 defects; all open severity-2 defects have accepted workarounds or fix transport scheduled | Exiting hypercare with known unresolved critical issues |
+| `business-process-throughput` | Business process transaction volume at or above 90% of expected daily volume for 5 consecutive business days | System technically stable but business process adoption below target |
+| `system-performance` | Key transaction response times within defined SLA thresholds for 5 consecutive business days | Performance degradation masked by low initial load |
+| `support-handover-complete` | Steady-state operations team trained, runbook received, and hypercare escalation contacts transitioned to standard support model | Abrupt handover with unprepared operations team |
+
+## Workflow
+
+1. **Identify hypercare scope** — confirm system types in scope, go-live date or approximate elapsed hypercare period, SAP support engagement level (standard / Preferred Success / MaxAttention).
+2. **Assess severity triage model** — confirm objective business impact criteria, triage authority assignment, and triage SLA definition per tier.
+3. **Evaluate war-room governance** — confirm activation threshold, named incident commander, stream lead assignments, communication cadence, and decision protocol.
+4. **Review incident and problem workflow** — assess universal recording, severity assignment timeliness, problem record triggers, and resolution criteria.
+5. **Assess root-cause investigation process** — confirm initiation criteria, methodology, evidence collection, corrective action tracking, and finding distribution.
+6. **Review business impact classification** — confirm that business impact dimensions are factored into severity triage and that business process owners participate in assessment.
+7. **Evaluate escalation paths** — confirm internal escalation triggers, SAP support priority mapping, premium engagement escalation, and coverage hours reachability.
+8. **Assess exit-from-hypercare criteria** — confirm measurability, time bounds, governance authority, and handover completeness criteria.
+9. **Assign overall hypercare governance posture** — `hypercare-ready` (all domains assessed as governed) / `conditional` (gaps with documented mitigation and accepted risk) / `hypercare-at-risk` (one or more domains with hypercare-critical or high-risk finding).
+10. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Hypercare scope (system types, go-live date or elapsed period, SAP support engagement level)
+2. Evidence label per domain (documentation-based / user-provided evidence / inference)
+3. Hypercare governance assessment table: domain, posture (GOVERNED/PARTIAL/UNGOVERNED/NOT-YET-ASSESSED), finding description
+4. Severity triage model completeness: objective vs. subjective criteria, triage authority assignment, SLA definition
+5. War-room governance completeness: activation threshold, named incident commander, stream lead coverage, communication cadence
+6. Exit-from-hypercare criteria completeness: measurable thresholds present, time-bounded, governance body named
+7. Overall hypercare governance posture: hypercare-ready / conditional / hypercare-at-risk
+8. Risk level per domain (hypercare-critical / high / medium / low)
+9. Prioritized governance gap remediation recommendations with SAP Activate hypercare methodology or Cloud ALM incident management reference
+10. Escalation notice for hypercare-critical findings — explicit statement that the program leadership must be made aware and the gap must be resolved before go-live or before the next hypercare phase
+11. Explicit advisory boundary reminder: this review does not create incident records, escalate to SAP, authorize system changes, or operate live incident response