@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/audit-evidence-mapping-protocol/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "audit-evidence-mapping-protocol",
+  "name": "Audit Evidence Mapping Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Maps compliance controls to audit evidence artifacts across Microsoft 365 workloads, verifies retention and legal-hold status against Microsoft Purview policy, identifies evidence gaps before the audit window opens, and assembles a signed-off attestation package. Covers Audit Standard and Audit Premium retention tiers (180 days, 1 year, 10 years with add-on), eDiscovery legal-hold verification, and privilege and privacy sensitivity labeling of the evidence package.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/purview/audit-solutions-overview",
+    "https://learn.microsoft.com/purview/audit-log-retention-policies",
+    "https://learn.microsoft.com/en-us/purview/ediscovery",
+    "https://learn.microsoft.com/en-us/purview/data-lifecycle-management"
+  ],
+  "security_notes": "Protocol is recommendation and orchestration only — never an authorization to release evidence to external parties or to modify retention policies, legal holds, or eDiscovery cases. All production-impacting steps (retention policy changes, legal-hold placement, evidence transmission to external auditors) must be escalated to the Purview compliance administrator and the human legal or compliance owner. Never requests credentials, tenant IDs, session tokens, or customer personal data to perform evidence discovery; works from sanitized control and workload scope signals only. Evidence touching legally privileged communications is flagged and routed to legal counsel before inclusion in any package. Special-category personal data triggers a jurisdiction confirmation gate before proceeding.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/audit-evidence-mapping-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/audit-evidence-mapping-protocol/references/workflow-and-output.md

@@ -0,0 +1,194 @@
+# Audit Evidence Mapping Protocol — Detailed Workflow and Output Contract
+
+## Overview
+
+This document provides the step-by-step workflow, decision tree, and output contract for the `audit-evidence-mapping-protocol` skill. It is intended for orchestrating agents and human compliance owners who need to understand how evidence mapping proceeds, where gates fire, and what the deliverable looks like.
+
+---
+
+## Detailed Workflow
+
+### Phase 1 — Scope and Ingest
+
+**Step 1.1 — Receive control framework**
+- Input: control IDs, framework name (ISO 27001, SOC 2 Type II, NIST CSF, internal), and control description
+- Action: normalize control IDs to a canonical internal format
+- Output: `control_register[]` with fields: `control_id`, `control_description`, `workload_hint`, `evidence_type_hint`
+
+**Step 1.2 — Confirm workload scope**
+- Input: list of Microsoft 365 services and Dynamics 365 / Power Platform environments in scope
+- Check: confirm Microsoft Purview licensing tier for each workload
+  - Audit Standard: 180-day default retention (as of October 17, 2023)
+  - Audit Premium (E5 or Purview Suite): 1-year default retention for Entra ID, Exchange, SharePoint, OneDrive
+  - Audit Premium + 10-year add-on: up to 10-year retention with explicit policy
+- Output: `workload_scope[]` with `service`, `environment_id`, `audit_tier`, `default_retention_days`
+
+**Step 1.3 — Load retention policy inventory**
+- Source: Microsoft Purview Audit log retention policies (exported summary, not live query requiring credentials)
+- Action: match each workload to its applicable custom retention policy; fall back to licensing default
+- Output: `retention_policy_map[]` with `workload`, `policy_name`, `retention_days`, `priority`
+
+---
+
+### Phase 2 — Evidence Discovery
+
+**Step 2.1 — Map controls to evidence artifacts**
+For each control in `control_register[]`:
+- Identify the primary evidence type:
+  - Audit log entry (Purview Unified Audit Log)
+  - Configuration export (Power Platform DLP policy, Entra ID Conditional Access policy)
+  - Access review record (Entra ID Access Reviews)
+  - Policy document or runbook (SharePoint)
+  - Dataverse / Dynamics 365 audit trail entry
+- Record: `evidence_artifact[]` with `control_id`, `artifact_type`, `source_workload`, `location_hint`, `expected_retention_required`
+
+**Step 2.2 — Verify evidence availability**
+- For each artifact: confirm whether the artifact exists within the retention window
+- Flag: `evidence_status` = `complete` | `partial` | `missing` | `retention_expired`
+
+**Step 2.3 — Check legal-hold coverage**
+- If a legal-hold case reference is provided:
+  - Confirm that each in-scope artifact is covered by an active eDiscovery hold in Microsoft Purview
+  - Flag uncovered artifacts as `hold_status` = `covered` | `not_covered` | `unknown`
+- If no legal-hold case reference: record `hold_status` = `not_applicable`
+
+---
+
+### Phase 3 — Gap Analysis and Escalation Gates
+
+**Step 3.1 — Build gap register**
+- Populate `gap_register[]` with every artifact where:
+  - `evidence_status` ≠ `complete`, OR
+  - `retention_days` < `expected_retention_required`, OR
+  - `hold_status` = `not_covered` (when a hold case is active)
+
+**Gate A — Evidence Completeness Gate**
+```
+IF gap_register[] is non-empty:
+  → PAUSE workflow
+  → Escalate to: compliance owner + m365-maestro-agent
+  → Action required: remediate gaps before audit window opens
+  → Do NOT assemble attestation package until gaps are resolved or explicitly accepted with risk note
+```
+
+**Gate B — Retention / Legal-Hold Deficiency Gate**
+```
+IF any artifact has retention_days < expected_retention_required
+OR any artifact has hold_status = not_covered AND legal hold is active:
+  → STOP workflow
+  → Escalate to: Purview compliance administrator + legal owner
+  → Action required: place legal hold or extend retention policy
+  → Do NOT proceed until human confirmation that deficiency is resolved or formally accepted
+```
+
+**Gate C — Privilege Sensitivity Gate**
+```
+IF any artifact is flagged as potentially privileged (attorney-client, work product):
+  → Flag artifact as privilege_sensitivity = HIGH
+  → Route to legal counsel before including in attestation package
+  → Do NOT transmit privileged artifact to external auditor without counsel sign-off
+```
+
+**Gate D — Special-Category Personal Data Gate**
+```
+IF any artifact contains health, biometric, racial/ethnic origin, or other special-category data:
+  → STOP
+  → Confirm jurisdiction and privacy owner
+  → Do NOT proceed until jurisdiction confirmed and privacy owner engaged
+```
+
+---
+
+### Phase 4 — Attestation Package Assembly
+
+**Step 4.1 — Compile attestation records**
+For each control:
+```
+{
+  "control_id": "<framework>-<id>",
+  "control_description": "...",
+  "evidence_artifact_ref": "<location or log reference>",
+  "source_workload": "Exchange Online | SharePoint | Entra ID | Dataverse | ...",
+  "retention_expiry": "<ISO date>",
+  "legal_hold_status": "covered | not_covered | not_applicable",
+  "evidence_quality": "complete | partial | missing",
+  "privilege_sensitivity": "HIGH | STANDARD",
+  "privacy_sensitivity": "HIGH | STANDARD",
+  "open_questions": ["..."],
+  "gap_notes": "..."
+}
+```
+
+**Step 4.2 — Assemble package header**
+```
+{
+  "attestation_package_id": "<uuid>",
+  "skill_id": "audit-evidence-mapping-protocol",
+  "skill_version": "0.1.0",
+  "invoked_by": "<agent or human id>",
+  "audit_window": { "start": "<date>", "end": "<date>" },
+  "control_framework": "<name>",
+  "workloads_in_scope": ["..."],
+  "total_controls": <n>,
+  "complete_evidence": <n>,
+  "partial_evidence": <n>,
+  "missing_evidence": <n>,
+  "retention_gaps": <n>,
+  "hold_gaps": <n>,
+  "escalations_fired": ["Gate A", "Gate B", ...],
+  "package_status": "ready_for_review | blocked_pending_escalation",
+  "timestamp": "<ISO datetime>"
+}
+```
+
+**Step 4.3 — Attach do-not-do list**
+Every attestation package includes:
+- Do not transmit evidence to an external auditor or regulator without human compliance owner sign-off.
+- Do not modify retention policies, legal holds, or eDiscovery cases to close gaps without Purview admin and legal owner approval.
+- Do not include potentially privileged communications in the package without legal counsel review.
+- Do not request or retain personal data beyond the minimum necessary to complete the attestation.
+- Do not interpret this package as legal advice or as a legal opinion on compliance status.
+
+---
+
+## Decision Tree (Condensed)
+
+```
+Receive control list
+  └─ Scope workloads + check licensing tier
+       └─ Map controls to evidence artifacts
+            └─ Verify retention and legal-hold status
+                 ├─ [Gap register non-empty] → Gate A: pause, escalate
+                 ├─ [Retention or hold deficiency] → Gate B: stop, escalate
+                 ├─ [Privileged content detected] → Gate C: flag, route to counsel
+                 ├─ [Special-category data, unknown jurisdiction] → Gate D: stop
+                 └─ [All gates clear] → Assemble attestation package
+                                           └─ Compliance owner review + sign-off
+                                                └─ Authorized external transmission (human only)
+```
+
+---
+
+## Output Contract
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `attestation_package_id` | string (UUID) | Yes | Unique package identifier |
+| `skill_id` | string | Yes | Must be `audit-evidence-mapping-protocol` |
+| `skill_version` | string | Yes | Semantic version |
+| `audit_window` | object | Yes | `start` and `end` ISO dates |
+| `control_framework` | string | Yes | Framework name and version |
+| `workloads_in_scope` | string[] | Yes | List of Microsoft 365 / D365 workloads |
+| `attestation_records` | object[] | Yes | One record per control (schema above) |
+| `gap_register` | object[] | Yes | Empty if no gaps; populated if Gate A fired |
+| `escalations_fired` | string[] | Yes | Which gates fired |
+| `package_status` | enum | Yes | `ready_for_review` or `blocked_pending_escalation` |
+| `do_not_do_list` | string[] | Yes | Mandatory refusal items |
+| `open_questions` | string[] | Yes | Unresolved items requiring human judgment |
+| `timestamp` | string (ISO) | Yes | Package assembly datetime |
+
+---
+
+## Audit Log Fields
+
+`attestation_package_id`, `skill_id`, `skill_version`, `invoked_by`, `input_hash`, `evidence_quality_summary`, `gates_fired`, `package_status`, `timestamp`

package/skills/cross-functional/case-to-resolution-protocol/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: case-to-resolution-protocol
+description: Use this skill when a customer service case must be triaged, routed to the right team, driven to resolution, and captured as reusable knowledge in Dynamics 365 Customer Service. Covers intake-to-routing, SLA tracking, escalation gates, knowledge capture, and post-resolution CSAT. Orchestrates the d365-customer-service-contact-center-agent as primary and invokes human escalation when SLA risk or knowledge gaps are detected. Does not make final resolution decisions or override customer service policies; all production-impacting steps escalate to the relevant service owner or quality team.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+  lifecycle: experimental
+---
+
+# Case to Resolution Protocol
+
+## Purpose
+This skill defines how a customer service case moves from first contact through
+routing, active resolution, and closure — and how every resolved case feeds
+the knowledge base so future cases resolve faster. It exists to ensure SLA
+accountability, consistent routing logic, and structured knowledge reuse across
+Dynamics 365 Customer Service. It does not replace human judgment on complex
+resolutions; it structures the handoffs so nothing falls through.
+
+## When to use
+- A new case must be triaged and routed to a queue, team, or specialist.
+- An active case risks breaching its SLA and needs escalation.
+- A case is resolved and a knowledge article should be created or updated.
+- Post-resolution CSAT is due and results must feed continuous-improvement loops.
+- Multiple channels (email, chat, voice, social) need a unified intake view.
+
+## When NOT to use
+- The case is already resolved and closed — routing decisions are moot.
+- The matter is a product defect escalation requiring engineering triage — use
+  your engineering escalation runbook.
+- Regulated health or financial-services data handling requires compliance
+  counsel that supersedes this protocol.
+- You need live Dynamics 365 configuration changes — escalate to the service
+  owner; this protocol is recommendation-only.
+
+## Participating agents
+- `d365-customer-service-contact-center-agent` (primary — case intake, routing, SLA monitoring, resolution, knowledge capture)
+
+## Inputs required
+- Case description and channel of origin (email, chat, voice, social, web form)
+- Customer or employee identity (authenticated or pending authentication)
+- Priority signal or SLA entitlement reference
+- Existing case history for this customer (if available)
+- Knowledge base search results (Dynamics 365 Customer Service or SharePoint)
+
+## Evidence required
+- Unified routing configuration (queues, skills, capacity rules) is in place
+- SLA definitions and entitlements are configured in Dynamics 365 Customer Service
+- Knowledge base is seeded and publishing workflow is active
+- CSAT survey mechanism (Dynamics 365 Customer Voice or equivalent) is configured
+
+## Workflow
+
+1. **Intake** — Log the case: capture channel, customer identity, description,
+   priority. Apply record creation and update rules to standardise fields.
+2. **Authentication** — Verify the requester's identity via entitlement lookup
+   or Dynamics 365 authentication flow before exposing account data.
+3. **Route** — Apply unified routing rules (skills matching, queue capacity,
+   SLA tier). Assign to the correct queue or representative automatically where
+   rules allow; flag ambiguous cases for supervisor review.
+4. **Acknowledge** — Send SLA-compliant acknowledgment to the customer. Start
+   the SLA clock.
+5. **Investigate** — Representative works the case using the knowledge base,
+   AI suggestions (Copilot in Dynamics 365), and collaboration via Microsoft
+   Teams swarming where needed.
+6. **Gate 1 — SLA attainment check** — If the first-response or resolution SLA
+   is at risk, escalate to supervisor and reassign if necessary. Do not allow
+   silent SLA breach.
+7. **Resolve** — Apply the resolution. Record resolution type, billable time,
+   and resolution summary in the case record.
+8. **Gate 2 — Knowledge capture** — Before closing, check whether the
+   resolution should produce a new or updated knowledge article. If yes, draft
+   the article and route it through the knowledge publishing workflow.
+9. **Close** — Set case status to Resolved. Trigger post-resolution CSAT survey
+   via Dynamics 365 Customer Voice.
+10. **CSAT review** — Route CSAT results to the responsible team. Flag low-
+    scoring cases for quality review and root-cause analysis.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| SLA attainment | First-response or resolution timer at 80% elapsed | Escalate to supervisor; consider reassignment |
+| Knowledge capture | Resolution not covered by existing article | Draft knowledge article before close |
+| Escalation trigger | Case complexity exceeds representative skill tier | Invoke Teams swarming or senior escalation queue |
+| CSAT threshold | CSAT score below agreed threshold | Flag for quality review; root-cause required |
+
+## Refusal triggers
+- Stop if the case requires access to regulated personal data (health, financial)
+  and applicable compliance requirements are not confirmed — escalate to
+  compliance owner.
+- Stop if resolving the case requires a live Dynamics 365 configuration change
+  that has not been approved by the service owner.
+- Stop if customer authentication has not been confirmed before exposing
+  account-specific data.
+
+## Handoff rules
+- All handoffs carry: case_id, skill_id, skill_version, invoked_by,
+  routing_basis, sla_status, open_questions, do_not_do_list.
+- Human escalations always include the SLA time remaining and a clear statement
+  of what has been tried.
+- Knowledge articles drafted by this protocol are submitted for human review
+  before publishing; this skill never auto-publishes.
+
+## KPIs
+- SLA attainment rate (first response, resolution)
+- Case resolution time (mean, P90)
+- Knowledge article creation rate per resolved case
+- CSAT score (mean, trend, low-score rate)
+- First-contact resolution rate
+
+## References
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-introduction
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-areas
+- https://learn.microsoft.com/dynamics365/customer-service/administer/overview-cases
+- https://learn.microsoft.com/dynamics365/customer-service/use/customer-service-hub-user-guide-resolve-cancel-reassign-a-case
+- https://learn.microsoft.com/dynamics365/customer-service/administer/set-up-case-resolution-agent

package/skills/cross-functional/case-to-resolution-protocol/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "case-to-resolution-protocol",
+  "name": "Case to Resolution Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Intake-to-routing-to-resolution-to-CSAT orchestration protocol for Dynamics 365 Customer Service. Covers case triage, unified routing, SLA tracking, escalation gates, knowledge capture, and post-resolution CSAT — ensuring every case closes with actionable knowledge and measurable service quality. Routing and resolution steps are recommendations only; all production-impacting decisions require the relevant service or quality owner.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-introduction",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-areas",
+    "https://learn.microsoft.com/dynamics365/customer-service/administer/overview-cases",
+    "https://learn.microsoft.com/dynamics365/customer-service/use/customer-service-hub-user-guide-resolve-cancel-reassign-a-case",
+    "https://learn.microsoft.com/dynamics365/customer-service/administer/set-up-case-resolution-agent"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration aid only; it is never an authorisation to resolve, escalate, or close a case. It never requests customer credentials, session IDs, PII, or production Dynamics 365 org IDs to classify or route a case. Cases involving regulated personal data (health, financial) require compliance owner confirmation before proceeding. Knowledge articles produced by this protocol are submitted for human review before publishing and are never auto-published. Production configuration changes (SLA rules, routing rules, queue setup) escalate to the relevant service owner. CSAT data is handled in aggregate and is never used to identify individual representatives without HR and privacy-team approval.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/case-to-resolution-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/case-to-resolution-protocol/references/workflow-and-output.md

@@ -0,0 +1,197 @@
+# Case to Resolution Protocol — Workflow and Output Contract
+
+## Detailed Workflow
+
+### Phase 1: Intake and Authentication
+
+**Trigger events**
+- Inbound email, chat, voice, social media, or web form submission
+- Agent or bot escalation from self-service channel
+- Manual case creation by a representative
+
+**Step 1.1 — Case logging**
+Log the case record in Dynamics 365 Customer Service. Capture:
+- Channel of origin
+- Customer/employee identity reference (do not log unverified PII as confirmed)
+- Case description and initial priority signal
+- Applicable entitlement or SLA tier
+
+**Step 1.2 — Record creation rules**
+Apply configured record creation and update rules to normalise fields. If the
+case arrives via email, validate that the record creation rule mapped it
+correctly to the right case type and queue.
+
+**Step 1.3 — Authentication gate**
+Verify the requester's identity before exposing account data. Options:
+- Entitlement lookup (case linked to known customer account)
+- Dynamics 365 authentication / Nuance Gatekeeper (voice)
+- Representative manual verification (flag as manually verified)
+
+If authentication cannot be confirmed, hold the case in a pending-authentication
+queue and notify the customer. Do not expose account data on an unverified case.
+
+---
+
+### Phase 2: Routing
+
+**Step 2.1 — Unified routing evaluation**
+Apply Dynamics 365 unified routing rules:
+- Skills matching (representative skill set vs. case requirements)
+- Queue capacity (available capacity in target queue)
+- SLA tier (premium entitlements route to priority queues)
+- Case type (product, billing, technical, returns, etc.)
+
+**Step 2.2 — Routing outcome**
+- If rules produce a confident match: auto-assign to queue or representative.
+- If rules produce an ambiguous match: flag for supervisor review; do not
+  silently assign to a default queue.
+- If case crosses multiple service domains: assign a primary representative and
+  note the secondary domain for potential swarm.
+
+**Step 2.3 — SLA clock start**
+Once routed, start the SLA clock. Send the SLA-compliant acknowledgment to
+the customer (configured in Dynamics 365 Customer Service SLA settings).
+
+---
+
+### Phase 3: Investigation and Resolution
+
+**Step 3.1 — Knowledge base search**
+Representative searches the Dynamics 365 knowledge base and any connected
+SharePoint knowledge sources. Copilot suggestions (AI-suggested articles and
+similar cases) are surfaced in Customer Service Workspace.
+
+**Step 3.2 — Collaboration**
+If the case requires cross-team input, invoke Microsoft Teams swarming from
+within Dynamics 365 Customer Service. Log all collaboration as activities on
+the case record.
+
+**Step 3.3 — SLA attainment check (Gate 1)**
+At 80% of the first-response or resolution SLA timer:
+- If on track: continue.
+- If at risk: escalate to supervisor via Dynamics 365 alert. Supervisor reviews
+  and either reassigns or confirms continued ownership with an agreed plan.
+  Do not allow silent SLA breach.
+
+**Step 3.4 — Resolution**
+Apply the resolution. Complete the resolution dialog in Dynamics 365 Customer
+Service:
+- Resolution type (how it was resolved)
+- Resolution summary (what was done)
+- Billable time (if entitlement tracks billable minutes)
+Case status transitions to Resolved only when the Resolve Case action is
+explicitly taken.
+
+---
+
+### Phase 4: Knowledge Capture and Closure
+
+**Step 4.1 — Knowledge capture gate (Gate 2)**
+Before closing, evaluate whether the resolution should produce a new or updated
+knowledge article:
+- Is this case type covered by an existing article? If yes, is the article
+  accurate and complete given this resolution?
+- If no: draft a new article.
+- If yes but outdated: flag the article for update.
+
+This gate is mandatory. If the representative cannot determine article coverage,
+escalate to the knowledge base owner before closure.
+
+**Step 4.2 — Knowledge article draft**
+Draft the article in the Dynamics 365 knowledge authoring tool. Submit for
+review through the configured publishing workflow. This protocol never
+auto-publishes a knowledge article.
+
+**Step 4.3 — Case closure**
+Set case status to Resolved. Confirm open activities are handled (cancelled or
+completed). Trigger the post-resolution CSAT survey via Dynamics 365 Customer
+Voice.
+
+---
+
+### Phase 5: CSAT Review
+
+**Step 5.1 — CSAT collection**
+Dynamics 365 Customer Voice sends the configured post-resolution survey to the
+customer. Respect opt-out preferences and survey fatigue controls.
+
+**Step 5.2 — CSAT routing**
+Route CSAT results to the responsible team or supervisor dashboard. Aggregate
+results in Power BI dashboards connected to Dynamics 365 Customer Service
+Insights.
+
+**Step 5.3 — Low-CSAT escalation**
+If CSAT score falls below the agreed threshold:
+- Flag the case for quality review.
+- Require a root-cause analysis within the agreed SLA.
+- Feed findings into the continuous-improvement process.
+
+---
+
+## Decision Tree
+
+```
+Case received
+  └── Authentication confirmed?
+        ├── No  → Hold in pending-authentication queue; notify customer
+        └── Yes → Log case; apply routing rules
+                    └── Routing rules produce confident match?
+                          ├── No  → Supervisor review; manual assignment
+                          └── Yes → Auto-assign; start SLA clock
+                                      └── SLA at risk (80% elapsed)?
+                                            ├── Yes → Escalate to supervisor
+                                            └── No  → Investigate and resolve
+                                                          └── Resolution complete?
+                                                                └── Knowledge article needed?
+                                                                      ├── Yes → Draft article; submit for review
+                                                                      └── No  → Close case; trigger CSAT
+                                                                                    └── CSAT below threshold?
+                                                                                          ├── Yes → Flag for quality review; root-cause required
+                                                                                          └── No  → Close cycle
+```
+
+---
+
+## Output Contract
+
+Every execution of this protocol produces the following artefacts:
+
+### Case capsule (per case)
+| Field | Type | Description |
+|---|---|---|
+| case_id | string | Dynamics 365 case identifier |
+| skill_id | string | `case-to-resolution-protocol` |
+| skill_version | string | `0.1.0` |
+| invoked_by | string | Agent or human who invoked this protocol |
+| channel | enum | email / chat / voice / social / web / manual |
+| routing_basis | string | Rule set applied for routing |
+| sla_status | enum | on-track / at-risk / breached |
+| knowledge_article_action | enum | none / drafted / updated |
+| csat_score | number or null | Post-resolution CSAT (null if not yet received) |
+| open_questions | array | Unresolved questions at handoff |
+| do_not_do_list | array | Actions explicitly excluded from this protocol's scope |
+| escalation_fired | boolean | Whether a human escalation was triggered |
+| timestamp | ISO 8601 | Protocol execution timestamp |
+
+### Gate verdicts (per gate)
+| Gate | Verdict options |
+|---|---|
+| SLA attainment check | pass / escalated / breached |
+| Knowledge capture | article-drafted / article-updated / no-action-required |
+
+### Refusal record (when triggered)
+| Field | Description |
+|---|---|
+| refusal_reason | Which refusal trigger was hit |
+| escalation_target | Where the case was sent |
+| timestamp | ISO 8601 |
+
+---
+
+## Quality Assurance Notes
+- This protocol does not modify Dynamics 365 routing rules, SLA definitions,
+  or queue configurations. Changes to these settings require the service owner.
+- Knowledge articles drafted by this protocol are in draft state until a human
+  knowledge manager approves and publishes them.
+- CSAT data is handled in aggregate only. Individual representative CSAT data
+  requires HR and privacy-team approval before use in performance review.

package/skills/cross-functional/change-request-to-go-live-protocol/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: change-request-to-go-live-protocol
+description: Use this skill when a Dynamics 365 change request must be structured and progressed through impact assessment, fit-gap analysis, UAT sign-off, go/no-go decision, go-live execution, and hypercare using the Success by Design framework. Defines the full change-to-go-live flow — change request intake, solution blueprint alignment, testing gates, cutover plan verification, go/no-go decision, deployment, and hypercare. Does not authorize go-live, cutover execution, or production deployments; all production-impacting actions require human approval from the project sponsor, release manager, and Microsoft FastTrack for Dynamics 365 team (where engaged). Does not replace a qualified Dynamics 365 architect or implementation partner.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Change Request to Go-Live Protocol
+
+## Purpose
+This skill defines how a Dynamics 365 change request is taken from intake through impact assessment, fit-gap analysis, UAT sign-off, go/no-go decision, go-live execution, and hypercare, aligned to the Microsoft Success by Design framework. It applies the Success by Design gate structure — Solution Blueprint Review, Implementation Reviews, and Go-live Readiness Review — to ensure that only well-tested, stakeholder-approved solutions reach production. No agent authorizes go-live, cutover execution, or production deployments; those are human decisions by the project sponsor, release manager, and (where engaged) the Microsoft FastTrack for Dynamics 365 team.
+
+## When to use
+- A new Dynamics 365 change request (feature, configuration, integration, or data migration) must be assessed for impact before development or deployment.
+- A solution is approaching the Prepare phase and a go-live readiness gate review is needed.
+- UAT sign-off or go/no-go criteria must be structured and tracked.
+- A cutover plan must be reviewed for completeness before a go-live window.
+- A hypercare plan must be confirmed and a support owner identified before go-live.
+
+## When NOT to use
+- The change is a minor hotfix that does not require a full Solution Blueprint Review — use the environment-to-production-release-protocol with expedited gates.
+- The implementation is not a Dynamics 365 project — this protocol is specifically aligned to the Dynamics 365 Success by Design framework.
+- The go-live has already occurred and the project is in the Operate phase — escalate post-go-live issues to the hypercare support owner.
+- The matter involves a regulatory or contractual commitment that requires legal review before the change can proceed — escalate to legal counsel first.
+
+## Participating agents
+- `d365-success-by-design-governance-agent` — primary: assesses Solution Blueprint Review readiness, go-live readiness checklist completion, and Success by Design gate compliance
+- `d365-data-migration-cutover-agent` — secondary: assesses data migration plan completeness, cutover plan, mock go-live execution, and rollback readiness
+
+## Inputs required
+- Change request description and scope (feature, configuration change, integration, or data migration)
+- Current Success by Design phase (Discover, Initiate, Implement, Prepare, Operate)
+- Solution Blueprint Review findings (if available)
+- Target go-live date and cutover window
+- Testing status (SIT, UAT, performance testing)
+- Open issues list from prior reviews
+
+## Evidence required
+- Solution Blueprint Review outcomes (risks, recommendations, open items)
+- System integration testing (SIT) results
+- User acceptance testing (UAT) results and sign-off status
+- Performance testing results
+- Data migration plan and mock cutover results
+- Go-live readiness checklist completion status
+- Production support plan and hypercare plan
+
+## Workflow
+
+1. **Intake and phase alignment** — receive change request; confirm current Success by Design phase; confirm whether a Solution Blueprint Review has been completed.
+2. **Impact and fit-gap assessment** — assess the functional and non-functional impact of the change against the approved solution design; identify fit-gap items (gaps between standard Dynamics 365 functionality and business requirements that require customization).
+3. **Solution Blueprint Review gate (if not yet completed)** — confirm Solution Blueprint Review has been conducted; review findings and open risks; confirm that Implementation Reviews for critical areas (data model, security, integration, ALM, testing strategy) are scheduled or completed.
+4. **Testing gate: SIT and performance** — confirm system integration testing and performance testing are complete; review results; flag any critical or blocking defects.
+5. **Testing gate: UAT sign-off** — confirm UAT is complete and business stakeholders have signed off; flag any open UAT defects; confirm UAT sign-off authority has formal sign-off on record.
+6. **Cutover plan verification** — confirm cutover plan is documented, includes task owners, durations, and dependencies; confirm mock go-live has been executed or is scheduled; confirm rollback criteria and rollback steps are defined.
+7. **Escalation gate: impact and fit-gap** — if critical fit-gap items are unresolved or the solution design has material gaps, pause and escalate to the project sponsor and Dynamics 365 architect before proceeding.
+8. **Escalation gate: UAT sign-off** — if UAT sign-off is not obtained or critical UAT defects are open, stop and escalate to the project sponsor; do not proceed to go/no-go without UAT sign-off.
+9. **Go-live readiness review** — conduct or confirm completion of the Go-live Readiness Review (Success by Design mandatory review); assess go-live readiness against the checklist: solution acceptance, user training, performance, integrations, code management, configuration management, blocking issues, cutover plan, risk mitigation, and support plan.
+10. **Escalation gate: go/no-go decision** — require explicit human go/no-go decision from project sponsor and release manager; record decision with timestamp and decision owner reference; do not initiate cutover without a confirmed Go decision.
+11. **Go-live and cutover execution** — confirm production deployment and data migration cutover execution per the approved cutover plan; monitor go-live status; record each cutover task completion.
+12. **Escalation gate: rollback** — if a blocking issue is detected during go-live that meets rollback criteria, stop and escalate to project sponsor and release manager for rollback decision; do not continue go-live over a rollback-trigger threshold without explicit authorization.
+13. **Hypercare** — confirm hypercare period is active; confirm hypercare support owner and escalation path; schedule post-go-live review; track and resolve post-go-live issues.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Impact and fit-gap | Critical fit-gap items unresolved or solution design has material gaps | Pause; escalate to project sponsor + Dynamics 365 architect |
+| UAT sign-off | UAT not signed off or critical UAT defects open | Stop; escalate to project sponsor; do not proceed to go/no-go |
+| Go/no-go | Human go/no-go decision not on record | Hold; do not initiate cutover; require decision from project sponsor + release manager |
+| Rollback | Blocking issue during go-live meets rollback criteria | Stop go-live; escalate to project sponsor + release manager for rollback decision |
+| Solution Blueprint Review | Solution Blueprint Review not completed | Flag; recommend completing before continuing; mandatory for complex implementations |
+
+## Refusal triggers
+- A request is made to proceed to go-live without UAT sign-off — refuse; UAT sign-off is mandatory.
+- A request is made to execute cutover without a documented cutover plan and rollback criteria — refuse.
+- A request is made to skip the Go-live Readiness Review for a complex implementation — refuse; escalate to Success by Design team.
+- Credentials, service principal secrets, tenant IDs, or production data are requested to assess go-live readiness — refuse; work from sanitized change request, test results, and checklist signals only.
+- A go/no-go Go decision is recorded without human authorization — refuse; human project sponsor sign-off is mandatory.
+
+## Handoff rules
+- Every handoff carries: change request scope, current phase, gate status, open issues, test results summary, cutover plan status, go/no-go decision reference, rollback plan reference, hypercare plan, and a do-not-do list.
+- No agent authorizes go-live, cutover execution, or production deployments. Human project sponsor and release manager own the go/no-go decision.
+- Post-go-live, the primary agent confirms hypercare activation and hands off to the hypercare support owner.
+
+## KPIs
+- Percentage of go-live readiness checklist items completed before the go/no-go gate
+- Number of critical defects open at UAT sign-off gate
+- Number of go-live rollbacks triggered
+- Hypercare issue resolution time (first response and full resolution)
+
+## References
+- [Introduction to Success by Design — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/implementation-guide/success-by-design)
+- [Prepare to go live — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-to-go-live)
+- [Go-live readiness workshops for Dynamics 365 projects](https://learn.microsoft.com/dynamics365/guidance/fasttrack/go-live-workshops)
+- [Use the go-live checklist — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-checklist)
+- [Manage changes during transition and handover — Dynamics 365](https://learn.microsoft.com/dynamics365/guidance/implementation-guide/change-management-transition-handover)