@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/cross-functional/license-to-value-protocol/references/workflow-and-output.md

@@ -0,0 +1,283 @@
+# License to Value Protocol — Workflow and Output Contract
+
+## Detailed Workflow
+
+### Phase 1: Baseline Definition
+
+**Trigger events**
+- A new Microsoft 365 or Dynamics 365 licence cohort has been deployed
+- A periodic licence review has been scheduled
+- Leadership has requested a value realisation report
+- A business unit has submitted a request for additional licences
+
+**Step 1.1 — Licence inventory**
+Collect the current licence inventory:
+- SKU name and total assigned count
+- Active user count per SKU (users who performed at least one licensed activity
+  in the past 28 days)
+- Licence type (user, device, add-on, Copilot)
+- Cohort or department (if licence tracking is segmented)
+
+**Step 1.2 — Adoption Score baseline**
+Retrieve the Microsoft 365 Adoption Score from the Microsoft 365 admin center:
+- Overall score (and maximum possible)
+- Per-category score: Communication, Meetings, Content Collaboration, Teamwork,
+  Mobility, AI Adoption (if Microsoft 365 Copilot is licensed)
+- Peer benchmark comparison
+- Score trend (28-day, 90-day, 180-day)
+
+If Adoption Score is unavailable (GCC High, GCC, DoD tenants, or reporting
+not enabled): stop. Require the licence owner to enable reporting or identify
+an alternative telemetry source before this protocol proceeds.
+
+**Step 1.3 — Copilot usage baseline (if applicable)**
+If Microsoft 365 Copilot licences are assigned, retrieve the Microsoft 365
+Copilot usage report:
+- Active users count (users who used Copilot on at least one day in the period)
+- Daily active users trend
+- Usage by application (Outlook, Teams, Word, PowerPoint, Excel, OneNote,
+  Copilot Chat, Loop)
+- AI Adoption Score
+
+**Step 1.4 — Business KPI mapping**
+Identify the business outcomes the licence cohort was intended to drive:
+- Example: "Reduce email volume by 20% via Teams migration"
+- Example: "Enable 100% of knowledge workers to use Copilot for meeting
+  summaries within 90 days"
+Map each business KPI to the relevant Adoption Score category or Copilot
+usage signal.
+
+**Step 1.5 — Baseline documentation**
+Document the baseline: date, licence counts, Adoption Score per category,
+Copilot usage if applicable, and business KPI starting values.
+
+---
+
+### Phase 2: Gate 1 — Baseline Defined
+
+**Required confirmation:**
+- microsoft-business-impact-value-realization-agent attests that:
+  - Adoption Score data is available and current
+  - Licence inventory is documented
+  - At least one business KPI is mapped to a measurable signal
+  - Baseline date is recorded
+
+If baseline data is unavailable: stop. Do not set adoption targets or produce
+value recommendations without a defined baseline.
+
+---
+
+### Phase 3: Adoption Target Setting
+
+**Step 3.1 — Peer benchmark review**
+Review the Adoption Score peer benchmark (organisations of similar size, region,
+industry, and tenure with Microsoft 365). Identify categories where the
+organisation is below the peer benchmark — these are the highest-value
+improvement opportunities.
+
+**Step 3.2 — AI Adoption target**
+For Copilot-licensed cohorts, the AI Adoption Score benchmark is that all
+licensed users achieve an average of at least three Copilot-active days per week
+(score of 100). Set a realistic time-bound target based on the baseline:
+- Example: "AI Adoption Score from 33 to 66 within 90 days" (one day/week to
+  two days/week habit formation)
+
+**Step 3.3 — Category targets**
+For each Adoption Score category below peer benchmark, set a time-bound target.
+Targets must be:
+- Specific (which category)
+- Measurable (target score or percentage)
+- Time-bound (by what date)
+- Owned by a named business or IT lead
+
+---
+
+### Phase 4: Value Instrumentation
+
+**Step 4.1 — Leading indicator mapping**
+Map Adoption Score and Copilot usage signals to business outcomes:
+
+| Business KPI | Adoption Score signal | Copilot usage signal |
+|---|---|---|
+| Meeting efficiency | Meetings score | Copilot meeting summary adoption |
+| Email reduction | Communication score | Copilot Outlook usage |
+| Document collaboration | Content Collaboration score | Copilot Word/PowerPoint usage |
+| Knowledge worker productivity | AI Adoption Score | Active Copilot days per user |
+
+**Step 4.2 — Forrester research anchoring**
+Reference Forrester research anchored in the Adoption Score framework:
+content collaboration in the cloud vs. email attachments can save up to 100
+minutes per user per week. Use such benchmarks to estimate productivity impact
+from adoption improvement.
+
+---
+
+### Phase 5: Inactive Licence Identification
+
+**Step 5.1 — Inactive user threshold agreement**
+Confirm the inactive user threshold with the licence owner (e.g. no licensed
+activity in 30 days). Document the agreed threshold and date.
+
+**Step 5.2 — Inactive user identification**
+Using Microsoft 365 usage reports, identify users who have not performed any
+licensed activity within the agreed threshold period. Segment by:
+- SKU (Microsoft 365 E3, E5, Copilot, Dynamics 365, etc.)
+- Department or cohort
+- Last activity date
+
+**Step 5.3 — Inactive licence classification**
+Classify inactive licences:
+- Confirmed inactive: no activity in threshold period, no known business
+  justification for dormancy
+- Pending review: no activity but a business justification is possible
+  (e.g. parental leave, project pause)
+- Candidate for reclaim: confirmed inactive with no blocking justification
+
+**Step 5.4 — Estimated waste calculation**
+For each confirmed inactive licence: calculate estimated annualised licence cost.
+This is the reclaim opportunity. Present to the licence owner as a cost-saving
+recommendation.
+
+---
+
+### Phase 6: Gate 2 — Inactive-Licence Reclaim Before Purchase
+
+**Required confirmation:**
+- If a purchase request is active: block the purchase recommendation until
+  inactive-licence reclaim has been reviewed.
+- Licence owner confirms the reclaim decision for each inactive cohort:
+  - Suspend: remove licence assignment immediately
+  - Downgrade: move to a lower-tier SKU
+  - Reassign: transfer to a new user with an active business need
+  - Retain: confirmed business justification for dormancy
+
+If this gate is not completed before a purchase recommendation is made: refuse
+the purchase recommendation and require gate completion first.
+
+---
+
+### Phase 7: Reclaim Recommendation
+
+Produce the reclaim recommendation:
+- List of users recommended for suspension, downgrade, or reassignment
+- Estimated annualised saving
+- Recommended action per user cohort
+- Route to the licence owner for confirmation (this protocol never executes
+  licence assignment changes autonomously)
+
+---
+
+### Phase 8: Value Realisation Report
+
+Produce the value realisation summary:
+
+| Section | Content |
+|---|---|
+| Baseline summary | Date, licence counts, Adoption Score at baseline |
+| Current state | Current Adoption Score per category vs. targets |
+| Progress vs. targets | Delta per category, trend direction |
+| AI Adoption (Copilot) | Current AI Adoption Score, active user rate, usage by app |
+| Estimated productivity impact | Based on Adoption Score improvement and Forrester benchmarks |
+| Inactive licences | Count, estimated annualised waste, reclaim decisions |
+| Reclaim savings | Confirmed savings from completed reclaim actions |
+| Recommended next actions | Adoption interventions, reclaim actions, purchase decisions |
+
+---
+
+### Phase 9: Renewal / Expansion Recommendation
+
+**If adoption targets are met and inactive licences are remediated:**
+Produce a data-supported expansion or renewal recommendation with:
+- Evidence: Adoption Score at or above peer benchmark, active user rate,
+  business KPI progress
+- Scope: which SKUs and how many additional licences
+- Gate 2 status: confirmed that inactive reclaim is complete
+
+**If adoption targets are not met:**
+Recommend an adoption intervention programme before expansion:
+- Targeted training or enablement for low-adoption cohorts
+- Copilot success kit deployment (where applicable)
+- Re-evaluation at the next review cycle
+
+---
+
+### Phase 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, purchase orders, or adoption programmes autonomously.
+
+---
+
+## Decision Tree
+
+```
+Licence review triggered
+  └── Adoption Score data available?
+        ├── No  → Stop; require licence owner to enable reporting
+        └── Yes → Baseline documented?
+                    ├── No  → Document baseline (Gate 1)
+                    └── Yes → Inactive-licence threshold agreed?
+                                ├── No  → Agree threshold with licence owner
+                                └── Yes → Inactive licences identified?
+                                            └── Purchase request active?
+                                                  ├── Yes → Gate 2: reclaim review required before purchase
+                                                  │          └── Reclaim decisions confirmed?
+                                                  │                ├── No  → Block purchase recommendation
+                                                  │                └── Yes → Purchase recommendation (with reclaim savings offset)
+                                                  └── No  → Adoption targets met?
+                                                                ├── Yes → Value realisation report; renewal/expansion recommendation
+                                                                └── No  → Adoption intervention recommendation; next review cycle
+```
+
+---
+
+## Output Contract
+
+### Licence review record
+| Field | Type | Description |
+|---|---|---|
+| licence_cohort_scope | string | SKU or user group assessed |
+| skill_id | string | `license-to-value-protocol` |
+| skill_version | string | `0.1.0` |
+| invoked_by | string | Agent or human who invoked this protocol |
+| baseline_date | ISO 8601 | Date baseline was established |
+| adoption_score_overall | float | Overall Adoption Score at assessment |
+| ai_adoption_score | float or null | AI Adoption Score (null if no Copilot licences) |
+| active_user_rate | float | Active users / assigned licences |
+| inactive_licence_count | integer | Licences confirmed inactive |
+| estimated_annualised_waste | number | Estimated cost of inactive licences |
+| gate_1_baseline_defined | boolean | Whether Gate 1 is confirmed |
+| gate_2_reclaim_reviewed | boolean | Whether Gate 2 is confirmed |
+| reclaim_recommendation | enum | suspend / downgrade / reassign / retain / pending |
+| value_recommendation | enum | expand / renew / intervene / hold |
+| open_questions | array | Unresolved questions |
+| do_not_do_list | array | Actions excluded from this protocol's scope |
+| timestamp | ISO 8601 | Protocol execution timestamp |
+
+### Gate verdicts
+| Gate | Verdict options |
+|---|---|
+| Baseline defined (Gate 1) | confirmed / not-confirmed |
+| Inactive-licence reclaim before purchase (Gate 2) | confirmed / not-confirmed |
+
+### Refusal record (when triggered)
+| Field | Description |
+|---|---|
+| refusal_reason | Which refusal trigger was hit |
+| escalation_target | Licence owner / IT procurement / finance |
+| timestamp | ISO 8601 |
+
+---
+
+## Quality Assurance Notes
+- This protocol never executes licence assignment changes, purchase orders, or
+  adoption programme deployments. All actions require human licence owner,
+  IT procurement, and finance sign-off.
+- Purchase recommendations without Gate 2 (inactive-licence reclaim) sign-off
+  are refused unconditionally.
+- All analysis is based on aggregate and anonymised signals. Individual-level
+  user activity data requires privacy-team approval before use.
+- Adoption Score is unavailable in GCC High, GCC, and DoD tenants. In those
+  environments, an alternative aggregate telemetry source must be agreed with
+  the licence owner before this protocol proceeds.

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

@@ -0,0 +1,95 @@
+---
+name: order-to-cash-protocol
+description: Use this skill to coordinate the order-to-cash process across Dynamics 365 Supply Chain Management, Finance, and Sales, covering confirmed order through fulfillment, invoicing, accounts receivable, and cash collection. It defines stage ownership, gate conditions, agent handoff rules, and escalation triggers for the post-order revenue cycle. The skill does not execute system transactions, approve credit changes, post invoices, or make collection decisions; all production-impacting steps are escalated to the relevant specialist agent or human owner.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+  lifecycle: experimental
+---
+
+# Order-to-Cash Protocol
+
+## Purpose
+This skill coordinates the order-to-cash (O2C) end-to-end process in Microsoft Dynamics 365 environments. Starting from a confirmed sales order, it orchestrates order management, inventory fulfillment, shipment, invoicing, accounts receivable, and cash collection. The protocol aligns d365-supply-chain-plan-to-produce-agent (fulfillment), d365-finance-close-to-report-agent (invoicing and AR), and d365-sales-revenue-operations-agent (sales performance and customer communication). It does not give business or financial advice; all recommendations are subject to human owner confirmation.
+
+## When to use
+- A confirmed sales order must progress through fulfillment, invoicing, and payment collection.
+- Multiple Dynamics 365 modules are involved and cross-agent coordination is required.
+- An accounts receivable aging item needs coordinated follow-up between Sales and Finance.
+- A return, credit memo, or dispute requires orchestrated handling across Supply Chain and Finance.
+- A post-order cash flow analysis or DSO escalation requires cross-domain visibility.
+
+## When NOT to use
+- The opportunity has not yet been converted to a confirmed order — use the lead-to-cash-protocol or prospect-to-quote process instead.
+- The matter is confined entirely to accounts payable or procurement — use procure-to-pay-protocol.
+- Direct live-order configuration or system transaction execution is required — escalate to the relevant specialist.
+- The matter involves revenue recognition complexity at contract inception — use lead-to-cash-protocol first.
+
+## Participating agents
+- d365-supply-chain-plan-to-produce-agent — owns order fulfillment, picking, packing, and shipment
+- d365-finance-close-to-report-agent — owns invoicing, accounts receivable, collections, and cash application
+- d365-sales-revenue-operations-agent — owns sales order policies, customer communication, and sales performance analysis
+
+## Inputs required
+- Confirmed sales order number and legal entity
+- Customer account and credit status
+- Requested and promised delivery date
+- Pricing and discount terms from the sales order
+- Accounts receivable payment terms for the customer
+
+## Evidence required
+- Sales order confirmation record from Dynamics 365 Supply Chain Management
+- Available-to-promise (ATP) or inventory reservation confirmation
+- Packing slip or delivery note reference
+- Invoice draft for accuracy review before posting
+- Payment receipt or remittance advice for cash application
+
+## Workflow
+1. Receive confirmed sales order from d365-sales-revenue-operations-agent or directly from the order management system.
+2. Verify order accuracy: line items, pricing, quantities, and delivery terms match the original customer agreement.
+3. Check customer credit status; if credit is on hold, escalate to d365-finance-close-to-report-agent and finance owner.
+4. Trigger inventory reservation and ATP confirmation via d365-supply-chain-plan-to-produce-agent.
+5. Monitor warehouse picking, packing, and shipment workflows; flag delays against committed delivery dates.
+6. Generate packing slip upon confirmed shipment; hand off to d365-finance-close-to-report-agent.
+7. Create and validate sales invoice against packing slip and sales order; surface discrepancies for human resolution.
+8. Post invoice and open accounts receivable entry in Dynamics 365 Finance.
+9. Monitor payment due dates; trigger collection activities per the customer's payment terms.
+10. Apply received cash to open invoices and close accounts receivable entries; update sales performance reporting.
+
+## Decision gates
+| Gate | Condition | Action if not met |
+|---|---|---|
+| Credit status | Customer account not on credit hold | Escalate to d365-finance-close-to-report-agent and finance credit manager |
+| Order accuracy | Lines, prices, and terms match customer agreement | Return to d365-sales-revenue-operations-agent for correction |
+| ATP confirmation | Stock reserved or ATP date within delivery window | Notify supply chain agent; surface gap to human owner |
+| Invoice accuracy | Invoice matches packing slip and sales order | Hold posting; flag for human review |
+| Collections escalation | Payment overdue beyond configurable threshold | Escalate to finance collections owner |
+
+## Refusal triggers
+- Live transaction execution is requested without human confirmation — refuse and escalate.
+- Credit hold override is requested without documented approval — refuse.
+- Customer PII, payment details, or bank account data are present in any input — stop; redact and escalate.
+- An invoice is requested to be posted with unresolved line discrepancies — refuse.
+- A write-off or bad-debt decision is requested — escalate to finance owner; do not decide unilaterally.
+
+## Handoff rules
+- Each handoff carries a structured capsule: matter_id, sales_order_id, current_stage, gate_outcomes, open_questions, do_not_do_list.
+- One primary agent per stage: Supply Chain owns fulfillment; Finance owns invoicing and collections; Sales owns customer communication.
+- No agent posts or reverses a financial transaction — all postings require human confirmation above materiality threshold.
+- Escalations are logged with trigger, timestamp, and receiving owner.
+
+## KPIs
+- Order fulfillment cycle time (order confirmation to shipment)
+- Invoice accuracy rate (first-pass match to packing slip)
+- Days sales outstanding (DSO)
+- Cash application rate (% of invoices settled within payment terms)
+- Collection effectiveness index (CEI)
+
+## References
+- [Order to cash end-to-end overview — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-overview)
+- [Order to cash business process areas overview](https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-areas-overview)
+- [Manage accounts receivable — Dynamics 365 Finance](https://learn.microsoft.com/dynamics365/guidance/business-processes/order-to-cash-areas-overview#manage-accounts-receivable)
+- [Work with order to cash in Dynamics 365 Supply Chain Management (training)](https://learn.microsoft.com/training/modules/work-with-order-to-cash-supply-chain-management/)

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

@@ -0,0 +1,19 @@
+{
+  "id": "order-to-cash-protocol",
+  "name": "Order-to-Cash Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Orchestration protocol for the order-to-cash process in Dynamics 365 environments, coordinating Supply Chain Management (order fulfillment and shipment), Finance (invoicing, accounts receivable, and collections), and Sales (customer communication and sales performance). Defines stage gates for credit, order accuracy, ATP, invoice match, and collections escalation, with structured handoff capsules between d365-supply-chain-plan-to-produce-agent, d365-finance-close-to-report-agent, and d365-sales-revenue-operations-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/order-to-cash-areas-overview",
+    "https://learn.microsoft.com/training/modules/work-with-order-to-cash-supply-chain-management/"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration guide only — it is never an authorization to post invoices, override credit holds, apply cash, or execute live system transactions. All production-impacting steps require confirmation by the relevant human owner or specialist agent. The protocol never requests customer PII, payment card data, bank account information, tenant IDs, or Dynamics 365 credentials. Write-off and bad-debt decisions are always escalated to the finance owner and never resolved by an agent unilaterally. Collections actions follow configured payment terms and escalation thresholds; no agent contacts customers directly.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/order-to-cash-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.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"
+}