Claude Cursor GitHub Copilot Skill

environment-to-production-release-protocol

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

LLM Mart · 0 points · 0 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download vincentchuwaichow-vanguard-frontier-agentic-skills_cross-functional_environment-to-production-release-protocol-febe32a.zip · 7 KB

vincentchuwaichow/vanguard-frontier-agentic 24 3 forks Apache-2.0 Updated 11h ago

Part of vincentchuwaichow/vanguard-frontier-agentic — 293 skills

Install

skills CLI

npx skills add https://github.com/VincentChuWaiChow/vanguard-frontier-agentic/tree/master/skills/cross-functional/environment-to-production-release-protocol

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install vincentchuwaichow-vanguard-frontier-agentic@llmmart

Git git clone https://github.com/VincentChuWaiChow/vanguard-frontier-agentic.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole vincentchuwaichow/vanguard-frontier-agentic collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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

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.
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.
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.
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.
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.
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.
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.
Escalation gate: approval — require human approval from environment owner or release manager before deploying to production; record approval reference.
Initiate pipeline deployment — invoke the pipeline deployment for the confirmed stage; monitor deployment status (in-progress, succeeded, failed, canceled).
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.
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

Files (vanguard-frontier-agentic)

references

workflow-and-output.md 9.6 KB

# 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`

metadata.json 2 KB

{
  "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: VincentChuWaiChow",
  "version": "0.1.0"
}

SKILL.md 8.5 KB

---
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: VincentChuWaiChow"
  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)