@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/order-to-cash-protocol/references/workflow-and-output.md

@@ -0,0 +1,140 @@
+# Order-to-Cash Protocol — Workflow and Output Contract
+
+## Overview
+This document provides the detailed step-by-step workflow, decision tree, and output contract for the order-to-cash-protocol skill. It is the authoritative reference for agent implementations and human reviewers tracing execution through the post-order revenue cycle.
+
+---
+
+## Detailed Step-by-Step Workflow
+
+### Phase 1 — Order Validation (d365-sales-revenue-operations-agent + d365-supply-chain-plan-to-produce-agent)
+
+**Step 1.1 — Receive confirmed sales order**
+- Accept the confirmed sales order number from the upstream system or lead-to-cash-protocol handoff.
+- Verify the order status is "Confirmed" in Dynamics 365 Supply Chain Management.
+- Confirm that legal entity, currency, and customer account are correctly set.
+
+**Step 1.2 — Order accuracy review**
+- Compare all line items: item numbers, quantities, unit prices, discount rates, delivery addresses, and requested delivery dates against the customer's accepted quote or purchase order.
+- Any discrepancy must be resolved by d365-sales-revenue-operations-agent and the customer before fulfillment proceeds.
+
+**Step 1.3 — Credit status check**
+- Query the customer's credit limit and current accounts receivable exposure in Dynamics 365 Finance.
+- If the customer account is on credit hold, halt fulfillment; escalate to d365-finance-close-to-report-agent and the finance credit manager.
+- Do not release from credit hold without documented human approval.
+
+---
+
+### Phase 2 — Fulfillment (d365-supply-chain-plan-to-produce-agent)
+
+**Step 2.1 — Inventory reservation and ATP check**
+- Reserve available inventory against each order line.
+- Calculate the available-to-promise (ATP) date for any line where stock is insufficient.
+- If the ATP date exceeds the promised delivery date, surface the gap to d365-sales-revenue-operations-agent and the human owner immediately; do not silently delay shipment.
+
+**Step 2.2 — Warehouse picking and packing**
+- Trigger picking work in the warehouse management system.
+- Monitor picking completion; flag pick shortages for supply chain owner resolution.
+- Confirm packing and generate a packing slip with shipment reference.
+
+**Step 2.3 — Shipment and delivery confirmation**
+- Record the shipment date and carrier details against the sales order.
+- Generate the delivery note or bill of lading reference.
+- Hand the packing slip and shipment confirmation to d365-finance-close-to-report-agent.
+
+---
+
+### Phase 3 — Invoicing (d365-finance-close-to-report-agent)
+
+**Step 3.1 — Invoice creation**
+- Generate a draft sales order invoice in Dynamics 365 Finance using the confirmed packing slip.
+- Validate that invoice lines match packing slip quantities and original sales order pricing.
+- Apply correct tax codes and customer-specific payment terms.
+
+**Step 3.2 — Invoice accuracy gate**
+- Compare draft invoice against sales order and packing slip line by line.
+- Any discrepancy (price, quantity, tax) triggers a hold; route to d365-sales-revenue-operations-agent for resolution.
+- Invoices above the configured materiality threshold require human approval before posting.
+
+**Step 3.3 — Invoice posting and AR entry**
+- Post the validated invoice in Dynamics 365 Finance.
+- Open an accounts receivable entry with the customer's due date based on payment terms.
+- Deliver the invoice to the customer via the configured channel (email, portal, EDI).
+
+---
+
+### Phase 4 — Collections and Cash Application (d365-finance-close-to-report-agent)
+
+**Step 4.1 — Payment monitoring**
+- Monitor the accounts receivable aging report for the invoice due date.
+- At configurable intervals before and after due date, surface collection activities to the finance owner.
+- Do not contact the customer directly; surface recommended actions to the human owner.
+
+**Step 4.2 — Cash application**
+- Upon receipt of customer payment or remittance advice, apply cash to the matching open invoice.
+- If the payment is short (partial payment or deduction), flag for finance owner; do not auto-close the AR entry.
+
+**Step 4.3 — Settlement and close**
+- Fully settled invoices are closed in Dynamics 365 Finance.
+- Update the sales performance report in d365-sales-revenue-operations-agent.
+- Confirm completion to the upstream lead-to-cash-protocol if this order-to-cash cycle was initiated from it.
+
+---
+
+## Decision Tree
+
+```
+START: Confirmed sales order received
+│
+├─ Order status confirmed in Supply Chain Management?
+│   └─ NO → STOP; return to order management
+│
+├─ Order accuracy verified?
+│   └─ NO → RETURN to d365-sales-revenue-operations-agent for correction
+│
+├─ Customer credit status: OK?
+│   └─ NO → HALT; escalate to finance credit manager
+│
+├─ Inventory ATP within delivery window?
+│   └─ NO → SURFACE gap to human owner; do not commit silently
+│
+├─ Picking and packing complete?
+│   └─ NO → MONITOR; alert supply chain owner on delay
+│
+├─ Invoice accurate (matches packing slip + order)?
+│   └─ NO → HOLD; flag for human resolution
+│
+├─ Invoice above materiality threshold?
+│   └─ YES → REQUIRE human approval before posting
+│
+├─ Payment received in full?
+│   └─ NO (partial) → FLAG for finance owner; do not auto-close
+│
+└─ Invoice settled?
+    └─ YES → CLOSE AR; update sales reporting
+```
+
+---
+
+## Output Contract
+
+Every execution of this protocol produces a structured output capsule with the following mandatory fields:
+
+| Field | Type | Description |
+|---|---|---|
+| matter_id | string | Unique identifier for this O2C instance |
+| sales_order_id | string | Confirmed sales order number |
+| current_stage | enum | One of: order_validated, credit_check, fulfillment, shipped, invoiced, collections, closed |
+| gate_outcomes | object | Pass/fail/escalated for each gate: credit, order_accuracy, atp, invoice_match, collections |
+| 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 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, timestamp

package/skills/cross-functional/procure-to-pay-protocol/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: procure-to-pay-protocol
+description: Use this skill to orchestrate the procure-to-pay (source-to-pay) process across Dynamics 365 Supply Chain Management, Finance, and compliance-aware separation-of-duties governance. It coordinates the journey from purchase requisition through purchase order approval, goods or services receipt, vendor invoice processing, and payment settlement. The skill enforces segregation-of-duties gates on purchase order approval, defines agent handoff rules, and escalates SoD conflicts to d365-security-sod-governance-agent. It does not approve purchase orders, release vendor payments, override procurement policies, or access vendor credentials; all production-impacting steps are escalated to the relevant specialist or human owner.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+  lifecycle: experimental
+---
+
+# Procure-to-Pay Protocol
+
+## Purpose
+This skill orchestrates the end-to-end procure-to-pay (P2P) / source-to-pay (S2P) business process in Microsoft Dynamics 365 environments. It coordinates Dynamics 365 Supply Chain Management (requisitions, purchase orders, and goods receipt), Dynamics 365 Finance (vendor invoice processing and payment), and Dynamics 365 security and compliance governance (segregation of duties on PO approval). The protocol ensures that no single agent approves, receives, and pays for the same purchase, and that SoD violations are identified and escalated before they reach the general ledger.
+
+## When to use
+- A purchase requisition must be evaluated, converted to a PO, approved, and tracked through receipt and payment.
+- A vendor invoice must be matched to a PO and goods receipt before payment is released.
+- A segregation-of-duties concern exists on a PO approval workflow.
+- Multiple Dynamics 365 modules are involved and cross-agent coordination is required.
+- A procurement compliance review is needed before a vendor payment run.
+
+## When NOT to use
+- The matter is confined to sales order fulfillment — use order-to-cash-protocol.
+- Direct configuration of Dynamics 365 procurement workflows is required — route to the supply chain specialist.
+- The matter is a vendor master data change — escalate to the supply chain specialist and finance owner.
+- The ask is for strategic sourcing or vendor selection advice without an active procurement request.
+
+## Participating agents
+- d365-supply-chain-plan-to-produce-agent — owns purchase requisitions, purchase orders, and goods/services receipt
+- d365-finance-close-to-report-agent — owns vendor invoice processing, accounts payable, and payment settlement
+- d365-security-sod-governance-agent — reviews and flags segregation-of-duties violations on PO approval workflows
+
+## Inputs required
+- Purchase requisition or purchase order number
+- Vendor account and legal entity
+- Goods or services description, quantities, and agreed pricing
+- Applicable procurement policy and approval workflow configuration
+- Budget availability confirmation (if applicable)
+
+## Evidence required
+- Approved purchase requisition with budget check result
+- Purchase order confirmation from vendor
+- Goods receipt note or service entry sheet
+- Vendor invoice with three-way match result (PO, receipt, invoice)
+- SoD clearance from d365-security-sod-governance-agent for PO approval
+
+## Workflow
+1. Receive purchase requisition; validate against procurement catalog and purchasing policy.
+2. Perform budget availability check; if budget is insufficient, pause and escalate to finance owner.
+3. Convert approved requisition to a purchase order; confirm vendor, pricing, and delivery terms.
+4. Route purchase order through the configured approval workflow.
+5. SoD gate: invoke d365-security-sod-governance-agent to verify that the PO approver is not the same person who raised the requisition or will receive the goods.
+6. If SoD conflict is detected, halt PO approval; escalate to compliance owner and document the conflict.
+7. Send confirmed purchase order to vendor; record confirmation reference.
+8. Monitor delivery against PO delivery date; flag overdue deliveries.
+9. Record goods receipt or service entry sheet upon delivery; perform quantity and quality check against PO.
+10. Receive vendor invoice in Dynamics 365 Finance; perform three-way match (PO, receipt, invoice).
+11. If match discrepancy exists, hold invoice and route to d365-supply-chain-plan-to-produce-agent and vendor for resolution.
+12. Approved and matched invoices are queued for payment; d365-finance-close-to-report-agent manages payment run per payment terms.
+13. Release payment; apply to vendor open transactions and close accounts payable entries.
+
+## Decision gates
+| Gate | Condition | Action if not met |
+|---|---|---|
+| Budget availability | Sufficient budget in the appropriate cost center | Pause; escalate to finance owner for budget approval |
+| Procurement policy | Request conforms to catalog and purchasing policy | Reject and return to requester |
+| SoD on PO approval | Approver, requisitioner, and receiver are different people | Halt; escalate to d365-security-sod-governance-agent and compliance owner |
+| Three-way match | PO, goods receipt, and invoice quantities and prices align | Hold invoice; route to supply chain agent and vendor for resolution |
+| Payment authorization | Payment run approved by authorized finance signatory | Do not release payment without documented authorization |
+
+## Refusal triggers
+- PO approval is requested for a person who also raised the requisition — refuse; escalate SoD violation.
+- Vendor payment is requested without a matched invoice and goods receipt — refuse.
+- Vendor credentials, banking details, or PII are included in any input — stop; redact and escalate.
+- A purchase order is requested to be back-dated — refuse; escalate to compliance owner.
+- An invoice is requested to be paid without three-way match and no documented exception approval — refuse.
+
+## Handoff rules
+- Every handoff carries a structured capsule: matter_id, po_id, current_stage, gate_outcomes, sod_status, open_questions, do_not_do_list.
+- Supply Chain owns requisition through goods receipt; Finance owns invoice processing through payment.
+- d365-security-sod-governance-agent is invoked at PO approval and again at payment authorization if personnel assignments have changed.
+- No agent releases a vendor payment — all payments require a human-authorized payment run.
+
+## KPIs
+- Purchase order cycle time (requisition to PO confirmation)
+- Three-way match rate (first-pass match without manual intervention)
+- Invoice processing time (receipt to posting)
+- Payment on-time rate (payments within agreed vendor terms)
+- SoD violation rate (conflicts detected per period)
+
+## References
+- [Source to pay end-to-end overview — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/business-processes/source-to-pay-overview)
+- [TechTalk: Procure to pay in Dynamics 365 Supply Chain Management](https://learn.microsoft.com/dynamics365/guidance/techtalks/supply-chain-procure-to-pay-overview)
+- [TechTalk: Source to pay in Dynamics 365 Finance and Supply Chain Management](https://learn.microsoft.com/dynamics365/guidance/techtalks/dynamics-365-finance-supply-chain-management-source-to-pay)
+- [Procurement and sourcing overview — Dynamics 365 Supply Chain Management](https://learn.microsoft.com/dynamics365/supply-chain/procurement/procurement-sourcing-overview)

package/skills/cross-functional/procure-to-pay-protocol/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "procure-to-pay-protocol",
+  "name": "Procure-to-Pay Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Orchestration protocol for the procure-to-pay (source-to-pay) process in Dynamics 365 environments, coordinating Supply Chain Management (requisitions, purchase orders, and goods receipt), Finance (vendor invoice processing and AP payment), and security/SoD governance (segregation-of-duties checks on PO approval). Enforces three-way match before payment, SoD gates at PO approval and payment authorization, and structured handoffs between d365-supply-chain-plan-to-produce-agent, d365-finance-close-to-report-agent, and d365-security-sod-governance-agent.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/source-to-pay-overview",
+    "https://learn.microsoft.com/dynamics365/guidance/techtalks/supply-chain-procure-to-pay-overview",
+    "https://learn.microsoft.com/dynamics365/supply-chain/procurement/procurement-sourcing-overview"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration guide only — it is never an authorization to approve purchase orders, release vendor payments, override procurement policies, or bypass segregation-of-duties controls. All production-impacting steps require confirmation by the relevant human owner or specialist agent. The protocol never requests vendor credentials, banking details, tenant IDs, or personal data. SoD violations detected at PO approval or payment authorization always halt the process and escalate to the compliance owner — no agent resolves a SoD conflict unilaterally. Back-dating of purchase orders and payment without a three-way match are explicitly refused.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/procure-to-pay-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.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>
+```