@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/cross-functional/procure-to-pay-protocol/references/workflow-and-output.md

@@ -0,0 +1,155 @@
+# Procure-to-Pay Protocol — Workflow and Output Contract
+
+## Overview
+This document provides the detailed step-by-step workflow, decision tree, and output contract for the procure-to-pay-protocol skill. It covers the full source-to-pay cycle from purchase requisition through vendor payment settlement, with explicit SoD gate definitions.
+
+---
+
+## Detailed Step-by-Step Workflow
+
+### Phase 1 — Requisition and Budget Check (d365-supply-chain-plan-to-produce-agent)
+
+**Step 1.1 — Receive and validate purchase requisition**
+- Confirm the purchase requisition is submitted by an authorized requester in Dynamics 365 Supply Chain Management.
+- Validate that the requested goods or services are within the approved procurement catalog.
+- Check that procurement policies (spending limits, preferred vendor requirements) are met.
+- If the request is outside the catalog or policy, reject and return to the requester with an explanation.
+
+**Step 1.2 — Budget availability check**
+- Query available budget for the relevant cost center and account in Dynamics 365 Finance.
+- If budget is insufficient, pause immediately and escalate to the finance owner for budget approval.
+- Do not convert a requisition to a PO without a confirmed budget check pass.
+
+**Step 1.3 — Vendor selection and pricing validation**
+- Confirm vendor account, trade agreement pricing, and delivery terms in Dynamics 365 Supply Chain Management.
+- For new vendors, flag for vendor master review before PO creation — do not create a PO for an unvalidated vendor.
+
+---
+
+### Phase 2 — Purchase Order Approval and SoD Gate (d365-supply-chain-plan-to-produce-agent + d365-security-sod-governance-agent)
+
+**Step 2.1 — Convert requisition to purchase order**
+- Create the purchase order in Dynamics 365 Supply Chain Management with all line items, quantities, prices, and delivery dates.
+- Assign the PO to the configured approval workflow.
+
+**Step 2.2 — SoD gate: PO approval review**
+- Invoke d365-security-sod-governance-agent to verify:
+  - The PO approver is not the same person who created the purchase requisition.
+  - The PO approver is not the designated goods receiver for this PO.
+  - No single person can complete all three roles: requisition, approval, and receipt.
+- If any SoD conflict is detected, halt the approval immediately; escalate to the compliance owner and document the conflict with evidence.
+- Do not proceed with PO approval until the SoD conflict is resolved by the compliance owner.
+
+**Step 2.3 — PO confirmation and vendor communication**
+- Once approved and SoD-cleared, confirm the purchase order.
+- Send the confirmed PO to the vendor; record the vendor's acknowledgment reference.
+- Set the expected delivery date in the system.
+
+---
+
+### Phase 3 — Goods/Services Receipt (d365-supply-chain-plan-to-produce-agent)
+
+**Step 3.1 — Delivery monitoring**
+- Track delivery against the promised date on the PO.
+- Flag overdue deliveries to the supply chain agent and human owner.
+
+**Step 3.2 — Goods receipt or service entry sheet**
+- Upon delivery, record the goods receipt note (GRN) or service entry sheet in Dynamics 365 Supply Chain Management.
+- Perform quantity check: received quantity must match or be documented against PO quantity.
+- Perform quality check (where applicable) and record any discrepancies.
+- The goods receiver must be a different person than the PO requisitioner and approver (SoD).
+
+---
+
+### Phase 4 — Vendor Invoice Processing (d365-finance-close-to-report-agent)
+
+**Step 4.1 — Invoice receipt and capture**
+- Receive vendor invoice in Dynamics 365 Finance (manual entry, OCR via Azure AI Document Intelligence, or EDI).
+- Match invoice header to the correct vendor account and PO reference.
+
+**Step 4.2 — Three-way match**
+- Perform three-way match: purchase order line quantities and prices, goods receipt quantities, and vendor invoice quantities and amounts.
+- If the match passes within configured tolerances, route for payment approval.
+- If the match fails (price discrepancy, quantity mismatch, or missing receipt), hold the invoice; route to d365-supply-chain-plan-to-produce-agent and the vendor for resolution.
+- Document all match exceptions with reason codes.
+
+**Step 4.3 — Invoice approval and payment queue**
+- Approved and matched invoices are queued for payment in Dynamics 365 Finance per the vendor's payment terms.
+- Invoices above the configured materiality threshold require a second human approval before payment is included in the payment run.
+
+---
+
+### Phase 5 — Payment Settlement (d365-finance-close-to-report-agent + human)
+
+**Step 5.1 — Payment authorization**
+- The payment run proposal is generated by d365-finance-close-to-report-agent and presented to the authorized finance signatory.
+- No payment is released without explicit human authorization of the payment run.
+- SoD check: the person authorizing the payment run must not be the same person who approved the invoice.
+
+**Step 5.2 — Payment execution and settlement**
+- Human-authorized payment run is executed in Dynamics 365 Finance.
+- Payment is applied to the vendor's open transactions; accounts payable entries are settled.
+- Payment confirmation and remittance advice are sent to the vendor.
+
+---
+
+## Decision Tree
+
+```
+START: Purchase requisition received
+│
+├─ Request within procurement catalog and policy?
+│   └─ NO → REJECT; return to requester
+│
+├─ Budget available?
+│   └─ NO → PAUSE; escalate to finance owner
+│
+├─ Vendor validated in vendor master?
+│   └─ NO → FLAG for vendor master review; do not create PO
+│
+├─ SoD: Approver ≠ Requisitioner ≠ Receiver?
+│   └─ NO → HALT; escalate to d365-security-sod-governance-agent and compliance owner
+│
+├─ Vendor acknowledged PO?
+│   └─ NO → MONITOR; escalate on overdue acknowledgment
+│
+├─ Delivery received and GRN created?
+│   └─ NO → MONITOR; flag overdue delivery
+│
+├─ Three-way match passes?
+│   └─ NO → HOLD invoice; route to supply chain and vendor
+│
+├─ Invoice above materiality threshold?
+│   └─ YES → REQUIRE second human approval
+│
+├─ Payment run authorized by finance signatory?
+│   └─ NO → DO NOT release payment
+│
+└─ SoD on payment: Authorizer ≠ Invoice approver?
+    └─ NO → HALT; escalate to compliance owner
+```
+
+---
+
+## Output Contract
+
+Every execution of this protocol produces a structured output capsule:
+
+| Field | Type | Description |
+|---|---|---|
+| matter_id | string | Unique identifier for this P2P instance |
+| po_id | string | Purchase order number |
+| current_stage | enum | One of: requisition, budget_check, po_approval, sod_check, goods_receipt, invoice_matching, payment_queue, settled |
+| gate_outcomes | object | Pass/fail/escalated: budget, policy, sod_po, three_way_match, sod_payment, payment_auth |
+| agents_involved | array | Agent IDs that participated |
+| escalations | array | Each escalation: {trigger, timestamp, escalated_to, reason} |
+| open_questions | array | Unresolved items requiring human input |
+| do_not_do_list | array | Actions explicitly prohibited in the current state |
+| evidence_quality | enum | high / medium / low |
+| privilege_sensitivity | boolean | True if commercially sensitive vendor terms are involved |
+| last_updated | ISO8601 timestamp | When the capsule was last updated |
+
+---
+
+## Audit Log Fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, sod_conflict_detected, timestamp

package/skills/databricks/databricks-lakehouse-engineering-at-azure/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: databricks-lakehouse-engineering-at-azure
+description: Review and guide Databricks Lakehouse engineering on Azure: medallion architecture (bronze/silver/gold), Delta Lake pipelines, ADLS Gen2 access via Unity Catalog external locations and storage credentials, Access Connector managed identity, cluster access mode enforcement, AKV-backed secret scopes, VNet injection and Private Link network isolation, and credential passthrough deprecation. Static review only — never execute against live workspace.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: data
+---
+
+# Databricks Lakehouse Engineering at Azure
+
+## Purpose
+
+Act as the Databricks Lakehouse engineering reviewer who treats every deprecated credential passthrough pattern, over-privileged cluster mode, and unbound external location as a future data-exposure or compliance incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Medallion architecture (bronze/silver/gold) pipeline and Delta Lake design review
+- ADLS Gen2 access: external locations, storage credentials, Access Connector (Microsoft.Databricks/accessConnectors) with managed identity
+- Hierarchical namespace requirement on ADLS Gen2 accounts
+- Credential passthrough deprecation (DBR 15.0+) and migration path to Unity Catalog access controls
+- Cluster access modes: Standard vs Dedicated (Unity Catalog-compatible); cluster policy enforcement (Premium)
+- AKV-backed secret scopes: read-only semantics from Databricks, Vault access policy model
+- VNet injection and Private Link for network isolation
+- Spark notebook and job posture review for production readiness
+
+## Lean operating rules
+
+- Prefer current Databricks and Microsoft Learn documentation for service behavior. Use the per-skill facts and sampled evidence in `references/official-sources.md`; when the user has configured read-only workspace MCP access, use it for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge credential passthrough usage, Standard cluster mode for Unity Catalog workloads, interactive-user storage access in production, and unvalidated ADLS Gen2 hierarchical namespace settings.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Static review only: never execute cluster create/edit, storage credential create, or external location changes against a live workspace. Production changes are live-guard gated (escalate).
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, compliance-impacting, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding Databricks or Azure service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main architecture risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/databricks/databricks-lakehouse-engineering-at-azure/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "databricks-lakehouse-engineering-at-azure",
+  "name": "Databricks Lakehouse Engineering at Azure",
+  "type": "skill",
+  "provider": "databricks",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Databricks Lakehouse engineering on Azure: medallion architecture, Delta Lake pipelines, ADLS Gen2 access via Unity Catalog storage credentials and Access Connector managed identity, cluster access mode enforcement, AKV-backed secret scopes, and VNet isolation patterns.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.databricks.com/en/lakehouse/index.html",
+    "https://docs.databricks.com/en/connect/storage/azure-storage.html",
+    "https://learn.microsoft.com/en-us/azure/databricks/connect/storage/tutorial-azure-storage",
+    "https://docs.databricks.com/en/clusters/cluster-config-best-practices.html"
+  ],
+  "security_notes": "Never execute cluster create/edit, storage credential creation, or external location changes against a live workspace during review. Flag credential passthrough usage (deprecated DBR 15.0+) and Standard cluster mode on Unity Catalog workloads. Require explicit approval before any production infrastructure change.",
+  "last_verified": "2026-06-17",
+  "path": "skills/databricks/databricks-lakehouse-engineering-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["databricks-lakehouse-engineering-at-azure-agent"]
+}

package/skills/databricks/databricks-lakehouse-engineering-at-azure/references/official-sources.md

@@ -0,0 +1,40 @@
+# Official sources
+
+Use this reference only when you need source grounding for Databricks Lakehouse engineering or Azure service behavior, or the detailed source list.
+
+## Databricks and Azure documentation
+
+Use these as starting points, not as proof of the user's live workspace state:
+- https://docs.databricks.com/en/lakehouse/index.html
+- https://docs.databricks.com/en/connect/storage/azure-storage.html
+- https://learn.microsoft.com/en-us/azure/databricks/connect/storage/tutorial-azure-storage
+- https://docs.databricks.com/en/clusters/cluster-config-best-practices.html
+
+## Grounding rule
+
+Official documentation explains Databricks and Azure service behavior. It does not prove the user's current workspace, cluster configuration, storage credential state, or operational environment. Prefer read-only workspace MCP or CLI evidence, repository evidence (Terraform/IaC), or sanitized user-provided evidence for current-state claims.
+
+## Current documentation refresh (2026-06-17)
+
+Service facts from official docs:
+
+**Medallion architecture:** Bronze (raw ingestion), Silver (cleaned/conformed), Gold (business-level aggregations). Delta Lake underpins all layers with ACID transactions, schema enforcement, and time travel.
+
+**ADLS Gen2 access:** Unity Catalog manages storage access via external locations and storage credentials. Storage credentials reference an Access Connector (Microsoft.Databricks/accessConnectors) with a system-assigned or user-assigned managed identity. ADLS Gen2 accounts must have hierarchical namespace (HNS) enabled; flat namespace accounts are not supported for Unity Catalog external locations.
+
+**Access Connector:** The preferred managed identity model. The Access Connector's managed identity is granted Storage Blob Data Contributor (or Reader) on the ADLS Gen2 container. Direct service principal credential injection into clusters is discouraged.
+
+**Credential passthrough DEPRECATED:** Azure Active Directory (now Microsoft Entra ID) credential passthrough is deprecated as of Databricks Runtime 15.0 and will be removed. Migrate to Unity Catalog storage credentials and external locations.
+
+**Cluster access modes:** Dedicated (formerly Single User) clusters are Unity Catalog-compatible. Standard (formerly Shared) clusters support Unity Catalog in DBR 13.3 LTS+. No Isolation Shared clusters do not support Unity Catalog. Cluster policies (Premium plan) enforce access mode compliance.
+
+**AKV-backed secret scopes:** Secret values stored in Azure Key Vault are read-only from Databricks; Databricks cannot write back to AKV. Use Vault access policy model (not RBAC model) when the workspace requires AKV-backed scopes.
+
+**Network isolation:** VNet injection places the Databricks control plane and data plane in the customer VNet. Private Link further isolates the workspace front-end and back-end. Both are required for high-compliance environments.
+
+**Certification reference:** DP-750 (Azure Databricks Data Engineer Associate) covers Lakehouse architecture and Unity Catalog integration fundamentals.
+
+Review implications:
+- Do not approve credential passthrough patterns; require migration timeline and Unity Catalog external location design.
+- Require cluster access mode evidence and policy enforcement before approving production cluster configuration.
+- Documentation cannot prove the user's actual cluster state, storage credentials, or VNet configuration.

package/skills/databricks/databricks-lakehouse-engineering-at-azure/references/safety-checklist.md

@@ -0,0 +1,26 @@
+# Safety checklist
+
+Use this reference before privileged, destructive, compliance-impacting, or production-impacting recommendations.
+
+## Non-negotiables
+
+- Never ask users to paste access tokens, service principal secrets, client secrets, connection strings, storage account keys, SAS tokens, or customer identifiers into chat.
+- Use read-only workspace MCP or IaC repository evidence for live state when available; otherwise use sanitized user evidence or official documentation and label the evidence level.
+- Do not invent cluster IDs, workspace URLs, storage account names, Access Connector resource IDs, external location paths, or live configuration state.
+- Require explicit user approval before privileged, destructive, compliance-impacting, or production-impacting recommendations.
+- Use current official Databricks and Microsoft Learn documentation for service behavior when the answer depends on platform details.
+- Keep remediation least-privilege, reversible, and scoped to the requested workspace or storage boundary.
+- Static review only: never execute cluster create/edit, storage credential create, external location create, or ADLS Gen2 configuration changes against live infrastructure. Production infrastructure changes are live-guard gated (escalate).
+
+## Stress checks
+
+- What can expose ADLS Gen2 data to unintended identities (misconfigured managed identity, open container ACL)?
+- What deprecated credential passthrough pattern creates a compliance or security gap?
+- What cluster access mode violation bypasses Unity Catalog enforcement?
+- What AKV-backed secret scope misconfiguration leaks secrets or creates read-path failures?
+- What VNet or Private Link gap allows data exfiltration or unintended public access?
+- What rollback or validation path is unproven?
+
+## Evidence labels
+
+Use `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's live cluster state, storage credential configuration, or network topology.

package/skills/databricks/databricks-lakehouse-engineering-at-azure/references/workflow-and-output.md

@@ -0,0 +1,64 @@
+# Workflow and output contract
+
+Use this reference only when performing the full engineering review, incident triage, implementation guidance, or production-readiness pass.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Architecture: medallion layer design (bronze/silver/gold), Delta Lake table properties, schema enforcement
+- Storage access: ADLS Gen2 HNS enabled, external location design, storage credential (Access Connector managed identity)
+- Credential passthrough: detect deprecated pattern; require migration plan to Unity Catalog access controls
+- Cluster access mode: Dedicated vs Standard vs No Isolation Shared; cluster policy enforcement via Premium plan
+- Secret management: AKV-backed secret scope read-only semantics, Vault access policy model
+- Network isolation: VNet injection configuration, Private Link workspace and data plane endpoints
+- Production posture: service principal identity, Access Connector managed identity, no interactive-user storage access
+
+## Safe workflow
+
+1. **Frame scope**
+   - Workspace/metastore/cluster/environment:
+   - Business criticality and owner:
+   - Data classification and compliance driver:
+   - Required outcome:
+   - Explicit non-goals:
+2. **Collect evidence**
+   - Prefer read-only workspace MCP evidence, repository IaC (Terraform), notebook/SQL source, or sanitized user-provided evidence for current-state claims.
+   - Otherwise inspect official documentation.
+   - Label each finding as `live evidence`, `repo evidence`, `user-provided evidence`, `documentation-based`, or `inference`.
+3. **Stress-test risk**
+   - What can expose storage data to unintended identities?
+   - What deprecated patterns create a compliance or security gap?
+   - What cluster mode violations break Unity Catalog enforcement?
+   - What network paths bypass Private Link isolation?
+   - What evidence is missing?
+4. **Recommend the smallest safe action**
+   - Prefer Unity Catalog managed access, managed identity, least-privilege cluster policies, and validated rollback.
+   - If the safest action is to stop and gather evidence, say that plainly.
+   - Production cluster/storage/network changes are live-guard gated (escalate).
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# Databricks Lakehouse Engineering Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH RISKS / NOT READY / 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
+- Commands or checks:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/databricks/databricks-live-unity-catalog-grant-guard-at-azure/SKILL.md

@@ -0,0 +1,144 @@
+---
+name: databricks-live-unity-catalog-grant-guard-at-azure
+description: Mutating-runtime live guard for Unity Catalog privilege management on Azure Databricks. Executes exactly ONE GRANT or REVOKE of a single privilege on a single Unity Catalog securable (schema, table, or volume) to a single principal — with explicit written human approval, dry-run preflight, prior-state capture, and a named rollback owner. Phase B strictly-scoped controlled mutation; never bulk, never wildcard, never ALL PRIVILEGES, never metastore/account admin grants.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+  execution_tier: mutating-runtime
+  mcp_servers: []
+  oauth_scopes: []
+  run_as_permissions:
+    required:
+      - "Service principal (Entra-managed) that holds MANAGE or IS OWNER of the single target securable (schema, table, or volume) — scoped to that one object only"
+      - "Unity Catalog privilege: MANAGE on the ONE target securable, or IS OWNER — not metastore admin, not account admin"
+    denied:
+      - "metastore admin"
+      - "account admin"
+      - "workspace admin"
+      - "ALL PRIVILEGES grant"
+      - "MANAGE grant at catalog level or above"
+      - "Ownership transfer (ALTER ... OWNER TO)"
+      - "catalog-wide grants"
+      - "MANAGE grant on metastore or catalog"
+  required_egress:
+    - "DATABRICKS_HOST (workspace endpoint, e.g. adb-<id>.azuredatabricks.net)"
+    - "login.microsoftonline.com"
+  requires_credentials:
+    - "DATABRICKS_HOST"
+    - "DATABRICKS_CLIENT_ID"
+  output_attestation:
+    schema: "grant-guard-attestation-v1"
+    signed_with: "idempotency-key"
+    audit_log: "required"
+  liveAgentFields:
+    execution_tier: "mutating-runtime"
+    gate: "explicit-written-human-approval"
+    approval_token_requirements:
+      - "exact securable name (catalog.schema.object or catalog.schema)"
+      - "exact privilege name"
+      - "exact principal name"
+      - "blast radius statement"
+    dry_run_required: true
+    idempotent: true
+    idempotency_key: true
+    audit_log: true
+    prior_state_capture: true
+    rollback_owner: "Databricks workspace admin or Unity Catalog metastore admin"
+    rollback_time_box: "30 minutes"
+    never_auto_dispatched: true
+  companion_agents:
+    - "databricks-live-unity-catalog-grant-guard-at-azure-agent"
+---
+
+# Databricks Live Unity Catalog Grant Guard at Azure
+
+## Purpose
+
+Act as the live mutating guard for Unity Catalog privilege management on Azure Databricks. On receipt of explicit written human approval, execute exactly ONE `GRANT <privilege> ON <securable_type> <securable> TO <principal>` statement — or its exact inverse `REVOKE` — on a single Unity Catalog securable (schema, table, or volume), scoped to a single privilege and a single principal. Capture prior state before execution. Emit a signed attestation. Never mutate without approval. Never execute bulk, wildcard, ALL PRIVILEGES, ownership transfer, or admin-level grants.
+
+## When to use
+
+- A single, specific Unity Catalog privilege must be granted or revoked on one securable, with a full audit trail
+- A human operator has provided a written approval token naming the exact securable, privilege, principal, and blast radius
+- A prior-state capture and named rollback plan are required before any mutation proceeds
+- The operation must be idempotent and produce a signed attestation
+
+## Live-guard gate
+
+This skill operates at `mutating-runtime` (Phase B). It is **never auto-dispatched** by a maestro. Before any mutation executes:
+
+1. Require explicit written human approval naming: exact securable, exact privilege, exact principal, blast radius.
+2. Run dry-run preflight: show current grants on the target securable + the single SQL statement to be executed.
+3. Confirm scope and environment with the approver.
+4. Capture prior grant state (record current grants on the target securable before execution).
+5. Execute the single statement.
+6. Emit signed output attestation (`signed_with: idempotency-key`) referencing the approval token, idempotency key, statement executed, and prior state snapshot.
+
+## Strictly-scoped operation contract
+
+- **EXACTLY ONE** `GRANT` or `REVOKE` per invocation — one privilege, one securable, one principal.
+- Securable types: schema, table, or volume within Unity Catalog.
+- Preferred principals: account groups. Service principals acceptable. Interactive users require additional justification.
+- **REVOKE is the inverse**: REVOKE exactly mirrors the GRANT — same privilege, same securable, same principal. Prior state must be captured before REVOKE.
+- Idempotent: if the grant already exists (for GRANT) or is already absent (for REVOKE), record and return without error.
+
+## Denied operations (hard stops)
+
+- `ALL PRIVILEGES` grant on any securable
+- `MANAGE` privilege grant on metastore, catalog, or schema not owned by the run-as SP
+- Ownership transfer (`ALTER <securable> OWNER TO`)
+- `account-admin` or `metastore-admin` group grants
+- Catalog-level grants (target must be schema, table, or volume — not catalog or metastore)
+- Any bulk or wildcard operation touching more than one securable per invocation
+- Grants to `account users` at broad scope
+
+## Credential posture
+
+- Run as: least-privilege Entra-managed service principal holding MANAGE or IS OWNER on the single target securable only.
+- Credentials referenced by environment variable name only: `DATABRICKS_HOST`, `DATABRICKS_CLIENT_ID`.
+- Client secret or certificate managed via Azure Key Vault — never stored in repo, chat, or logs.
+- Entra app registration recommended; Entra-managed SP required (not workspace-local user).
+
+## Dry-run preflight output
+
+Before execution, emit:
+
+```
+DRY-RUN PREFLIGHT
+Target securable : <catalog>.<schema>[.<object>] (<type>)
+Privilege        : <PRIVILEGE>
+Principal        : <principal_name>
+Operation        : GRANT | REVOKE
+Current grants   : <output of SHOW GRANTS ON <type> <securable>>
+Statement to run : GRANT <privilege> ON <type> <catalog>.<schema>[.<object>] TO `<principal>`;
+Approval token   : <token from approval>
+Blast radius     : <description>
+```
+
+Await explicit confirmation before proceeding.
+
+## Rollback
+
+- Prior state: capture `SHOW GRANTS ON <securable_type> <securable>` output before execution.
+- Inverse statement: `REVOKE <privilege> ON <securable_type> <securable> FROM `<principal>`` (for GRANT operations); `GRANT` inverse for REVOKE.
+- Owner: Databricks workspace admin or Unity Catalog metastore admin.
+- Time-box: rollback executable within 30 minutes of mutation.
+
+## Lean operating rules
+
+- Prefer docs.databricks.com and learn.microsoft.com documentation for platform-documented behavior.
+- Never print, echo, or log credential values; reference by env-var name only.
+- Label all observations as sampled configured-environment evidence.
+- If the request implies more than one securable, push back — that exceeds this skill's scope.
+- State what is unknown; documentation proves service behavior, not the workspace's deployed state.
+
+## Official sources
+
+- https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html
+- https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/index.html
+- https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-grant.html
+- https://docs.databricks.com/en/admin/users-groups/service-principals.html
+- https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/

package/skills/databricks/databricks-live-unity-catalog-grant-guard-at-azure/metadata.json

@@ -0,0 +1,22 @@
+{
+  "id": "databricks-live-unity-catalog-grant-guard-at-azure",
+  "name": "Databricks Live Unity Catalog Grant Guard at Azure",
+  "type": "skill",
+  "provider": "databricks",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Mutating-runtime live guard for Unity Catalog privilege management on Azure Databricks. Executes exactly ONE GRANT or REVOKE of a single privilege on a single Unity Catalog securable (schema, table, or volume) to a single principal — with explicit written human approval, dry-run preflight, prior-state capture, and named rollback. Phase B strictly-scoped controlled mutation; never ALL PRIVILEGES, never metastore/account admin, never catalog-wide grants.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html",
+    "https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/index.html",
+    "https://docs.databricks.com/en/sql/language-manual/sql-ref-syntax-ddl-grant.html",
+    "https://docs.databricks.com/en/admin/users-groups/service-principals.html",
+    "https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/"
+  ],
+  "security_notes": "Mutating-runtime Phase B. Executes exactly one GRANT or REVOKE per invocation. Never auto-dispatched; requires explicit written human approval token referencing exact securable, privilege, principal, and blast radius. Run-as principal holds MANAGE or IS OWNER on the single target securable only — not metastore admin or account admin. ALL PRIVILEGES, catalog-wide grants, and ownership transfers are explicitly denied.",
+  "last_verified": "2026-06-17",
+  "path": "skills/databricks/databricks-live-unity-catalog-grant-guard-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["databricks-live-unity-catalog-grant-guard-at-azure-agent"]
+}

package/skills/databricks/databricks-unity-catalog-governance-at-azure/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: databricks-unity-catalog-governance-at-azure
+description: Review Databricks Unity Catalog governance on Azure: three-level namespace design, GRANT privilege model, identity federation with Microsoft Entra ID, service principal posture, workspace-catalog binding, account/workspace/metastore admin separation, audit via system tables, and least-privilege schema-scoped grant patterns. Static review only — never execute against live workspace.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-17"
+  category: security
+---
+
+# Databricks Unity Catalog Governance at Azure
+
+## Purpose
+
+Act as the Databricks Unity Catalog governance reviewer who treats every overly broad grant, workspace-local identity, and missing parent privilege as a future incident until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Unity Catalog three-level namespace design (metastore → catalog → schema → table/volume/function)
+- GRANT privilege model: USE CATALOG, USE SCHEMA, SELECT, MODIFY, CREATE TABLE, CREATE VOLUME, CREATE FUNCTION
+- Identity federation: account groups vs workspace-local groups, Microsoft Entra ID managed service principals
+- Service principal posture for production workloads (run as SERVICE PRINCIPAL, not interactive user)
+- Account/workspace/metastore admin separation and blast-radius review
+- Workspace-catalog binding configuration (read-only vs full binding)
+- Audit trail design using Unity Catalog system tables
+- Least-privilege schema-scoped grant reviews and ALL PRIVILEGES exclusion analysis
+
+## Lean operating rules
+
+- Prefer current Databricks and Microsoft Learn documentation for service behavior. Use the per-skill facts and sampled evidence in `references/official-sources.md`; when the user has configured read-only workspace MCP access, use it for current-state evidence instead of guessing.
+- Separate confirmed facts from inference. If state was not queried or shown, say so.
+- Challenge broad grants, workspace-local identities in production, interactive-user run patterns, and undocumented admin assignments.
+- Keep the answer scoped, reversible, least-privilege, and explicit about blockers or unknowns.
+- Static review only: never execute GRANT, REVOKE, or any DDL against a live workspace. Production grant/role/policy changes are live-guard gated (escalate).
+- Load references only when needed; do not pull all deep guidance into short answers.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full review, incident triage, implementation guidance, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before privileged, destructive, compliance-impacting, or production-impacting recommendations.
+- [Official sources](references/official-sources.md) — use when grounding Databricks or Azure service behavior or checking the detailed source list.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main privilege risks or control gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/databricks/databricks-unity-catalog-governance-at-azure/metadata.json

@@ -0,0 +1,28 @@
+{
+  "id": "databricks-unity-catalog-governance-at-azure",
+  "name": "Databricks Unity Catalog Governance at Azure",
+  "type": "skill",
+  "provider": "databricks",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Databricks Unity Catalog governance on Azure: three-level namespace design, GRANT privilege model, Microsoft Entra ID identity federation, service principal posture, workspace-catalog binding, admin separation, and least-privilege schema-scoped grant patterns.",
+  "source_type": "original",
+  "official_docs": [
+    "https://docs.databricks.com/en/data-governance/unity-catalog/index.html",
+    "https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/privileges.html",
+    "https://docs.databricks.com/en/admin/users-groups/service-principals.html",
+    "https://learn.microsoft.com/en-us/azure/databricks/data-governance/unity-catalog/"
+  ],
+  "security_notes": "Never execute GRANT, REVOKE, or DDL against a live workspace during review. Require explicit approval before any production grant or admin assignment. Challenge workspace-local groups in production and interactive-user run patterns. Always prefer service principals over interactive users for automated workloads.",
+  "last_verified": "2026-06-17",
+  "path": "skills/databricks/databricks-unity-catalog-governance-at-azure",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "companion_agents": ["databricks-unity-catalog-governance-at-azure-agent"]
+}