@raishin/vanguard-frontier-agentic 2.10.0 → 2.11.0

package/skills/microsoft/d365-customer-service-contact-center/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "d365-customer-service-contact-center",
+  "name": "D365 Customer Service & Contact Center",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Customer Service and Contact Center across the case-to-resolution lifecycle: case management, unified routing, Omnichannel for Customer Service, queues, entitlements, SLAs, knowledge management, and Copilot in Service to improve resolution time, routing accuracy, knowledge reuse, and CSAT.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/customer-service/implement/overview",
+    "https://learn.microsoft.com/dynamics365/customer-service/administer/overview-cases",
+    "https://learn.microsoft.com/dynamics365/customer-service/administer/create-enhanced-sla",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-overview",
+    "https://learn.microsoft.com/dynamics365/customer-service/administer/create-standard-sla"
+  ],
+  "security_notes": "Static review only. Do not modify production unified-routing rules, SLA configurations, channel/workstream setup, or knowledge publishing workflows; these are escalated to a qualified Customer Service administrator with a rollback plan. Do not ask for credentials, environment URLs, tenant IDs, connection strings, or customer data. Treat misrouted cases, SLAs without warning actions, stale knowledge bases, and uncapped channel capacity as CSAT and cost-to-serve risks until reviewed.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-customer-service-contact-center",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "operational",
+  "companion_agents": ["d365-customer-service-contact-center-agent"]
+}

package/skills/microsoft/d365-customer-service-contact-center/references/official-sources.md

@@ -0,0 +1,25 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Customer Service behavior or the case-to-resolution business process.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live Customer Service configuration or operational metrics:
+
+- https://learn.microsoft.com/dynamics365/customer-service/implement/overview — Customer Service capabilities: cases, interactions, knowledge base, unified routing, omnichannel (incl. voice), SLAs, entitlements, dashboards. Administration via the Copilot Service admin center. Supports scope and KPI workflow steps.
+- https://learn.microsoft.com/dynamics365/customer-service/administer/overview-cases — Case management components: cases, activities, entitlements, knowledge articles, queues, Copilot case summaries, SLAs, record creation/update rules, routing rules. Supports the case-management review step.
+- https://learn.microsoft.com/dynamics365/customer-service/administer/create-enhanced-sla — Enhanced SLAs: SLA KPIs, applicable-when conditions, success criteria, warning/failure actions. Supports the SLA review step.
+- https://learn.microsoft.com/dynamics365/customer-service/administer/create-standard-sla — Standard SLAs and the available SLA workflow actions. Supports the SLA design and pushback steps.
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/case-to-resolution-overview — Case to resolution end-to-end process and featured capabilities: Omnichannel, unified routing, knowledge base, Microsoft Teams collaboration, AI suggestions, Customer Insights, Customer Voice. Supports the end-to-end lifecycle workflow.
+
+## Certification alignment (verify currency)
+
+- Exam MB-230: Microsoft Dynamics 365 Customer Service Functional Consultant — skills measured updated as of March 11, 2026 (verify status before citing): case management (51–55%), representative experience and routing (25–30%), extend Customer Service (15–20%).
+
+## Terminology note
+
+The Customer Service admin center was renamed the Copilot Service admin center. Some Learn articles may use either name. Verify current naming before presenting configuration locations.
+
+## Grounding rule
+
+Official documentation explains Customer Service behavior. It does not prove the user's actual SLA attainment, routing accuracy, knowledge freshness, channel configuration, or CSAT. Prefer exported reports, sanitized user-provided metrics, or read-only evidence for current-state claims.

package/skills/microsoft/d365-customer-service-contact-center/references/safety-checklist.md

@@ -0,0 +1,34 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production unified-routing rules, SLA configuration, channel/workstream setup, or knowledge publishing in Dynamics 365 Customer Service.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, tenant IDs, environment URLs, connection strings, certificates, or customer data into chat.
+- Use exported reports or sanitized user-provided evidence for current-state claims; otherwise use documentation and label the evidence level.
+- Do not invent SLA attainment percentages, case volumes, routing distributions, or CSAT scores.
+- Require explicit human approval before recommending any production routing-rule, SLA, channel, or knowledge-publishing change.
+- Use current official Microsoft Learn documentation for Customer Service, Omnichannel, and unified routing behavior.
+- Keep recommendations least-change, reversible, and scoped to the domain in question.
+
+## Stress checks
+
+- What cases are misrouted, reassigned repeatedly, or manually triaged at scale?
+- Which SLAs lack warning actions, realistic business calendars, or recalculation-on-reopen settings?
+- Is the knowledge base curated, current, and de-duplicated, or stale?
+- Are omnichannel capacity profiles set to prevent agent overload?
+- What rollback exists if a routing-rule or SLA change misbehaves in production?
+
+## Evidence labels
+
+Use `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual SLA attainment, routing accuracy, knowledge freshness, or CSAT.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Modifying production unified-routing rules, work classification, or capacity profiles
+- Changing production SLA KPIs, success criteria, or warning/failure actions
+- Configuring or reconfiguring production channels/workstreams (voice, chat, messaging)
+- Publishing, unpublishing, or bulk-editing production knowledge articles
+- Executing bulk case reassignment, status changes, or queue moves

package/skills/microsoft/d365-customer-service-contact-center/references/workflow-and-output.md

@@ -0,0 +1,66 @@
+# Workflow and output contract
+
+Use this reference only when performing the full Dynamics 365 Customer Service & Contact Center review or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Case management: record creation/update rules, resolution experience, status reasons, timeline configuration, security roles
+- Unified routing: rule-based vs. skills-based routing, work classification, capacity profiles, queue/agent assignment
+- Omnichannel: configured channels (voice, chat, messaging), workstreams, agent experience, capacity
+- Queues and entitlements: queue design, entitlement terms, service scheduling
+- SLAs: KPIs, applicable-when conditions, success criteria, warning/failure actions, recalculation on terminal status
+- Knowledge management: authoring/curation/publishing, internal and external (SharePoint) search, AI suggestions, article freshness/expiry
+- Copilot in Service: case/conversation summaries, ask-a-question, draft-a-response, knowledge sources
+- KPIs: first-response/resolution time, SLA attainment, routing accuracy, self-service deflection, CSAT
+
+## Safe workflow
+
+1. **Frame scope**
+   - Area in scope (case management / routing / omnichannel / SLA / knowledge):
+   - Licensing and channels in use (Customer Service, Contact Center, Omnichannel voice):
+   - Required outcome (resolution time / routing accuracy / SLA attainment / knowledge reuse / CSAT):
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer exported reports: case aging, SLA attainment, routing distribution, knowledge usage, CSAT survey results.
+   - Otherwise inspect sanitized user-provided summaries or official Microsoft Learn documentation.
+   - Label each finding as `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - What cases are misrouted or manually triaged at scale?
+   - Which SLAs lack warning actions or realistic business-hours calendars?
+   - Is the knowledge base curated and current, or stale and duplicative?
+   - Are channels configured with capacity profiles to prevent agent overload?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer configuration and process fixes over channel/routing-engine changes.
+   - Production routing-rule, SLA, and channel configuration changes require live-guard escalation with a rollback plan.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Customer Service & Contact Center Review: <scope>
+## Executive verdict
+- Status: HEALTHY / HEALTHY WITH RISKS / AT RISK / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Reports or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-data-migration-cutover/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: d365-data-migration-cutover
+description: Review Dynamics 365 data migration planning and go-live cutover readiness. Enforces mock migration evidence, data quality gates, staging table validation, reconciliation controls, cutover runbook completeness, rollback plan, and owner sign-off before production migration. Refuses to bless production cutover without reconciliation evidence and rollback plan. Production data migration is live-guard gated and requires escalation.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: data
+---
+
+# D365 Data Migration & Cutover
+
+## Purpose
+
+Act as the Dynamics 365 data migration and cutover reviewer who treats every unvalidated legacy data extract, failed or skipped mock migration, missing reconciliation evidence, and untested rollback plan as a production go-live blocker until proven otherwise.
+
+## When to use
+
+Use this skill for:
+
+- Data migration strategy review (entity selection, migration sequence, full vs. delta load approach)
+- Data Management Framework usage: data entities, data packages, import/export jobs, staging table validation
+- Legacy data quality assessment and cleansing planning
+- Mock migration (dry run) planning, execution, and results review
+- Reconciliation control design: record counts, field-level sampling, business user validation
+- Cutover runbook review: sequenced tasks, owners, durations, dependencies, go/no-go criteria
+- Rollback plan assessment: rollback triggers, rollback owner, rollback time window, rollback validation
+- Production data migration authorization and go-live cutover readiness sign-off
+- Post-migration hyper-care: data validation, issue triage, escalation path
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Dynamics 365 data management framework behavior, data entities, and cutover strategy. Use the per-skill facts and sources in `references/official-sources.md` for grounding.
+- Separate confirmed facts from inference. If a mock migration was not completed or reconciliation evidence was not provided, say so explicitly.
+- Challenge missing mock migration evidence, unvalidated legacy data, record-count-only reconciliation, missing rollback plans, and cutover authorizations without business owner sign-off.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed; do not pull all deep guidance into short answers.
+- Never ask for credentials, connection strings, environment URLs, tenant IDs, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full migration or cutover review, or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production data migration, cutover authorization, or rollback execution.
+- [Official sources](references/official-sources.md) — use when grounding Data Management Framework behavior, data entity usage, or cutover strategy guidance.
+- [Data Migration & Cutover Guide](references/data-migration-cutover-guide.md) — use for domain-specific failure modes, safe review workflow, verification targets, and pushback criteria.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped migration target and evidence level,
+- the main data quality issues, mock migration gaps, reconciliation risks, or cutover runbook gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-data-migration-cutover/metadata.json

@@ -0,0 +1,32 @@
+{
+  "id": "d365-data-migration-cutover",
+  "name": "D365 Data Migration & Cutover",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 data migration planning and go-live cutover readiness. Enforces mock migration evidence, data quality gates, staging table validation, reconciliation controls, cutover runbook completeness, rollback plan, and owner sign-off before production migration. Detects dirty legacy data, failed mock migrations, weak reconciliation, missing rollback paths, and go-live chaos risks. Refuses to bless production cutover without reconciliation evidence and rollback plan. Production data migration is live-guard gated and requires escalation.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-to-go-live",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-checklist",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities-data-packages",
+    "https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/data-entities/data-import-export-job",
+    "https://learn.microsoft.com/training/modules/prepare-data-migration-finance-operations/",
+    "https://learn.microsoft.com/power-platform/architecture/key-concepts/data-migration/cut-over-planning"
+  ],
+  "security_notes": "Never approve production data migration or cutover without documented evidence of at least one completed mock migration, reconciliation sign-off comparing source and target record counts, and a tested rollback plan. Production data migration is live-guard gated and must be escalated to a human implementation lead and business data owner before execution. Data quality issues discovered during staging table validation must be resolved and re-validated before migration to production. Do not accept record count matching alone as reconciliation evidence; require field-level sampling and business user validation. Do not ask for credentials, connection strings, environment URLs, tenant IDs, or customer data. Treat every unvalidated legacy data extract, failed mock migration, and missing rollback plan as a production go-live blocker.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-data-migration-cutover",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "data",
+  "companion_agents": ["d365-data-migration-cutover-agent"]
+}

package/skills/microsoft/d365-data-migration-cutover/references/data-migration-cutover-guide.md

@@ -0,0 +1,76 @@
+# Data Migration & Cutover Guide
+
+Use this reference for Dynamics 365 data migration failure modes, safe review workflow, Data Management Framework patterns, reconciliation design, cutover runbook requirements, verification targets, and pushback criteria.
+
+## What people get wrong
+
+The lazy story is:
+
+> Run an export from the legacy system, import it into Dynamics 365 using the Data Management workspace, check the record count, and you are done.
+
+Wrong. Record count matching is a necessary but not sufficient reconciliation control. Field-level data quality issues, staging table transformation errors, dependency sequencing failures, and financial balance discrepancies are invisible to record count checks alone. A single failed mock migration that is declared "good enough" is the leading predictor of production cutover chaos.
+
+Common bad assumptions:
+
+- One mock migration is sufficient regardless of error rate or elapsed time.
+- Staging table errors that were manually resolved in the test environment do not need to be re-validated after fix.
+- Record count reconciliation is sufficient to prove data integrity.
+- The cutover window is generous enough to absorb a 2x slowdown from production environment differences.
+- Legacy data cleansing can be completed during the cutover window.
+- Rollback is simple and can be planned ad hoc if needed.
+- Delta loads between the final mock migration and production cutover do not need a separate test run.
+
+## Data migration failure modes
+
+- Legacy data quality issues (duplicates, nulls in required fields, invalid codes, format mismatches) are discovered during production migration after the cutover window has started.
+- Staging table errors not resolved before production promotion cause partial entity loads, creating referential integrity violations in target tables.
+- Entity dependency sequence not respected: transactional data imported before master data causes failed lookups.
+- Migration throughput measured in development or sandbox environment does not reflect production environment capacity, causing the cutover window to be exceeded.
+- Delta load strategy not designed: data changed in the legacy system between the final mock migration and production cutover is not captured, leaving gaps.
+- Rollback plan not tested: when rollback is needed, the steps are unclear, the owner is unknown, and the rollback itself fails.
+- Reconciliation performed only by the implementation team, not validated by business data owners who know the expected values.
+
+## High-risk data domains (examples)
+
+- **Chart of accounts and financial dimensions**: must be migrated and validated before any financial transaction data; errors here cascade across all financial reporting.
+- **Customer and vendor master data**: deduplication failures create billing, payment, and compliance issues post-go-live.
+- **Open purchase orders and open invoices**: in-flight transactions must be captured completely or business operations halt at go-live.
+- **Fixed asset master and net book values**: incorrect opening balances trigger depreciation calculation errors.
+- **Inventory on-hand balances**: quantity or cost inaccuracies surface immediately at go-live in procurement and production.
+- **Bank account and payment method configuration**: missing or incorrect data blocks payment processing from day one.
+
+## Minimum safe migration review workflow
+
+1. Confirm scope: Dynamics 365 workloads, legal entities, data domains, legacy sources, go-live date, cutover window.
+2. Review entity selection and dependency sequence: all required entities identified, sequenced in dependency order.
+3. Confirm mock migration evidence: at least one completed mock migration with documented staging error counts, elapsed time per entity, and reconciliation totals.
+4. Review data quality plan: legacy data cleansing completed or in progress, known issues logged with mitigations.
+5. Review reconciliation design: record counts, field-level sampling plan, financial balance checks, business user validation sign-off.
+6. Review cutover runbook: task sequence, owners, durations, system freeze point, delta load steps, go/no-go checkpoint.
+7. Review rollback plan: trigger criteria, rollback owner, rollback steps, rollback validation, rollback time estimate.
+8. Confirm stakeholder sign-off: business data owner and implementation lead approvals documented.
+9. Provide minimum-safe-action recommendation scoped to highest-severity migration gaps.
+10. Require live-guard escalation for any production migration authorization.
+
+## Verification targets
+
+- Mock migration results: completed runs, staging error count, elapsed time, entity coverage
+- Data quality: cleansing status, known issues log, deduplication results
+- Reconciliation: record counts, field samples, financial balances, business user validation
+- Cutover runbook: task sequence, owners, durations, go/no-go criteria, rollback section
+- Rollback plan: trigger criteria, owner, steps, validation, time estimate
+- Delta load strategy: designed, tested, sequenced relative to freeze point
+- Stakeholder sign-off: business data owner and implementation lead named and dated
+
+## When to push back
+
+Push back if the user asks to:
+
+- approve production migration without at least one completed mock migration with documented results
+- accept record count matching alone as sufficient reconciliation evidence
+- proceed to production cutover with unresolved staging table errors
+- approve a cutover window that has no throughput buffer based on measured migration performance
+- proceed without a tested rollback plan that includes a named rollback owner and trigger criteria
+- sign off on reconciliation without business data owner validation
+- skip the go/no-go checkpoint before starting production migration
+- authorize post-migration legacy data deletion before business users have validated the target environment

package/skills/microsoft/d365-data-migration-cutover/references/official-sources.md

@@ -0,0 +1,51 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 data migration, Data Management Framework behavior, or cutover strategy guidance.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live migration state or data quality posture:
+
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-to-go-live
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-checklist
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/prepare-go-live-cutover-strategy
+- https://learn.microsoft.com/dynamics365/fin-ops-core/dev-itpro/data-entities/data-entities-data-packages
+- https://learn.microsoft.com/dynamics365/fin-ops-core/fin-ops/data-entities/data-import-export-job
+- https://learn.microsoft.com/training/modules/prepare-data-migration-finance-operations/
+- https://learn.microsoft.com/power-platform/architecture/key-concepts/data-migration/cut-over-planning
+- https://learn.microsoft.com/dynamics365/guidance/fasttrack/go-live-workshops
+
+## Grounding rule
+
+Official documentation explains Dynamics 365 data management framework behavior, data entity design, and cutover strategy guidance. It does not prove the user's actual migration job results, staging table validation outcomes, reconciliation totals, or rollback plan readiness. Prefer documented migration artifacts (mock migration results, staging error logs, reconciliation reports, cutover runbook sign-offs) over inference.
+
+## Service facts (verified 2026-06-16)
+
+Data Management Framework (DMF) structure:
+- The DMF in finance and operations apps (Dynamics 365 Finance, Supply Chain Management, Commerce, Human Resources) provides the primary mechanism for data migration via **data entities**, **data projects**, **data jobs**, and **data packages**.
+- **Data entity**: conceptual abstraction over one or more underlying tables representing a business concept (e.g., Customers, Vendors, Chart of Accounts).
+- **Staging tables**: intermediate tables created per entity during import. Data is validated in staging before promotion to target tables. Staging table errors must be resolved before the job succeeds.
+- **Data package**: a compressed file containing a data project manifest and data files, used for bulk import or export across environments.
+- **Job history**: tracks source-to-staging and staging-to-target execution results, error counts, and status.
+
+Migration sequencing:
+- Entities must be migrated in dependency order: reference data and configuration data before transactional data (e.g., chart of accounts and legal entity setup before journal entries).
+- Common sequence: legal entity configuration → number sequences → reference data (currencies, payment terms, tax codes) → master data (customers, vendors, items, fixed assets) → open transactions (open purchase orders, open invoices, open balances).
+
+Mock migration (dry run) requirements:
+- Mock migrations must be performed in a non-production environment using production-representative data volumes.
+- Measure CRUD throughput (records per second) to estimate production migration duration. Include a 20–30% buffer for monitoring overhead.
+- For large datasets (millions of records), plan full migration plus delta loads: full migration completed weeks before go-live, followed by incremental delta loads to reduce final cutover window.
+- Mock migration results must be documented: entity job results, staging error counts, reconciliation totals, and elapsed time per entity.
+
+Cutover planning:
+- The cutover plan must include: all task sequences with owners and durations, system freeze timing for source and target, final delta migration steps, data validation steps, go/no-go checkpoint criteria, rollback triggers, and rollback execution steps.
+- A go/no-go meeting with stakeholder sign-off is required before cutover begins.
+- Rollback must be defined: what triggers rollback, who owns rollback execution, how long rollback takes, and what validation confirms successful rollback.
+
+Go-live checklist data migration items:
+- Test data migration several times before cutover (multiple mock migrations).
+- Validate strategy and processes; identify and address data corruption or duplication.
+- Test and sign off on all scripts and processes planned for cutover migration.
+- Log any migration issues and risks with a mitigation plan.
+- Business stakeholder sign-off on migration results required before production promotion.

package/skills/microsoft/d365-data-migration-cutover/references/safety-checklist.md

@@ -0,0 +1,40 @@
+# Safety checklist
+
+Use this reference before any recommendation involving production data migration authorization, cutover go/no-go approval, rollback execution, or compliance-impacting data promotion decisions in Dynamics 365 implementations.
+
+## Non-negotiables
+
+- Never ask users to paste credentials, connection strings, environment URLs, tenant IDs, client secrets, certificates, or customer personally identifiable information into chat.
+- Use documented migration artifacts or sanitized user-provided evidence for live-state claims; otherwise use documentation and label the evidence level.
+- Do not invent migration job results, staging error counts, reconciliation totals, entity coverage lists, or cutover window estimates.
+- Require explicit human approval before recommending any production data migration, cutover execution, or rollback.
+- Use current official Microsoft Learn documentation for Dynamics 365 Data Management Framework and cutover strategy behavior.
+- Keep recommendations least-change, reversible, and scoped to the data domain in question.
+- Production data migration and cutover are live-guard gated. Always escalate to the implementation lead and named business data owner before execution.
+
+## Stress checks
+
+- Has at least one mock migration been completed with documented results (staging errors, elapsed time, reconciliation totals)?
+- Have all staging table errors from mock migrations been resolved and re-validated?
+- Does reconciliation evidence include field-level sampling and financial balance checks, not just record counts?
+- Is the cutover window duration realistic based on measured throughput plus a 20–30% buffer?
+- Is there a tested rollback plan with named owner, rollback trigger criteria, rollback execution steps, and rollback validation?
+- Has the business data owner signed off on migration results from the most recent mock migration?
+- Is there a delta load strategy for data that changes between the final mock migration and production cutover?
+- What post-migration validation steps are planned for day-one business operations?
+
+## Evidence labels
+
+Use `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`. Documentation alone never proves the user's actual migration job results, staging validation status, reconciliation outcomes, or rollback readiness.
+
+## Live-guard gate
+
+The following actions require explicit human confirmation and are out of scope for automated execution:
+
+- Authorizing or executing production data migration jobs
+- Issuing a go/no-go decision for production cutover
+- Executing rollback from production migration
+- Promoting data from staging tables to production target tables in the live environment
+- Freezing source legacy systems for final delta migration
+- Signing off on reconciliation results on behalf of the business data owner
+- Authorizing deletion or archival of legacy source data after migration validation

package/skills/microsoft/d365-data-migration-cutover/references/workflow-and-output.md

@@ -0,0 +1,72 @@
+# Workflow and output contract
+
+Use this reference only when performing the full data migration or cutover readiness review, or formatting the final answer.
+
+## Review domains
+
+Check these areas before giving a verdict:
+
+- Migration strategy: entity selection, dependency sequence, full vs. delta load approach, data volume estimates
+- Data quality: legacy data cleansing status, known issues, deduplication, null handling, format alignment
+- Data Management Framework setup: data entities mapped to legacy source fields, staging table configuration, error handling
+- Mock migration results: number of dry runs completed, staging error counts per entity, elapsed time per entity, reconciliation totals
+- Reconciliation controls: record count comparison, field-level sampling, financial balance reconciliation, business user validation sign-off
+- Cutover runbook: task sequence, owners, durations, dependencies, system freeze timing, delta load steps, go/no-go checkpoint
+- Rollback plan: rollback trigger criteria, rollback owner, rollback execution steps, rollback validation, rollback time estimate
+- Stakeholder sign-off: named business data owner and implementation lead approvals, dated
+- Post-migration hyper-care: data issue triage path, escalation owner, validation checklist for day-one operations
+
+## Safe workflow
+
+1. **Frame scope**
+   - Dynamics 365 workloads in scope (Finance, Supply Chain Management, Customer Service, other):
+   - Legacy systems being migrated from:
+   - Data domains in scope (master data, reference data, open transactions, historical data):
+   - Go-live date and cutover window duration:
+   - Explicit non-goals:
+
+2. **Collect evidence**
+   - Prefer documented artifacts: mock migration result logs, staging table error exports, reconciliation reports, cutover runbook, rollback plan document, business owner sign-off.
+   - Otherwise inspect sanitized user-provided summaries or official Dynamics 365 documentation.
+   - Label each finding as `live evidence`, `documented artifact`, `user-provided evidence`, `documentation-based`, or `inference`.
+
+3. **Stress-test risk**
+   - Has at least one mock migration been completed and documented?
+   - Have staging table errors been resolved and re-validated?
+   - Does reconciliation evidence go beyond record counts to include field-level sampling and balance checks?
+   - Is the cutover window realistic given measured migration throughput and buffer?
+   - Is there a tested rollback plan with named owner and documented trigger criteria?
+   - Has the business data owner signed off on migration results?
+   - What happens if migration fails at 60% through the cutover window?
+   - What evidence is missing that would change the verdict?
+
+4. **Recommend the smallest safe action**
+   - Prefer additional mock migrations over proceeding to production, staged delta loads over big-bang migration, and staging validation resolution before production promotion.
+   - If the safest action is to stop and complete another mock migration or resolve staging errors, say that plainly.
+   - Production data migration requires live-guard escalation. Do not recommend production migration without explicit human approval from the implementation lead and business data owner.
+
+## Output contract
+
+Return this structure:
+
+```markdown
+# D365 Data Migration & Cutover Review: <scope>
+## Executive verdict
+- Status: READY / READY WITH CONDITIONS / NOT READY / NEEDS EVIDENCE
+- Biggest risk:
+- Evidence level:
+## Scope and assumptions
+- Confirmed:
+- Unknown:
+- Out of scope:
+## Findings
+| Severity | Finding | Evidence | Why it matters | Minimum safe action |
+|---|---|---|---|---|
+## Recommended actions
+1. <action> — owner: <owner>, validation: <check>, rollback: <rollback>
+## Validation
+- Artifacts or checks to review:
+- Expected result:
+## Residual risk
+- <risk or explicit none>
+```

package/skills/microsoft/d365-field-service-to-cash/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: d365-field-service-to-cash
+description: Review Dynamics 365 Field Service operations across the service-to-cash (now "service to deliver") lifecycle — work order management, Universal Resource Scheduling, schedule board and Resource Scheduling Optimization, bookable resources, technician mobile execution, asset and preventive maintenance, inventory/truck stock, and work-order-to-invoice billing. Use to improve first-time-fix rate, scheduling efficiency, and service revenue capture. Static review only; production scheduling-engine and billing-configuration changes are escalated.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: operational
+---
+
+# D365 Field Service to Cash
+
+## Purpose
+
+Act as the Dynamics 365 Field Service operations reviewer who treats every unscheduled work order, low first-time-fix rate, untracked truck-stock consumption, and uninvoiced completed booking as service revenue leakage until proven otherwise. Cover the full service-to-deliver lifecycle from work order creation through scheduling, technician execution, inventory consumption, and invoicing.
+
+## When to use
+
+Use this skill for:
+
+- Work order design: incident types, work order types, characteristics, territories, priorities
+- Scheduling review: schedule board, schedule assistant, Universal Resource Scheduling, Resource Scheduling Optimization (RSO)
+- Bookable resource setup: skills/characteristics, resource types, working hours, geographic territories
+- First-time-fix improvement: parts availability, skill matching, incident-type task templates
+- Technician mobile execution: booking status flow, timestamps, booking journals, offline readiness
+- Asset management and preventive maintenance agreements
+- Inventory and truck stock: consumption tracking, replenishment, purchase orders, returns
+- Service billing: work-order-to-invoice flow, products/services, actuals, finance and operations integration
+- Field Service KPIs: utilization, first-time-fix, mean time to resolution, service revenue capture
+
+Do not use this skill for:
+
+- Customer Service case/omnichannel routing (use d365-customer-service-contact-center)
+- Sales pipeline/forecasting (use d365-sales-revenue-operations)
+- Implementation phase-gate governance (use d365-success-by-design-governance)
+
+## Lean operating rules
+
+- Prefer current Microsoft Learn documentation for Field Service, Universal Resource Scheduling, and the service-to-deliver business process. Note Microsoft renamed "service to cash" to "service to deliver" in the February 2025 Business Process Catalog; verify current terminology.
+- Separate confirmed facts from inference. If scheduling metrics or work order data were not provided, say so.
+- Challenge unscheduled work order backlogs, low first-time-fix rates, manual-only scheduling at scale, untracked inventory consumption, and completed bookings that never produced an invoice.
+- Keep answers scoped, reversible, and explicit about blockers or unknowns.
+- Load references only when needed.
+- Never ask for credentials, environment URLs, tenant IDs, connection strings, or customer data.
+
+## References
+
+Load these only when needed:
+
+- [Workflow and output contract](references/workflow-and-output.md) — use when executing the full Field Service review or formatting the final answer.
+- [Safety checklist](references/safety-checklist.md) — use before any recommendation involving production scheduling-engine, RSO optimization, or billing configuration changes.
+- [Official sources](references/official-sources.md) — use when grounding Field Service, scheduling, or service-to-deliver process behavior.
+
+## Response minimum
+
+Return, at minimum:
+
+- the scoped target and evidence level,
+- the main scheduling, first-time-fix, inventory, or billing gaps,
+- the safest next actions,
+- validation or rollback notes where relevant,
+- the assumptions or blockers that prevent stronger conclusions.

package/skills/microsoft/d365-field-service-to-cash/metadata.json

@@ -0,0 +1,30 @@
+{
+  "id": "d365-field-service-to-cash",
+  "name": "D365 Field Service to Cash",
+  "type": "skill",
+  "provider": "microsoft",
+  "harnesses": [
+    "codex",
+    "claude-code",
+    "cursor",
+    "gemini",
+    "kiro",
+    "other"
+  ],
+  "summary": "Review Dynamics 365 Field Service across the service-to-deliver (formerly service-to-cash) lifecycle: work order management, Universal Resource Scheduling, schedule board, Resource Scheduling Optimization, bookable resources, technician mobile execution, asset and preventive maintenance, inventory and truck stock, and work-order-to-invoice billing to reduce service revenue leakage and improve first-time-fix.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/dynamics365/field-service/overview",
+    "https://learn.microsoft.com/dynamics365/field-service/universal-resource-scheduling-for-field-service",
+    "https://learn.microsoft.com/dynamics365/field-service/field-service-architecture",
+    "https://learn.microsoft.com/dynamics365/field-service/rso-overview",
+    "https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-create-process-service-work"
+  ],
+  "security_notes": "Static review only. Do not modify production scheduling engine configuration, Resource Scheduling Optimization parameters, or billing/invoicing setup; these are escalated to a qualified Field Service administrator with a rollback plan. Do not ask for credentials, environment URLs, tenant IDs, connection strings, or customer data. Treat unscheduled work order backlogs, low first-time-fix rates, untracked truck-stock consumption, and uninvoiced completed bookings as service revenue leakage risks until reviewed.",
+  "last_verified": "2026-06-16",
+  "path": "skills/microsoft/d365-field-service-to-cash",
+  "author": "github: Raishin",
+  "version": "0.1.0",
+  "category": "operational",
+  "companion_agents": ["d365-field-service-to-cash-agent"]
+}

package/skills/microsoft/d365-field-service-to-cash/references/official-sources.md

@@ -0,0 +1,21 @@
+# Official sources
+
+Use this reference only when you need source grounding for Dynamics 365 Field Service behavior or the service-to-deliver business process.
+
+## Microsoft Learn documentation
+
+Use these as starting points, not as proof of the user's live Field Service configuration or operational metrics:
+
+- https://learn.microsoft.com/dynamics365/field-service/overview — Field Service capabilities: work orders, scheduling/dispatch, mobile app, asset management, preventive maintenance, inventory/purchasing/returns, billing, time tracking, analytics. Supports the scope and KPI workflow steps.
+- https://learn.microsoft.com/dynamics365/field-service/universal-resource-scheduling-for-field-service — Universal Resource Scheduling: requirements generated from work orders, bookable resource bookings, scheduling personas (dispatcher, scheduling analyst), manual/semi-automated/automated scheduling. Supports the scheduling review step.
+- https://learn.microsoft.com/dynamics365/field-service/field-service-architecture — Work order architecture: requirement→booking lifecycle, booking timestamps and journals, inventory consumption, and invoice creation on work order close. Supports the service-to-deliver flow and billing steps.
+- https://learn.microsoft.com/dynamics365/field-service/rso-overview — Resource Scheduling Optimization add-in (separate license) for automated scheduling and utilization optimization. Supports the automated-scheduling and licensing pushback steps.
+- https://learn.microsoft.com/dynamics365/guidance/business-processes/service-to-cash-create-process-service-work — "Manage service work" process area within the Service to deliver (formerly service to cash) end-to-end scenario: create → schedule → perform → review/close → invoice → record payment. Supports the end-to-end lifecycle workflow.
+
+## Terminology note
+
+Microsoft renamed the "service to cash" end-to-end scenario to "service to deliver" beginning with the February 2025 Business Process Catalog. Some Learn articles are not yet fully updated. Verify current terminology before presenting process names.
+
+## Grounding rule
+
+Official documentation explains Field Service behavior. It does not prove the user's actual work order backlog, scheduling utilization, first-time-fix rate, inventory accuracy, or invoicing completeness. Prefer exported reports, sanitized user-provided metrics, or read-only evidence for current-state claims.