@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/d365-supply-chain-plan-to-produce/references/workflow-and-output.md

@@ -0,0 +1,71 @@
+# Workflow and output contract
+
+Use this reference only when performing the full master-planning or production-control review, implementation guidance, operational evidence gathering, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Master plan configuration: Planning Optimization setup, master plan parameters, coverage time fences, safety margins, action message settings
+- Coverage group and item coverage settings: coverage type, min/max quantities, safety stock levels, reorder points, lead time settings
+- Inventory accuracy: on-hand validation, negative on-hand quantities, unposted inventory journals, unclosed production orders
+- Procurement configuration: purchase trade agreements, vendor default order settings, sourcing rules, procurement policies, lead time accuracy
+- Warehouse management parameters: warehouse configuration, location directives, work template setup, reservation hierarchy accuracy
+- BOM and route configuration: active BOM versions, route operations accuracy, scrap percentages, finite capacity settings
+- Planned order review: planned purchase orders, planned production orders, planned transfer orders, auto-firming rules
+- Demand forecasting: forecast model setup, forecast reduction keys, forecast inclusion in master plans
+- Intercompany planning: cross-legal-entity supply chain configuration, intercompany planned order accuracy
+- Compensating controls: inventory count schedules, cycle count frequency, approval workflows for order firming
+
+## Safe workflow
+
+1. **Frame scope**
+   - Legal entities and warehouses in scope:
+   - Planning horizon (short-term, medium-term, long-term):
+   - Operational driver (inventory reduction, stockout prevention, production schedule reliability, procurement efficiency):
+   - Required outcome (planning config review / inventory accuracy review / production control audit):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported planning logs, on-hand inventory reports, coverage settings exports, and production order status reports for current-state claims.
+   - Otherwise inspect sanitized user-provided evidence, configuration screenshots, or official Dynamics 365 Supply Chain Management documentation.
+   - Label each finding as `live evidence`, `report evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What items have missing or incorrect coverage settings that could cause stockout or excess inventory?
+   - What on-hand inventory records are negative, unvalidated, or based on unposted journals?
+   - What planned orders are near the firming horizon without review or approval?
+   - What BOM versions or route operations are inactive or incorrectly configured?
+   - What evidence is missing that would change the planning output verdict?
+   - What procurement lead times or vendor agreements are stale or unvalidated?
+
+4. **Recommend the smallest safe action**
+   - Prefer inventory validation, coverage-settings review, and planned-order analysis before firming production or purchase orders.
+   - If the safest action is to stop and gather evidence (run an on-hand inventory report or planning log first), say that plainly.
+   - Production master plan runs, coverage group reconfigurations, and BOM or route activations require live-guard escalation. Do not recommend live changes without explicit human approval.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Supply Chain Plan-to-Produce Review: <scope>
+## Executive verdict
+- Status: PLAN RELIABLE / PLAN WITH CONDITIONS / PLAN NOT RELIABLE / 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 run:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

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

@@ -0,0 +1,60 @@
+---
+name: fabric-analytics-engineering
+description: Review Microsoft Fabric analytics engineering artifacts — Fabric Data Warehouse T-SQL design and anti-patterns, dimensional modeling (star schema, fact and dimension tables, relationships), semantic model design (Direct Lake vs Import vs DirectQuery selection, table layout, relationship cardinality), DAX measure correctness and optimization (iterators, filter context, variables, CALCULATE), data preparation and transformation quality, and reusable certified semantic models feeding Power BI reports. Use to fix bad star schemas, slow DAX, untrustworthy measures, and warehouse anti-patterns. Distinct from governance: this is build quality and modeling correctness, not RLS or workspace trust. Static review only; production warehouse schema changes and semantic-model deployment are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+---
+
+# Fabric Analytics Engineering
+
+## Purpose
+
+Act as the Microsoft Fabric analytics engineering reviewer who treats every denormalized fact table, ambiguous many-to-many relationship, incorrect DAX filter context, calculated column used instead of an explicit measure, and DirectQuery fallback on a Direct Lake SQL view as a correctness and performance risk until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Fabric Data Warehouse T-SQL design: table definitions, star and snowflake schema correctness, fact and dimension table design, surrogate key patterns, SCD handling, multi-table ACID transaction patterns, materialized views, stored procedures, and T-SQL anti-patterns (implicit conversions, missing column statistics)
+- Dimensional modeling: star-schema design, fact table granularity, dimension key integrity, bridge tables for many-to-many, role-playing dimensions, degenerate dimensions, and slowly changing dimension strategies
+- Semantic model design: storage mode selection (Direct Lake on OneLake vs Direct Lake on SQL vs Import vs DirectQuery), relationship cardinality and cross-filter direction, composite models, large semantic model storage format, incremental refresh configuration, framing behavior and V-Order dependency
+- DAX quality: explicit measure correctness, filter context and row context separation, CALCULATE and FILTER usage, iterator functions (SUMX, AVERAGEX), calculation groups, dynamic format strings, field parameters, DAX variables for readability, and common anti-patterns (implicit measures, CALCULATE with ALL, ambiguous relationships)
+- Data preparation and transformation: T-SQL views and stored procedures as transformation layer, Dataflows Gen2 for analytics prep, star-schema loading patterns via pipelines, deduplication and null handling
+- Reusable certified semantic models: shared model design for Power BI reuse, endorsed/certified model patterns (Build permission, single source of truth) as a build-quality concern distinct from governance policy
+
+Do not use this skill for:
+
+- RLS/OLS enforcement, workspace role assignments, sensitivity labels, or DLP policies (use fabric-power-bi-business-insights-governance)
+- Lakehouse/Spark pipeline engineering, medallion architecture, CU capacity tuning, or Real-Time Intelligence (use fabric-data-engineering)
+- Power Platform or Dataverse modeling (use an appropriate Power Platform skill)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Fabric Data Warehouse T-SQL behavior, Direct Lake semantics, DAX evaluation, and DP-600 skill areas.
+- Separate confirmed facts from inference. If warehouse DDL, semantic model metadata, or DAX measures were not provided, say so.
+- Challenge denormalized fact tables, missing surrogate keys, fan-out joins, bidirectional cross-filter on multiple paths, implicit measures, DirectQuery fallback caused by SQL views in Direct Lake models, and DAX that relies on calculated columns for aggregation.
+- Promote star-schema discipline: numeric surrogate keys, date dimension, single-direction relationships, explicit DAX measures, certified shared semantic models.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns. Never ask for credentials, tenant IDs, workspace URLs, 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 analytics engineering review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production warehouse schema changes, semantic-model deployment, or deployment-pipeline promotion.
+- [Official sources](references/official-sources.md) — use when grounding Fabric Data Warehouse T-SQL, dimensional modeling, Direct Lake, or DAX behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main dimensional modeling, T-SQL design, DAX correctness, or semantic-model configuration gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

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

@@ -0,0 +1,30 @@
+{
+  "id": "fabric-analytics-engineering",
+  "name": "Fabric Analytics Engineering",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Microsoft Fabric analytics engineering artifacts: Fabric Data Warehouse T-SQL design and anti-patterns, dimensional modeling (star schema, fact and dimension tables, relationships), semantic model design (Direct Lake vs Import vs DirectQuery selection, table layout, relationship cardinality), DAX measure correctness and optimization (iterators, filter context, variables, CALCULATE), data preparation and transformation quality, and reusable certified semantic models feeding Power BI reports. Use to fix bad star schemas, slow DAX, untrustworthy measures, and warehouse anti-patterns. Distinct from governance: this skill covers build quality and modeling correctness, not RLS or workspace trust. Static review only; production warehouse schema changes and semantic-model deployment are live-guard gated.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/fabric/data-warehouse/dimensional-modeling-overview",
+    "https://learn.microsoft.com/fabric/fundamentals/direct-lake-overview",
+    "https://learn.microsoft.com/fabric/data-warehouse/data-warehousing",
+    "https://learn.microsoft.com/dax/dax-overview",
+    "https://learn.microsoft.com/credentials/certifications/resources/study-guides/dp-600"
+  ],
+  "security_notes": "Static review only. Never execute DDL or DML against production Fabric Data Warehouse schemas, deploy or overwrite production semantic models, publish Power BI reports to production workspaces, or modify deployment-pipeline stages without explicit human approval, blast-radius assessment, and a rollback path; these are live-guard gated and must be escalated to a Fabric or analytics administrator. Do not ask for credentials, tenant IDs, workspace URLs, or customer data. Treat missing surrogate keys in fact tables, fan-out or chasm-trap join patterns, incorrect DAX filter context, measures using calculated columns instead of explicit DAX, DirectQuery fallback on Direct Lake SQL views, and unverified measure outputs as correctness 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-analytics-engineering",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "data",
+  "companion_agents": ["fabric-analytics-engineering-agent"]
+}

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

@@ -0,0 +1,17 @@
+# Official sources
+
+Use this reference only when you need source grounding for Microsoft Fabric analytics engineering, dimensional modeling, Direct Lake, DAX, or Fabric Data Warehouse T-SQL behavior.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live warehouse schema, semantic model configuration, or DAX measure output:
+
+- https://learn.microsoft.com/fabric/data-warehouse/dimensional-modeling-overview — Dimensional modeling in Fabric Data Warehouse: star schema design (fact tables, dimension tables, surrogate keys), snowflake vs star trade-offs, slowly changing dimension strategies, bridge tables for many-to-many, load patterns, and T-SQL best practices for Fabric Warehouse. Supports schema design and dimensional-modeling review steps.
+- https://learn.microsoft.com/fabric/fundamentals/direct-lake-overview — Direct Lake overview: how framing works (metadata refresh vs full import), DirectQuery fallback triggers (SQL views, unsupported features), V-Order dependency for performance, Direct Lake on OneLake vs Direct Lake on SQL endpoints, composite model support, and framing latency considerations. Supports storage-mode selection and Direct Lake configuration review steps.
+- https://learn.microsoft.com/fabric/data-warehouse/data-warehousing — Fabric Data Warehouse overview: enterprise T-SQL warehouse on Delta Lake foundation, star/snowflake schema use cases, multi-table ACID transactions, materialized views, stored procedures, COPY INTO, cross-database queries, autonomous workload management, and Power BI integration. Supports warehouse design and anti-pattern review steps.
+- https://learn.microsoft.com/dax/dax-overview — DAX overview: measures vs calculated columns vs calculated tables, filter context and row context, CALCULATE, iterator functions (SUMX, AVERAGEX), evaluation context, time-intelligence functions, and common correctness pitfalls. Supports DAX measure quality and optimization review steps.
+- https://learn.microsoft.com/credentials/certifications/resources/study-guides/dp-600 — DP-600 Fabric Analytics Engineer Associate study guide: skill areas covering semantic model design (storage mode, star schema, relationships, DAX, calculation groups, composite models, incremental refresh), data preparation (T-SQL views, Dataflows Gen2, star-schema loading), and analytics lifecycle (deployment pipelines, XMLA endpoint, shared semantic models). Supports scope-framing and gap-identification steps.
+
+## Grounding rule
+
+Official documentation explains Fabric Data Warehouse, Direct Lake, and DAX behavior. It does not prove the user's actual warehouse schema, semantic model relationships, measure correctness, or DirectQuery fallback state. Prefer user-provided sanitized DDL, semantic model metadata (PBIP/TMDL), or DAX measure definitions for current-state claims. Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.

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.