@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/incident-to-remediation-protocol/references/workflow-and-output.md

@@ -0,0 +1,200 @@
+# Incident-to-Remediation Protocol — Detailed Workflow and Output Contract
+
+## Overview
+
+This document provides the step-by-step workflow, decision tree, and output contract for the `incident-to-remediation-protocol` skill. It is the reference for `m365-identity-zero-trust-agent`, `copilot-governance-maestro-agent`, `microsoft-maestro-agent`, and human incident commanders who need to understand the gate structure, the incident record format, and post-incident review requirements.
+
+Zero Trust assume-breach is applied at every phase: the scope of compromise is assumed to be larger than initial signals suggest until forensic evidence explicitly narrows it.
+
+---
+
+## Detailed Workflow
+
+### Phase 1 — Detection and Triage
+
+**Step 1.1 — Ingest incident signal**
+- Source: Microsoft Defender portal incident queue, manual report, or alert from a connected workload
+- Record: `incident_id`, `detection_source`, `initial_alert_count`, `affected_entity_types[]` (users, devices, mailboxes, apps, Dataverse environments), `incident_type_hypothesis`
+- Apply assume-breach immediately: treat affected scope as potentially wider than initial entity list
+
+**Step 1.2 — Severity classification**
+Microsoft Defender XDR severity scale:
+- **Informational**: no immediate risk; monitor
+- **Low**: limited scope; standard response cadence
+- **Medium**: moderate scope or data sensitivity; elevated response
+- **High**: significant scope or high-value asset at risk; escalate immediately
+- **Critical**: organization-wide threat, ransomware, or mass credential compromise; immediate escalation
+
+Blast radius factors:
+- Number of affected entities
+- Sensitivity classification of accessed data (e.g., Purview sensitivity labels)
+- Production environment impact
+- Presence of lateral movement indicators
+
+Output: `severity_assessment` with `severity_level`, `blast_radius_estimate`, `lateral_movement_suspected: true|false`, `data_exfiltration_suspected: true|false`
+
+**Step 1.3 — Cross-workload scope mapping**
+- Map affected entities to workloads: Entra ID, Exchange Online, SharePoint, Teams, Dynamics 365 / Dataverse, Copilot Studio
+- Identify which Microsoft Defender workloads have signals (Defender for Identity, Defender for Endpoint, Defender for Office 365, Defender for Cloud Apps)
+- Output: `workload_scope_map` with per-workload `affected: true|false`, `signal_source`, `entity_list[]`
+
+---
+
+### Phase 2 — Escalation and Containment Gates
+
+**Gate 1 — Severity Triage Gate**
+```
+IF severity_level = High OR Critical:
+  → ESCALATE IMMEDIATELY to:
+    - Incident commander (human)
+    - microsoft-maestro-agent (for Defender XDR SecOps coordination)
+    - copilot-governance-maestro-agent (if Copilot surface area is in scope)
+  → Do NOT proceed to containment planning without incident commander acknowledgment
+  → Record: escalation_timestamp, escalation_target, commander_acknowledgment_reference
+```
+
+**Gate 2 — Containment Approval Gate**
+```
+FOR EVERY containment action (user disable, device isolation, IP/domain block, session revoke):
+  → REQUEST explicit human approval from incident commander or security owner
+  → Record: action_description, approver_id, approval_timestamp, approval_reference
+  → Do NOT execute any containment action without recorded approval
+  → If approval cannot be obtained within the required timeframe for a Critical incident:
+    → Escalate to security leadership for emergency authorization
+```
+
+**Step 2.1 — Containment planning**
+Identify containment actions per affected entity type:
+| Entity type | Possible containment actions |
+|---|---|
+| User identity | Disable account, revoke sessions, reset credentials, enforce MFA via Conditional Access |
+| Device | Isolate device via Microsoft Defender for Endpoint |
+| Mailbox | Block external forwarding, remove malicious inbox rules |
+| IP / domain | Block in Microsoft Defender portal |
+| Dataverse environment | Revoke service principal access, disable affected flows |
+| Copilot surface | Disable affected agent instance, revoke data source connections |
+
+---
+
+### Phase 3 — Investigation
+
+**Step 3.1 — Attack story analysis**
+- Use Microsoft Defender XDR correlated incident view to trace the attack timeline
+- Identify: initial access vector, privilege escalation path, lateral movement, persistence mechanisms, data accessed or exfiltrated
+- Map findings to MITRE ATT&CK techniques where applicable
+- Output: `attack_story_summary` with `initial_access_vector`, `techniques[]`, `affected_data_classification`, `exfiltration_evidence: true|false|suspected`
+
+**Step 3.2 — Identity and Zero Trust posture assessment**
+- `m365-identity-zero-trust-agent` assesses:
+  - Conditional Access coverage gaps that enabled the attack
+  - Entra ID risk event details for affected identities
+  - Privileged Identity Management (PIM) anomalies
+  - Zero Trust gap: which verify-explicitly or least-privilege control failed
+- Output: `identity_zt_assessment` with `ca_gap[]`, `risk_events[]`, `pim_anomalies[]`, `zt_gap_summary`
+
+**Step 3.3 — Audit log and evidence preservation**
+- Confirm relevant audit logs are preserved (Purview Unified Audit Log)
+- If legal or regulatory investigation is likely: escalate to compliance owner for legal-hold placement in Microsoft Purview eDiscovery
+- Do NOT allow audit logs to be deleted or retention shortened during active investigation
+
+---
+
+### Phase 4 — Remediation
+
+**Step 4.1 — Remediation planning**
+For each confirmed compromise or misconfiguration:
+- Identify remediation action (credential reset, device re-image, inbox rule cleanup, Conditional Access policy correction, service principal removal)
+- Confirm action is least-privilege (does not require broader permissions than necessary)
+- Confirm action is reversible where possible; flag irreversible actions for extra approval
+- Output: `remediation_plan[]` with `action`, `target_entity`, `reversible: true|false`, `approval_required: true|false`
+
+**Step 4.2 — Remediation execution**
+- Execute each approved remediation action
+- Record: `action`, `executor`, `timestamp`, `result: success|failed|partial`
+- Verify each action with confirmation evidence (e.g., sign-in log showing no further anomalous activity, device compliance status restored)
+
+**Step 4.3 — Zero Trust posture hardening**
+- Based on the Zero Trust gap identified in Step 3.2, recommend and apply (with human approval) Conditional Access policy corrections, PIM role scope reductions, or MFA enforcement changes
+- Do NOT apply Zero Trust hardening that would lock out legitimate users without testing in report-only mode first
+
+---
+
+### Phase 5 — Post-Incident Review
+
+**Gate 3 — Post-Incident Review Gate**
+```
+Mandatory before incident closure:
+  → Complete structured post-incident review (items below)
+  → Do NOT close incident in Microsoft Defender portal without completed review
+  → Hand off review findings to security owner for playbook and policy updates
+```
+
+**Post-incident review checklist:**
+1. Confirmed attack type, MITRE ATT&CK techniques, and impact summary
+2. Root cause: which control failed, was misconfigured, or was absent
+3. Detection gap: how long between initial access and detection; what reduced MTTD
+4. Response gap: what slowed containment; what improved MTTC
+5. Data accessed or exfiltrated: confirmed or suspected; sensitivity classification
+6. Regulatory or legal notification obligation: yes / no / under assessment (escalate to legal if yes)
+7. Zero Trust gap findings and recommended Conditional Access or identity hardening
+8. Playbook updates required
+9. Policy changes required (with owner and timeline)
+
+---
+
+## Decision Tree (Condensed)
+
+```
+Incident detected
+  └─ Severity triage
+       ├─ High / Critical → Gate 1: escalate to IC + maestro → awaiting acknowledgment
+       └─ Low / Medium → containment planning
+            └─ Gate 2: approval for each containment action
+                 └─ Execute approved containment
+                      └─ Investigation (attack story, identity ZT assessment, audit log)
+                           └─ Remediation planning + Gate 2 (approval for each action)
+                                └─ Execute remediation
+                                     └─ Gate 3: post-incident review (mandatory)
+                                          └─ Resolve incident in Defender portal
+```
+
+---
+
+## Output Contract
+
+### Incident Record
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `incident_record_id` | string (UUID) | Yes | Unique record identifier |
+| `skill_id` | string | Yes | Must be `incident-to-remediation-protocol` |
+| `skill_version` | string | Yes | Semantic version |
+| `incident_id` | string | Yes | Microsoft Defender portal incident ID |
+| `severity_level` | enum | Yes | `Informational | Low | Medium | High | Critical` |
+| `blast_radius_estimate` | string | Yes | Affected entity count and data sensitivity summary |
+| `workload_scope_map` | object | Yes | Per-workload affected status and entity list |
+| `containment_actions` | object[] | Yes | Each action with approval reference and result |
+| `attack_story_summary` | object | Yes | Initial access, techniques, data accessed |
+| `identity_zt_assessment` | object | Yes | CA gaps, risk events, ZT gap summary |
+| `remediation_plan` | object[] | Yes | Each remediation action with approval and result |
+| `escalations_fired` | string[] | Yes | Which gates fired |
+| `post_incident_review` | object | Yes (before closure) | Full review checklist completed |
+| `incident_status` | enum | Yes | `open | contained | remediated | closed` |
+| `do_not_do_list` | string[] | Yes | Mandatory refusal items |
+| `open_questions` | string[] | Yes | Unresolved items for human judgment |
+| `timestamp` | string (ISO) | Yes | Record creation datetime |
+
+### Do-Not-Do List (always attached)
+
+- Do not execute containment actions (user disable, device isolation, IP block) without recorded human approval.
+- Do not close an incident without a completed post-incident review.
+- Do not allow audit logs to be deleted or retention shortened during an active investigation.
+- Do not minimize the assumed scope of compromise until forensic evidence explicitly narrows it.
+- Do not treat this protocol as covering data breach regulatory notification obligations; escalate breach scenarios to the privacy owner and legal counsel.
+- Do not request credentials, session tokens, or personal data to perform investigation; work from sanitized incident signals only.
+
+---
+
+## Audit Log Fields
+
+`incident_record_id`, `skill_id`, `skill_version`, `invoked_by`, `incident_id`, `severity_level`, `gates_fired`, `containment_actions_count`, `remediation_actions_count`, `post_incident_review_complete`, `incident_status`, `timestamp`

package/skills/cross-functional/lead-to-cash-protocol/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: lead-to-cash-protocol
+description: Use this skill to orchestrate the end-to-end lead-to-cash business process across Dynamics 365 Sales, Supply Chain Management, and Finance. It coordinates the journey from a qualified sales opportunity through order creation, fulfillment, invoicing, and final revenue recognition. The skill defines stage gates, agent handoff rules, escalation triggers, and decision logic for cross-functional coordination. It does not make business decisions, approve credit limits, authorize revenue recognition treatments, or execute any system transactions; 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
+---
+
+# Lead-to-Cash Protocol
+
+## Purpose
+This skill orchestrates the cross-functional lead-to-cash process in Microsoft Dynamics 365 environments. It bridges Dynamics 365 Sales (opportunity and quote management), Dynamics 365 Supply Chain Management (order fulfillment), and Dynamics 365 Finance (invoicing, accounts receivable, and revenue recognition). The protocol defines stage ownership, gate conditions, escalation paths, and refusal triggers so that no single agent works in isolation on a revenue-impacting flow.
+
+## When to use
+- A qualified sales opportunity must progress to a confirmed sales order.
+- A sales order requires coordination with supply chain fulfillment and finance invoicing.
+- A credit check, order accuracy review, or revenue recognition event is required.
+- Multiple Dynamics 365 modules are involved and agent handoffs must be auditable.
+- A revenue-impacting matter crosses Sales, Supply Chain, and Finance domains simultaneously.
+
+## When NOT to use
+- The matter is contained within a single Dynamics 365 module and no cross-domain coordination is needed.
+- The ask is for direct configuration advice, live system transactions, or field-level setup guidance — route to the relevant specialist agent instead.
+- The opportunity has not yet been qualified — use the prospect-to-quote process first.
+- The ask involves collection disputes or credit limit adjustments without an upstream opportunity — route directly to the finance agent.
+
+## Participating agents
+- d365-sales-revenue-operations-agent — owns opportunity qualification, quote approval, and order entry
+- d365-supply-chain-plan-to-produce-agent — owns order fulfillment, inventory reservation, and delivery
+- d365-finance-close-to-report-agent — owns invoicing, accounts receivable, revenue recognition, and cash application
+
+## Inputs required
+- Opportunity or sales order identifier
+- Legal entity and currency
+- Requested delivery date or fulfillment window
+- Revenue recognition method (ASC 606 / IFRS 15 classification if applicable)
+- Credit limit status for the customer account
+- Applicable pricing agreement or trade agreement reference
+
+## Evidence required
+- Opportunity stage confirmation from d365-sales-revenue-operations-agent
+- Credit check outcome from finance or credit management system
+- Inventory availability signal from d365-supply-chain-plan-to-produce-agent
+- Revenue recognition classification from d365-finance-close-to-report-agent
+- Approval chain documentation for discount exceptions above threshold
+
+## Workflow
+1. Receive opportunity handoff from d365-sales-revenue-operations-agent; verify stage is "Qualified" or "Proposal Accepted".
+2. Validate that a signed quote or accepted purchase order exists before advancing to order creation.
+3. Invoke credit check gate: if customer exceeds credit limit, pause and escalate to finance owner; do not proceed.
+4. Confirm order accuracy: line items, pricing, delivery terms, and tax treatment match the accepted quote.
+5. Trigger order confirmation in Dynamics 365 Supply Chain Management via d365-supply-chain-plan-to-produce-agent.
+6. Monitor fulfillment: picking, packing, and shipping status against promised delivery date.
+7. Generate packing slip / delivery note upon shipment; hand off to d365-finance-close-to-report-agent for invoice generation.
+8. Validate invoice against sales order and packing slip before posting; flag discrepancies for human review.
+9. Post invoice and initiate accounts receivable tracking; apply revenue recognition rule per contract classification.
+10. Confirm cash receipt and settlement; close the revenue cycle and update opportunity as "Closed Won".
+
+## Decision gates
+| Gate | Condition | Action if not met |
+|---|---|---|
+| Credit check | Customer credit within approved limit | Pause; escalate to finance credit manager |
+| Order accuracy | Line items and pricing match accepted quote | Return to d365-sales-revenue-operations-agent for correction |
+| Inventory availability | Stock confirmed before order confirmation | Notify d365-supply-chain-plan-to-produce-agent; assess ATP date |
+| Revenue recognition | Contract classification confirmed | Escalate to d365-finance-close-to-report-agent and finance owner |
+| Invoice match | Invoice matches order and packing slip | Hold posting; flag discrepancy for human review |
+
+## Refusal triggers
+- A production system transaction is requested without human confirmation — refuse and escalate.
+- Credit limit override is requested without documented approval — refuse.
+- Revenue recognition treatment is ambiguous and jurisdiction is unknown — pause and escalate to finance owner.
+- Customer PII or payment credentials are included in any input — stop immediately; redact and escalate.
+- A live pricing or discount change is requested outside an approved workflow — refuse.
+
+## Handoff rules
+- Every handoff uses a structured context capsule containing: matter_id, stage, evidence quality, open questions, do_not_do_list, and privilege sensitivity flag.
+- Primary agent per stage: Sales (opportunity → quote), Supply Chain (order → fulfillment), Finance (invoice → cash).
+- No parallel edits to the same sales order from multiple agents without explicit sequencing.
+- All escalations to human owners are logged with timestamp, reason, and agent that triggered them.
+
+## KPIs
+- Days from opportunity close to order confirmation
+- Order accuracy rate (lines matching quote on first pass)
+- Days sales outstanding (DSO)
+- Invoice-to-cash cycle time
+- Revenue recognition compliance rate (no late adjustments)
+
+## References
+- [Dynamics 365 order-to-cash overview](https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-overview)
+- [Prospect to quote end-to-end overview](https://learn.microsoft.com/dynamics365/guidance/business-processes/prospect-to-quote-overview)
+- [Manage accounts receivable — Dynamics 365 Finance](https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-areas-overview#manage-accounts-receivable)
+- [Revenue recognition in Dynamics 365 Finance](https://learn.microsoft.com/dynamics365/finance/accounts-receivable/revenue-recognition-overview)

package/skills/cross-functional/lead-to-cash-protocol/metadata.json

@@ -0,0 +1,19 @@
+{
+  "id": "lead-to-cash-protocol",
+  "name": "Lead-to-Cash Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Orchestration protocol for the end-to-end lead-to-cash process in Dynamics 365 environments, coordinating Sales (opportunity and quote), Supply Chain Management (order fulfillment), and Finance (invoicing and revenue recognition). Defines stage gates, agent handoff rules, credit check escalation, and revenue recognition decision logic across d365-sales-revenue-operations-agent, d365-supply-chain-plan-to-produce-agent, and d365-finance-close-to-report-agent.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-overview",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/prospect-to-quote-overview",
+    "https://learn.microsoft.com/dynamics365/finance/accounts-receivable/revenue-recognition-overview"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration guide only — it is never an authorization for system transactions, credit approvals, revenue recognition treatments, or pricing changes. All production-impacting steps must be confirmed by the relevant human owner or specialist agent. The protocol never requests customer credentials, tenant IDs, payment card data, or personal customer data. Credit limit overrides require documented approval before any agent proceeds. Revenue recognition ambiguity triggers an immediate pause and human escalation rather than an agent judgment call.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/lead-to-cash-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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

@@ -0,0 +1,166 @@
+# Lead-to-Cash Protocol — Workflow and Output Contract
+
+## Overview
+This document provides the detailed step-by-step workflow, decision tree, and output contract for the lead-to-cash-protocol skill. It is the authoritative reference for agent implementations and human reviewers who need to trace execution through the protocol.
+
+---
+
+## Detailed Step-by-Step Workflow
+
+### Phase 1 — Opportunity Qualification (d365-sales-revenue-operations-agent)
+
+**Step 1.1 — Receive and validate opportunity signal**
+- Confirm the opportunity record exists in Dynamics 365 Sales with a stage of "Qualified" or "Proposal Accepted".
+- Verify that an estimated revenue, close date, and primary contact are populated.
+- If the opportunity stage is earlier than "Qualified", stop and return to the prospect-to-quote process; do not advance.
+
+**Step 1.2 — Quote or purchase order confirmation**
+- Confirm that a signed customer quote (in Dynamics 365 Sales) or an accepted customer purchase order is on file.
+- Validate that pricing, discount bands, and delivery terms on the quote match the approved trade agreement or contract.
+- Any discount that exceeds the configured approval threshold must have a documented manager approval before advancing.
+
+**Step 1.3 — Revenue recognition pre-classification**
+- Identify whether the contract contains multiple performance obligations (ASC 606 / IFRS 15).
+- If contract complexity is detected (e.g., bundled products and services, milestone billing, variable consideration), flag for d365-finance-close-to-report-agent before order creation.
+- Document classification decision and evidence quality in the handoff capsule.
+
+---
+
+### Phase 2 — Credit and Order Gate (d365-finance-close-to-report-agent + human)
+
+**Step 2.1 — Credit check**
+- Query the customer's credit limit and current exposure in Dynamics 365 Finance.
+- If the order value plus existing open AR balance exceeds the credit limit, the protocol halts.
+- Produce a credit risk summary for the finance credit manager; do not override or assume approval.
+- Record the outcome (approved / denied / escalated) before proceeding.
+
+**Step 2.2 — Order accuracy review**
+- Compare line items, quantities, unit prices, delivery addresses, and tax codes on the draft sales order against the accepted quote.
+- Flag any discrepancy for human correction. Do not post an inaccurate order.
+- Confirm that the legal entity, currency, and applicable price list are correct.
+
+---
+
+### Phase 3 — Order Fulfillment (d365-supply-chain-plan-to-produce-agent)
+
+**Step 3.1 — Inventory availability check**
+- Query available-to-promise (ATP) data for each order line.
+- If ATP date is after the requested delivery date, surface the gap to the sales agent and human owner; propose alternatives but do not commit a delivery date unilaterally.
+
+**Step 3.2 — Order confirmation**
+- Confirm the sales order in Dynamics 365 Supply Chain Management once credit and order accuracy gates are passed.
+- Trigger warehouse picking and packing workflows.
+
+**Step 3.3 — Shipment and delivery note**
+- Monitor picking and packing completion.
+- Upon shipment, generate a packing slip / delivery note in the system.
+- Hand the packing slip reference and shipment date to d365-finance-close-to-report-agent.
+
+---
+
+### Phase 4 — Invoicing and Revenue Recognition (d365-finance-close-to-report-agent)
+
+**Step 4.1 — Invoice generation**
+- Create a sales order invoice in Dynamics 365 Finance based on the confirmed packing slip.
+- Validate that invoice lines match the packing slip quantities and the original sales order pricing.
+- Apply the correct revenue recognition schedule per the pre-classification in Step 1.3.
+
+**Step 4.2 — Invoice posting**
+- Human owner confirms invoice accuracy before posting if the invoice exceeds a configurable materiality threshold.
+- Post the invoice; accounts receivable entry is created.
+
+**Step 4.3 — Cash application and close**
+- Monitor customer payment receipt.
+- Apply cash to the open AR entry and settle the invoice.
+- Update opportunity status in Dynamics 365 Sales to "Closed Won" and record the final revenue amount.
+
+---
+
+## Decision Tree
+
+```
+START: Opportunity signal received
+│
+├─ Opportunity stage < Qualified?
+│   └─ YES → STOP; return to prospect-to-quote process
+│
+├─ Signed quote or accepted PO on file?
+│   └─ NO → STOP; escalate to d365-sales-revenue-operations-agent
+│
+├─ Discount within approval threshold?
+│   └─ NO → PAUSE; require documented manager approval
+│
+├─ Revenue recognition complexity detected?
+│   └─ YES → FLAG to d365-finance-close-to-report-agent before order creation
+│
+├─ Credit check passed?
+│   └─ NO → HALT; escalate to finance credit manager; do not proceed
+│
+├─ Order accuracy confirmed?
+│   └─ NO → RETURN to d365-sales-revenue-operations-agent for correction
+│
+├─ ATP date within requested delivery window?
+│   └─ NO → SURFACE gap to human owner; do not commit delivery date
+│
+├─ Invoice matches packing slip and order?
+│   └─ NO → HOLD posting; flag for human review
+│
+└─ Cash received and applied?
+    └─ YES → CLOSE revenue cycle; update opportunity to Closed Won
+```
+
+---
+
+## 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 lead-to-cash instance |
+| opportunity_id | string | Dynamics 365 Sales opportunity record ID |
+| sales_order_id | string | Confirmed sales order number |
+| current_stage | enum | One of: qualification, credit_check, order_confirmed, fulfillment, invoiced, closed |
+| gate_outcomes | object | Pass/fail/escalated for each gate: credit, order_accuracy, atp, invoice_match |
+| agents_involved | array | List of agent IDs that participated in this execution |
+| escalations | array | Each escalation: {trigger, timestamp, escalated_to, reason} |
+| open_questions | array | Any unresolved items requiring human input |
+| do_not_do_list | array | Actions explicitly prohibited in the current state |
+| evidence_quality | enum | high / medium / low — reflecting confidence in input data |
+| privilege_sensitivity | boolean | True if the matter contains legally sensitive commercial terms |
+| last_updated | ISO8601 timestamp | When the capsule was last updated |
+
+### Example output capsule (partial)
+```json
+{
+  "matter_id": "L2C-2026-001234",
+  "opportunity_id": "OPP-98765",
+  "sales_order_id": "SO-20260001",
+  "current_stage": "invoiced",
+  "gate_outcomes": {
+    "credit": "pass",
+    "order_accuracy": "pass",
+    "atp": "pass",
+    "invoice_match": "pass"
+  },
+  "agents_involved": [
+    "d365-sales-revenue-operations-agent",
+    "d365-supply-chain-plan-to-produce-agent",
+    "d365-finance-close-to-report-agent"
+  ],
+  "escalations": [],
+  "open_questions": [],
+  "do_not_do_list": [
+    "Do not adjust invoice amounts without human approval",
+    "Do not override credit limit without documented approval"
+  ],
+  "evidence_quality": "high",
+  "privilege_sensitivity": false,
+  "last_updated": "2026-06-16T10:30:00Z"
+}
+```
+
+---
+
+## Audit Log Fields
+- matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp

package/skills/cross-functional/license-to-value-protocol/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: license-to-value-protocol
+description: Use this skill when Microsoft 365 or Dynamics 365 licenses have been assigned and the organisation needs to measure adoption, instrument value outcomes, identify waste, and reclaim inactive licenses before purchasing more. Orchestrates microsoft-business-impact-value-realization-agent as primary. Gates include baseline definition before adoption target is set, and inactive-license reclaim before any new license purchase is recommended. Does not make purchase decisions or modify license assignments autonomously. Never requests credentials, tenant IDs, or customer data; production-impacting steps escalate to the licence owner or IT procurement team.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: finance
+  lifecycle: experimental
+---
+
+# License to Value Protocol
+
+## Purpose
+This skill defines how an organisation moves from license assignment through
+adoption instrumentation, value measurement, and proactive waste reclaim. It
+exists so licence investment is justified by measurable adoption outcomes, and
+so inactive or redundant licenses are identified and reclaimed before additional
+spend is approved. It does not make procurement decisions; it produces
+structured evidence that finance, IT, and business owners use to make
+well-informed decisions.
+
+## When to use
+- A Microsoft 365 or Dynamics 365 licence cohort has been deployed and adoption
+  measurement has not yet been established.
+- A periodic licence review is due and inactive-licence analysis is required.
+- Leadership needs a value realisation report to justify renewal or expansion.
+- A business unit has requested additional licences and the existing estate must
+  be reviewed for reclaim opportunities before purchase.
+- Adoption Score or Microsoft Viva Insights signals indicate low utilisation
+  in a licensed cohort.
+
+## When NOT to use
+- The matter is a licensing compliance audit with legal implications — route to
+  your software asset management (SAM) team and legal counsel.
+- The organisation has no telemetry access (Adoption Score, usage reports) —
+  prerequisites are not met; this protocol cannot produce evidence-based findings.
+- You need to execute license assignment changes in the Microsoft 365 admin
+  center — that requires the license owner; this protocol is recommendation-only.
+- The matter is a cost-management optimisation across non-Microsoft cloud spend
+  — use the appropriate FinOps protocol.
+
+## Participating agents
+- `microsoft-business-impact-value-realization-agent` (primary — adoption instrumentation, value measurement, inactive-licence identification, reclaim recommendation)
+
+## Inputs required
+- Microsoft 365 Adoption Score (current score and trend, per category including
+  AI adoption if Microsoft 365 Copilot is licensed)
+- Microsoft 365 Copilot usage report (if applicable)
+- Assigned licence count vs. active user count per SKU
+- Business outcomes or KPIs the licence cohort was intended to drive
+- Inactive user threshold (days without activity) agreed with the business
+
+## Evidence required
+- Microsoft 365 admin center access is available to the licence owner
+- Adoption Score reporting is enabled (not in GCC High/GCC/DOD tenants where
+  Adoption Score is unavailable)
+- Usage reports are enabled and privacy controls allow aggregate analysis
+- An agreed inactive-user threshold exists (e.g. 30 days without any activity)
+- A licence owner (IT or procurement contact) is identified
+
+## Workflow
+
+1. **Baseline definition** — Establish the adoption baseline: current Adoption
+   Score per category, licensed user count, active user count, and the business
+   KPIs the deployment was intended to drive. Document the baseline date.
+2. **Gate 1 — Baseline defined** — Do not set adoption targets until a baseline
+   exists. microsoft-business-impact-value-realization-agent attests baseline
+   completeness. If baseline data is unavailable, stop and require the licence
+   owner to enable reporting before proceeding.
+3. **Adoption target setting** — Based on the baseline and peer benchmarks
+   (Adoption Score peer benchmark), set time-bound adoption targets per user
+   cohort and per value category (Communication, Meetings, Content
+   Collaboration, AI Adoption, etc.).
+4. **Value instrumentation** — Map Adoption Score signals and Copilot usage
+   metrics to the organisation's stated business outcomes. Identify which
+   metrics are leading indicators of value (e.g. AI Adoption Score ≥ 66 signals
+   users on track for three-day weekly habit).
+5. **Inactive licence identification** — Using usage reports and agreed
+   inactive-user thresholds, identify users who have not performed any licensed
+   activity within the threshold period. Segment by SKU, department, and
+   licence tier.
+6. **Gate 2 — Inactive-licence reclaim before purchase** — Before recommending
+   any new licence purchase, confirm that inactive licences have been reviewed
+   and a reclaim decision has been made by the licence owner. Do not recommend
+   purchase without this gate.
+7. **Reclaim recommendation** — For inactive licences: recommend suspension,
+   downgrade, or reassignment. Provide estimated cost saving. Route recommendation
+   to licence owner for confirmation.
+8. **Value realisation report** — Produce a value realisation summary: adoption
+   progress vs. targets, value category scores, estimated productivity impact,
+   reclaim savings, and recommended next actions.
+9. **Renewal / expansion recommendation** — If adoption targets are met and
+   inactive licences are remediated, produce a data-supported expansion or
+   renewal recommendation. If adoption targets are not met, recommend an
+   adoption intervention before expansion.
+10. **Human confirmation** — Route all purchase, reclaim, and adoption
+    intervention recommendations to the licence owner, IT procurement, and
+    finance team. This protocol never executes licence changes autonomously.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Baseline defined | No adoption baseline exists | Stop; require licence owner to enable reporting |
+| Inactive-licence reclaim | Inactive licences not reviewed before purchase request | Block purchase recommendation; complete reclaim review first |
+| Adoption target not met | Adoption Score below peer benchmark with no improvement trend | Recommend adoption intervention before expansion |
+| Reporting unavailable | Adoption Score or usage reports disabled | Stop; flag as prerequisite gap to licence owner |
+
+## Refusal triggers
+- Stop if adoption baseline data does not exist — do not produce value
+  recommendations based on anecdote or assumption.
+- Stop if a purchase recommendation is requested without first completing the
+  inactive-licence reclaim gate.
+- Stop if credentials, tenant IDs, or individual-level user data are requested
+  — this protocol works with aggregate and anonymised signals only.
+- Stop if the organisation is in a tenant type where Adoption Score is
+  unavailable (GCC High, GCC, DoD) without an alternative telemetry source
+  agreed with the licence owner.
+
+## Handoff rules
+- All handoffs carry: licence_cohort_scope, skill_id, skill_version,
+  invoked_by, baseline_date, gate_status, open_questions, do_not_do_list.
+- Reclaim recommendations always include the inactive threshold used, the
+  review date, and the licence owner who confirmed the threshold.
+- Purchase recommendations are never produced without the inactive-reclaim gate
+  sign-off attached.
+
+## KPIs
+- Microsoft 365 Adoption Score (overall and per category)
+- Copilot AI Adoption Score (if Microsoft 365 Copilot licensed)
+- Active user rate (active / assigned licences per SKU)
+- Inactive licence count and estimated annualised waste
+- Time from licence assignment to adoption baseline establishment
+
+## References
+- https://learn.microsoft.com/microsoft-365/admin/adoption/adoption-score
+- https://learn.microsoft.com/microsoft-365/admin/adoption/ai-adoption-score
+- https://learn.microsoft.com/microsoft-365/copilot/microsoft-365-copilot-licensing
+- https://learn.microsoft.com/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage
+- https://learn.microsoft.com/microsoft-365/copilot/microsoft-365-copilot-enablement-resources

package/skills/cross-functional/license-to-value-protocol/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "license-to-value-protocol",
+  "name": "License to Value Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Adoption-to-value protocol for Microsoft 365 and Dynamics 365 licence estates. Establishes an adoption baseline, instruments value via Microsoft Adoption Score and Copilot usage reports, identifies inactive licences, and produces a reclaim recommendation before any expansion purchase is approved. Gate: inactive-licence reclaim must be reviewed before new licences are purchased. All purchase, reclaim, and adoption intervention recommendations require licence owner, IT procurement, and finance sign-off; this protocol never executes licence changes autonomously.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/microsoft-365/admin/adoption/adoption-score",
+    "https://learn.microsoft.com/microsoft-365/admin/adoption/ai-adoption-score",
+    "https://learn.microsoft.com/microsoft-365/copilot/microsoft-365-copilot-licensing",
+    "https://learn.microsoft.com/microsoft-365/admin/activity-reports/microsoft-365-copilot-usage",
+    "https://learn.microsoft.com/microsoft-365/copilot/microsoft-365-copilot-enablement-resources"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration aid only; it is never an authorisation to purchase, assign, suspend, or reclaim licences. It never requests credentials, tenant IDs, individual-level user activity data, or customer PII; all analysis is based on aggregate and anonymised signals from Microsoft 365 Adoption Score and usage reports. Recommending additional licence purchases without first completing the inactive-licence reclaim gate is refused. Adoption baseline data is a prerequisite; value recommendations must not be based on anecdote or assumption. Organisations in tenant types where Adoption Score is unavailable (GCC High, GCC, DoD) require an alternative telemetry source agreed with the licence owner before this protocol proceeds. All reclaim, purchase, and adoption intervention recommendations are routed to the licence owner, IT procurement, and finance team for human confirmation.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/license-to-value-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}