@raishin/vanguard-frontier-agentic 2.10.0 → 2.13.0

package/skills/sap/sap-analytics-cloud-planning-governance/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: sap-analytics-cloud-planning-governance
+description: Review SAP Analytics Cloud governance: stories, planning models, versions, data actions, allocations, value driver trees, live vs. import connections, data access control, and performance. Flags planning model design gaps, version management risks, data action correctness issues, and access control weaknesses. Does not touch live systems.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: data
+  lifecycle: experimental
+---
+
+# SAP Analytics Cloud Planning Governance Review
+
+## Purpose
+
+Assess the governance, design, and operational posture of an SAP Analytics Cloud (SAC) implementation covering both analytics and planning workloads. Review story and model design for correctness, planning model structure (versions, categories, dimensions, and measures), data action and multi-action design for correctness and sequencing, allocation step configuration, value driver tree design, live connection vs. import connection selection and refresh governance, data access control (role-based and story-level), and performance posture of models and stories. Surface planning model design gaps, version management risks, data action correctness and sequencing issues, connection type misuse, and access control weaknesses. Does not connect to or mutate any live SAC tenant.
+
+## When to use
+
+Use this skill when the user asks to:
+
+- review SAC story design for layout correctness, widget-to-model binding, filter logic, and performance (page count, number of queries, widget density),
+- assess planning model design: version category structure (actual, budget, forecast, rolling forecast), dimension design, account dimension configuration, date dimension setup, and measure definition,
+- evaluate data action design for step sequencing, script logic correctness (Advanced Formula), trigger and schedule configuration, and error handling,
+- review allocation step design: allocation method selection (spread, distribution, breakback), driver dimension choice, and allocation result validation approach,
+- assess value driver tree (VDT) design for formula correctness, node connectivity, and planning model binding,
+- audit multi-action configuration for step ordering, action dependencies, and failure handling between actions,
+- review live connection vs. import connection decisions for each SAC model: connection type appropriateness, import schedule cadence, incremental load vs. full refresh trade-offs,
+- evaluate data access control: role assignment (BI Admin, Planner, Viewer, custom roles), team-level data access, dimension member-level access restrictions in planning models,
+- flag planning anti-patterns: missing version locking after actuals close, overly complex data action scripts, unbounded allocation hierarchies, or stories consuming too many import models without caching.
+
+## When not to use
+
+- When the user needs live inspection of a running SAC tenant, model refresh status, or data action execution log — this skill accepts only user-provided descriptions, model exports, story screenshots, or architecture documents.
+- When the request is about the underlying Datasphere semantic model that feeds a SAC live connection — use `sap-datasphere-data-product-architecture`.
+- When the request concerns BTP-level governance (entitlements, subaccounts, SAC service instance provisioning) — use `sap-btp-governance-review`.
+- When the request is specifically about HANA Cloud performance for models connected via live HANA connection — use `sap-hana-cloud-performance-cost`.
+
+## Does not touch live systems
+
+This skill operates on user-provided descriptions, story screenshots, model export files, data action scripts, planning model configuration summaries, connection configuration descriptions, or architecture documents. It does not connect to any SAC tenant, invoke SAC APIs, refresh any model, execute any data action, or access any live connection source. All live inspection is out of scope.
+
+## Lean operating rules
+
+- Classify findings before recommending. Every finding must be assigned to a design domain (stories, planning models, data actions, allocations, value driver trees, connections, data access controls, performance) before remediation is proposed.
+- Planning version categories are the governance backbone. Actuals must be locked after the close period. Budget and forecast versions must have explicit owner assignment and locking governance. Missing version locking is a planning integrity risk.
+- Data actions are sequential and stateful. The order of steps in a data action matters: steps that read data must execute before steps that overwrite it. Incorrect step ordering produces silent wrong results, not errors.
+- Advanced Formula correctness requires explicit scope. Data action Advanced Formula steps that do not explicitly scope their MEMBERSET or RESULTLOOKUP expressions operate on the full model scope, which is a performance and correctness risk.
+- Live connections require SAC-compatible model types on the source. SAC live connections to Datasphere, BW, or S/4HANA require source objects with specific metadata. Connecting to an incompatible source object type produces a broken story, not an error at connection time.
+- Import models require governed refresh schedules. An import model without a defined refresh schedule becomes stale. Missing refresh schedules on planning-adjacent import models (actuals feed) undermine planning model accuracy.
+- Allocation hierarchies must have bounded scope. Allocation steps that traverse unfiltered dimension hierarchies on large planning models cause timeout failures. Allocation hierarchy scope must be bounded by filter or version to production-safe levels.
+- Role assignments must follow least-privilege for planning. Planner roles must not be assigned to users who should only view data. BI Admin access must not be used as a default role. Custom roles scoped to specific models and stories are the correct pattern for large multi-team SAC deployments.
+- Evidence from user-provided artifacts or official SAP Analytics Cloud documentation takes precedence over inference.
+- Load only the reference needed for the component under review.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP Analytics Cloud Help Portal documentation, SAP Help Portal planning guides, or official SAC connection and security docs
+- `user-provided evidence` — story screenshots, model export files, data action scripts, planning model configuration summaries, or architecture documents provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no SAC API call, tenant login, model refresh trigger, data action execution, allocation run, or connection to any source system in this skill's execution path. Users must supply story screenshots, model configuration exports, data action scripts, or written descriptions of their SAC implementation for this skill to review.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — design domain taxonomy, finding severity, output format.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, common mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAC story design, planning models, data actions, allocations, live and import connections, data access controls, and performance docs.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: design domain(s) affected (stories / planning models / data actions / allocations / value driver trees / connections / data access controls / performance) and specific finding(s).
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (planning integrity breach or unauthorized data access) / high (planning model failure, data action correctness error, or connection reliability risk) / medium (governance gap or performance risk) / low (best practice deviation).
+- **Recommended action**: specific remediation per finding (version locking, data action step reordering, Advanced Formula scope restriction, connection type change, role scope reduction, allocation filter addition, or refresh schedule definition).
+- **Refusal / escalation triggers**: if live SAC tenant access, model refresh, data action execution, or allocation run is required to complete the review, state that clearly and do not proceed.
+- **Business impact**: planning integrity risk, reporting accuracy risk, performance degradation, unauthorized data access, or compliance gap.
+- **Next verification step**: validate recommended changes against the current SAC tenant model configuration before applying.

package/skills/sap/sap-analytics-cloud-planning-governance/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Analytics Cloud Planning Governance Review"
+  short_description: "Review SAP Analytics Cloud governance: stories, planning models, version categories, data actions, allocations, value driver trees, live vs. import connections, data access controls, and performance. Flags planning integrity risks and access control weaknesses."
+  default_prompt: "Use $sap-analytics-cloud-planning-governance to assess the provided SAP Analytics Cloud implementation. Classify each finding by design domain (stories, planning models, data actions, allocations, value driver trees, connections, data access controls, performance), assign a risk level (critical/high/medium/low), and recommend specific remediation actions. State evidence level (documentation-based, user-provided evidence, inference) and whether live tenant access is required to complete the review."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/SAP_ANALYTICS_CLOUD/00f68c2e08b941f081002fd3691d86a7/5b12c2e3b0f14e31bcee9b0b19d3b254.html"
+      description: "SAP Analytics Cloud planning model documentation — primary reference for version categories, dimension design, and planning model governance"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-analytics-cloud-planning-governance/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-analytics-cloud-planning-governance",
+  "name": "SAP Analytics Cloud Planning Governance Review",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review SAP Analytics Cloud governance: stories, planning models, version categories, data actions, allocations, value driver trees, live vs. import connections, data access controls, and performance. Flags planning model design gaps, version management risks, data action correctness issues, and access control weaknesses. Does not access live systems.",
+  "source_type": "original",
+  "category": "data",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/stories",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/planning-models",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-actions",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/allocations",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/live-data-connections",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-access-control",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/performance",
+    "https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/what-is-sap-analytics-cloud"
+  ],
+  "security_notes": "Does not access live SAP Analytics Cloud tenants, model APIs, data action execution APIs, or connected source systems. Accepts only user-provided story screenshots, model export files, data action scripts, planning model configuration summaries, or written descriptions. Never request or accept SAC tenant credentials, OAuth tokens, API keys, planning model data, or dimension member data that may contain personal or financial information. Governance recommendations must be validated against the live SAC tenant configuration before applying.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-analytics-cloud-planning-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-analytics-cloud-planning-governance/references/official-sources.md

@@ -0,0 +1,89 @@
+# Official sources — SAP Analytics Cloud Planning Governance Review
+
+Use this reference when grounding SAC story design, planning model governance, data action review, allocation assessment, connection type evaluation, data access control audit, and performance posture review.
+
+**Evidence level**: documentation-based (SAP Analytics Cloud Help Portal). No live-system evidence is collected by this skill.
+
+## Stories and models
+
+- Stories in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/stories
+  source_owner: SAP SE
+  topic_supported: Story design, page layout, widget types, filter configuration, model binding, calculated measures in stories
+  why_needed: Primary reference for classifying story design findings including widget-to-model binding correctness, filter scope, and story-level performance governance
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Planning models
+
+- Planning models in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/planning-models
+  source_owner: SAP SE
+  topic_supported: Planning model creation, version category structure (actual, budget, forecast, rolling forecast), account dimension, date dimension, measure definition, model locking
+  why_needed: Defines the planning model structure — required to classify version category design gaps, dimension configuration errors, and missing version locking as planning integrity findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data actions
+
+- Data actions in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-actions
+  source_owner: SAP SE
+  topic_supported: Data action step types (Advanced Formula, copy, allocation, date-based distribution), step sequencing, trigger configuration, multi-action orchestration
+  why_needed: Defines the data action execution model — required to classify step sequencing errors, incorrect scope definitions, and missing trigger configuration as planning pipeline findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Allocations
+
+- Allocations in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/allocations
+  source_owner: SAP SE
+  topic_supported: Allocation methods (spread, distribution, breakback), driver dimension selection, allocation hierarchy scope, allocation result validation
+  why_needed: Defines the allocation step model — required to classify incorrect allocation method selection, unbounded hierarchy scope, and missing validation as planning process findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Connections
+
+- Live data connections in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/live-data-connections
+  source_owner: SAP SE
+  topic_supported: Live connection vs. import connection capabilities, supported source systems, connection type trade-offs, import data refresh scheduling, incremental load configuration
+  why_needed: Defines the connection type model — required to classify live vs. import connection misuse, missing refresh schedules on import models, and incremental load configuration gaps
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Data access controls
+
+- Data access control in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/data-access-control
+  source_owner: SAP SE
+  topic_supported: Role-based access (BI Admin, Planner, Viewer, custom roles), team-level data access, dimension member-level access restrictions in planning models, folder and story sharing permissions
+  why_needed: Defines the SAC access control model — required to classify over-permissive role assignments, missing dimension-level data restrictions, and ungoverned story sharing as access control findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Performance
+
+- Performance optimization in SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/performance
+  source_owner: SAP SE
+  topic_supported: Story performance optimization, widget count guidelines, query reduction strategies, model size limits, import model caching, live connection query push-down behavior
+  why_needed: Defines the performance model for SAC stories and models — required to classify stories with excessive widget density, unbounded query scope, or import model refresh cadence gaps as performance findings
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Overview
+
+- What is SAP Analytics Cloud
+  https://help.sap.com/docs/sap-analytics-cloud/sap-analytics-cloud/what-is-sap-analytics-cloud
+  source_owner: SAP SE
+  topic_supported: SAP Analytics Cloud product overview, feature set, BI and planning capabilities, tenant model
+  why_needed: Provides the product-level context for all governance assessment; defines capability boundaries and tenant model
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP Analytics Cloud Help Portal documentation describes the designed behavior of stories, planning models, data actions, allocations, connections, and access controls. It does not prove which models exist in the user's tenant, whether data actions are correctly configured, or whether version locking is in effect. Users must supply story screenshots, model configuration exports, data action scripts, or written descriptions for concrete assessment.

package/skills/sap/sap-analytics-cloud-planning-governance/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist — SAP Analytics Cloud Planning Governance Review
+
+Use before making any remediation recommendation, especially for findings that affect planning version locking, data action execution, allocation design, or role-based access.
+
+## Non-negotiables
+
+- Do not access, connect to, or request access to any live SAC tenant, model, data action, or connected source system. This skill reviews artifacts only.
+- Do not accept or request SAC tenant credentials, OAuth tokens, API keys, model data exports containing financial data, or dimension member lists that may contain personal or organizational data.
+- Do not recommend unlocking a locked actuals version. Locked actuals versions represent closed-period data and must not be unlocked without a documented change control process involving data owners and finance governance.
+- Do not recommend executing a data action or allocation on a production planning model based on review alone. All data action changes must be tested in a development or quality model before production deployment.
+- Do not recommend changing the account dimension type or date dimension granularity of an existing planning model with active data. These are foundational model properties — changing them requires model rebuild and data migration, not in-place configuration change.
+- Do not recommend granting BI Admin role as a workaround for access issues. BI Admin provides tenant-wide administration rights. The correct remedy for access gaps is a scoped custom role, not elevated built-in role assignment.
+- Do not classify a finding as `critical` without being able to trace the specific planning integrity breach or unauthorized access path from user-provided artifacts or official documentation.
+
+## What people get wrong
+
+- **Treating data actions and multi-actions as equivalent**: Data actions contain steps that execute as a single unit within one model. Multi-actions orchestrate multiple data actions, potentially across models, with independent execution and separate failure points. Sequencing recommendations for data action steps do not apply at the multi-action orchestration level and vice versa.
+- **Recommending live connection for planning models**: SAC planning models cannot be backed by a live connection — they require an import connection or are created natively in SAC. Recommending a live connection for a planning model is incorrect; live connections apply only to analytics-only models.
+- **Assuming all dimension member restrictions apply automatically to all story users**: Dimension member-level data access restrictions in SAC apply to teams, not directly to individual users. A user must be a member of a correctly configured team to inherit dimension member restrictions. Recommending restrictions without confirming the team membership model is incomplete.
+- **Conflating version locking with model locking**: Version locking prevents writes to a specific planning version (e.g., actuals). Model locking prevents any user from editing or running data actions on the entire model. They are different controls with different operational consequences.
+- **Missing the impact of model structure changes on active stories**: Changes to the planning model (removing measures, renaming dimensions, changing account hierarchy) immediately break any SAC story that references the changed elements. There is no graceful degradation — stories display errors. Model changes must be coordinated with story owners before deployment.
+- **Recommending full refresh for large import models where incremental load is available**: Full refresh replaces all model data on each run and is appropriate for small models. Large import models (millions of rows) should use incremental (delta) load where the source connection supports it. Recommending full refresh without confirming model size and refresh window creates data availability gaps.
+
+## When to push back
+
+- Push back when the user asks to confirm a data action correctness finding from a description alone without providing the data action script or step configuration.
+- Push back when the user asks for specific allocation amounts or formula values — this skill reviews governance and design, not planning content.
+- Push back when the user asks to recommend unlocking actuals or deploying data action changes to a production model without a development/test validation step.
+- Push back when a request requires live SAC tenant access, model data inspection, data action execution, or allocation run — state clearly that live inspection is out of scope and ask the user to supply the relevant configuration exports or descriptions.
+
+## Evidence labels
+
+- `documentation-based` — grounded in SAP Analytics Cloud Help Portal documentation covering stories, planning models, data actions, allocations, connections, or access control
+- `user-provided evidence` — story screenshots, model export files, data action scripts, planning model configuration summaries, connection descriptions, or architecture 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-analytics-cloud-planning-governance/references/workflow-and-output.md

@@ -0,0 +1,70 @@
+# Workflow and output contract — SAP Analytics Cloud Planning Governance Review
+
+Use this reference for all finding classification, risk assignment, remediation path selection, and output formatting.
+
+## Design domain taxonomy
+
+| Domain | Scope | Typical findings |
+|--------|-------|-----------------|
+| `stories` | Story layout, widget binding, filter configuration, calculated measures | Incorrect model binding, filter scope too broad or too narrow, excessive page count, missing input control for planning tables |
+| `planning-models` | Version category structure, dimension design, account dimension, date dimension, measure types | Missing actual version lock after period close, incorrect account dimension type, absence of rolling forecast version, incorrect date dimension granularity |
+| `data-actions` | Step type selection, sequencing, Advanced Formula scope, trigger and schedule configuration | Incorrect step order causing data overwrite before read, unbounded MEMBERSET scope, missing trigger configuration, no multi-action failure handling |
+| `allocations` | Allocation method selection, driver dimension, hierarchy scope, validation approach | Incorrect allocation method for use case (spread vs. distribution vs. breakback), unfiltered hierarchy traversal on large model, no result validation step |
+| `value-driver-trees` | Node formula correctness, model binding, hierarchy connectivity | Broken node formula referencing deleted measure, disconnected VDT node, incorrect measure aggregation in VDT formula |
+| `connections` | Live vs. import connection selection, import refresh schedule, incremental load | Live connection to incompatible source object, import model without refresh schedule, full refresh where incremental load is supported and preferred |
+| `data-access-controls` | Role assignment scope, team data access, dimension member restrictions | BI Admin assigned as default role, planner access granted to view-only users, missing dimension member restriction on regulated data, ungoverned public story sharing |
+| `performance` | Widget density, query count, model size, import model caching | Story with excessive widget count per page, live connection story with no default page filter, import model queried without caching strategy |
+
+## Risk severity classification
+
+| Risk level | Criteria |
+|-----------|---------|
+| `critical` | Planning integrity breach or unauthorized data access: missing version lock on actuals allowing post-close changes, BI Admin access granted to non-admin users, missing dimension-level data restriction on regulated financial data |
+| `high` | Planning model failure or data action correctness error: data action step sequencing error producing incorrect plan data, live connection to incompatible source breaking story load, allocation with unfiltered hierarchy causing timeout |
+| `medium` | Governance gap or performance risk: import model without refresh schedule, planning model without rolling forecast version, story with excessive widget density causing slow load |
+| `low` | Best practice deviation: missing naming convention on versions, undocumented data action trigger schedule, VDT with no description on nodes |
+
+## Remediation path decision tree
+
+For each finding:
+
+1. **Is this a missing version lock on an actuals version after the period has closed?**
+   - Yes → `critical`. Lock the actuals version immediately. Audit all data action triggers that write to the actuals version and restrict them to authorized users only. Enable version change history to detect if unauthorized edits occurred during the unlocked window.
+   - No → continue.
+
+2. **Is this an unauthorized role assignment (BI Admin as default, Planner where Viewer is correct)?**
+   - Yes → `critical` or `high` depending on the data sensitivity. Reduce the role to the minimum required (Viewer for read-only consumers, custom scoped Planner role for authorized contributors). Remove generic BI Admin assignments from users who do not require tenant administration.
+   - No → continue.
+
+3. **Is this a data action step sequencing error or unbounded Advanced Formula scope?**
+   - Yes → `high`. For sequencing errors, reorder steps so read steps precede write steps for any shared data region. For unbounded scope, add explicit MEMBERSET restrictions to limit formula execution to the intended version, entity, and time dimensions.
+   - No → continue.
+
+4. **Is this a live connection to an incompatible source object type?**
+   - Yes → `high`. Confirm the source object type against the SAC live connection compatibility matrix. Convert to a compatible source object (for Datasphere: analytic model or analytical dataset; for BW: BEx query or Composite Provider with defined characteristics and key figures) or switch to import connection if live is not required.
+   - No → continue.
+
+5. **Is this a governance or performance gap?**
+   - Yes → `medium`. Define import model refresh schedules, add rolling forecast version to planning model, apply default page filters to live connection stories, or add dimension member restrictions to regulated data models.
+   - No → classify as `low` and provide best practice guidance.
+
+## Workflow
+
+1. **Receive artifacts** — story screenshots, model configuration exports, data action scripts, planning model configuration summaries, connection descriptions, or user descriptions.
+2. **Classify each finding** by design domain and finding type.
+3. **Assign risk level** (critical / high / medium / low).
+4. **Apply remediation decision tree** per finding.
+5. **Prioritize** — critical planning integrity and access control findings first; then high model and data action failures; then medium governance and performance gaps; then low best-practice items.
+6. **Return output** per the output contract below.
+
+## Output contract
+
+Return:
+
+1. Design domain and specific finding type
+2. Evidence label (documentation-based / user-provided evidence / inference)
+3. Risk level per finding (critical / high / medium / low)
+4. Recommended remediation action with specific implementation guidance
+5. Planning governance posture after remediation
+6. Prioritized remediation sequence
+7. Escalation trigger if live SAC tenant access, model refresh, or data action execution is required to confirm or apply the finding

package/skills/sap/sap-audit-evidence-packaging/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: sap-audit-evidence-packaging
+description: Package and structure audit evidence for SAP controls covering Segregation of Duties, change management, access management, and financial controls. Defines evidence taxonomy, maps controls to evidence artifacts, establishes chain-of-custody and redaction requirements, and aligns evidence packages to SOC 2, ISO 27001, SOX, and GxP frameworks. Does not touch live systems and never includes secrets, credentials, or personal identifiable information in evidence packages.
+allowed-tools: Read Grep Glob WebSearch WebFetch
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-19"
+  category: compliance
+  lifecycle: experimental
+---
+
+# SAP Audit Evidence Packaging
+
+## Purpose
+
+Structure, classify, and package audit evidence for SAP system controls to support internal audit, external audit, and regulatory compliance assessments. Define an evidence taxonomy aligned to SAP control domains. Map controls to the specific evidence artifacts required to demonstrate control effectiveness. Establish chain-of-custody requirements and redaction rules for evidence that contains sensitive system or personal data. Assess evidence reproducibility and advise on gaps. Align evidence packages to the requirements of SOC 2 Type II, ISO/IEC 27001, SOX ITGC, and GxP (21 CFR Part 11 / EU Annex 11) frameworks. Does not connect to any live SAP system, never requests or accepts credentials, and never includes secrets, credentials, personal identifiable information, or customer data in evidence packages.
+
+## When to use
+
+Use this skill when the user needs to:
+
+- define an evidence taxonomy for a SAP audit: which artifact types constitute valid evidence for each SAP control domain (SoD, access management, change management, financial controls),
+- map specific SAP controls from a control framework (SOX ITGC, SOC 2 CC6/CC8, ISO 27001 A.9, GxP Annex 11) to the concrete evidence artifacts that demonstrate their effectiveness,
+- structure an evidence package for a specific control: what to collect, how to label it, what metadata to include, and how to maintain chain-of-custody,
+- review a set of evidence artifacts provided by the user and assess whether they are sufficient to demonstrate control effectiveness for the stated control objective,
+- advise on redaction of sensitive data from SAP audit evidence: which fields must be redacted from GRC SoD reports, role assignment exports, transport request logs, and financial posting reports before inclusion in an audit package,
+- assess evidence reproducibility: whether the evidence artifact can be regenerated from the same source system state and time window, and what risks affect reproducibility,
+- define a control-to-evidence mapping document suitable for use in an audit readiness assessment or external auditor evidence request response.
+
+## When not to use
+
+- When the user needs live enumeration of SAP system configuration to gather evidence — use `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for read-only live evidence gathering.
+- When the user needs SoD conflict review or IAM posture assessment rather than evidence packaging — use `sap-security-iam-grc-sod-review`.
+- When the request is about implementing SAP GRC Access Control rulesets or configuring audit log settings — this skill is advisory and evidence-packaging focused, not implementation focused.
+- When the request is about non-SAP control evidence packaging or general compliance framework interpretation without SAP-specific context.
+
+## Does not touch live systems
+
+This skill operates on user-provided evidence artifacts, control descriptions, audit scope descriptions, control framework excerpts, and written descriptions of the SAP landscape. It does not connect to any SAP system, BTP subaccount, GRC Access Control instance, ABAP system, S/4HANA tenant, or audit log service. All live evidence gathering is out of scope.
+
+## Lean operating rules
+
+- Classify evidence by control domain before structuring. Every evidence artifact or gap must be assigned to a control domain (SoD / Access Management / Change Management / Financial Controls / System Configuration) before packaging advice is given.
+- Chain-of-custody is required for all live evidence. Evidence gathered from a live SAP system must be accompanied by: source system identifier, extraction method, extraction timestamp, person who extracted it, and any transformations applied. Evidence without chain-of-custody metadata is incomplete.
+- Redaction before packaging is mandatory. Any evidence artifact that contains passwords, API keys, OAuth tokens, SAML private keys, personal identifiable information (employee IDs, social security numbers, salary data), or customer confidential data must be redacted before inclusion in an audit package.
+- Reproducibility must be assessed. For each evidence artifact, advise whether it can be reproduced from the same source and time window. Evidence that cannot be reproduced (e.g., a one-time GRC report extraction from a period now past) must be designated as non-reproducible and stored with heightened custody controls.
+- Framework alignment is explicit. For each control-to-evidence mapping, state which specific control requirement from the target framework (SOC 2 Trust Service Criteria, ISO 27001 Annex A, SOX ITGC, GxP Annex 11) the evidence addresses.
+- Gaps are findings. A control that lacks sufficient evidence to demonstrate effectiveness is a gap finding. Classify gaps by severity: a control with no evidence is `critical`; a control with partial evidence is `high`; a control with evidence that does not cover the full audit period is `medium`.
+- Evidence from user-provided artifacts and official SAP and regulatory framework documentation takes precedence over inference.
+- Load only the reference needed for the control domain in scope.
+
+## Evidence rules
+
+Label all claims with one of:
+
+- `documentation-based` — grounded in SAP audit and compliance documentation, GRC best practices, or regulatory framework requirements (SOC 2, ISO 27001, SOX, GxP)
+- `user-provided evidence` — audit evidence artifacts, control descriptions, audit scope descriptions, or written landscape descriptions provided by the user
+- `inference` — derived reasoning not directly confirmed by official docs or user evidence
+
+## Live-environment rules
+
+**This skill does not touch live systems.** There is no SAP system API call, GRC Access Control connection, BTP subaccount access, ABAP RFC call, audit log service query, or S/4HANA tenant access in this skill's execution path. Users must supply evidence artifacts, control descriptions, and audit scope information for this skill to advise on packaging, redaction, and framework alignment.
+
+**This skill never includes in any output**:
+- Passwords, API keys, OAuth tokens, or credentials of any kind
+- SAML signing certificate private keys or X.509 private keys
+- Personal identifiable information: employee names, employee IDs, national identification numbers, salary data, or health data
+- Customer confidential data or customer personal data
+- BTP service key values, client secrets, or connection strings with embedded credentials
+
+If a user-provided evidence artifact contains any of the above, advise on redaction before including any excerpt in this skill's output.
+
+## References
+
+Load only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — evidence taxonomy, control-to-evidence mapping structure, chain-of-custody format, output contract.
+- [Safety checklist](references/safety-checklist.md) — non-negotiables, redaction requirements, common audit evidence mistakes, when to push back.
+- [Official sources](references/official-sources.md) — SAP GRC documentation, SAP audit and compliance guides, SOC 2, ISO 27001, SOX ITGC, and GxP references.
+
+## Response minimum
+
+Return, at minimum:
+
+- **Problem classification**: control domain(s) in scope (SoD / Access Management / Change Management / Financial Controls / System Configuration) and the specific controls or evidence gaps being addressed.
+- **Evidence used**: documentation-based / user-provided evidence / inference.
+- **Risk level**: critical (control with no evidence; unmitigated gap before audit deadline) / high (partial evidence; evidence not covering full audit period) / medium (evidence present but chain-of-custody incomplete; redaction not applied) / low (minor metadata gap; reproducibility risk only).
+- **Recommended action**: specific evidence artifact to collect, redaction to apply, chain-of-custody metadata to add, or framework mapping to document.
+- **Refusal / escalation triggers**: if live SAP system access, GRC report extraction, or audit log query is required to complete the evidence package, state that clearly and direct to `sap-live-readonly-landscape-discovery` or `sap-live-readonly-identity-trust-discovery` for the evidence gathering step.
+- **Business impact**: audit finding risk, regulatory non-compliance, certification failure, or evidence admissibility challenge.
+- **Next verification step**: confirm chain-of-custody completeness and redaction with the control owner before submitting evidence to an external auditor.

package/skills/sap/sap-audit-evidence-packaging/agents/openai.yaml

@@ -0,0 +1,11 @@
+interface:
+  display_name: "SAP Audit Evidence Packaging"
+  short_description: "Package and structure audit evidence for SAP controls: SoD, change management, access management, and financial controls — with evidence taxonomy, chain-of-custody, redaction, and SOC 2/ISO 27001/SOX/GxP alignment"
+  default_prompt: "Use $sap-audit-evidence-packaging to advise on structuring the provided SAP audit evidence. Classify findings by control domain (SoD / Access Management / Change Management / Financial Controls / System Configuration), assign severity to evidence gaps (critical / high / medium / low), state evidence level (documentation-based / user-provided evidence / inference), and recommend specific artifacts, chain-of-custody metadata, redaction actions, and framework mappings per control. Never include credentials, personal identifiable information, or customer data in any output."
+dependencies:
+  tools:
+    - type: "web"
+      value: "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control"
+      description: "SAP GRC Access Control documentation — verify SoD evidence artifact types and control report formats"
+policy:
+  allow_implicit_invocation: true

package/skills/sap/sap-audit-evidence-packaging/metadata.json

@@ -0,0 +1,33 @@
+{
+  "id": "sap-audit-evidence-packaging",
+  "name": "SAP Audit Evidence Packaging",
+  "type": "skill",
+  "provider": "sap",
+  "harnesses": [
+    "claude-code",
+    "codex",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Package and structure audit evidence for SAP controls covering Segregation of Duties, change management, access management, and financial controls. Defines evidence taxonomy, control-to-evidence mapping, chain-of-custody, redaction rules, and framework alignment for SOC 2, ISO 27001, SOX, and GxP. Does not access live systems and never includes secrets, credentials, or personal identifiable information in evidence packages.",
+  "source_type": "original",
+  "category": "compliance",
+  "official_docs": [
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control",
+    "https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties",
+    "https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/what-is-sap-grc-process-control",
+    "https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/documentation-and-evidence-collection",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/audit-logging-in-the-cloud-foundry-environment",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/audit-management",
+    "https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/change-document-logs",
+    "https://help.sap.com/docs/btp/sap-business-technology-platform/change-and-transport-system"
+  ],
+  "security_notes": "Does not access live SAP systems, GRC Access Control instances, BTP subaccounts, ABAP systems, audit log services, or S/4HANA tenants. Accepts only user-provided evidence artifacts, control descriptions, and audit scope information. Never request or accept SAP system credentials, BTP service keys, OAuth tokens, or GRC logon credentials. Never include in output: passwords, API keys, personal identifiable information, employee IDs, salary data, customer confidential data, or SAP SAML private keys. Any user-provided evidence artifact containing sensitive data must be advised for redaction before inclusion.",
+  "last_verified": "2026-06-19",
+  "path": "skills/sap/sap-audit-evidence-packaging",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "lifecycle": "experimental"
+}

package/skills/sap/sap-audit-evidence-packaging/references/official-sources.md

@@ -0,0 +1,92 @@
+# Official sources — SAP Audit Evidence Packaging
+
+Use this reference when grounding SAP control evidence requirements, GRC documentation, audit log configuration, change management evidence, and regulatory framework alignment.
+
+**Evidence level**: documentation-based (SAP Help Portal, SAP GRC documentation, regulatory framework publications). No live-system evidence is collected by this skill.
+
+## SAP GRC Access Control
+
+- What Is SAP GRC Access Control
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/what-is-sap-grc-access-control
+  source_owner: SAP SE
+  topic_supported: GRC Access Control overview — Access Risk Analysis, Access Request Management, Emergency Access Management, Business Role Management; evidence artifact types generated by each module
+  why_needed: Defines the GRC Access Control report types and module outputs that constitute valid SoD and access management audit evidence
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Segregation of Duties in SAP GRC Access Control
+  https://help.sap.com/docs/sap-grc-access-control/sap-grc-access-control/segregation-of-duties
+  source_owner: SAP SE
+  topic_supported: SoD rule sets, function definitions, permission-level risk definitions, SoD conflict report generation, risk classification, mitigation control documentation
+  why_needed: Defines what a complete SoD evidence artifact looks like from GRC Access Control; used to assess whether a user-provided SoD report is sufficient for audit
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## SAP GRC Process Control
+
+- What Is SAP GRC Process Control
+  https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/what-is-sap-grc-process-control
+  source_owner: SAP SE
+  topic_supported: Continuous control monitoring, control documentation, assessment workflows, policy management, issue management — evidence artifacts for financial and operational controls
+  why_needed: Defines the GRC Process Control evidence artifact types for financial control and operational control assessment documentation
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- Documentation and Evidence Collection in SAP GRC Process Control
+  https://help.sap.com/docs/sap-grc-process-control/sap-grc-process-control/documentation-and-evidence-collection
+  source_owner: SAP SE
+  topic_supported: Evidence attachment to controls in GRC Process Control, assessment documentation, evidence types, audit trail of assessment activities
+  why_needed: Authoritative source for what constitutes valid evidence attachment in GRC Process Control; used to advise on evidence linking and chain-of-custody within the GRC system
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## BTP Audit Logging
+
+- Audit Logging in the Cloud Foundry Environment
+  https://help.sap.com/docs/btp/sap-business-technology-platform/audit-logging-in-the-cloud-foundry-environment
+  source_owner: SAP SE
+  topic_supported: BTP audit log service — configuration audit messages, security event logging, audit log retrieval via API, audit log retention
+  why_needed: Defines BTP audit log evidence artifact types and API-based extraction methods for BTP platform controls; used to assess BTP audit log evidence completeness
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud Change Management
+
+- SAP S/4HANA Cloud — change document logs
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/change-document-logs
+  source_owner: SAP SE
+  topic_supported: Change document logs in S/4HANA Cloud: financial posting change documents, master data change documents, configuration change logging, evidence export
+  why_needed: Defines change document evidence artifacts for financial control and master data governance audits; used to assess evidence completeness for SOX ITGC change management controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+- BTP Change and Transport System
+  https://help.sap.com/docs/btp/sap-business-technology-platform/change-and-transport-system
+  source_owner: SAP SE
+  topic_supported: SAP Change and Transport System (CTS), transport request lifecycle, transport route configuration, transport log export, import queue management
+  why_needed: Defines the change management evidence artifact types from CTS; used to assess completeness of transport log and approval evidence for SOX ITGC change management controls
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## S/4HANA Cloud Audit and Compliance
+
+- SAP S/4HANA Cloud — audit management
+  https://help.sap.com/docs/sap-s4hana-cloud/sap-s4hana-cloud/audit-management
+  source_owner: SAP SE
+  topic_supported: S/4HANA Cloud audit management — security audit log activation, audit log analysis, data access logging, retention settings for audit evidence
+  why_needed: Defines the S/4HANA Cloud audit log and security audit evidence artifacts available for access control and financial control audits
+  evidence_level: primary
+  last_verified: 2026-06-19
+
+## Grounding rule
+
+SAP documentation describes available report types, API endpoints, and control artifact formats. It does not prove whether a specific GRC report was run for the correct audit period, whether the change management approval chain was actually followed, or whether evidence artifacts are sufficient to satisfy a specific external auditor's evidentiary requirements. Compliance declarations and evidence sufficiency assessments must be made by qualified auditors, not by this skill.
+
+## Regulatory framework references
+
+The following are cited by this skill for framework alignment. They are referenced by name and article/clause only — do not treat this skill as a legal or regulatory compliance authority.
+
+- **SOC 2 Trust Service Criteria**: CC6 (Logical and Physical Access Controls), CC8 (Change Management) — AICPA Trust Services Criteria 2017 with 2022 points of focus
+- **ISO/IEC 27001:2022**: Annex A controls A.5 (Organizational Controls), A.8 (Technological Controls), A.9 (Physical Controls) — particularly A.5.15 (Access Control), A.8.2 (Privileged Access Rights), A.8.32 (Change Management)
+- **SOX ITGC**: Logical Access, Program Change, Computer Operations, and Data Center / Physical Security control categories as defined in AS 2201 (PCAOB)
+- **GxP**: 21 CFR Part 11 (FDA electronic records and signatures) and EU GMP Annex 11 (Computerised Systems) — particularly clauses 7 (Access Security), 10 (Change and Configuration Management), 11 (Data Storage), and 12 (Audit Trails)