@raishin/vanguard-frontier-agentic 2.9.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/netsuite-routing-protocol/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: netsuite-routing-protocol
+description: Use this skill when a NetSuite matter must be classified and routed to the right specialist agent, when a matter crosses multiple NetSuite domains and needs parallel review, when a live-account mutation intent must be gated, or when specialist agents disagree and the conflict must be resolved. It defines routing rules per matter type, the cross-domain overlap matrix covering finance × developer × identity × integration × analytics × OneWorld × AI-connector × compliance, and the conflict-resolution protocol. Does not give NetSuite or business advice; routing is a recommendation only and never makes a binding routing decision on behalf of a human owner.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-09"
+  category: platform
+  lifecycle: experimental
+---
+
+# NetSuite Routing Protocol
+
+## Purpose
+This skill defines how a NetSuite matter is classified, routed to the right
+specialist agent, and coordinated when it crosses multiple NetSuite domains. It
+exists so agents never work in silos when risk crosses a domain boundary, and so
+every handoff is controlled and auditable rather than free-form. It does not give
+NetSuite or business advice; routing is a recommendation that a human owner
+confirms.
+
+## When to use
+- The `netsuite-maestro-agent` must classify an incoming NetSuite matter and dispatch it.
+- A specialist agent finds a matter has crossed into another NetSuite domain.
+- A matter triggers an escalation gate and must be paused.
+- Specialist agents reach conflicting recommendations.
+- A matter is ambiguous and cannot be confidently assigned to a single domain.
+
+## When not to use
+- The matter is already classified and a specialist agent is actively working it.
+- The matter is outside NetSuite scope entirely.
+- You need direct live-account mutation handling — that is owned by
+  `netsuite-live-org-mutation-guard-agent`, not this routing skill.
+
+## Communication principles
+- One accountable human owner per matter. One primary agent per matter.
+- Parallel review only when the matter genuinely crosses domains.
+- No agent makes a final configuration, deployment, posting, period-close,
+  or compliance decision.
+- Every high-risk cross-domain matter produces a **pause and escalate**
+  recommendation unless sufficient documented controls already exist.
+- Every agent defaults to least-privilege access (never the Administrator role)
+  and minimum-necessary, sanitized data.
+
+## Routing rules
+
+### Governance / evidence / release drift
+Evidence labelling, release-sensitive claims, biannual NetSuite release drift →
+**netsuite-evidence-release-drift-agent**.
+
+### Enterprise architecture
+Multi-account/OneWorld topology, solution design, platform strategy →
+**netsuite-enterprise-architecture-agent**.
+
+### Audit / SOX / financial controls
+Segregation of duties, posting, period close, revenue recognition, approval
+workflows, audit trail → **netsuite-audit-controls-sox-agent**.
+
+### Foundation / administration / consulting
+SuiteFoundation setup, administration, ERP consulting and configuration →
+**netsuite-suitefoundation-agent**, **netsuite-administrator-agent**, or
+**netsuite-erp-consultant-agent**.
+
+### Finance
+Financial setup, AP/AR, accounting configuration →
+**netsuite-financial-foundations-agent** (escalate close-impacting items to
+audit-controls-sox).
+
+### BI / reporting / saved searches
+Reports, dashboards, KPIs, data-source semantics →
+**netsuite-bi-reporting-agent**; saved search and SuiteAnalytics Workbook
+mechanics, PII-in-export → **netsuite-saved-searches-workbook-agent**.
+
+### Development
+SuiteScript records and UIF/SPA → **netsuite-application-developer-agent**;
+SDF and SuiteScript upgrade → **netsuite-suitecloud-developer-agent**; static
+SuiteScript security review → **netsuite-suitescript-secure-code-review-agent**;
+SuiteFlow workflow review → **netsuite-suiteflow-automation-agent**.
+
+### Identity / access / auth
+Roles, permissions, segregation of duties → **netsuite-identity-access-role-permission-agent**;
+OAuth 2.0 / TBA / SSO / SAML authentication → **netsuite-sso-oauth-tba-agent**.
+
+### Integration
+SuiteTalk REST/SOAP record APIs → **netsuite-web-services-integration-agent**;
+end-to-end integration architecture and SOAP→REST migration →
+**netsuite-integration-migration-agent**.
+
+### OneWorld / multi-subsidiary
+Subsidiary, currency, tax jurisdiction, legal entity, intercompany boundaries →
+**netsuite-oneworld-multisubsidiary-agent**.
+
+### Data governance / privacy
+PII exposure, retention, field-level access, export controls →
+**netsuite-data-governance-privacy-agent**.
+
+### AI Connector / MCP
+AI Connector and MCP governance, tool allowlists, prompt-injection testing →
+**netsuite-ai-connector-mcp-agent**.
+
+### Sandbox / non-production governance
+Sandbox vs release-preview vs production separation, sandbox OAuth
+re-authorization → **netsuite-sandbox-nonproduction-governance-agent**.
+
+### SDF / DevOps / release
+SuiteCloud Development Framework project structure, deployment controls,
+environment promotion → **netsuite-sdf-devops-release-agent**.
+
+## Cross-domain overlap matrix
+
+| Overlap scenario | Primary agent | Secondary agents | Escalation gate |
+|---|---|---|---|
+| Saved search exposes cross-subsidiary data | netsuite-saved-searches-workbook-agent | netsuite-oneworld-multisubsidiary-agent, netsuite-data-governance-privacy-agent | cross-subsidiary-data |
+| SuiteScript change + auth/secret handling | netsuite-suitescript-secure-code-review-agent | netsuite-sso-oauth-tba-agent | production-data |
+| AI Connector tool scope + permissions | netsuite-ai-connector-mcp-agent | netsuite-identity-access-role-permission-agent | autonomous-AI-action |
+| Role change + segregation of duties | netsuite-identity-access-role-permission-agent | netsuite-audit-controls-sox-agent | segregation-of-duties |
+| SDF deploy + live mutation | netsuite-sdf-devops-release-agent | netsuite-live-org-mutation-guard-agent | irreversible-deploy |
+| SOAP integration + migration timeline | netsuite-integration-migration-agent | netsuite-web-services-integration-agent | soap-deprecation |
+| Reporting logic + period close impact | netsuite-bi-reporting-agent | netsuite-audit-controls-sox-agent | finance/revenue |
+
+## Conflict-resolution protocol
+When specialist agents disagree, follow this order and stop at the first unmet step:
+1. Freeze any irreversible action.
+2. Preserve evidence; preserve sandbox state if applicable.
+3. State the disagreement precisely — what each agent concluded and why.
+4. Separate technical risk from financial/operational risk; do not collapse them.
+5. Identify the accountable human owner.
+6. Escalate to a qualified NetSuite architect or control owner.
+7. Document unresolved assumptions and open questions.
+8. Produce options, not a single conclusion.
+9. Require human approval before any action.
+10. Log the decision path in the audit log.
+
+## Security notes
+- Routing is a recommendation, never an authorization. The protocol never
+  approves, denies, or directs a deployment, posting, or configuration action.
+- A matter is routed on sanitized signals. Never request account credentials,
+  tokens, the Administrator role, customer PII, or production account IDs to classify.
+- When classification is ambiguous, mark the matter `unclassified` rather than guessing.
+- This protocol does not authorize live-account mutations; those route to
+  `netsuite-live-org-mutation-guard-agent`.
+
+## Audit log fields
+- matter_id, agent_id, agent_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp
+
+## Stop conditions
+- A live-mutation action is requested — stop and route to netsuite-live-org-mutation-guard-agent.
+- Classification requires production account credentials — stop and refuse.
+- Matter involves regulated personal data and jurisdiction is unknown — stop and escalate.

package/skills/cross-functional/netsuite-routing-protocol/metadata.json

@@ -0,0 +1,18 @@
+{
+  "id": "netsuite-routing-protocol",
+  "name": "NetSuite Routing Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Classification and routing discipline for NetSuite matters — routing rules per matter type, the cross-domain overlap matrix (finance × developer × identity × integration × analytics × OneWorld × AI-connector × compliance), and the conflict-resolution protocol. Does not give NetSuite or business advice; routing is a recommendation only.",
+  "source_type": "original",
+  "official_docs": [
+    "https://www.netsuite.com/portal/services/training/suite-training/netsuite-certification.shtml",
+    "https://docs.oracle.com/en/cloud/saas/netsuite/index.html"
+  ],
+  "security_notes": "Routing is a recommendation, never an authorization; never approves, denies, or directs deployment, posting, or configuration actions. Classifies matters from sanitized signals only and never requests account credentials, tokens, the Administrator role, or production account IDs.",
+  "last_verified": "2026-06-09",
+  "path": "skills/cross-functional/netsuite-routing-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

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"
+}