@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/microsoft/fabric-analytics-engineering/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production warehouse schema changes, semantic-model deployment, or deployment-pipeline promotion.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, workspace URLs, connection strings, or customer data into chat.
+- Use sanitized DDL scripts, semantic model metadata (PBIP/TMDL), or DAX measure definitions for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent warehouse schemas, relationship configurations, DAX measure outputs, or DirectQuery fallback states.
+- Require explicit human approval before recommending any production warehouse DDL change (ALTER TABLE, DROP, schema rename), semantic-model publication or overwrite, deployment-pipeline promotion, or XMLA endpoint write operation.
+- Use current official Microsoft Learn documentation for Fabric Data Warehouse T-SQL, Direct Lake, and DAX behavior.
+- Keep recommendations least-breaking and reversible; prefer additive changes (new columns, new measures) over destructive schema replacements.
+
+## Stress checks
+
+- Which fact tables lack surrogate keys or have wrong granularity (measure accuracy risk)?
+- Which DAX measures use implicit aggregation, calculated columns for aggregation, or incorrect filter context (result correctness risk)?
+- Which Direct Lake models use SQL views that will silently fall back to DirectQuery and degrade performance?
+- Which relationships have bidirectional cross-filter creating multiple ambiguous paths (incorrect filter propagation risk)?
+- Which T-SQL queries carry implicit type conversions or missing WHERE clauses on large fact scans (query performance risk)?
+- What rollback path exists if a warehouse DDL change breaks a downstream semantic model or Power BI report?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual warehouse schema, semantic model relationship state, DAX measure correctness, or DirectQuery fallback behavior.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Executing DDL (CREATE, ALTER TABLE, DROP, RENAME) against production Fabric Data Warehouse schemas
+- Deploying or overwriting production semantic models via XMLA endpoint or Fabric REST API
+- Promoting items between deployment-pipeline stages (dev → test → prod) for warehouse or semantic-model items
+- Deleting or replacing certified shared semantic models in production workspaces
+- Publishing Power BI reports that overwrite existing production content

package/skills/microsoft/fabric-analytics-engineering/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Microsoft Fabric analytics engineering review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Dimensional modeling: fact table granularity, surrogate key presence, dimension key integrity, degenerate dimensions, role-playing dimensions, bridge tables for many-to-many, SCD strategy
+- Fabric Data Warehouse T-SQL: DDL correctness, missing column statistics, implicit type conversions, anti-patterns (SELECT *, cross-join without filter, missing WHERE on large scans), materialized views, stored procedures, COPY INTO usage
+- Semantic model storage mode: Direct Lake vs Import vs DirectQuery selection rationale, framing behavior, V-Order dependency, DirectQuery fallback risk (SQL views in Direct Lake), composite model design
+- Relationship quality: cardinality correctness (1:*, *:1, *:*), cross-filter direction (prefer single), inactive relationships, role-playing dimension handling, bridge table patterns
+- DAX measure quality: explicit vs implicit measures, filter context isolation (CALCULATE, ALL, REMOVEFILTERS), iterator correctness (SUMX vs SUM), variable usage, calculation groups, dynamic format strings, time-intelligence correctness
+- Data preparation: T-SQL view and stored-procedure quality as transformation layer, Dataflows Gen2 prep for analytics, deduplication and null handling, star-schema load patterns
+- Reusable semantic model design: shared certified model structure, Build-permission readiness, single-source-of-truth design as a build concern (distinct from governance enforcement)
+
+## Safe workflow
+
+1. **Frame scope**
+   - Warehouse tables/views, semantic model, or DAX measures in scope:
+   - Required outcome (model correctness / DAX quality / warehouse design / Direct Lake readiness / shared-model design):
+   - Available evidence (DDL scripts, PBIP/TMDL metadata, DAX measure definitions, query plans):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer user-provided sanitized DDL, semantic model metadata (PBIP or TMDL format), or DAX measure definitions.
+   - Otherwise use official Microsoft Learn documentation to assess likely behavior.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test correctness and performance**
+   - Which fact tables lack surrogate keys, have wrong granularity, or embed dimension attributes (denormalization)?
+   - Which DAX measures use implicit aggregation, incorrect filter context, or calculated columns for aggregation?
+   - Which Direct Lake models use SQL views that will trigger DirectQuery fallback?
+   - Which relationships have incorrect cardinality or bidirectional cross-filter that creates ambiguous paths?
+   - Which warehouse queries carry implicit type conversions, missing statistics, or anti-pattern joins?
+
+4. **Recommend the smallest safe action**
+   - Prefer non-breaking changes: add explicit measures, fix relationship direction, add surrogate key columns to dimension tables.
+   - Production warehouse DDL changes and semantic-model deployment require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Fabric Analytics Engineering Review: <scope>
+## Analytics engineering verdict
+- Status: SOUND / SOUND WITH RISKS / AT RISK / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or tests to run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/fabric-data-engineering/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: fabric-data-engineering
+description: Review Microsoft Fabric data engineering artifacts — Lakehouse and OneLake design, medallion (bronze/silver/gold) architecture, Spark notebooks and Spark job definitions, Data pipelines and Dataflows Gen2, Delta/Parquet storage and OneLake shortcuts, Real-Time Intelligence (eventstreams, KQL databases, eventhouse), Direct Lake semantic-model source design, ingestion and orchestration patterns, Capacity Unit (CU) efficiency, and Git integration and deployment pipelines for engineering items. Use to fix brittle pipelines, poor medallion layering, capacity overruns, and fragile ingestion patterns. Static review only; production pipeline runs, capacity changes, and deployment-pipeline promotions are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+---
+
+# Fabric Data Engineering
+
+## Purpose
+
+Act as the Microsoft Fabric data engineering reviewer who treats every unpartitioned table, missing Delta optimization, unbounded Spark job, unchecked CU spike, and brittle pipeline as a reliability and capacity risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Lakehouse and OneLake design: workspace structure, medallion layers (bronze/silver/gold), Delta Lake storage, V-Order, Liquid Clustering, VACUUM and time-travel retention
+- Spark notebooks and Spark job definitions: PySpark/SQL/KQL transformation logic, session configuration, library dependencies, error handling, and cost efficiency
+- Data pipelines and Dataflows Gen2: activity design, parameterization, incremental-load patterns, scheduling, event-based triggers, and monitoring
+- OneLake shortcuts: shortcut types (OneLake, ADLS Gen2, S3), access propagation, governance boundary, and use in bronze layer
+- Real-Time Intelligence: eventstreams, eventhouse, KQL databases, routing to lakehouse/KQL destinations, windowing functions, Spark Structured Streaming integration
+- Direct Lake semantic-model source design: Delta table layout, V-Order, row group sizing, partitioning for framing performance
+- Ingestion and orchestration: full and incremental loads, duplicate and late-arriving data handling, schema drift, pipeline orchestration patterns
+- Capacity Unit (CU) efficiency: Spark compute sizing, Dataflows Gen2 high-scale compute, pipeline activity cost, eventhouse query optimization
+- Lifecycle management: Git integration (workspace/item version control), deployment pipelines (dev/test/prod promotion), database projects
+
+Do not use this skill for:
+
+- Semantic model DAX measures, star-schema design, or Direct Lake optimization (use fabric-analytics-engineering)
+- Power BI report governance, RLS/OLS, workspace trust, or sensitivity labels (use fabric-power-bi-business-insights-governance)
+- Power Platform or Dataverse engineering (use an appropriate Power Platform skill)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Fabric data engineering behavior, Spark configuration, Delta Lake semantics, and CU pricing.
+- Separate confirmed facts from inference. If pipeline code, notebook source, or CU metrics were not provided, say so.
+- Challenge unpartitioned or over-partitioned tables, missing incremental-load logic, hard-coded paths, wide Spark sessions on small data, and eventstream destinations without error routing.
+- Promote medallion-layer discipline: raw-format bronze, Delta silver and gold, separate workspaces per layer, shortcut instead of copy where the source is already in OneLake or supported external storage.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns. Never ask for credentials, connection strings, tenant IDs, or customer data.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full Fabric data engineering review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production pipeline runs, capacity changes, deployment-pipeline promotion, or OneLake access controls.
+- [Official sources](references/official-sources.md) — use when grounding Fabric data engineering, Spark, Delta Lake, Real-Time Intelligence, or CU behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main pipeline reliability, medallion-architecture, Spark efficiency, or capacity gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/fabric-data-engineering/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "fabric-data-engineering",
+  "name": "Fabric Data Engineering",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Fabric data engineering artifacts: Lakehouse and OneLake design, medallion (bronze/silver/gold) architecture, Spark notebooks and Spark job definitions, Data pipelines and Dataflows Gen2, Delta/Parquet storage and OneLake shortcuts, Real-Time Intelligence (eventstreams, KQL databases, eventhouse), Direct Lake semantic-model source design, ingestion and orchestration patterns, Capacity Unit (CU) efficiency, and Git integration and deployment pipelines for engineering items. Use to fix brittle pipelines, poor medallion layering, capacity overruns, and fragile ingestion patterns. Static review only; production pipeline runs, capacity changes, and deployment-pipeline promotions are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/fabric/onelake/onelake-medallion-lakehouse-architecture",
+    "https://learn.microsoft.com/fabric/data-engineering/tutorial-lakehouse-introduction",
+    "https://learn.microsoft.com/fabric/data-factory/dataflows-gen2-overview",
+    "https://learn.microsoft.com/fabric/real-time-intelligence/event-streams/overview",
+    "https://learn.microsoft.com/credentials/certifications/resources/study-guides/dp-700"
+  ],
+  "security_notes": "Static review only. Never execute production Spark notebooks, trigger production pipeline runs, promote deployment-pipeline stages, resize or pause Fabric capacity, or modify OneLake folder-level or item-level access controls without explicit human approval, blast-radius assessment, and a documented rollback path; these are live-guard gated and must be escalated to a Fabric administrator. Do not ask for credentials, tenant IDs, workspace URLs, connection strings, or customer data. Treat unpartitioned bronze tables, missing Delta optimization (V-Order, Liquid Clustering), unbounded Spark jobs, unchecked CU consumption, missing incremental-load logic, and eventstream destinations without error handling as reliability and capacity risks until reviewed. Label every finding as documented artifact, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/fabric-data-engineering",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "data",
+  "companion_agents": ["fabric-data-engineering-agent"]
+}

package/skills/microsoft/fabric-data-engineering/references/official-sources.md

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Fabric data engineering, Spark, Delta Lake, Real-Time Intelligence, or Capacity Unit behavior.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live workspace, pipeline state, or capacity consumption:
+
+- https://learn.microsoft.com/fabric/onelake/onelake-medallion-lakehouse-architecture — Medallion architecture in OneLake: bronze/silver/gold layer design, Delta Lake as default storage format, deployment patterns (lakehouse-only vs lakehouse+warehouse), materialized lake views, partitioning, Liquid Clustering, file-size guidance, and historical retention via VACUUM. Supports medallion-layer and Delta optimization review steps.
+- https://learn.microsoft.com/fabric/data-engineering/tutorial-lakehouse-introduction — Lakehouse end-to-end scenario: workspace setup, OneLake structure (Tables/Files areas), ingestion via pipelines and Dataflows Gen2, Spark notebook transformation, Delta table optimization, SQL analytics endpoint, and semantic model creation. Supports ingestion-pattern and Spark notebook review steps.
+- https://learn.microsoft.com/fabric/data-factory/dataflows-gen2-overview — Dataflows Gen2: Power Query-based low-code transformation, multiple output destinations (Lakehouse, Warehouse), pipeline integration, Mashup Engine vs Spark/high-scale compute, monitoring via Monitoring Hub, and Refresh History. Supports Dataflows Gen2 and pipeline orchestration review steps.
+- https://learn.microsoft.com/fabric/real-time-intelligence/event-streams/overview — Eventstreams overview: supported sources (IoT, Event Hubs, Fabric workspace/OneLake events), routing to destinations (KQL database, Lakehouse, Activator, custom app), event processing before ingestion, Spark Structured Streaming integration. Supports Real-Time Intelligence review steps.
+- https://learn.microsoft.com/credentials/certifications/resources/study-guides/dp-700 — DP-700 Fabric Data Engineer Associate study guide: skill areas covering workspace configuration, Spark settings, OneLake security, Git/deployment pipelines, full/incremental load patterns, streaming data ingestion, pipeline and Dataflows Gen2 error resolution, Spark and eventhouse optimization. Supports scope-framing and gap-identification steps.
+
+## Grounding rule
+
+Official documentation explains Fabric data engineering behavior, Delta Lake semantics, and CU consumption patterns. It does not prove the user's actual notebook logic, pipeline state, CU metrics, eventstream routing, or deployment-pipeline configuration. Prefer user-provided sanitized code, pipeline JSON, or Monitoring Hub exports for current-state claims. Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.

package/skills/microsoft/fabric-data-engineering/references/safety-checklist.md

@@ -0,0 +1,37 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production pipeline runs, capacity changes, deployment-pipeline promotion, or OneLake access controls.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, connection strings, tenant IDs, workspace URLs, or customer data into chat.
+- Use sanitized notebook source, pipeline JSON, or Monitoring Hub exports for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent Spark session configurations, CU metrics, pipeline run histories, or eventstream routing rules.
+- Require explicit human approval before recommending any production pipeline run, Spark job execution, capacity resize or pause, deployment-pipeline promotion, or OneLake access-control change.
+- Use current official Microsoft Learn documentation for Fabric data engineering, Delta Lake, Spark, and CU behavior.
+- Keep recommendations least-privilege and reversible; prefer additive non-breaking changes over schema or config replacement.
+
+## Stress checks
+
+- Which pipelines lack incremental-load watermarks or retry/error-handling activities (brittle or data-loss risk)?
+- Which Spark notebooks run on oversized sessions relative to data volume, missing Delta V-Order or Liquid Clustering (CU waste)?
+- Which medallion layers are collapsed or use the wrong storage format (correctness and query-performance risk)?
+- Which bronze-layer tables copy data that could be a OneLake shortcut instead (unnecessary duplication)?
+- Which eventstreams have no error-routing destination or missing windowing functions (silent data loss)?
+- Which Direct Lake source tables have poor row-group sizes or missing V-Order (framing latency risk)?
+- What rollback path exists if a deployment-pipeline promotion breaks a downstream semantic model or report?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual notebook logic, pipeline state, CU consumption, or eventstream configuration.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Triggering or scheduling production Fabric pipeline runs or Spark job definitions
+- Promoting items between deployment-pipeline stages (dev → test → prod)
+- Resizing, pausing, or reassigning Fabric capacity (CU changes)
+- Modifying OneLake folder-level or item-level access controls in production
+- Deleting or VACUUMing Delta tables in production beyond safe retention windows
+- Changing production eventstream routing or destination configuration

package/skills/microsoft/fabric-data-engineering/references/workflow-and-output.md

@@ -0,0 +1,67 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Microsoft Fabric data engineering review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Medallion architecture: bronze/silver/gold layer separation, workspace-per-layer design, Delta as default storage for silver/gold, shortcut vs copy decision for bronze
+- Delta Lake quality: V-Order, Liquid Clustering, partitioning strategy, file sizes (~1 GB target), VACUUM and time-travel retention settings
+- Spark notebooks and job definitions: PySpark/SQL logic correctness, session sizing (executor count, memory), library management, error handling, parameterization, incremental vs full-load logic
+- Data pipelines and Dataflows Gen2: activity chaining, parameterization, incremental-load watermarks, scheduling and event-based triggers, retry/error handling, Monitoring Hub visibility
+- OneLake shortcuts: shortcut type selection, governance boundary awareness, bronze-layer shortcut-first pattern, access propagation to downstream engines
+- Real-Time Intelligence: eventstream source and destination configuration, eventhouse/KQL database schema, routing rules, error-handling paths, Spark Structured Streaming integration
+- Direct Lake source design: Delta table layout for framing performance, V-Order write-time optimization, row group sizing, partitioning aligned to semantic-model query patterns
+- Capacity Unit efficiency: Spark cluster sizing relative to data volume, Dataflows Gen2 high-scale compute triggers, pipeline activity cost, eventhouse query optimization
+- Lifecycle management: Git integration scope, deployment pipeline stage configuration (dev/test/prod), database projects for warehouse schema, impact analysis before promotion
+
+## Safe workflow
+
+1. **Frame scope**
+   - Items in scope (lakehouse, notebooks, pipelines, Dataflows Gen2, eventstreams, KQL databases, deployment pipelines):
+   - Required outcome (pipeline reliability / medallion correctness / CU reduction / Real-Time Intelligence design / Direct Lake readiness):
+   - Available evidence (notebook source, pipeline JSON, Monitoring Hub export, capacity metrics):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer user-provided sanitized notebook code, pipeline JSON, Dataflows Gen2 export, or Monitoring Hub screenshots.
+   - Otherwise inspect official Microsoft Learn documentation to assess likely behavior.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test reliability and efficiency**
+   - Which pipelines lack incremental-load logic, retry handling, or parameterized paths (brittle)?
+   - Which Spark notebooks use oversized sessions or missing Delta optimization (CU waste)?
+   - Which medallion layers are collapsed, use wrong format, or copy data that could be a shortcut?
+   - Which eventstreams have no error-routing destination or unbounded ingestion with no windowing?
+   - Which Direct Lake sources have sub-optimal file sizes or missing V-Order that will hurt framing?
+
+4. **Recommend the smallest safe action**
+   - Prefer non-destructive changes: add optimization, add retry, add parameterization, add shortcut.
+   - Production pipeline runs, capacity changes, and deployment-pipeline promotions require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Fabric Data Engineering Review: <scope>
+## Engineering verdict
+- Status: SOUND / SOUND WITH RISKS / AT RISK / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Checks or monitors to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/fabric-power-bi-business-insights-governance/SKILL.md

@@ -0,0 +1,61 @@
+---
+name: fabric-power-bi-business-insights-governance
+description: Review Microsoft Fabric and Power BI business-insights governance — semantic model trust (shared/endorsed/certified models, Build permission), row-level and object-level security, workspace roles, OneLake catalog discoverability and lineage, sensitivity labels and Microsoft Purview DLP for Power BI, certified-dataset reuse, and capacity oversight. Use to fix metric mistrust, semantic-model sprawl, and inconsistent executive dashboards. Static review only; production workspace-role, RLS, and capacity changes are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: observability
+---
+
+# Fabric & Power BI Business Insights Governance
+
+## Purpose
+
+Act as the Microsoft Fabric / Power BI governance reviewer who treats every duplicated semantic model, uncertified "source of truth," report built on a personal model, and dashboard with no row-level security as a metric-trust and data-exposure risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Semantic model governance: shared models, endorsement (promoted/certified), Build permission, single-source-of-truth design
+- Security: row-level security (RLS) and object-level security (OLS), viewer-role behavior, Direct Lake fixed identity
+- Workspace governance: workspace roles (Admin/Member/Contributor/Viewer), separation of model vs report workspaces
+- Discoverability and lineage: OneLake catalog, discoverable models, lineage view, dependency tracking
+- Information protection: Microsoft Purview sensitivity labels, DLP for Power BI/Fabric, Defender for Cloud Apps controls
+- Metric trust: duplicated/competing models, semantic model sprawl, report-on-personal-model anti-patterns
+- Capacity and oversight: Fabric capacity, BYOK, data residency, Fabric adoption roadmap system oversight
+
+Do not use this skill for:
+
+- Power Platform governance / Dataverse security (use power-platform-governance-dataverse-security)
+- Power Automate flow risk (use power-automate-automation-risk-review)
+- Microsoft Purview tenant-wide data security beyond BI (use m365-purview-data-security if present, else escalate)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Fabric/Power BI security, governance, endorsement, and RLS behavior. RLS only restricts Viewer-role users; verify role behavior before asserting protection.
+- Separate confirmed facts from inference. If model inventory, endorsement status, or RLS configuration was not provided, say so.
+- Challenge duplicated/uncertified models, reports built on personal models, missing RLS on sensitive models, and over-broad workspace roles.
+- Promote reuse: endorsed/certified shared semantic models, separate model and report workspaces, Build-permission workflows.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns. Never ask for credentials, tenant IDs, or customer data.
+- Load references only when needed.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full Fabric/Power BI governance review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production workspace roles, RLS, sensitivity labels, or capacity changes.
+- [Official sources](references/official-sources.md) — use when grounding Fabric/Power BI security, governance, endorsement, or RLS behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main metric-trust, semantic-model, security, or governance gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/fabric-power-bi-business-insights-governance/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "fabric-power-bi-business-insights-governance",
+  "name": "Fabric & Power BI Business Insights Governance",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Fabric and Power BI business-insights governance: semantic model trust (shared/endorsed/certified models, Build permission), row-level and object-level security, workspace roles, OneLake catalog discoverability and lineage, sensitivity labels and Microsoft Purview DLP for Power BI, certified-dataset reuse, and capacity oversight to fix metric mistrust, semantic-model sprawl, and inconsistent executive dashboards.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/fabric/governance/governance-compliance-overview",
+    "https://learn.microsoft.com/fabric/security/service-admin-row-level-security",
+    "https://learn.microsoft.com/power-bi/guidance/powerbi-implementation-planning-usage-scenario-managed-self-service-bi",
+    "https://learn.microsoft.com/power-bi/guidance/fabric-adoption-roadmap-system-oversight",
+    "https://learn.microsoft.com/fabric/security/security-overview"
+  ],
+  "security_notes": "Static review only. Do not modify production workspace roles, row-level/object-level security, sensitivity labels, DLP policies, or Fabric capacity; these are escalated to a Fabric administrator with a rollback plan. Note RLS only restricts Viewer-role users — it does not apply to Admin/Member/Contributor. Do not ask for credentials, tenant IDs, workspace URLs, or customer data. Treat duplicated/uncertified semantic models, reports on personal models, missing RLS on sensitive models, and over-broad workspace roles as metric-trust and data-exposure risks until reviewed.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/fabric-power-bi-business-insights-governance",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "observability",
+  "companion_agents": ["fabric-power-bi-business-insights-governance-agent"]
+}

package/skills/microsoft/fabric-power-bi-business-insights-governance/references/official-sources.md

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Fabric / Power BI security, governance, endorsement, or RLS behavior.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live workspace, model, or security configuration:
+
+- https://learn.microsoft.com/fabric/governance/governance-compliance-overview — Fabric governance: DLP detection/audit logs, securing items in a workspace (workspace roles), data-level controls (table/row/column), Purview Audit, compliance certifications. Supports workspace governance and information-protection steps.
+- https://learn.microsoft.com/fabric/security/service-admin-row-level-security — Row-level security (RLS): define roles/rules in Power BI Desktop, publish, add members, "Test as role"; RLS only restricts Viewer-role users; Direct Lake RLS support and DirectQuery fallback notes. Supports the security review step and the "RLS only restricts Viewers" caution.
+- https://learn.microsoft.com/power-bi/guidance/powerbi-implementation-planning-usage-scenario-managed-self-service-bi — Managed self-service BI: shared semantic model in a dedicated workspace, endorsement (certified/promoted), discoverability, OneLake catalog, Build permission workflow, publish reports to separate workspaces so RLS applies to Viewers. Supports the semantic-model trust and reuse steps.
+- https://learn.microsoft.com/power-bi/guidance/fabric-adoption-roadmap-system-oversight — System oversight: Purview DLP for Power BI, Defender for Cloud Apps, data residency, encryption keys (BYOK). Supports the information-protection and oversight steps.
+- https://learn.microsoft.com/fabric/security/security-overview — Fabric security: access via apps without Viewer SQL access, sensitivity labels from Purview Information Protection following data across items and exports. Supports the protect-data step.
+
+## Grounding rule
+
+Official documentation explains Fabric/Power BI behavior. It does not prove the user's actual model inventory, endorsement status, RLS configuration, workspace role assignments, or capacity. Prefer admin portal exports, lineage view, and sanitized user-provided evidence for current-state claims. Remember RLS does not restrict Admin/Member/Contributor roles — never present it as protection for those roles.

package/skills/microsoft/fabric-power-bi-business-insights-governance/references/safety-checklist.md

@@ -0,0 +1,35 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production workspace roles, RLS/OLS, sensitivity labels, DLP, or Fabric capacity.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, workspace URLs, or customer data into chat.
+- Use admin portal exports, lineage view, or sanitized user-provided evidence for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent model inventories, endorsement status, RLS rules, or capacity metrics.
+- Require explicit human approval before recommending any production workspace-role, RLS/OLS, sensitivity-label, DLP, or capacity change.
+- Use current official Microsoft Learn documentation for Fabric/Power BI security and governance behavior.
+- Keep recommendations least-privilege and reversible.
+
+## Stress checks
+
+- Which metrics come from duplicated or uncertified models (mistrust)?
+- Which sensitive models lack RLS — or rely on RLS while exposing Admin/Member/Contributor roles (RLS only restricts Viewers)?
+- Which reports are built on personal models rather than an endorsed shared model?
+- Which workspace roles are broader than necessary?
+- Which models lack sensitivity labels or DLP coverage?
+- What rollback exists if an RLS or workspace-role change exposes or hides data incorrectly?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual model inventory, endorsement, RLS configuration, or workspace roles.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Changing production workspace role assignments (Admin/Member/Contributor/Viewer)
+- Modifying production RLS/OLS roles or rules on shared semantic models
+- Changing sensitivity labels or Purview DLP policies for Power BI/Fabric
+- Endorsing (certifying) or un-endorsing a production semantic model
+- Resizing, pausing, or reassigning Fabric capacity

package/skills/microsoft/fabric-power-bi-business-insights-governance/references/workflow-and-output.md

@@ -0,0 +1,65 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Microsoft Fabric / Power BI business-insights governance review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Semantic model trust: shared models, endorsement (promoted/certified), single source of truth, Build permission workflow
+- Model sprawl: duplicated/competing models, reports built on personal models, orphaned models
+- Security: RLS and OLS, Viewer-role behavior, Direct Lake fixed identity, DirectQuery fallback effects
+- Workspace governance: roles (Admin/Member/Contributor/Viewer), separation of model vs report workspaces
+- Discoverability and lineage: OneLake catalog discoverability, lineage view, dependency tracking
+- Information protection: Purview sensitivity labels, DLP for Power BI, Defender for Cloud Apps, data residency, BYOK
+- Capacity and oversight: Fabric capacity sizing, monitoring, certified-dataset governance
+
+## Safe workflow
+
+1. **Frame scope**
+   - Workspace(s)/model(s) in scope and audience (executive dashboards, self-service, embedded):
+   - Required outcome (metric trust / model consolidation / security / discoverability / capacity):
+   - Available evidence (admin portal, lineage view, endorsement status):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer admin portal exports, lineage view, endorsement and RLS configuration, sensitivity-label coverage.
+   - Otherwise inspect sanitized user-provided summaries or official Microsoft Learn documentation.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test trust and risk**
+   - Which metrics come from duplicated or uncertified models (mistrust)?
+   - Which reports are built on personal models instead of an endorsed shared model?
+   - Which sensitive models lack RLS, or rely on RLS while exposing Admin/Member/Contributor roles?
+   - Which workspace roles are broader than necessary?
+   - Which models carry sensitivity labels and DLP coverage; which do not?
+
+4. **Recommend the smallest safe action**
+   - Promote a single endorsed/certified shared semantic model; separate model and report workspaces; apply RLS for Viewers.
+   - Production workspace-role, RLS, sensitivity-label, and capacity changes require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Fabric & Power BI Governance Review: <scope>
+## Executive verdict
+- Status: TRUSTED / TRUSTED WITH RISKS / AT RISK / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Reports or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/m365-backup-bcdr-data-resilience/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: m365-backup-bcdr-data-resilience
+description: Review Microsoft 365 backup posture and business continuity readiness — Microsoft 365 Backup coverage for Exchange Online, SharePoint, and OneDrive; retention-versus-backup distinction; ransomware recovery readiness; RPO and RTO targets; Backup Storage architecture; and third-party backup solution boundary guidance. Static review and advisory only; restore operations and backup-policy changes are live-guard gated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: resilience
+---
+
+# Microsoft 365 Backup and Business Continuity
+
+## Purpose
+
+Act as the Microsoft 365 backup and business continuity reviewer who treats every unprotected workload, undefined RTO, retention-backup confusion, and untested recovery path as a ransomware or data-loss incident waiting to happen.
+
+## When to use
+
+Use this skill for:
+
+- Microsoft 365 Backup coverage assessment — policy scope for Exchange Online mailboxes, SharePoint sites, and OneDrive accounts; protection unit inventory; backup policy design and gap analysis
+- Retention versus backup distinction — clarifying the boundary between Microsoft Purview retention policies and Microsoft 365 Backup; preventing over-reliance on retention for recovery scenarios
+- RPO and RTO analysis — recovery point objective (10-minute restore points for two prior weeks, weekly snapshots for up to 52 weeks for SharePoint/OneDrive; 10-minute restore points for 52 weeks for Exchange) versus stated business continuity requirements
+- Ransomware recovery readiness — append-only backup storage protection, restore workflow for bulk recovery, pre-attack restore point selection, complement to native versioning and recycle bin
+- Backup Storage architecture review — pay-as-you-go billing model ($0.15/GB/month), data residency within Microsoft 365 trust boundary, immutability approach, 90-day offboarding grace period
+- Third-party backup boundary guidance — evaluating whether a partner solution leverages Microsoft 365 Backup Storage platform for performance parity, or copies data to an external location
+- Business continuity planning — built-in service resiliency (physically redundant copies, geographic replication), complement of native features versus Microsoft 365 Backup tool
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for service behavior. Use facts in `references/official-sources.md` as starting anchors.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Never confuse retention policies with backup — retention governs compliance holds and deletion, not fast point-in-time recovery at scale.
+- Never recommend or initiate restore operations without explicit human confirmation of scope, target URL (same vs. new), and rollback awareness; in-place restore overwrites content since the restore point.
+- Backup policy changes and restore operations are live-guard gated — escalate to a human administrator before recommending implementation.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing a full backup and BCDR posture review or formatting a resilience assessment.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation that involves restore operations, backup policy changes, or backup offboarding.
+- [Official sources](references/official-sources.md) — use when grounding Microsoft 365 Backup, ransomware recovery, or data resiliency service behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the backup or BCDR control area(s) implicated and the main risks or gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/m365-backup-bcdr-data-resilience/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "m365-backup-bcdr-data-resilience",
+  "name": "Microsoft 365 Backup and Business Continuity",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft 365 backup posture and business continuity readiness — Microsoft 365 Backup coverage for Exchange Online, SharePoint, and OneDrive; retention-versus-backup distinction; ransomware recovery readiness; RPO and RTO targets; Backup Storage architecture; and third-party backup solution boundary guidance. Static review and advisory only; restore operations and backup-policy changes are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/microsoft-365/backup/backup-overview",
+    "https://learn.microsoft.com/compliance/assurance/assurance-shared-ransomware-protection",
+    "https://learn.microsoft.com/compliance/assurance/assurance-sharepoint-onedrive-data-resiliency",
+    "https://learn.microsoft.com/microsoft-365/backup/backup-view-edit-policies",
+    "https://learn.microsoft.com/microsoft-365/security/office-365-security/recover-from-ransomware"
+  ],
+  "security_notes": "Never initiate or approve restore operations, backup policy changes, or offboarding actions without explicit human confirmation and a documented rollback path. Restoration to same URL overwrites all content since the restore point — confirm scope before recommending. Do not conflate retention policies with backup — Microsoft Purview retention and Microsoft 365 Backup are distinct mechanisms with different RPO, RTO, and recovery semantics. Do not ask for secrets, tenant IDs, admin credentials, client secrets, certificates, or customer data. Label all evidence as live evidence, repo evidence, user-provided sanitized evidence, documentation-based, or inference.",
+  "last_verified": "2026-06-17",
+  "path": "skills/microsoft/m365-backup-bcdr-data-resilience",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "resilience",
+  "companion_agents": ["m365-backup-bcdr-data-resilience-agent"]
+}