@raishin/vanguard-frontier-agentic 2.11.0 → 2.13.0

package/skills/sap/sap-rise-sla-vendor-risk-review/references/official-sources.md

@@ -0,0 +1,73 @@
+# Official sources — RISE with SAP SLA and Vendor Risk Review
+
+Use this reference when grounding responsibility split classification, SLA and credit mechanism assessment, availability and DR commitments, data residency obligations, exit and portability provisions, shared security responsibilities, and audit rights.
+
+**Evidence level**: documentation-based (SAP Trust Center, SAP Help Portal, SAP cloud service descriptions). No live-system evidence is collected by this skill.
+
+## RISE with SAP contractual framework
+
+- RISE with SAP
+  https://help.sap.com/docs/RISE/rise-with-sap/rise-with-sap
+  source_owner: SAP SE
+  topic_supported: RISE with SAP commercial model, included services scope, infrastructure and application layer responsibilities, bundled SAP BTP entitlements
+  why_needed: Primary reference for understanding what is included in RISE with SAP and where the boundary between SAP-managed and customer-managed scope lies
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Trust Center: Cloud Service Agreements
+  https://www.sap.com/about/trust-center/cloud-service-agreements.html
+  source_owner: SAP SE
+  topic_supported: SAP cloud service level agreements, cloud service descriptions, supplemental terms, data processing agreements, order forms
+  why_needed: Primary contractual reference for SLA tier definitions, credit mechanisms, availability commitments, and the legal framework governing RISE with SAP and other SAP cloud services
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Trust Center: Shared Responsibility Model
+  https://www.sap.com/about/trust-center/shared-responsibility-model.html
+  source_owner: SAP SE
+  topic_supported: SAP vs customer responsibility matrix for infrastructure, platform, application, and data layers across RISE with SAP and SAP BTP
+  why_needed: Canonical reference for the shared responsibility split — defines what SAP manages and what the customer manages, which is the foundation for all responsibility gap findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Security and trust
+
+- SAP Trust Center: Security
+  https://www.sap.com/about/trust-center/security.html
+  source_owner: SAP SE
+  topic_supported: SAP security framework, security certifications (ISO 27001, SOC 2, BSI C5), penetration testing, vulnerability management, security incident response
+  why_needed: Required to assess what security obligations SAP fulfills contractually versus what the customer must implement, and to evaluate the adequacy of third-party certification evidence
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- SAP Trust Center: Availability
+  https://www.sap.com/about/trust-center/availability.html
+  source_owner: SAP SE
+  topic_supported: SAP cloud service availability status, historical uptime, planned maintenance windows, incident communication
+  why_needed: Provides the published availability track record against which SLA commitments can be contextually evaluated; also defines the maintenance window model that affects effective availability
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data privacy and residency
+
+- SAP Trust Center: Data Privacy
+  https://www.sap.com/about/trust-center/data-privacy.html
+  source_owner: SAP SE
+  topic_supported: SAP data processing agreements, GDPR compliance posture, data residency options, cross-border data transfer mechanisms (SCCs, BCRs), data subject rights
+  why_needed: Primary reference for data residency and cross-border transfer obligations — required to assess whether contractual data residency clauses are backed by adequate legal transfer mechanisms and technical controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## System and contract administration
+
+- SAP Customer Administration Center (SAP for Me / CAC)
+  https://support.sap.com/en/my-support/systems-installations/cac.html
+  source_owner: SAP SE
+  topic_supported: SAP contract and system administration, system details, license and contract information access, system provisioning status
+  why_needed: Reference for understanding how customers access and manage their SAP contractual system information — relevant when assessing whether exit and portability provisions are practically accessible
+  evidence_level: supplementary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Trust Center and cloud service agreement documentation describe SAP's published contractual framework, standard SLA terms, and stated security and privacy commitments. They do not prove what terms are in the user's specific signed contract, what SLA credits have been granted historically, or whether SAP's operational practices match the published commitments. Users must supply their signed contract excerpts, SLA schedules, or order forms for concrete contractual risk assessment. This skill does not provide legal advice.

package/skills/sap/sap-rise-sla-vendor-risk-review/references/safety-checklist.md

@@ -0,0 +1,36 @@
+# Safety checklist — RISE with SAP SLA and Vendor Risk Review
+
+Use before making any vendor risk or SLA recommendation, especially for findings that affect data residency, exit provisions, business continuity commitments, or security responsibility boundaries.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system, SAP contract management portal, SAP for Me, or signed contract repository. This skill reviews artifacts only.
+- Do not accept or request SAP contract portal credentials, customer-specific contract identifiers, or confidential commercial pricing.
+- Do not provide legal advice on contract terms. This skill provides advisory risk classification. Legal counsel must be engaged for binding contract interpretation or renegotiation strategy.
+- Do not classify a contractual gap as low risk without first confirming it does not affect regulatory compliance (GDPR, SOX, HIPAA, local data protection law) or business continuity.
+- Do not assert that SAP's published shared responsibility model matches the user's signed contract. Published models describe the standard; the signed contract governs. Always ask the user to confirm against their contract.
+- Do not conflate RISE with SAP Private Cloud Edition responsibilities with RISE with SAP Public Cloud (S/4HANA Cloud Public Edition) responsibilities. The infrastructure and application responsibility split is materially different between these two models.
+- Do not recommend withholding SLA credit claims without confirming the credit request window in the user's contract. Credit windows vary and missing the window forfeits the credit.
+
+## What people get wrong
+
+- **Assuming RISE with SAP means SAP manages everything**: RISE with SAP is a bundling model. SAP manages infrastructure and base application operations. The customer retains responsibility for configuration, authorizations, data quality, custom code, integration endpoints, and end-user access management.
+- **Treating ISO 27001 certification as coverage for the customer's configuration**: SAP's ISO 27001 certification covers SAP's managed infrastructure and operations. It does not certify the customer's application configuration, custom code, or data handling practices within the system.
+- **Assuming data residency equals data sovereignty**: A contractual data residency commitment (data stored in a specific region) does not automatically address data sovereignty requirements (which law governs the data). Both must be assessed independently.
+- **Missing the maintenance window impact on effective availability**: A 99.5% availability SLA that permits planned maintenance of up to 10 hours per month may effectively deliver significantly less availability during business hours. Evaluate effective availability against business continuity requirements, not just the headline SLA percentage.
+- **Treating exit provisions as final at contract signature**: Data export format, timeline, and cost are often negotiable at renewal or renegotiation. Flag weak exit provisions as remediation opportunities at next contract event.
+- **Confusing SAP-provided audit reports with customer audit rights**: SAP typically provides SOC 2 Type II reports and ISO certifications. These are not the same as the customer's right to commission an independent audit of SAP's operations. Confirm which mechanism the contract provides.
+- **Underestimating sub-processor risk**: SAP cloud services rely on third-party infrastructure providers (hyperscalers). The data processing agreement's sub-processor list and notification obligations for sub-processor changes are a GDPR compliance dependency. An outdated or absent sub-processor list is a regulatory risk.
+
+## When to push back
+
+- Push back when the user asks to assess SLA adequacy without providing the actual SLA schedule or availability commitment. Do not infer SLA terms from the product name alone.
+- Push back when the user asks for a legal interpretation of contract language. Classify the risk and recommend legal counsel engagement.
+- Push back when a request requires access to the signed contract and the user cannot provide relevant excerpts. State that the assessment cannot be completed without the contract evidence and ask the user to provide the relevant sections.
+- Push back when the user asks to recommend contract renegotiation positions. Risk classification is in scope; negotiation strategy requires legal and commercial counsel.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Trust Center publications, SAP cloud service descriptions, RISE with SAP documentation, or SAP shared responsibility model
+- `user-provided evidence` — contract excerpts, SLA schedules, order forms, or written descriptions of contractual obligations provided by the user
+- `inference` — derived reasoning not directly confirmed by official SAP publications or user-provided contract text; must always be labeled as such

package/skills/sap/sap-rise-sla-vendor-risk-review/references/workflow-and-output.md

@@ -0,0 +1,56 @@
+# Workflow and output contract — RISE with SAP SLA and Vendor Risk Review
+
+Use this reference for contract domain classification, responsibility layer assessment, SLA evaluation, and output formatting.
+
+## Contract domain taxonomy
+
+| Contract domain | Scope | Typical findings |
+|-----------------|-------|-----------------|
+| `responsibility-split` | Who manages what across infrastructure, platform, application, and data layers (SAP vs customer vs partner) | Customer assumes responsibility for application configuration that SAP actually manages; partner obligations not captured in a tripartite agreement; data layer ownership ambiguous |
+| `sla-and-credits` | SLA tier definitions, availability targets, credit calculation, credit request process, credit caps | Credit cap insufficient to compensate for downtime cost; credit request window too short (e.g., 30 days vs 90 days); SLA exclusions broad enough to negate most credits |
+| `availability-and-dr` | System availability commitments, planned maintenance windows, disaster recovery RTO/RPO, business continuity | DR RTO/RPO not specified in contract; maintenance windows not aligned with customer business hours; no contractual obligation to notify before maintenance |
+| `data-residency` | Data processing location, cross-border transfer mechanisms, data residency options, processing sub-processors | Contractual residency clause without audit evidence; cross-border transfer mechanism (SCC, BCR) not specified; sub-processor list not disclosed or not current |
+| `exit-and-portability` | Data export provisions, export format and timeline, contract exit obligations, post-termination data retention and deletion | Export format not specified; export timeline too short for a large data volume; export billed at unreasonable cost; post-termination retention period not defined |
+| `security-responsibilities` | Shared security model, customer security obligations, SAP security obligations, incident response, vulnerability disclosure | Customer security obligations not documented; SAP incident notification SLA not contractually bound; no contractual obligation to perform penetration testing on the customer's instance |
+| `audit-rights` | Customer audit rights, third-party certification, SAP-provided audit reports, regulator access | Audit right limited to SAP-provided reports only with no independent audit option; certification scope does not cover the customer's deployed configuration; regulator access not addressed |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Contractual gap that creates unmanaged regulatory non-compliance (e.g., GDPR data residency breach, no data processing agreement), business continuity exposure with no contractual remedy, or complete absence of an SLA for a production system |
+| `high` | Ambiguous responsibility boundary for a critical function (e.g., backup and restore ownership unclear), SLA credit mechanism that is practically unusable (cap below cost of downtime, request window too short), or exit provision that does not guarantee data return |
+| `medium` | Missing provision that is negotiable but currently absent (e.g., no maintenance window notification obligation), SLA exclusion that is broad but the risk is manageable with compensating controls, or data residency clause without audit evidence |
+| `low` | Best practice deviation in contract structure (SLA definitions are present but not referenced from the operational runbook, portability clause present but format not specified) |
+
+## Responsibility layer classification
+
+For each finding, classify the responsibility layer:
+
+- `sap-managed`: SAP is solely responsible per the published shared responsibility model and contract
+- `customer-managed`: The customer is solely responsible per the published shared responsibility model and contract
+- `partner-managed`: A system integrator or implementation partner holds the obligation per a separate engagement agreement
+- `shared`: Both SAP and customer hold obligations — define the split explicitly
+- `ambiguous`: The contract or published model does not clearly assign responsibility — this is itself a risk finding
+
+## Workflow
+
+1. **Receive artifacts** — contract excerpts, SLA schedules, order forms, SAP Trust Center references, or written descriptions of contractual obligations.
+2. **Classify each finding** by contract domain.
+3. **Classify responsibility layer** for each finding (SAP-managed / customer-managed / partner-managed / shared / ambiguous).
+4. **Assign risk level** (critical / high / medium / low).
+5. **Assess against SAP published baseline** — compare user-provided terms against SAP Trust Center published standards and shared responsibility model.
+6. **Prioritize** — critical compliance and business continuity gaps first; then high responsibility and SLA issues; then medium missing provisions; then low best-practice items.
+7. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Contract domain and specific finding
+2. Responsibility layer (SAP-managed / customer-managed / partner-managed / shared / ambiguous)
+3. Evidence label (documentation-based / user-provided evidence / inference)
+4. Risk level per finding (critical / high / medium / low)
+5. Recommended action (renegotiate clause, request SLA addendum, obtain certification evidence, implement compensating control, engage legal counsel)
+6. Business impact (regulatory exposure, business continuity gap, vendor lock-in risk, audit finding risk)
+7. Escalation trigger if legal interpretation or live contract access is required

package/skills/sap/sap-s4hana-transformation-architecture-review/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: sap-s4hana-transformation-architecture-review
+description: Review an SAP S/4HANA transformation approach for architectural soundness. Assesses brownfield conversion, greenfield reimplementation, and selective data transition (SDT) strategies against SAP Activate methodology, deployment model options (Cloud Public Edition, Cloud Private Edition, RISE with SAP), SAP Readiness Check findings, simplification item impact, and fit-to-standard alignment. Advisory only — does not access or modify live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: architecture
+  lifecycle: experimental
+---
+
+# SAP S/4HANA Transformation Architecture Review
+
+## Purpose
+
+Assess the architectural approach to an SAP S/4HANA transformation program. Review the chosen migration strategy (brownfield, greenfield, or selective data transition), evaluate alignment with SAP Activate methodology, qualify the selected deployment model (Cloud Public Edition, Cloud Private Edition, or RISE with SAP), interpret SAP Readiness Check output and simplification item impact, and evaluate fit-to-standard posture. Surface architectural risks, strategy mismatches, and prioritized recommendations. Does not access, read, or modify live SAP systems.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- assess whether brownfield (system conversion), greenfield (new implementation), or selective data transition (SDT) is the right approach for their S/4HANA transformation,
+- review an existing transformation program plan against SAP Activate phases (Discover, Prepare, Explore, Realize, Deploy, Run),
+- evaluate deployment model options — SAP S/4HANA Cloud Public Edition (multi-tenant SaaS), SAP S/4HANA Cloud Private Edition, or RISE with SAP — and their architectural trade-offs,
+- interpret SAP Readiness Check results (simplification items, business functions, custom code impact, technical prerequisites),
+- review the organization's fit-to-standard workshop coverage and scope of configuration versus custom development,
+- assess transformation readiness: organizational change management, data quality prerequisites, integration landscape impacts, and testing strategy,
+- review phasing, sequencing, and scope decisions in a multi-wave or multi-country S/4HANA rollout.
+
+## When not to use
+
+- When the user needs a review of custom ABAP code against clean core — use `sap-clean-core-debt-review` or `sap-custom-code-remediation-review`.
+- When the request is about data migration execution readiness — use `sap-data-migration-cutover-readiness`.
+- When the request is about specific ABAP extensibility or RAP architecture — use `sap-abap-cloud-rap-review`.
+- When the request is about transport mechanics — use `sap-guarded-transport-import`.
+- When live system discovery is needed before architecture review — use `sap-live-readonly-landscape-discovery` first.
+
+## Does not touch live systems
+
+This skill operates on user-provided documentation, SAP Readiness Check reports, simplification item lists, transformation project plans, scope documents, fit-to-standard workshop outputs, or described architectural decisions. It does not connect to any SAP system, run system checks, read configuration tables, or access BTP cockpit. All live system evidence must be provided by the user.
+
+## Lean operating rules
+
+- Strategy first. Classify the transformation approach (brownfield / greenfield / SDT / hybrid) before assessing any other dimension. Strategy choice drives all downstream architectural decisions.
+- SAP Activate is the reference methodology. All phasing and deliverable recommendations use SAP Activate (Discover, Prepare, Explore, Realize, Deploy, Run) as the structural framework.
+- Deployment model has architectural consequences. S/4HANA Cloud Public Edition restricts extensibility to key-user and side-by-side patterns only. Private Edition and RISE offer more ABAP extensibility but do not equal on-premise freedom. Always qualify the deployment model before discussing extensibility.
+- Simplification items are upgrade blockers until resolved. SAP Readiness Check simplification item hits must be classified by impact severity (conversion-blocking, functional change, manual re-implementation required) before a transformation timeline is assessed.
+- Fit-to-standard reduces risk. Configurations that align with SAP standard processes reduce upgrade risk, future clean core compliance burden, and support cost. Scope deviations must be explicitly justified.
+- Evidence from official SAP sources takes precedence over memory or training data.
+- Do not assume deployment model from context alone. Confirm with the user whether the target is Cloud Public Edition, Cloud Private Edition, RISE with SAP on hyperscaler, or on-premise managed.
+- Do not fabricate simplification item counts or Readiness Check findings. Only classify findings the user has provided.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Activate methodology docs, S/4HANA deployment guides, SAP Readiness Check documentation, or SAP Help Portal
+- `user-provided evidence` — SAP Readiness Check reports, project plans, scope documents, fit-to-standard outputs, or architectural descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence; must always be labeled
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no credential, API call, RFC connection, or SAP system access in this skill's execution path. Users must supply Readiness Check output, transformation plans, project documentation, or written descriptions of their landscape and transformation decisions for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — strategy classification taxonomy, assessment dimensions, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common assessment mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP Activate methodology, Readiness Check, S/4HANA deployment, simplification items.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: transformation strategy type (brownfield / greenfield / SDT / hybrid), deployment model, and SAP Activate phase alignment.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: transformation-blocking / high-risk / medium-risk / low-risk per dimension assessed.
+- **Recommended action**: strategy recommendation or gap remediation path with rationale grounded in official SAP guidance.
+- **Refusal / escalation triggers**: if live system data is required before assessment, redirect to `sap-live-readonly-landscape-discovery`; if custom code impact is the primary concern, redirect to `sap-custom-code-remediation-review`.
+- **Business impact**: timeline risk, license model impact, extensibility restrictions, and organizational change management implications.
+- **Next verification step**: which SAP Activate deliverable or Readiness Check finding to validate next before the transformation proceeds.

package/skills/sap/sap-s4hana-transformation-architecture-review/agents/openai.yaml

@@ -0,0 +1,14 @@
+interface:
+  display_name: "SAP S/4HANA Transformation Architecture Review"
+  short_description: "Review brownfield, greenfield, or selective data transition approach for S/4HANA transformation — SAP Activate alignment, deployment model trade-offs, Readiness Check findings, simplification item impact, and fit-to-standard posture. Advisory only."
+  default_prompt: "Use $sap-s4hana-transformation-architecture-review to assess the S/4HANA transformation architecture. Classify the strategy (brownfield / greenfield / selective data transition / hybrid), confirm the deployment model (Cloud Public Edition, Cloud Private Edition, RISE with SAP, or on-premise), identify SAP Activate phase alignment gaps, and surface simplification item risks from any provided Readiness Check output. State evidence level and risk classification for each dimension assessed."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_ACTIVATE"
+      description: "SAP Activate methodology portal — verify phase deliverables, accelerators, and best-practice templates for the transformation approach under review"
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_READINESS_CHECK"
+      description: "SAP Readiness Check documentation — interpret simplification item categories, custom code impact levels, and technical prerequisite findings"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-s4hana-transformation-architecture-review/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "sap-s4hana-transformation-architecture-review",
+  "name": "SAP S/4HANA Transformation Architecture Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review the architectural approach to an SAP S/4HANA transformation: brownfield vs greenfield vs selective data transition, SAP Activate methodology alignment, deployment model trade-offs (Cloud Public Edition, Cloud Private Edition, RISE with SAP), SAP Readiness Check interpretation, simplification item impact, and fit-to-standard posture. Advisory only — does not access live systems.",
+  "source_type": "original",
+  "category": "architecture",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-activate/sap-activate-methodology/sap-activate-methodology",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/system-conversion",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/selective-data-transition",
+    "https://help.sap.com/docs/sap-readiness-check/sap-readiness-check/what-is-sap-readiness-check",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/fit-to-standard",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/deployment-options",
+    "https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/simplification-items"
+  ],
+  "security_notes": "Does not access live SAP systems. Accepts only user-provided project documentation, SAP Readiness Check reports, simplification item lists, and architectural descriptions. Never request or accept system credentials, RFC destinations, S-user authentication tokens, or BTP service keys. Transformation strategy recommendations must be validated against the user's specific landscape version, license model, and SAP Activate release before implementation.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-s4hana-transformation-architecture-review",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-s4hana-transformation-architecture-review/references/official-sources.md

@@ -0,0 +1,75 @@
+# Official sources — SAP S/4HANA Transformation Architecture Review
+
+Use this reference when grounding transformation strategy assessment, SAP Activate methodology guidance, deployment model evaluation, SAP Readiness Check interpretation, and simplification item analysis.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP Activate community, SAP Readiness Check portal). No live-system evidence is collected by this skill.
+
+## SAP Activate methodology
+
+- SAP Activate methodology — overview and phases
+  https://help.sap.com/docs/sap-activate/sap-activate-methodology/sap-activate-methodology
+  source_owner: SAP SE
+  topic_supported: SAP Activate phase structure (Discover, Prepare, Explore, Realize, Deploy, Run), deliverables per phase, accelerators, fit-to-standard workshop approach
+  why_needed: Primary methodology framework used to assess whether the user's transformation program is phase-aligned and deliverable-complete
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA system conversion (brownfield)
+
+- SAP S/4HANA system conversion guide
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/system-conversion
+  source_owner: SAP SE
+  topic_supported: Brownfield (system conversion) process: prerequisites, pre-conversion checks, conversion steps, simplification item handling, post-conversion tasks
+  why_needed: Authoritative technical reference for assessing brownfield conversion approach, scope, and risk — including prerequisite SAP notes and technical conversion tooling
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- S/4HANA simplification items
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/simplification-items
+  source_owner: SAP SE
+  topic_supported: Simplification item list for S/4HANA conversion: impacted business functions, deprecated objects, mandatory configuration adjustments, manual re-implementation items
+  why_needed: Grounds classification of simplification item hits from user-supplied Readiness Check reports; defines conversion-blocking vs. functional-change vs. optional items
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud Public Edition (greenfield / SaaS)
+
+- SAP S/4HANA Cloud — fit-to-standard approach
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/fit-to-standard
+  source_owner: SAP SE
+  topic_supported: Greenfield implementation in S/4HANA Cloud Public Edition (multi-tenant SaaS): fit-to-standard as mandatory approach, extensibility constraints (key-user and side-by-side only), three-system landscape (DEV/TEST/PROD)
+  why_needed: Defines the architectural constraints and implementation approach unique to Cloud Public Edition — critical for assessing whether the user's transformation plan is compatible with this deployment model
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- S/4HANA Cloud — deployment options
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/deployment-options
+  source_owner: SAP SE
+  topic_supported: Comparison of S/4HANA Cloud Public Edition vs. Cloud Private Edition vs. on-premise deployment: update cycles, extensibility permissions, operations responsibilities, license considerations
+  why_needed: Primary reference for assessing deployment model trade-offs when the user is evaluating or has already chosen a deployment target
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Selective data transition (SDT)
+
+- SAP S/4HANA selective data transition approach
+  https://help.sap.com/docs/sap-s4hana-on-premise/sap-s4hana-on-premise/selective-data-transition
+  source_owner: SAP SE
+  topic_supported: Selective data transition (SDT) methodology: use cases, tooling (SAP LT Replication Server, Data Migration Cockpit), data selection criteria, cutover complexity vs. greenfield and brownfield
+  why_needed: Authoritative reference for assessing when SDT is appropriate, what data migration tooling applies, and what additional complexity SDT introduces compared to a pure brownfield or greenfield approach
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP Readiness Check
+
+- SAP Readiness Check for SAP S/4HANA — what is SAP Readiness Check
+  https://help.sap.com/docs/sap-readiness-check/sap-readiness-check/what-is-sap-readiness-check
+  source_owner: SAP SE
+  topic_supported: SAP Readiness Check tool: simplification item impact assessment, custom code analysis scope, business function usage detection, add-on compatibility, technical prerequisite checks, output report structure
+  why_needed: Defines how to interpret the Readiness Check report the user may supply — maps finding categories to transformation risk levels and required remediation actions before conversion begins
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Help Portal and SAP Activate documentation describe methodology, recommended phases, deployment model constraints, and conversion tooling. They do not prove which simplification items affect the user's specific source ECC or S/4HANA release, which business functions are active in their system, or whether the user's landscape has applied the required SAP notes. Users must supply SAP Readiness Check output, project scoping documents, or landscape descriptions for concrete transformation assessment.

package/skills/sap/sap-s4hana-transformation-architecture-review/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety checklist — SAP S/4HANA Transformation Architecture Review
+
+Use before making any transformation strategy recommendation or risk classification, especially for program commitments or deployment model decisions.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAP system. This skill reviews documentation and user-provided artifacts only.
+- Do not accept or request SAP system credentials, RFC destinations, S-user passwords, BTP service keys, or cloud platform API tokens.
+- Do not assume the deployment model. Always confirm with the user whether the target is Cloud Public Edition, Cloud Private Edition, RISE with SAP, or on-premise managed. These have fundamentally different extensibility and operations constraints.
+- Do not classify simplification item impact from memory alone. Only classify findings the user has supplied from their actual Readiness Check output.
+- Do not recommend brownfield conversion without confirming the user's source release is a supported conversion start point for their target S/4HANA release.
+- Do not recommend Cloud Public Edition for a program with significant approved custom ABAP requirements — Cloud Public Edition restricts in-system ABAP extensibility to key-user tools only.
+- Do not recommend selective data transition without acknowledging the additional cutover complexity and dual-tooling requirement compared to brownfield or greenfield.
+- Do not validate fit-to-standard completeness without knowing which modules and lines of business the workshops covered.
+
+## What people get wrong
+
+- **Treating RISE with SAP as a deployment model**: RISE with SAP is a commercial bundle (subscription model including cloud migration, SAP S/4HANA Cloud Private Edition or Public Edition, BTP entitlements). The underlying deployment model is either Cloud Private Edition or Cloud Public Edition. Architectural constraints depend on the underlying edition, not the RISE designation.
+- **Conflating brownfield with minimal-change**: Brownfield conversion still requires simplification item resolution, custom code remediation, and post-conversion fit-to-standard alignment. It is not a "lift and shift" of ECC to S/4HANA.
+- **Assuming greenfield eliminates custom code risk**: Greenfield eliminates the conversion-time custom code issue but does not eliminate the need to re-implement business requirements that SAP standard does not cover. Those requirements still need clean-core-compliant extensibility.
+- **Skipping fit-to-standard workshops**: Fit-to-standard workshops are mandatory in the SAP Activate Explore phase to identify genuine gaps before development begins. Programs that skip them often discover scope in the Realize phase when it is expensive to change direction.
+- **Treating SDT as brownfield-plus-data-selection**: SDT is a distinct approach with its own tooling (SAP LT Replication Server or LTMC-based migration), data selection logic, and cutover complexity. It is not a brownfield conversion with a filter applied.
+- **Ignoring quarterly update discipline for Cloud Public Edition**: Cloud Public Edition mandates quarterly updates with no opt-out. Custom code and integrations must be tested each quarter. Programs that ignore this accumulate testing debt rapidly.
+- **Recommending parallel landscapes without acknowledging cost**: Selective data transition requires running both legacy and S/4HANA systems in parallel during migration, which has infrastructure and license implications the user should budget for explicitly.
+
+## When to push back
+
+- Push back when the user wants to commit to a strategy before the SAP Readiness Check has been executed.
+- Push back when the user wants to adopt Cloud Public Edition but has described requirements that require in-system custom ABAP development.
+- Push back when the transformation roadmap does not include a formal simplification item resolution plan.
+- Push back when fit-to-standard workshops have not been planned or completed for the Explore phase.
+- Push back when the user presents a brownfield cutover plan without a documented rollback / fallback procedure.
+- Push back when the user treats SAP Activate as optional or as a documentation exercise rather than a structural delivery framework.
+- Push back when custom code remediation scope is unknown and the user wants to commit to a Realize phase start date.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Activate methodology, S/4HANA deployment guides, Readiness Check documentation, or SAP Help Portal
+- `user-provided evidence` — SAP Readiness Check output, project plans, fit-to-standard workshop results, or architectural 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-s4hana-transformation-architecture-review/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract — SAP S/4HANA Transformation Architecture Review
+
+Use this reference for all strategy classification, risk assessment, and output formatting.
+
+## Transformation strategy taxonomy
+
+| Strategy | Definition | Primary use case | Key risk |
+|----------|-----------|-----------------|---------|
+| `brownfield` | System conversion of existing ECC or S/4HANA system in-place | Organizations wanting to retain historical data, custom configurations, and existing processes with minimal disruption | Simplification item volume; custom code and modification debt surfaced at conversion time |
+| `greenfield` | New S/4HANA implementation starting from a clean system | Organizations willing to re-implement processes to standard; strong fit-to-standard discipline | Business re-design effort; data migration from legacy; organizational change management scope |
+| `selective-data-transition` | Hybrid approach migrating selected data subsets from legacy to a new S/4HANA system | Organizations needing both a clean system baseline and selective historical data retention | Highest complexity; dual tooling (LT Replication + Migration Cockpit); cutover sequencing risk |
+| `hybrid-phased` | Multi-wave program combining strategies across entities, geographies, or modules | Large enterprises with heterogeneous landscapes (mixed ECC versions, multiple SIDs) | Governance risk; data consistency across wave boundaries; integration architecture between legacy and S/4HANA systems during transition |
+
+## Deployment model taxonomy
+
+| Model | ABAP extensibility | Update cycle | Operations responsibility |
+|-------|------------------|-------------|--------------------------|
+| `cloud-public-edition` | Key-user + side-by-side only; no custom ABAP in-system | Quarterly (mandatory) | SAP-managed SaaS |
+| `cloud-private-edition` | ABAP developer extensibility permitted; clean core recommended | Aligned with SAP S/4HANA on-premise release rhythm | Customer-managed on hyperscaler or SAP Managed Cloud |
+| `rise-with-sap` | Depends on underlying edition (Public or Private); RISE is a bundled commercial offering, not a separate technical variant | Inherits from underlying edition | SAP or partner managed |
+| `on-premise` | Full ABAP developer extensibility; clean core optional | Customer-controlled; SAP support packages and enhancement packages | Customer IT operations |
+
+## SAP Activate phase alignment assessment
+
+For each phase, assess whether the user's program has completed required deliverables:
+
+| Phase | Key deliverables | Common gaps |
+|-------|-----------------|------------|
+| Discover | Business case, transformation roadmap, deployment model decision | No formal deployment model decision; roadmap not SAP Activate structured |
+| Prepare | Project plan, system landscape, governance model, initial Readiness Check run | Readiness Check not yet executed; governance model not defined |
+| Explore | Fit-to-standard workshops, delta design for gaps, simplification item resolution plan | Fit-to-standard workshops incomplete; gaps not triaged; simplification items not classified |
+| Realize | Configuration, development of approved extensibility, data migration mock run 1 | Mock runs not scheduled; extensibility developed outside clean core boundaries |
+| Deploy | Final data migration, cutover rehearsal, go-live readiness gate | No formal go/no-go criteria; cutover rehearsal not completed |
+| Run | Hypercare, operations handover, post-go-live review | No hypercare plan; operations handover not defined |
+
+## Simplification item impact classification
+
+| Impact class | Definition | Assessment action |
+|-------------|-----------|------------------|
+| `conversion-blocking` | System cannot convert until this item is resolved (e.g., deprecated business function active) | Must resolve before conversion; add to critical path |
+| `functional-change` | Process or configuration change required post-conversion; data or process behavior changes | Plan and test in Realize phase; update fit-to-standard scope |
+| `manual-reimplementation` | Custom code or configuration must be manually re-implemented in new SAP approach | Add to custom code remediation scope; classify via `sap-custom-code-remediation-review` |
+| `informational` | No blocking or functional impact; awareness item only | Document; no action required |
+
+## Workflow
+
+1. **Classify transformation strategy** — confirm brownfield / greenfield / SDT / hybrid from user-provided context.
+2. **Confirm deployment model** — confirm target edition (Cloud Public, Cloud Private, RISE, on-premise); flag extensibility implications.
+3. **Assess SAP Activate phase alignment** — map user's program state to SAP Activate phase; identify missing deliverables per phase.
+4. **Classify Readiness Check findings** — if Readiness Check output is provided, classify each finding by impact class above.
+5. **Review fit-to-standard posture** — assess workshop coverage, gap resolution approach, and scope of approved extensibility vs. standard configuration.
+6. **Identify architectural risks** — surface strategy mismatches, deployment model constraint violations, and timeline risks.
+7. **Prioritize recommendations** — conversion-blocking items first; then functional-change and manual-reimplementation; then advisory and optimization.
+8. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Transformation strategy classification and deployment model confirmation
+2. Evidence label per dimension (documentation-based / user-provided evidence / inference)
+3. SAP Activate phase alignment assessment with gap list
+4. Simplification item classification table (if Readiness Check output provided)
+5. Fit-to-standard posture assessment (workshop completeness, gap handling approach)
+6. Risk level per dimension (transformation-blocking / high / medium / low)
+7. Prioritized recommendations with SAP Activate deliverable reference
+8. Escalation trigger if live system data, custom code analysis, or data migration scope is needed before proceeding