@raishin/vanguard-frontier-agentic 2.9.0 → 2.11.0

package/skills/cross-functional/environment-to-production-release-protocol/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: environment-to-production-release-protocol
+description: Use this skill when a Power Platform or Dynamics 365 solution must progress through a structured dev-to-test-to-production release pipeline using managed solutions and Power Platform pipelines, when rollback readiness must be verified before go-live, or when a deployment approval gate must be enforced. Defines the full ALM release flow — solution packaging, pipeline stage progression, pre-deployment validation, approval, deployment, rollback verification, and post-deployment confirmation. Does not authorize production deployments directly; all production-impacting actions require human approval from the environment owner or release manager. Does not replace a qualified Power Platform admin or ALM specialist.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: delivery
+  lifecycle: experimental
+---
+
+# Environment-to-Production Release Protocol
+
+## Purpose
+This skill defines how Power Platform and Dynamics 365 solutions are packaged, validated, and promoted from development through test to production using managed solutions and Power Platform pipelines. It enforces the principle that only managed solutions reach production environments, that every deployment stage is preceded by pre-flight validation, and that a tested rollback path exists before a production deployment is approved. No agent authorizes a production deployment; that is a human decision by the environment owner or release manager.
+
+## When to use
+- A solution in a development environment is ready to be promoted to test or production via a Power Platform pipeline.
+- A release manager needs a structured checklist and gate review before approving a production deployment.
+- A rollback plan must be confirmed and tested before a go-live window opens.
+- A Copilot Studio agent or Power Automate flow packaged in a solution needs to be promoted through ALM stages.
+- A deployment failed and a structured rollback or recovery must be initiated.
+
+## When NOT to use
+- The solution has not been exported as a managed solution — unmanaged solutions must not be deployed to test or production.
+- The pipeline has not been configured by an admin in the Power Platform admin center — ad hoc deployments bypass this protocol.
+- The matter is a hotfix to an already-live production environment requiring emergency change procedures — use the change-request-to-go-live-protocol with expedited gates instead.
+- The deployment targets an environment outside Power Platform (e.g., pure Azure infrastructure) — this protocol does not cover Azure DevOps pipelines for non-Power Platform workloads.
+
+## Participating agents
+- `power-platform-alm-pipelines-agent` — primary: validates solution packaging, pipeline stage configuration, dependency checks, and deployment readiness
+- `copilot-studio-agent-governance-alm-agent` — secondary: validates Copilot Studio agent configurations, topic schemas, and governance controls packaged in the solution
+
+## Inputs required
+- Solution name and version (current and new)
+- Target pipeline and stage ID (from Power Platform pipelines configuration)
+- Development environment reference
+- Target environment reference (test or production)
+- Connection references and environment variable values for target environment
+- Rollback plan or prior deployment artifact reference
+
+## Evidence required
+- Power Platform pipeline configuration (pipeline name, stages, environments)
+- Solution checker results (no critical violations)
+- Connection reference and environment variable configuration status for target environment
+- Prior deployment history (if available) from the Power Platform admin center deployment hub
+- Approval records from prior pipeline stages (test must be deployed before production)
+
+## Workflow
+
+1. **Validate solution packaging** — confirm the solution is exported as managed; confirm the version is incremented; confirm no unmanaged layers will be left in the target environment.
+2. **Run pre-flight checks** — execute Power Platform solution checker against the solution; flag any critical or high-severity violations; confirm all solution dependencies are present in the target environment.
+3. **Verify pipeline stage order** — confirm that the solution has been deployed to all prerequisite stages (e.g., test before production) per the pipeline configuration; pipelines enforce stage order and the same solution version is promoted.
+4. **Validate connection references and environment variables** — confirm all connection references are configured and valid in the target environment; confirm environment variable values are set; flag any missing configurations.
+5. **Confirm rollback artifact** — verify that a prior managed solution version (or unmanaged recovery artifact) is available and documented in the deployment history; confirm rollback steps are written and owner is identified.
+6. **Escalation gate: managed-solution-only in production** — if the solution is unmanaged or contains unmanaged layers targeting production, stop and refuse; escalate to Power Platform admin.
+7. **Escalation gate: rollback tested** — confirm rollback procedure has been rehearsed or can be executed from deployment history; if untested, flag as risk item and require release manager acknowledgment before proceeding.
+8. **Escalation gate: approval** — require human approval from environment owner or release manager before deploying to production; record approval reference.
+9. **Initiate pipeline deployment** — invoke the pipeline deployment for the confirmed stage; monitor deployment status (in-progress, succeeded, failed, canceled).
+10. **Post-deployment validation** — confirm solution import succeeded; validate connection references are live; run smoke tests or confirm with functional owner that critical paths are working.
+11. **Hypercare confirmation** — confirm hypercare period start; identify support owner for post-deployment issues; schedule post-deployment review.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Managed-solution-only | Solution is unmanaged OR contains unmanaged layers targeting production | Stop; refuse; escalate to Power Platform admin |
+| Rollback tested | Rollback plan is undocumented or untested | Flag; require release manager acknowledgment; do not deploy until acknowledged |
+| Approval | Human approval from environment owner or release manager not on record | Hold; do not initiate deployment; escalate to release manager |
+| Pre-flight failures | Solution checker returns critical violations OR dependencies missing | Stop; return to development for remediation |
+| Stage order | Test stage not successfully completed before production stage | Stop; enforce stage order per pipeline configuration |
+
+## Refusal triggers
+- A request is made to bypass pipeline stage order and deploy directly to production — refuse; enforce stage order.
+- A request is made to deploy an unmanaged solution to a production or test environment — refuse; only managed solutions may be deployed to non-development environments.
+- Credentials, service principal secrets, or tenant IDs are requested to initiate or validate a deployment — refuse; work from sanitized configuration signals only.
+- A rollback path does not exist and the release manager has not acknowledged the risk — refuse to proceed until acknowledged.
+
+## Handoff rules
+- Every handoff carries: solution name, version, pipeline name, stage, deployment status, pre-flight results, connection reference status, rollback plan reference, approval reference, open questions, and a do-not-do list.
+- No agent triggers a production deployment without a recorded human approval.
+- Post-deployment, the primary agent confirms deployment success and hands off to the functional owner for hypercare.
+
+## KPIs
+- Percentage of production deployments that pass all gates without a manual override
+- Number of deployment failures requiring rollback
+- Time from solution packaging to production deployment approval
+- Rollback execution time (from failure detection to rollback completion)
+
+## References
+- [Overview of pipelines in Power Platform](https://learn.microsoft.com/power-platform/alm/pipelines)
+- [Run pipelines in Power Platform](https://learn.microsoft.com/power-platform/alm/run-pipeline)
+- [Admin deployment page in Power Platform](https://learn.microsoft.com/power-platform/alm/admin-deployment-hub)
+- [Recommendations for standardizing tools and processes — Power Platform ALM](https://learn.microsoft.com/power-platform/well-architected/operational-excellence/tools-processes)

package/skills/cross-functional/environment-to-production-release-protocol/metadata.json

@@ -0,0 +1,20 @@
+{
+  "id": "environment-to-production-release-protocol",
+  "name": "Environment-to-Production Release Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Defines the structured ALM release flow for Power Platform and Dynamics 365 solutions from development through test to production using managed solutions and Power Platform pipelines. Enforces managed-solution-only deployment to production, pipeline stage order, pre-flight validation via solution checker, connection reference and environment variable verification, rollback plan confirmation, and human approval gates before any production-impacting deployment action.",
+  "source_type": "original",
+  "official_docs": [
+    "https://learn.microsoft.com/power-platform/alm/pipelines",
+    "https://learn.microsoft.com/power-platform/alm/run-pipeline",
+    "https://learn.microsoft.com/power-platform/alm/admin-deployment-hub",
+    "https://learn.microsoft.com/power-platform/well-architected/operational-excellence/tools-processes"
+  ],
+  "security_notes": "Protocol is recommendation and orchestration only — never an authorization for production deployments. All production-impacting deployment actions require explicit human approval from the environment owner or release manager, recorded before the deployment is initiated. Only managed solutions may be deployed to test or production environments; unmanaged solutions targeting non-development environments are a hard refusal trigger. Never requests credentials, service principal secrets, tenant IDs, or customer data to validate or initiate a deployment; works from sanitized pipeline configuration and solution metadata signals only. Rollback plan must be documented and acknowledged before production deployment proceeds.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/environment-to-production-release-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}

package/skills/cross-functional/environment-to-production-release-protocol/references/workflow-and-output.md

@@ -0,0 +1,214 @@
+# Environment-to-Production Release Protocol — Detailed Workflow and Output Contract
+
+## Overview
+
+This document provides the step-by-step workflow, decision tree, and output contract for the `environment-to-production-release-protocol` skill. It is the reference for `power-platform-alm-pipelines-agent`, `copilot-studio-agent-governance-alm-agent`, and human release managers who need to understand the gate structure, the deployment record format, and the rollback initiation procedure.
+
+---
+
+## Detailed Workflow
+
+### Phase 1 — Release Candidate Preparation
+
+**Step 1.1 — Solution packaging validation**
+- Confirm solution is exported as a managed solution (not unmanaged)
+- Confirm version number is incremented from the last deployed version in the target environment
+- Confirm no unmanaged layers targeting test or production environments
+- Output: `solution_package_record` with `solution_name`, `version`, `managed: true|false`, `version_increment_confirmed: true|false`
+
+**Step 1.2 — Solution checker execution**
+- Run Power Platform solution checker against the managed solution
+- Severity thresholds:
+  - Critical violations: deployment is blocked until remediated
+  - High violations: flagged; release manager must acknowledge before proceeding
+  - Medium / Low: recorded; no block
+- Output: `solution_checker_result` with `critical_count`, `high_count`, `medium_count`, `low_count`, `check_passed: true|false`
+
+**Step 1.3 — Dependency verification**
+- Confirm all solution dependencies (other solutions, components) are present and at the required version in the target environment
+- Flag any missing or mismatched dependencies
+- Output: `dependency_check` with `all_satisfied: true|false`, `missing_dependencies[]`
+
+---
+
+### Phase 2 — Pipeline Stage Validation
+
+**Step 2.1 — Confirm pipeline configuration**
+- Confirm the pipeline is configured in the Power Platform admin center or a custom host environment
+- Confirm the pipeline stages exist and the target stage is the next valid stage in sequence
+- Power Platform pipelines enforce stage order: you cannot deploy to production before test has succeeded with the same solution version
+- Output: `pipeline_stage_check` with `pipeline_name`, `stage_name`, `stage_order_valid: true|false`, `prior_stage_status`
+
+**Step 2.2 — Connection references and environment variables**
+- Confirm all connection references in the solution are configured and have valid connections in the target environment
+- Confirm all required environment variable values are set for the target environment
+- Output: `config_readiness` with `connection_refs_status: ready|incomplete`, `env_vars_status: ready|incomplete`, `missing_items[]`
+
+**Step 2.3 — Rollback artifact confirmation**
+- Confirm that a prior successful managed solution deployment exists in the deployment history for the target environment (recoverable from pipelines host)
+- Confirm rollback steps are documented and a named rollback owner is identified
+- Output: `rollback_readiness` with `prior_artifact_available: true|false`, `rollback_steps_documented: true|false`, `rollback_owner`
+
+---
+
+### Phase 3 — Gate Enforcement
+
+**Gate 1 — Managed-Solution-Only Gate**
+```
+IF solution_package_record.managed = false
+OR unmanaged_layers_in_target = true:
+  → STOP
+  → Refuse deployment
+  → Escalate to Power Platform admin
+  → Do NOT proceed until solution is re-exported as managed
+```
+
+**Gate 2 — Pre-Flight Gate**
+```
+IF solution_checker_result.critical_count > 0
+OR dependency_check.all_satisfied = false:
+  → STOP
+  → Return to development for remediation
+  → Do NOT initiate pipeline deployment
+```
+
+**Gate 3 — Stage Order Gate**
+```
+IF pipeline_stage_check.stage_order_valid = false:
+  → STOP
+  → Enforce stage progression
+  → Do NOT skip stages
+```
+
+**Gate 4 — Configuration Readiness Gate**
+```
+IF config_readiness.connection_refs_status = incomplete
+OR config_readiness.env_vars_status = incomplete:
+  → PAUSE
+  → Escalate to environment owner to complete configuration
+  → Do NOT deploy until all connection references and env vars are ready
+```
+
+**Gate 5 — Rollback Tested Gate**
+```
+IF rollback_readiness.prior_artifact_available = false
+OR rollback_readiness.rollback_steps_documented = false:
+  → FLAG as risk item
+  → Require release manager written acknowledgment before proceeding
+  → Record acknowledgment reference in deployment record
+```
+
+**Gate 6 — Human Approval Gate**
+```
+ALWAYS required before production deployment:
+  → Request approval from environment owner or release manager
+  → Record: approver_id, approval_timestamp, approval_reference
+  → Do NOT initiate production deployment without recorded approval
+```
+
+---
+
+### Phase 4 — Deployment Execution
+
+**Step 4.1 — Initiate pipeline deployment**
+- Trigger pipeline deployment for the confirmed stage and solution version
+- Monitor status: in-progress → succeeded | failed | canceled
+- Record: `deployment_run_id`, `start_time`, `end_time`, `status`
+
+**Step 4.2 — Deployment failure handling**
+```
+IF deployment status = failed:
+  → Capture failure reason from deployment log
+  → Assess: is rollback required? (data migration, custom connector changes may require rollback)
+  → If rollback required: initiate rollback procedure with rollback owner
+  → Escalate to release manager with failure summary and rollback status
+  → Do NOT retry deployment without root cause identified
+```
+
+---
+
+### Phase 5 — Post-Deployment Confirmation
+
+**Step 5.1 — Post-deployment validation**
+- Confirm solution import status in target environment
+- Confirm connection references are live (not in error state)
+- Confirm environment variables are applied
+- Request functional owner smoke-test confirmation for critical user paths
+- Output: `post_deployment_validation` with `import_status`, `connection_refs_live: true|false`, `smoke_test_status: passed|pending|failed`
+
+**Step 5.2 — Hypercare initiation**
+- Record hypercare period start date and end date
+- Confirm hypercare support owner is identified
+- Schedule post-deployment review meeting
+- Output: `hypercare_record` with `start_date`, `end_date`, `support_owner`, `review_scheduled_date`
+
+---
+
+## Decision Tree (Condensed)
+
+```
+Solution ready for promotion
+  └─ Gate 1: Managed solution? → No → STOP
+       └─ Gate 2: Pre-flight clear? → No → STOP (return to dev)
+            └─ Gate 3: Stage order valid? → No → STOP
+                 └─ Gate 4: Config ready? → No → PAUSE
+                      └─ Gate 5: Rollback documented? → No → FLAG + require acknowledgment
+                           └─ Gate 6: Human approval? → Not received → HOLD
+                                └─ Initiate pipeline deployment
+                                     ├─ Failed → Assess rollback → Escalate
+                                     └─ Succeeded → Post-deployment validation → Hypercare
+```
+
+---
+
+## Output Contract
+
+### Deployment Record
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `deployment_record_id` | string (UUID) | Yes | Unique deployment identifier |
+| `skill_id` | string | Yes | Must be `environment-to-production-release-protocol` |
+| `skill_version` | string | Yes | Semantic version |
+| `solution_name` | string | Yes | Power Platform solution name |
+| `solution_version` | string | Yes | Managed solution version |
+| `pipeline_name` | string | Yes | Pipeline name from pipelines configuration |
+| `stage_name` | string | Yes | Target deployment stage |
+| `target_environment` | string | Yes | Environment display name or ID |
+| `gates_passed` | string[] | Yes | Which gates were cleared |
+| `gates_blocked` | string[] | Yes | Which gates fired a stop or hold |
+| `approval_reference` | string | Yes (for production) | Approver ID + timestamp |
+| `rollback_owner` | string | Yes | Named rollback responsible party |
+| `deployment_status` | enum | Yes | `succeeded | failed | canceled | in_progress` |
+| `post_deployment_validation` | object | Yes | Import status, connection ref status, smoke test |
+| `hypercare_record` | object | Yes | Start/end dates, support owner |
+| `do_not_do_list` | string[] | Yes | Mandatory refusal items |
+| `open_questions` | string[] | Yes | Unresolved items for human judgment |
+| `timestamp` | string (ISO) | Yes | Deployment record creation datetime |
+
+### Do-Not-Do List (always attached)
+
+- Do not deploy an unmanaged solution to a test or production environment.
+- Do not skip pipeline stage order; test must succeed before production is attempted.
+- Do not initiate a production deployment without a recorded human approval.
+- Do not proceed without a documented rollback plan and named rollback owner.
+- Do not request service principal credentials, tenant IDs, or customer data to validate a deployment.
+- Do not retry a failed deployment without identifying the root cause first.
+
+---
+
+## Rollback Initiation Procedure
+
+1. Release manager declares rollback required.
+2. Identify the prior managed solution version from the deployment history in the Power Platform admin center deployment hub (Import Solutions from Pipelines Host feature).
+3. Import the prior managed solution version to the target environment using the standard import path.
+4. Confirm all connection references and environment variables are correctly set for the restored version.
+5. Run post-deployment validation for the restored version.
+6. Document rollback completion in the deployment record.
+7. Schedule a root-cause analysis for the failed deployment.
+
+---
+
+## Audit Log Fields
+
+`deployment_record_id`, `skill_id`, `skill_version`, `invoked_by`, `solution_name`, `solution_version`, `stage_name`, `target_environment`, `gates_passed`, `gates_blocked`, `approval_reference`, `deployment_status`, `timestamp`

package/skills/cross-functional/erp-crm-cutover-protocol/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: erp-crm-cutover-protocol
+description: Use this skill when a Dynamics 365 ERP or CRM implementation is approaching go-live and must progress through mock migration, data reconciliation, cutover runbook execution, rollback testing, and the Success by Design go-live gate before production switchover. Orchestrates d365-data-migration-cutover-agent as primary, d365-success-by-design-governance-agent for SbD gate sign-off, and d365-security-sod-governance-agent for separation-of-duties validation. Gates include reconciliation sign-off, rollback readiness, and SbD go-live gate. Never makes the go/no-go decision autonomously; all production-impacting steps require human owner and Microsoft FastTrack confirmation where applicable.
+allowed-tools: Read Grep Glob
+metadata:
+  author: "github: Raishin"
+  version: "0.1.0"
+  updated: "2026-06-16"
+  category: data
+  lifecycle: experimental
+---
+
+# ERP / CRM Cutover Protocol
+
+## Purpose
+This skill defines the controlled sequence for taking a Dynamics 365 ERP or CRM
+implementation from pre-production readiness through mock migration, data
+reconciliation, runbook execution, rollback validation, and the Success by
+Design (SbD) go-live gate to production go-live. It exists so that no cutover
+proceeds without tested rollback paths, reconciled data, and explicit stakeholder
+sign-off at each gate. It does not execute migration scripts or production
+deployments; it structures the process so human owners can make well-informed
+go/no-go decisions.
+
+## When to use
+- A Dynamics 365 Finance, Supply Chain Management, Customer Engagement, or
+  Business Central implementation is entering the Prepare phase and a cutover
+  plan must be validated.
+- A mock cutover has been completed and reconciliation findings must be reviewed
+  before the real cutover is authorised.
+- An organisation needs to confirm SbD go-live gate criteria before requesting
+  Microsoft FastTrack go-live readiness review.
+- An existing production environment must be refreshed or migrated to a new
+  release and cutover risk must be assessed.
+
+## When NOT to use
+- The go-live has already completed and this is post-go-live hypercare support
+  — use the hypercare support runbook instead.
+- The migration involves a third-party ERP not on the Dynamics 365 platform —
+  this protocol is scoped to Dynamics 365.
+- You need live production database or environment access to execute migration
+  scripts — that requires the infrastructure owner; this protocol is
+  recommendation-only.
+
+## Participating agents
+- `d365-data-migration-cutover-agent` (primary — mock migration, data reconciliation, cutover runbook, rollback plan)
+- `d365-success-by-design-governance-agent` (SbD gate review, go-live readiness sign-off)
+- `d365-security-sod-governance-agent` (separation of duties validation, security role sign-off)
+
+## Inputs required
+- Cutover plan document (task list, owners, timing, rollback steps)
+- Data migration strategy and scripts (for review, not execution)
+- Mock cutover results from sandbox environment (including error log)
+- Go-live checklist status from the SbD Prepare phase
+- Security role assignments and SoD analysis for go-live users
+- Integration test results and external dependency sign-off
+
+## Evidence required
+- At least one successful mock cutover has been completed in a sandbox
+  environment that mirrors production
+- UAT has been completed and signed off by business stakeholders
+- Performance testing is complete and SLAs are met
+- Production environment is provisioned and matches the version in
+  development/test environments
+- Rollback plan has been tested and timing confirmed
+
+## Workflow
+
+1. **Mock cutover review** — Review mock cutover results. Identify all errors,
+   timing overruns, and unresolved issues. Confirm the mock was run with
+   production-representative data and all integration steps.
+2. **Data reconciliation** — Validate that migrated data matches source records
+   within agreed tolerance thresholds. Identify exceptions and require sign-off
+   from the data owner on accepted variances.
+3. **Gate 1 — Reconciliation sign-off** — Data owner and project lead must
+   formally sign off that reconciliation thresholds are met. d365-data-migration-
+   cutover-agent produces the reconciliation report. Do not proceed without
+   this sign-off.
+4. **Rollback plan validation** — Confirm the rollback plan is documented,
+   tested, and timed. Confirm who has authority to invoke rollback and the
+   criteria that trigger it.
+5. **Gate 2 — Rollback tested** — Confirm rollback has been rehearsed in the
+   sandbox. d365-data-migration-cutover-agent attests rollback is feasible
+   within the cutover window. Do not proceed without this confirmation.
+6. **SoD validation** — d365-security-sod-governance-agent reviews production
+   security role assignments for separation-of-duties violations. Flag any
+   violations for remediation before go-live.
+7. **SbD go-live gate** — d365-success-by-design-governance-agent runs the SbD
+   go-live readiness review against the full go-live checklist: solution scope,
+   UAT sign-off, performance, integrations, data migration, change management,
+   support readiness. Produce a go/conditional-go/no-go recommendation.
+8. **Gate 3 — SbD go-live gate sign-off** — Project steering committee and
+   Microsoft FastTrack (where applicable) must confirm the go-live gate.
+   This protocol never issues the final go/no-go autonomously.
+9. **Cutover execution readiness** — Confirm all people, environments, and
+   communication plans are in place. Verify the cutover window is realistic
+   given mock timing plus buffer.
+10. **Post-cutover validation** — After go-live, confirm data accuracy in
+    production, integration health, and user access. Invoke hypercare plan.
+
+## Decision gates
+
+| Gate | Condition | Action |
+|---|---|---|
+| Reconciliation sign-off | Data variances exceed agreed thresholds | Stop cutover; require data owner resolution |
+| Rollback tested | Rollback not rehearsed or timing exceeds window | Stop cutover; require rollback rehearsal |
+| SoD violations | Production roles contain SoD conflicts | Escalate to d365-security-sod-governance-agent; remediate before go-live |
+| SbD go-live gate | Any SbD blocking issues unresolved | Stop cutover; require issue owner sign-off |
+| Mock cutover errors | Critical errors unresolved from mock | Stop cutover; require second mock |
+
+## Refusal triggers
+- Stop if no successful mock cutover has been completed — do not recommend
+  production go-live without at least one successful rehearsal.
+- Stop if reconciliation sign-off has not been obtained from the data owner.
+- Stop if the rollback plan is untested or the rollback window exceeds what
+  the business can tolerate.
+- Stop if SbD blocking issues are unresolved — do not substitute judgement
+  for the SbD gate process.
+- Stop if credentials, production org IDs, or customer data are requested
+  as inputs to this protocol — refuse and escalate.
+
+## Handoff rules
+- All handoffs carry: project_id, skill_id, skill_version, invoked_by,
+  gate_status, open_issues, rollback_status, sbd_verdict, do_not_do_list.
+- Human go/no-go decisions are always documented with decision-maker name,
+  date, and statement of accepted risk.
+- SbD gate sign-off from d365-success-by-design-governance-agent is the
+  minimum required before any production cutover recommendation.
+
+## KPIs
+- Mock cutover success rate (errors per rehearsal)
+- Data reconciliation pass rate (% within tolerance)
+- Rollback rehearsal completion (yes/no with timing)
+- SbD go-live gate outcome (go / conditional-go / no-go)
+- Actual vs. planned cutover window duration
+
+## References
+- 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/guidance/fasttrack/go-live-workshops
+- https://learn.microsoft.com/dynamics365/guidance/implementation-guide/success-by-design

package/skills/cross-functional/erp-crm-cutover-protocol/metadata.json

@@ -0,0 +1,21 @@
+{
+  "id": "erp-crm-cutover-protocol",
+  "name": "ERP / CRM Cutover Protocol",
+  "type": "skill",
+  "provider": "generic",
+  "harnesses": ["codex", "claude-code", "cursor", "gemini", "kiro", "other"],
+  "summary": "Controlled go-live protocol for Dynamics 365 ERP and CRM implementations. Sequences mock migration, data reconciliation sign-off, cutover runbook validation, rollback rehearsal, Success by Design (SbD) go-live gate, and separation-of-duties review before the production switchover recommendation is produced. No cutover proceeds without reconciliation sign-off, a tested rollback plan, and SbD gate approval. The go/no-go decision is always made by the human project steering committee; this protocol never authorises a production go-live autonomously.",
+  "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/guidance/fasttrack/go-live-workshops",
+    "https://learn.microsoft.com/dynamics365/guidance/implementation-guide/success-by-design"
+  ],
+  "security_notes": "This protocol is a recommendation and orchestration aid only; it is never an authorisation to execute a production migration, cutover, or go-live. It never requests production environment credentials, database connection strings, org IDs, or customer data as protocol inputs. The go/no-go decision requires explicit sign-off from the human project steering committee and Microsoft FastTrack (where applicable). Reconciliation sign-off must come from the named data owner; estimated or assumed sign-off is refused. Rollback plans that have not been rehearsed in a sandbox block the cutover recommendation unconditionally. Separation-of-duties violations in production security roles must be remediated before go-live is recommended. All SbD blocking issues require the named issue owner to confirm resolution before the SbD gate is cleared.",
+  "last_verified": "2026-06-16",
+  "path": "skills/cross-functional/erp-crm-cutover-protocol",
+  "author": "github: Raishin",
+  "version": "0.1.0"
+}