@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.0

package/skills/sap/sap-supply-chain-ibp-resilience-review/references/safety-checklist.md

@@ -0,0 +1,38 @@
+# Safety checklist — SAP Supply Chain IBP Resilience Review
+
+Use before making any IBP resilience remediation recommendation, especially for findings involving single-source supply dependencies, forecast bias in critical product segments, infeasible supply plans, or missing control tower coverage for material exceptions.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP IBP tenant, SAP S/4HANA system, IBP Excel add-in session, IBP Fiori launchpad, or production supply chain planning database. This skill reviews artifacts only.
+- Do not accept or request SAP IBP login credentials, API tokens, IBP Excel add-in connection details, or direct planning database access.
+- Do not create, modify, approve, publish, or activate demand plans, supply plans, inventory targets, alert rules, scenario configurations, or S&OP plan versions. There is no planning data mutation in this skill's execution path. Recommendations always describe configuration and process design changes, not direct plan modifications.
+- Do not recommend implementing IBP configuration changes (alert threshold edits, safety stock parameter updates, forecasting model changes) directly in a production IBP tenant. All recommendations must first be tested in a non-production IBP environment before promoting to the live planning system.
+- Do not use memory alone to assert what forecasting algorithms are active in the user's IBP tenant, what safety stock parameters are configured, or what control tower alert thresholds are set. All findings must be grounded in user-provided artifacts or official SAP IBP documentation.
+- Do not conflate forecast accuracy improvement (a model and process improvement action) with forecast override (a one-time correction to a specific period forecast). Overrides address symptoms; model improvement addresses root cause. Distinguish between these when recommending remediation.
+- Do not treat alert threshold recalibration as a substitute for alert coverage gap resolution. Raising a threshold to reduce noise is different from adding a missing alert rule for an uncovered exception type. Both may be needed but for different reasons.
+
+## What people get wrong
+
+- **Treating safety stock as a demand-only buffer**: Safety stock that only buffers demand variability (demand standard deviation × service level factor × replenishment lead time) but ignores supplier lead time variability systematically understates the required buffer for supply-side disruption scenarios. The formula must incorporate both demand and supply uncertainty to be structurally complete.
+- **Conflating a completed S&OP meeting with a consensus plan**: An S&OP meeting that reviews plans but does not resolve disagreements, close capacity gaps, or produce a single version-controlled approved plan is not a functioning S&OP process regardless of meeting frequency. S&OP governance requires a decision output, not just a discussion forum.
+- **Overlooking lifecycle planning gaps for new product introduction**: Demand planning reviews often focus on established product lines with historical data. New product introduction (NPI) and end-of-life (EOL) transitions require lifecycle planning configuration in IBP because statistical algorithms cannot produce useful forecasts without historical data or lifecycle profile guidance. Missing lifecycle planning for NPI/EOL is a common and high-impact demand planning gap.
+- **Accepting control tower alert counts as a proxy for control tower effectiveness**: High daily alert counts may indicate good coverage or may indicate threshold miscalibration producing noise. Low alert counts may indicate good calibration or may indicate coverage gaps masking real exceptions. Alert count alone does not assess control tower quality — the actionable exception rate and coverage mapping against known exception types are the meaningful measures.
+- **Missing the single-source supply dependency check**: Supply planning reviews often assess whether the plan is feasible against modeled constraints but do not systematically identify single-source dependencies that exist outside the model. A feasible supply plan built on an unmodeled single-source dependency can fail catastrophically in a real disruption even when the plan shows no exceptions.
+- **Treating IBP scenario planning as a crisis response tool**: Scenario planning that is only activated during or after a disruption event (reactive) provides limited resilience value. Proactive scenario planning — modeling high-probability disruption scenarios before they occur and integrating the outputs into S&OP — is the governance model that delivers resilience. A reactive-only scenario planning posture is a medium finding regardless of scenario quality.
+- **Ignoring forecast bias direction**: Positive systematic bias (forecasting too high) creates excess inventory and working capital consumption. Negative systematic bias (forecasting too low) creates stockouts and service level failures. Both are material, but they create different downstream impacts. Bias direction must be noted when classifying forecast accuracy findings.
+
+## When to push back
+
+- Push back (and escalate to supply chain leadership) when a critical single-source supply dependency with no contingency plan is identified for a product critical to customer service or revenue — do not defer this for a routine planning cycle.
+- Push back when the user asks to confirm IBP planning quality from memory alone without providing planning parameter exports, forecast accuracy reports, alert rule summaries, or written descriptions of the IBP configuration.
+- Push back when the request requires live IBP tenant access, IBP API calls, or real-time supply plan inspection — state clearly that live inspection is out of scope and ask the user to supply the relevant exports, reports, or summaries.
+- Push back when asked to create demand plans, modify supply plans, change inventory targets, activate alert rules, or publish S&OP plan versions — this is an absolute boundary and must be refused in all circumstances.
+- Push back when asked to confirm that the supply chain is resilient without evidence that single-source dependencies have been modeled in scenario planning and that safety stock incorporates lead time variability.
+- Push back when the user presents a single planning horizon or single product segment view as a complete IBP resilience assessment — demand planning, supply planning, inventory optimization, control tower, and scenario planning must all be assessed for a meaningful resilience posture evaluation.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Integrated Business Planning Help Portal documentation, SAP IBP configuration guides, SAP supply chain best practice documentation, or SAP S&OP governance guidance
+- `user-provided evidence` — planning parameter exports, S&OP process documentation, forecast accuracy metric reports, inventory policy summaries, control tower alert rule descriptions, scenario planning configuration notes, supply plan exception reports, or written 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-supply-chain-ibp-resilience-review/references/workflow-and-output.md

@@ -0,0 +1,89 @@
+# Workflow and output contract — SAP Supply Chain IBP Resilience Review
+
+Use this reference for all IBP resilience finding classification, risk level assignment, remediation path selection, and output formatting.
+
+## IBP resilience finding taxonomy
+
+| Domain | Finding class | Description |
+|--------|--------------|-------------|
+| `demand-planning` | `forecast-bias-unaddressed` | Statistical demand forecast shows persistent positive or negative bias above a material threshold that is tracked but not being corrected through model parameter adjustment or override governance |
+| `demand-planning` | `wrong-model-for-demand-pattern` | Forecasting algorithm is mismatched to the demand pattern — smooth demand model applied to intermittent or highly variable demand, or no lifecycle model for new product or end-of-life products |
+| `demand-planning` | `consensus-process-governance-gap` | Consensus demand planning process has no structured override governance — demand planners or commercial teams can override statistical forecasts without documented justification, accountability, or accuracy tracking |
+| `supply-planning` | `capacity-constraint-not-modeled` | A material production, transport, or storage capacity constraint exists in the physical supply chain but is not represented in the IBP supply planning model — supply plans can be infeasible against the unmodeled constraint |
+| `supply-planning` | `single-source-not-in-plan` | A product or location relies on a single source of supply with no alternative source, and no supply planning scenario or contingency supply path is modeled in IBP |
+| `supply-planning` | `supply-plan-exception-unresolved` | IBP supply plan exceptions (capacity violation, supply shortfall, lead time breach) are accumulating without a defined resolution workflow or ownership assignment |
+| `sop-governance` | `competing-plan-versions` | S&OP process results in multiple unresolved plan versions across functions (finance, supply chain, commercial) without a governance-driven consensus resolution and single approved plan |
+| `sop-governance` | `no-escalation-path` | S&OP cadence has no structured escalation path for unresolved volume or capacity gaps — disagreements between functions are not escalated to a decision authority within the S&OP cycle |
+| `sop-governance` | `sop-cycle-not-structured` | S&OP meeting cadence exists but is not supported by a structured IBP plan version workflow — meetings discuss plans that are not version-controlled or traceable to the S&OP output |
+| `inventory-optimization` | `safety-stock-excludes-lead-time-variability` | Safety stock calculation uses demand variability only and does not account for supplier lead time variability or replenishment cycle uncertainty — safety stock is structurally understated for disruption-exposed supply lanes |
+| `inventory-optimization` | `service-level-target-not-stratified` | All products or locations are assigned the same service level target regardless of criticality or margin profile — high-value or critical products are not differentiated from low-priority SKUs in safety stock policy |
+| `inventory-optimization` | `stratification-stale` | ABC/XYZ or equivalent inventory stratification has not been refreshed to reflect current demand patterns — products that have changed demand profile (seasonal, ramp-up, decline) retain stale inventory policy parameters |
+| `forecast-accuracy` | `accuracy-metric-not-configured` | IBP forecast error metrics (MAPE, WMAPE, bias, tracking signal) are not configured or not reported — forecast quality is invisible to planning management |
+| `forecast-accuracy` | `accuracy-not-driving-improvement` | Forecast accuracy metrics are reported but are not linked to a model review or parameter tuning process — persistent low accuracy in a product segment is not triggering a planning improvement response |
+| `control-tower` | `alert-coverage-gap` | Material supply chain exception types (demand deviation, inventory below safety stock, supplier delivery failure, transportation delay) are not covered by control tower alert rules — exceptions occur without alert generation |
+| `control-tower` | `alert-fatigue` | Alert volume is high relative to actionable exception rate — more than 30% of daily alerts are resolved without action, indicating threshold miscalibration or alert hierarchy design gap |
+| `control-tower` | `alert-no-owner` | Control tower alerts are generated but not routed to a defined owner or team — alerts age without resolution and exception patterns are not escalated |
+| `scenario-planning` | `disruption-scenario-missing` | High-probability supply disruption scenarios (single-source failure, major geographic event, demand shock) have not been modeled in IBP scenario planning — financial and service level impact is unquantified |
+| `scenario-planning` | `scenario-not-in-sop` | Scenario planning outputs are not integrated into the S&OP review process — what-if analysis is conducted outside the governance cycle and does not inform the consensus plan |
+
+## Risk level assignment
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Supply plan cannot respond to a high-probability disruption due to single-source dependency with no modeled contingency and no alternative supply path; S&OP producing competing unresolved plans with no governance escalation path and active supply constraint |
+| `high` | Persistent forecast bias distorting supply plan at material scale; safety stock not accounting for lead time variability in a disruption-exposed supply lane; capacity constraint not modeled causing infeasible supply plans; critical control tower alert coverage gap masking material exceptions |
+| `medium` | Alert fatigue with resolution rate indicating threshold miscalibration; inventory stratification stale; S&OP without structured escalation; scenario planning not integrated with S&OP; consensus demand planning without override governance |
+| `low` | Best practice deviation in forecasting model selection or S&OP template design; minor alert rule refinement opportunity; cosmetic inventory stratification adjustment |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is there a single-source supply dependency with no modeled contingency and no alternative supply path for a critical product?**
+   - Yes → `critical`. Escalate to supply chain leadership. Add the single-source disruption as an immediate what-if scenario in IBP. Identify and qualify alternative suppliers. Define a contingency supply path and minimum inventory buffer as an interim measure until alternative sourcing is secured.
+   - No → continue.
+
+2. **Is there persistent forecast bias above a material threshold that is not being corrected?**
+   - Yes → `high`. Review and adjust the statistical forecasting model parameters for the biased product segments. Implement a bias correction adjustment in the consensus demand planning process. Track bias correction effectiveness monthly.
+   - No → continue.
+
+3. **Is safety stock excluding lead time variability for a disruption-exposed supply lane?**
+   - Yes → `high`. Update the safety stock calculation method to incorporate supplier lead time standard deviation alongside demand variability. Recalculate safety stock targets for affected products and locations. Review service level targets for alignment with the updated calculation.
+   - No → continue.
+
+4. **Is a material capacity constraint missing from the supply planning model?**
+   - Yes → `high`. Model the missing capacity constraint in IBP supply planning. Re-run supply plan for affected planning buckets and review plan feasibility. Add capacity violation alerts to the control tower for the newly modeled constraint.
+   - No → continue.
+
+5. **Is a critical control tower alert coverage gap masking material supply chain exceptions?**
+   - Yes → `high`. Define and activate alert rules for the uncovered exception type. Assign an alert owner and resolution workflow for the new alert type. Monitor false positive rate for the first two weeks after activation and recalibrate thresholds if alert fatigue emerges.
+   - No → continue.
+
+6. **Is there an alert fatigue pattern (>30% of alerts resolved without action)?**
+   - Yes → `medium`. Review alert thresholds for the highest-volume low-action alert types. Raise thresholds to filter noise. Implement an alert hierarchy that promotes only high-severity exceptions to active monitoring dashboards. Track actionable exception rate after recalibration.
+   - No → classify as `medium` or `low` and provide guidance.
+
+## Workflow
+
+1. **Receive artifacts** — planning parameter exports, S&OP process documentation, forecast accuracy reports, inventory policy summaries, control tower alert rule descriptions, scenario planning notes, supply plan exception reports, or written descriptions of the IBP planning landscape.
+2. **Classify each finding** by IBP planning domain and finding class.
+3. **Assign risk level** per the table above (critical / high / medium / low).
+4. **Flag critical findings** immediately — single-source supply dependencies with no contingency and infeasible supply plans with no escalation path must be surfaced before other remediation.
+5. **Apply remediation decision tree** per finding.
+6. **Prioritize** — critical single-source and S&OP governance failures first; then high forecast bias, safety stock gaps, capacity modeling gaps, and control tower coverage gaps; then medium alert fatigue and stratification staleness; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. IBP planning 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. Finding detail: affected planning dimension (product, location, planning bucket), IBP module (demand planning, supply planning, S&OP, inventory optimization, control tower, scenario planning), and specific configuration or governance gap
+5. Quantified impact estimate where data is available (forecast bias percentage, safety stock shortfall, alert noise rate, scenario financial impact gap)
+6. Recommended remediation action (forecasting model parameter adjustment, safety stock method update, capacity constraint modeling, alert threshold recalibration, S&OP escalation path design, scenario addition, stratification refresh, etc.)
+7. IBP resilience posture after remediation
+8. Escalation notice for any critical single-source supply dependency with no contingency — explicit statement that this requires supply chain leadership review and contingency plan activation
+9. Prioritized remediation sequence
+10. Confirmation that no demand plans were modified, no supply plans were run, no inventory targets were changed, and no alert configurations were activated or modified in this review

package/skills/sap/sap-testing-quality-gate-review/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: sap-testing-quality-gate-review
+description: Review SAP testing strategy and quality gate completeness for S/4HANA and SAP BTP programs: test scope and risk-based prioritization, SAP Cloud ALM test management configuration, automation coverage with Tricentis/CBTA, regression strategy for upgrades and transports, test data availability and masking, defect management workflow, and entry and exit criteria per test phase. Advisory only — does not execute tests, trigger automation runs, or mutate test management configuration.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: delivery
+  lifecycle: experimental
+---
+
+# SAP Testing and Quality Gate Review
+
+## Purpose
+
+Assess the completeness and risk coverage of the SAP testing strategy for S/4HANA transformation and SAP BTP programs. Review test scope and risk-based test prioritization: which business processes are in scope, how risk tiers are assigned, and whether high-risk or integration-intensive processes have adequate test coverage. Evaluate SAP Cloud ALM test management configuration: test plan structure, test case library completeness, defect record integration, and test execution tracking. Assess automation coverage with Tricentis Test Automation for SAP (formerly CBTA): which regression suites are automated, which processes remain manual, and whether automation coverage is sufficient for regression cycles on upgrade or transport-heavy releases. Review the regression strategy for system upgrades, support packages, and change transport cycles: how regression scope is defined, how often regression is executed, and whether regression results gate transport imports into production. Assess test data availability and data masking: whether representative test data exists for all test tiers, whether production data used in test environments is masked or anonymized, and whether test data refresh cadence supports the test schedule. Evaluate defect management workflow: severity and priority classification, defect-to-transport traceability, defect backlog governance, and exit criteria enforcement at defect closure gates. Validate that entry and exit criteria are formally defined and measurable for each test phase (unit, integration, UAT, regression, performance). This is an advisory quality gate review. It does not execute tests, trigger automation runs, import transports, or mutate SAP Cloud ALM test management configuration.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review the overall testing strategy for an SAP S/4HANA transformation or BTP program, including which test types are planned (unit, string, integration, regression, UAT, performance) and how coverage is allocated across business processes,
+- assess risk-based test prioritization: whether high-risk processes (financial close, order-to-cash, payroll, integration-intensive flows) have adequate test case coverage and whether the risk tier assignment rationale is documented,
+- evaluate SAP Cloud ALM test management configuration: whether test plans are structured per phase, whether test cases are linked to business processes and requirements, whether defect records are created from failed test cases, and whether test execution progress is tracked and reported,
+- assess automation coverage with Tricentis Test Automation for SAP (formerly CBTA): what percentage of regression test cases are automated, whether automation scripts are maintained and current for the target release, and whether automated regression is executed as part of the transport release cycle,
+- review the regression strategy for upgrades and change transport cycles: how regression scope is selected, how baseline regression is maintained, and whether regression execution gates transport imports into the production environment,
+- assess test data availability and masking: whether representative test data exists at the volume and variety required for each test phase, whether production data used in lower environments is anonymized or masked, and whether test data refresh procedures are documented and followed,
+- evaluate defect management workflow: whether defect severity and priority classifications are consistently applied, whether defects are traceable to the transport responsible for the change, whether the defect backlog is actively governed, and whether exit criteria require resolution of all open defects above a defined severity threshold before phase sign-off,
+- review entry and exit criteria for each test phase: whether criteria are formally documented, measurable (not subjective), and enforced by named sign-off authority.
+
+## When not to use
+
+- When the user wants to execute test cases, trigger Tricentis automation runs, or operate SAP Cloud ALM test plans — this skill does not assist with test execution. A separate guarded execution agent would be required.
+- When the user needs a data migration readiness assessment — use `sap-data-migration-cutover-readiness`.
+- When the user needs a transport or change management collision review — use `sap-release-change-collision-review`.
+- When the user needs a go-live or hypercare incident command review — use `sap-hypercare-incident-commander-review`.
+- When the user needs live SAP Cloud ALM operations monitoring or incident governance review rather than test management — use `sap-cloud-alm-sre-incident-review`.
+
+## Advisory-only boundary — explicitly stated
+
+**This skill does not execute tests, trigger automation runs, or mutate any SAP Cloud ALM test management configuration.** It does not:
+
+- connect to SAP Cloud ALM tenants, Tricentis platforms, CBTA test runners, or any SAP system,
+- trigger test case execution, automation script runs, or regression suite invocations,
+- create, update, or close defect records, test plans, or test cases in any test management tool,
+- approve, authorize, or imply authorization for phase exit or go/no-go sign-off decisions,
+- access production test data, personally identifiable data, or business records from any SAP environment.
+
+All quality gate assessment is based on testing strategy documentation, test plan descriptions, defect status summaries, automation coverage reports, and test data management documentation supplied by the user. Test execution is a risk-relevant activity that requires a separate explicitly scoped execution skill.
+
+## Lean operating rules
+
+- Risk-based prioritization must be evidence-grounded. A testing strategy that applies equal effort across all business processes regardless of risk profile is not a risk-based strategy. Risk tiers must be assigned with documented rationale and must drive test case count and automation investment allocation.
+- Automation coverage must be quantified. A claim that "automation is in place" is not sufficient. The automation coverage percentage for regression test cases must be stated, and the maintenance status of automation scripts must be confirmed against the target SAP release.
+- Entry and exit criteria must be measurable. Subjective exit criteria such as "UAT is substantially complete" or "quality is acceptable" are not enforceable. Criteria must include specific numeric thresholds: defect counts by severity, test case execution percentage, pass rate minimum.
+- Test data masking is non-negotiable for production data in test environments. Any use of unmasked production data containing personally identifiable information or confidential business data in a lower environment is a compliance finding regardless of the testing benefit.
+- Defect backlog governance is required before phase exit. An unreviewed defect backlog at phase exit boundary is a quality gate failure. All open defects must be reviewed, classified, and assigned a resolution or accepted-risk status before exit criteria can be evaluated.
+- Do not fabricate defect counts, test execution rates, or automation coverage percentages. Only classify findings the user has provided from their actual test management reports or automation coverage outputs.
+- Evidence from official SAP Cloud ALM documentation and Tricentis documentation takes precedence over memory or training data.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Cloud ALM test management documentation, Tricentis Test Automation for SAP documentation, SAP Activate testing methodology guidance, or SAP Help Portal
+- `user-provided evidence` — test strategy documents, test plans, defect status reports, automation coverage reports, test data management documentation, or phase exit criteria documents 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, Tricentis platform connection, test case execution, automation script run, or SAP system access in this skill's execution path. Users must supply testing strategy documentation, test plan descriptions, defect status summaries, automation coverage reports, and test data management documentation for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — test phase taxonomy, quality gate assessment dimensions, risk tier classification, defect governance criteria, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common testing strategy review mistakes, advisory boundary enforcement, when to push back.
+- [Official sources](references/official-sources.md) — SAP Cloud ALM test management, Tricentis Test Automation for SAP, SAP Activate testing methodology, test data management guidance.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: testing program scope (transformation phase, system types in scope, test types planned), automation maturity (no automation / partial / regression-ready), and quality gate posture (entry and exit criteria defined / partially defined / absent).
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: quality-gate-blocking / high / medium / low per assessment dimension.
+- **Recommended action**: specific quality gate control per finding (define measurable exit criteria, add test cases for high-risk process, configure Tricentis automation for regression suite, implement test data masking, create defect governance checkpoint, etc.), grounded in SAP Cloud ALM documentation or SAP Activate testing methodology.
+- **Refusal / escalation triggers**: refuse to assess phase readiness if no test execution results or defect status data have been provided; do not provide test execution guidance under any circumstances; escalate to compliance review if unmasked production data is confirmed in a lower environment.
+- **Business impact**: go-live date risk from insufficient test coverage, defect leakage into production, regression risk from insufficient automation, data privacy compliance exposure from unmasked test data.
+- **Next verification step**: which test phase evidence or defect status data must be provided before the quality gate can be assessed as met.

package/skills/sap/sap-testing-quality-gate-review/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "SAP Testing and Quality Gate Review"
+  short_description: "Advisory review of SAP testing strategy and quality gate completeness: test scope, risk-based prioritization, SAP Cloud ALM test management, Tricentis automation coverage, regression strategy, test data masking, defect management, and entry and exit criteria per test phase. Does not execute tests or mutate test configuration."
+  default_prompt: "Use $sap-testing-quality-gate-review to assess the provided SAP testing strategy and quality gate artifacts. Classify findings by assessment dimension (Test Scope and Risk Prioritization / SAP Cloud ALM Test Management / Automation Coverage / Regression Strategy / Test Data Management / Defect Management / Entry and Exit Criteria), assign a risk level (quality-gate-blocking / high / medium / low), state evidence level (documentation-based / user-provided evidence / inference), and recommend specific quality gate controls per finding. Do not execute tests, trigger automation runs, or access live SAP systems."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/cloud-alm/applicationhelp/test-management"
+      description: "SAP Cloud ALM test management documentation — primary reference for test plan structure, test case library, defect integration, and test execution tracking"
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/b4741e40c77640d2b8e8f33c6bdf1af8.html"
+      description: "SAP Activate testing methodology — verify recommended test phase sequence, entry and exit criteria standards, and quality gate definitions"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-testing-quality-gate-review/metadata.json

@@ -0,0 +1,31 @@
+{
+  "id": "sap-testing-quality-gate-review",
+  "name": "SAP Testing and Quality Gate Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Advisory review of SAP testing strategy and quality gate completeness: test scope and risk-based prioritization, SAP Cloud ALM test management configuration, Tricentis automation coverage, regression strategy for upgrades and transports, test data availability and masking, defect management workflow, and entry and exit criteria per test phase. Does not execute tests or mutate test management configuration.",
+  "source_type": "original",
+  "category": "delivery",
+  "official_docs": [
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/test-management",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/testing",
+    "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/b4741e40c77640d2b8e8f33c6bdf1af8.html",
+    "https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/0f3d2cfb4e2f4b40888a6c1ac2cf1e14.html",
+    "https://help.sap.com/docs/cloud-alm/applicationhelp/defect-management",
+    "https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/test-automation-for-sap-solutions-with-tricentis/ba-p/13540785"
+  ],
+  "security_notes": "Does not access live SAP Cloud ALM tenants, execute test cases, trigger Tricentis automation runs, or connect to any SAP system. Accepts only user-provided testing strategy documents, test plans, defect status reports, automation coverage reports, and test data management documentation. Never accept test data extracts containing personally identifiable information, production system credentials, Cloud ALM API tokens, or Tricentis platform credentials. Does not authorize phase exit or go/no-go sign-off decisions — that authority belongs to the customer project governance body. If unmasked production data is confirmed in a lower environment, escalate to compliance review immediately.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-testing-quality-gate-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-testing-quality-gate-review/references/official-sources.md

@@ -0,0 +1,65 @@
+# Official sources — SAP Testing and Quality Gate Review
+
+Use this reference when grounding test scope assessment, SAP Cloud ALM test management configuration review, automation coverage evaluation, regression strategy assessment, test data management review, defect governance analysis, and entry and exit criteria evaluation.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Cloud ALM application help, SAP Activate methodology portal). No live-system evidence is collected by this skill.
+
+## SAP Cloud ALM — Test Management
+
+- Test Management in SAP Cloud ALM
+  https://help.sap.com/docs/cloud-alm/applicationhelp/test-management
+  source_owner: SAP SE
+  topic_supported: Test plan structure and configuration in SAP Cloud ALM, test case library management, test case assignment to business processes and requirements, test execution tracking, defect record creation from failed test cases, test progress reporting and status dashboards
+  why_needed: Primary reference for assessing SAP Cloud ALM test management configuration completeness — defines the test plan model, test case library structure, defect integration capability, and execution tracking mechanism used to classify test management coverage findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Testing in SAP Cloud ALM — Operations and Scope
+  https://help.sap.com/docs/cloud-alm/applicationhelp/testing
+  source_owner: SAP SE
+  topic_supported: Testing use case scope within SAP Cloud ALM, test phase management, test scope definition, integration with SAP Solution Manager test workbench for migration scenarios, transition from SolMan-based testing to Cloud ALM
+  why_needed: Required to assess whether SAP Cloud ALM test management is correctly configured for the program's test phases and scope, including transition scenarios from SAP Solution Manager
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Cloud ALM — Defect Management
+
+- Defect Management in SAP Cloud ALM
+  https://help.sap.com/docs/cloud-alm/applicationhelp/defect-management
+  source_owner: SAP SE
+  topic_supported: Defect record creation, severity and priority classification, defect lifecycle workflow, defect-to-test-case traceability, defect reporting and backlog governance, integration with external defect tracking systems
+  why_needed: Required to assess defect management workflow governance — defines the defect classification model, lifecycle states, traceability to test cases and transports, and reporting capabilities used to classify defect governance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Activate — Testing Methodology
+
+- SAP Activate — Testing in the Realize Phase
+  https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/b4741e40c77640d2b8e8f33c6bdf1af8.html
+  source_owner: SAP SE
+  topic_supported: SAP Activate Realize phase testing deliverables: test plan preparation, string testing, integration testing, regression testing, UAT preparation; test phase sequencing; recommended entry and exit criteria framework; testing workstream governance
+  why_needed: Authoritative methodology reference for assessing whether the user's test phase sequence, entry and exit criteria, and testing deliverables meet SAP Activate recommended standards for the Realize and Deploy phases
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Activate — UAT and Go-Live Readiness Testing
+  https://help.sap.com/docs/SAP_ACTIVATE/80d20672e1e74bde9f0c7f84cda1e3a6/0f3d2cfb4e2f4b40888a6c1ac2cf1e14.html
+  source_owner: SAP SE
+  topic_supported: User acceptance testing approach in SAP Activate Deploy phase, UAT entry and exit criteria, go-live readiness testing, performance testing recommendations, sign-off and approval governance
+  why_needed: Required to assess UAT completeness and go-live readiness testing governance — defines the UAT phase deliverables, exit criteria standards, and performance testing recommendations used to classify UAT quality gate findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Tricentis Test Automation for SAP
+
+- Test Automation for SAP Solutions with Tricentis
+  https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/test-automation-for-sap-solutions-with-tricentis/ba-p/13540785
+  source_owner: SAP SE (SAP Community)
+  topic_supported: Tricentis Test Automation for SAP (formerly CBTA): automation framework architecture, SAP Fiori and GUI automation support, regression suite automation, integration with SAP Cloud ALM test management, automation coverage metrics
+  why_needed: Reference for assessing Tricentis automation coverage claims — describes the automation framework scope, SAP technology support (Fiori, GUI, BTP), and integration with Cloud ALM used to evaluate whether automation coverage is sufficient and current for the target SAP release
+  evidence_level: supplementary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal, SAP Cloud ALM application help, and SAP Activate methodology documentation describe the designed test management model, recommended phase sequence, entry and exit criteria framework, and automation integration capabilities. They do not prove which test cases the user's program has authored, what defect counts exist in the user's test management tool, what automation coverage percentage the user's regression suite achieves, or whether the user's test data is masked. Users must supply testing strategy documents, test plan descriptions, defect status reports, automation coverage reports, and test data management documentation for concrete quality gate assessment.

package/skills/sap/sap-testing-quality-gate-review/references/safety-checklist.md

@@ -0,0 +1,53 @@
+# Safety checklist — SAP Testing and Quality Gate Review
+
+Use before making any quality gate assessment, test coverage finding, or defect governance recommendation related to SAP testing strategy.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP Cloud ALM tenant, Tricentis platform, CBTA test runner, or SAP system.
+- Do not accept or request SAP system credentials, Cloud ALM API tokens, Tricentis platform credentials, test data extracts containing personally identifiable information, or production data from any SAP environment.
+- Do not execute test cases, trigger automation runs, import transports, or provide step-by-step guidance for test execution operations. This skill is advisory only.
+- Do not authorize or imply authorization for phase exit, UAT sign-off, or go/no-go decisions. Sign-off authority belongs to the customer project governance body with a named approver. This skill can assess whether criteria are met based on user-provided evidence, but cannot authorize the decision.
+- Do not assess phase readiness if no test execution results or defect status data have been provided. Insufficient evidence cannot support a readiness assessment.
+- Do not fabricate test case counts, defect counts, pass rates, or automation coverage percentages. Only classify findings the user has provided from their actual test management reports.
+- Do not recommend proceeding to the next test phase when quality-gate-blocking gaps are identified. Always surface blocking gaps first.
+- If unmasked production data is confirmed in a lower SAP environment, classify as a compliance finding and escalate to the customer's data privacy and security team immediately — do not defer.
+
+## Advisory-only boundary enforcement
+
+If the user asks this skill to:
+- "run the test cases,"
+- "execute the regression suite,"
+- "trigger the Tricentis automation,"
+- "sign off on UAT,"
+- "approve phase exit,"
+- "help me mark defects as resolved,"
+
+respond: This skill is an advisory quality gate reviewer and does not execute tests, trigger automation, update defect records, or authorize phase sign-off decisions. For live test execution or defect management operations, a separate guarded execution agent would be required.
+
+## What people get wrong
+
+- **Treating test case existence as test coverage**: Test cases that exist in a spreadsheet outside SAP Cloud ALM are not tracked, not linked to defects, and not reportable. Coverage that cannot be measured against execution progress is not governed coverage.
+- **Confusing validation run success with integration test coverage**: A successful SAP Migration Cockpit validation run or transport import into QA confirms technical correctness of a specific object. It does not confirm that the business process end-to-end flow across integrated systems works correctly. Integration testing requires scenario-level execution.
+- **Treating automation script count as automation coverage**: The number of automation scripts does not indicate coverage. Coverage is measured as the percentage of regression test cases that can be executed via automation against the current target release without manual correction. Outdated scripts that fail against the current release contribute zero effective coverage.
+- **Deferring performance testing to post-go-live**: Performance testing for volume, peak load, and year-end processing requirements must be completed before go-live. Deferring performance testing to hypercare assumes the system will perform adequately under production load — an assumption that has no evidence base and may require emergency infrastructure changes during the most sensitive operational period.
+- **Accepting "test data is available" without masking confirmation**: Test data availability and test data masking are separate concerns. Production data copied to a lower environment without masking is a compliance violation under GDPR and similar data privacy regulations regardless of its value for testing purposes.
+- **Treating exit criteria as negotiable at gate time**: Exit criteria that are renegotiated at the gate boundary to accommodate schedule pressure are not exit criteria — they are aspirational targets. Criteria must be agreed before the phase begins and enforced as written at the gate.
+- **Ignoring defect-to-transport traceability**: Defects that are not linked to the transport responsible for the failing change cannot be efficiently resolved or retested. Traceability is required to ensure that when a fix transport is imported, the relevant defects are identified and regression-tested.
+
+## When to push back
+
+- Push back when the user wants a quality gate assessment without providing test execution results, defect status data, or automation coverage reports.
+- Push back when exit criteria are subjective or have no named sign-off authority.
+- Push back when automation coverage is claimed but script currency against the target SAP release has not been confirmed.
+- Push back when production data in a lower environment is mentioned without a confirmed masking or anonymization procedure — classify as compliance finding immediately.
+- Push back when performance testing has not been planned and the go-live involves high transaction volumes, year-end processing, or multi-tenant SAP BTP workloads.
+- Push back when the user asks for execution guidance for test case runs, automation invocations, or defect record operations.
+- Push back when critical or high severity defects are unresolved and the user requests assessment of phase exit readiness.
+- Push back when the defect backlog has not been reviewed and there is no formal risk acceptance for deferred defects.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Cloud ALM test management documentation, Tricentis Test Automation for SAP documentation, SAP Activate testing methodology, or SAP Help Portal
+- `user-provided evidence` — test strategy documents, test plans, defect status reports, automation coverage reports, test data management documentation, or phase exit criteria documents 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-testing-quality-gate-review/references/workflow-and-output.md

@@ -0,0 +1,98 @@
+# Workflow and output contract — SAP Testing and Quality Gate Review
+
+Use this reference for all quality gate assessment, risk tier classification, defect governance evaluation, and output formatting.
+
+## Assessment dimension taxonomy
+
+| Dimension | Description |
+|-----------|-------------|
+| `test-scope-risk-prioritization` | Coverage of business processes across test types; risk tier assignment rationale; high-risk process test case density |
+| `cloud-alm-test-management` | Test plan structure per phase; test case library completeness; defect integration; execution tracking |
+| `automation-coverage` | Tricentis/CBTA automation coverage percentage; automation maintenance status; regression suite readiness for target release |
+| `regression-strategy` | Regression scope definition; regression trigger conditions; transport-to-regression gating; baseline maintenance |
+| `test-data-management` | Test data availability per phase; production data masking and anonymization; data refresh cadence |
+| `defect-management` | Severity and priority classification consistency; defect-to-transport traceability; backlog governance; exit criteria enforcement |
+| `entry-exit-criteria` | Measurability of criteria; formal documentation; named sign-off authority per phase |
+
+## Test phase sequence
+
+| Phase | Typical SAP Activate stage | Key gate concerns |
+|-------|--------------------------|-------------------|
+| `unit-testing` | Realize (early) | Individual configuration object correctness; developer-owned; pass rate tracking |
+| `string-testing` | Realize (mid) | End-to-end process strand coverage for integrated configuration; cross-object dependencies |
+| `integration-testing` | Realize (late) | Cross-system interface testing; integration scenario coverage; error handling verification |
+| `regression-testing` | Realize and Deploy | Baseline coverage for unaffected processes; automation coverage; transport-triggered execution |
+| `uat` | Deploy | Business user sign-off; risk-based scope; measurable exit criteria; formal phase acceptance |
+| `performance-testing` | Deploy (if in scope) | Volume and peak load testing; response time thresholds; infrastructure sizing validation |
+
+## Risk tier model
+
+| Tier | Assignment criteria | Required test coverage |
+|------|--------------------|-----------------------|
+| `tier-1-critical` | Financial posting processes, payroll, regulatory reporting, cross-system integration on critical path | Full test case coverage; automation required for regression; UAT sign-off mandatory |
+| `tier-2-high` | Core order-to-cash, procure-to-pay, inventory management, manufacturing execution | High test case density; automation recommended; UAT coverage expected |
+| `tier-3-medium` | Supporting processes, reporting, non-critical interfaces | Moderate test case coverage; manual regression acceptable; UAT sampling |
+| `tier-4-low` | Configuration-only changes, static master data, informational reports | Smoke test or focused check; no UAT required unless stakeholder-requested |
+
+## Quality gate status values
+
+Each gate is assessed as: `PASS` / `PARTIAL` / `FAIL` / `NOT-YET-ASSESSED`
+
+| Gate | Minimum pass criteria | Common failure modes |
+|------|-----------------------|---------------------|
+| `test-scope-coverage` | All tier-1 and tier-2 processes have test cases; risk tier assignment documented | Missing tier-1 process in test scope; no documented rationale for risk tier assignment |
+| `cloud-alm-test-management` | Test plans exist per phase; test cases linked to processes; defect records created from failures; execution progress tracked | Test cases exist in spreadsheets not Cloud ALM; defects not linked to test cases; no execution tracking |
+| `automation-coverage` | Minimum 60% of regression test cases automated for tier-1 and tier-2 processes; scripts verified against target release | Automation scripts written for prior release and not updated; coverage percentage not quantified |
+| `regression-gate` | Regression scope defined; regression triggered by transport release cycle; results reviewed before production transport approval | Regression run ad hoc with no defined scope; no transport-to-regression gating |
+| `test-data-availability` | Test data exists at representative volume and variety for each phase; masking applied to any production data in lower environments | Test data too limited for integration testing; unmasked production data confirmed in lower environment |
+| `defect-governance` | All open defects reviewed and classified before phase exit; critical and high defects resolved or formally risk-accepted; backlog prioritized | Unreviewed defect backlog at phase exit boundary; critical defects deferred without risk acceptance documentation |
+| `exit-criteria-enforced` | Measurable exit criteria formally documented per phase; named sign-off authority; criteria enforced at gate | Exit criteria subjective or absent; sign-off authority not named; criteria not formally approved by project governance |
+
+## Automation coverage maturity model
+
+| Maturity level | Automation coverage | Characteristics |
+|----------------|--------------------|--------------------|
+| `no-automation` | 0% | All regression is manual; high regression execution time; significant regression cost per cycle |
+| `initial` | < 30% | Partial automation; coverage concentrated on a subset of processes; incomplete regression without manual complement |
+| `developing` | 30–60% | Meaningful automation coverage for tier-1 processes; gaps remain for tier-2 and integration scenarios |
+| `regression-ready` | 60–80% | Sufficient automation to execute a complete regression cycle with targeted manual complement |
+| `optimized` | > 80% | Comprehensive automation coverage; regression cycle is fast and reliable; manual testing focused on exploratory and UAT |
+
+## Defect governance criteria
+
+A governed defect backlog at phase exit must include, for each open defect:
+
+- Severity and priority classification (critical / high / medium / low)
+- Resolution status (open / in-progress / resolved / deferred with accepted risk)
+- Responsible transport (where defect is attributable to a specific change)
+- Target resolution date or accepted-risk record with approver name
+- Phase exit impact assessment (blocking / non-blocking with mitigation)
+
+## Workflow
+
+1. **Identify program scope** — confirm SAP system types, transformation phase, and test types in scope (unit, string, integration, regression, UAT, performance).
+2. **Assess test scope and risk prioritization** — confirm risk tier assignment and test case coverage allocation per tier.
+3. **Review Cloud ALM test management configuration** — assess test plan structure, test case library, defect integration, and execution tracking.
+4. **Evaluate automation coverage** — determine maturity level and confirm script currency against target release.
+5. **Assess regression strategy** — confirm regression scope definition, trigger conditions, and transport gating.
+6. **Review test data management** — confirm data availability, masking status, and refresh cadence.
+7. **Evaluate defect governance** — assess classification consistency, backlog governance, and exit criteria enforcement.
+8. **Validate entry and exit criteria** — confirm measurability, documentation, and named sign-off authority per phase.
+9. **Assign overall quality gate posture** — `gates-met` (all gates PASS) / `conditional` (gaps with documented mitigation and accepted risk) / `gates-not-met` (one or more gates FAIL or quality-gate-blocking gap).
+10. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Program scope and test phase sequence in scope
+2. Evidence label per dimension (documentation-based / user-provided evidence / inference)
+3. Quality gate assessment table: gate name, status (PASS/PARTIAL/FAIL/NOT-YET-ASSESSED), gap description
+4. Risk tier coverage summary: tier-1 and tier-2 process test case coverage completeness
+5. Automation maturity level and regression readiness assessment
+6. Defect backlog governance assessment: open critical and high defects, resolution status, blocking classification
+7. Overall quality gate posture: gates-met / conditional / gates-not-met
+8. Risk level per gate (quality-gate-blocking / high / medium / low)
+9. Prioritized gap remediation recommendations with SAP Cloud ALM or SAP Activate reference
+10. Escalation trigger if unmasked production data, missing test execution evidence, or unreviewed critical defects require immediate action
+11. Explicit advisory boundary reminder: this review does not execute tests, trigger automation, or authorize phase sign-off

package/skills/sap/sap-transformation-portfolio-triage-review/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: sap-transformation-portfolio-triage-review
+description: Advisory triage of an SAP transformation program portfolio: workstream prioritization, dependency and risk mapping, value vs effort classification, readiness gating across S/4HANA, BTP, integration, and security workstreams, and RAID log assessment. Does not touch or mutate any live system.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: architecture
+  lifecycle: experimental
+---
+
+# SAP Transformation Portfolio Triage Review
+
+## Purpose
+
+Assess the portfolio-level posture of an SAP transformation program. Evaluate workstream prioritization, cross-workstream dependency mapping, risk and risk interdependency exposure, value vs effort classification, readiness gating criteria across S/4HANA conversion or greenfield, BTP platform adoption, integration modernization, and security workstreams, and the completeness of the RAID log (Risks, Assumptions, Issues, Decisions). Surface workstreams that are underplanned, sequenced incorrectly, missing readiness gates, or carrying unresolved cross-workstream dependencies that threaten the program. Does not connect to or mutate any live system, project tool, or SAP environment.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- triage an SAP transformation program portfolio to identify which workstreams are highest risk or blocking others,
+- review workstream sequencing and dependency ordering across S/4HANA, BTP, integration, and security tracks,
+- classify workstreams by value vs effort to support reprioritization or executive escalation,
+- assess readiness gating criteria across program workstreams and flag workstreams entering execution without sufficient readiness evidence,
+- review a RAID log for completeness, unresolved risks, unowned issues, or stale assumptions,
+- identify dependency chains that create single points of failure in the transformation timeline,
+- evaluate whether the transformation program structure aligns with SAP Activate methodology phases (Discover, Prepare, Explore, Realize, Deploy, Run),
+- support a program health check, steering committee review, or transformation audit preparation.
+
+## When not to use
+
+- When the request requires live access to a project management tool, SAP Solution Manager, SAP Cloud ALM, or Jira — this skill accepts only user-provided descriptions, exports, or architecture documents.
+- When the request concerns technical clean core compliance of specific ABAP objects — use `sap-clean-core-debt-review`.
+- When the request is specifically about BTP account model governance — use `sap-btp-governance-review`.
+- When the request concerns RISE with SAP contract obligations, SLA commitments, or vendor risk — use `sap-rise-sla-vendor-risk-review`.
+- When the request is about SAP licensing cost optimization — use `sap-license-btp-consumption-finops-review`.
+
+## Does not touch live systems
+
+This skill operates on user-provided transformation program artifacts: project plans, workstream charters, RAID logs, dependency maps, architecture decision records, steering committee decks, or written descriptions of the program structure. It does not connect to SAP Cloud ALM, SAP Solution Manager, any SAP backend system, any cloud project management platform, or any live environment. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify workstreams before prioritizing. Every workstream must be classified by type (S/4HANA conversion, BTP platform, integration modernization, data migration, security and compliance, change management, infrastructure) before sequencing recommendations are made.
+- Use SAP Activate as the reference methodology. Workstream readiness gates correspond to SAP Activate phase exits (Prepare exit, Explore exit, Realize exit). Workstreams that enter a phase without completing the prior phase exit checklist carry structural program risk.
+- Dependency direction matters. Distinguish predecessor dependencies (A must complete before B starts) from shared-outcome dependencies (A and B must reach a milestone together). Both create timeline risk but through different mechanisms.
+- Value vs effort classification uses the program's own evidence. Do not invent value scores. Derive from the user's provided program artifacts — business case, OKRs, or value driver trees.
+- RAID items must be owned and dated. Unowned risks, undated assumptions, and issues without a resolution path are program governance deficiencies regardless of their content.
+- Readiness gating is a binary gate, not a score. A workstream is either ready to proceed to the next phase or it is not. Partial readiness is not readiness.
+- S/4HANA conversion sequencing is non-negotiable. Fit-to-standard workshops must precede solution design which must precede configuration. Gap analysis must precede extensibility decisions. Reversing this order is a rework risk.
+- Integration workstreams are cross-cutting. Integration dependencies affect every other workstream. Flag integration workstreams that are underplanned relative to the S/4HANA and BTP workstreams they serve.
+- Evidence from user-provided artifacts or official SAP methodology documentation takes precedence over inference.
+- Load only the reference needed for the workstream domain under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Activate methodology documentation, SAP Transformation Navigator guidance, or official SAP program management resources
+- `user-provided evidence` — project plans, RAID logs, workstream charters, dependency maps, or program decks provided by the user
+- `inference` — derived reasoning not directly confirmed by official documentation or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no API call, project tool connection, SAP system access, SAP Cloud ALM query, or Jira integration in this skill's execution path. Users must supply program artifacts, workstream descriptions, RAID log exports, or written descriptions of the transformation program structure for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — workstream classification taxonomy, risk severity, RAID assessment criteria, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common sequencing mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Activate methodology, SAP Transformation Navigator, SAP Cloud ALM program management documentation.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: workstream domain(s) affected (S/4HANA conversion / BTP platform / integration / security / data migration / change management) and specific triage finding(s).
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (dependency or sequencing failure that threatens the program delivery date or regulatory commitment) / high (workstream without readiness gate or with unresolved blocking dependency) / medium (RAID gap or workstream prioritization imbalance) / low (best practice deviation in program structure).
+- **Recommended action**: specific triage remediation per finding (resequence, add readiness gate, escalate unowned RAID item, restructure dependency, deprioritize low-value workstream).
+- **Refusal / escalation triggers**: if live project tool access or SAP Cloud ALM data is required to complete the triage, state that clearly and do not proceed.
+- **Business impact**: program delivery risk, regulatory deadline exposure, budget overrun risk, or scope creep from underplanned workstreams.
+- **Next verification step**: validate workstream sequencing and dependency map against the program's current project plan before communicating to stakeholders.