| name | containerize-deploy |
| description | Complete end-to-end workflow for containerizing and deploying applications to OpenShift or standalone RHEL systems. Orchestrates /detect-project, /s2i-build, /deploy, /helm-deploy, and /rhel-deploy skills with user confirmation checkpoints at each phase. Supports S2I, Podman, Helm deployment strategies for OpenShift, and Podman/native deployments for RHEL hosts. Use this skill when user wants to go from source code to running application in one guided workflow. Supports resume after interruption and rollback on failure. Triggers on /containerize-deploy command.
|
| model | inherit |
| color | green |
| license | Apache-2.0 |
| allowed-tools | resources_list resources_get resources_create_or_update pods_list pods_list_in_namespace pods_log events_list get_file_contents helm_list helm_install inventory__find_host_by_name vulnerability__get_system_cves planning__get_rhel_lifecycle |
| metadata | {"user_invocable":"true"} |
/containerize-deploy Skill
Provide a complete, guided workflow from local source code to running application on OpenShift or standalone RHEL systems. This skill orchestrates /detect-project, /s2i-build, /deploy, /helm-deploy, and /rhel-deploy with clear user checkpoints at each phase.
Overview
[Intro] → [Detect] → [Target] → [Strategy] ──┬─→ [OpenShift: S2I/Podman/Helm] ──┬─→ [Complete]
└─→ [RHEL: /rhel-deploy] ──────────┘
When to Use This Skill
Use /containerize-deploy when a user wants a complete guided workflow from source code to running application on OpenShift or standalone RHEL systems. This skill orchestrates project detection, build strategy selection, and deployment with user confirmation at each phase.
Critical: Human-in-the-Loop Requirements
See Human-in-the-Loop Requirements for mandatory checkpoint behavior.
Workflow
Phase 0: Introduction
Present the workflow overview and available deployment targets/strategies. Ask: Ready to begin? (yes/no)
WAIT for user confirmation before proceeding.
Phase 1: Project Detection
Execute the /detect-project workflow.
If Remote URL provided:
Follow the "Remote Repository Strategy" path in /detect-project.
- Ask user to choose: Remote S2I, Remote Podman, or Clone.
If Local Files:
Proceed with standard detection.
## Phase 1: Analyzing Your Project
[If Local]
Scanning project directory for language indicators...
[If Remote]
Analyzing remote repository options...
...
Store confirmed values in session state, including BUILD_STRATEGY and HELM_CHART_DETECTED.
Phase 1.4: Deployment Target Selection
## Deployment Target
Where would you like to deploy this application?
| Target | Description | Requirements |
|--------|-------------|--------------|
| **OpenShift** | Deploy to OpenShift/Kubernetes cluster | `oc login` access |
| **RHEL Host** | Deploy directly to a standalone RHEL system | SSH access to RHEL 8+ |
**Which target would you like to use?**
1. OpenShift - Deploy to current cluster
2. RHEL - Deploy to a RHEL host via SSH
Store DEPLOYMENT_TARGET in session state.
WAIT for user confirmation before proceeding.
If user selects "RHEL":
- Store
DEPLOYMENT_TARGET = "rhel" in session state
- Delegate to
/rhel-deploy skill with detected project info
- Pass:
APP_NAME, LANGUAGE, FRAMEWORK, VERSION, BUILDER_IMAGE, CONTAINER_PORT
- The
/rhel-deploy skill handles SSH connection, deployment strategy, and service creation
- After
/rhel-deploy completes → Go to Phase 8 (Completion)
If user selects "OpenShift":
- Store
DEPLOYMENT_TARGET = "openshift" in session state
- Continue to Phase 1.5 (Strategy Selection)
Phase 1.5: Strategy Selection
If multiple deployment options are available (Helm chart detected, Dockerfile present, or standard project):
## Deployment Strategy
Based on my analysis, you have these options:
| Strategy | Use When | Detected |
|----------|----------|----------|
| **S2I** | Standard apps, no Dockerfile needed | [Yes/No] |
| **Podman** | Custom Containerfile/Dockerfile exists | [Yes/No] |
| **Helm** | Helm chart exists or complex deployments | [Yes/No] |
**Detected in your project:**
[List what was found: language indicators, Dockerfile, Helm chart at ./chart]
**Which deployment strategy would you like to use?**
1. S2I - Build with Source-to-Image
2. Podman - Build from Containerfile/Dockerfile
3. Helm - Use existing Helm chart
4. Create Helm chart - Generate a new Helm chart for your project (if no chart exists)
Store DEPLOYMENT_STRATEGY in session state.
WAIT for user confirmation before proceeding.
Phase 1.6: Image Selection (S2I/Podman only)
If user selected S2I or Podman deployment strategy, offer image selection options:
## Image Selection
**Current recommendation:** `[builder-image]`
(Based on: [language] [version])
**Image Selection Options:**
- **quick** - Use the recommended image (good for most cases)
- **smart** - Run `/recommend-image` for tailored selection (production vs dev, security, performance)
Which option would you prefer?
If user selects "smart":
- Invoke
/recommend-image skill with detected LANGUAGE, FRAMEWORK, VERSION
- Store the result in
BUILDER_IMAGE and IMAGE_VARIANT session state
- Continue to Phase 2
If user selects "quick":
- Use the already-detected
BUILDER_IMAGE
- Continue to Phase 2
BRANCHING LOGIC:
- If
DEPLOYMENT_STRATEGY is "S2I" or "Podman" → After Phase 2, continue to Phase 3 (S2I/Podman Path)
- If
DEPLOYMENT_STRATEGY is "Helm" → After Phase 2, go to Phase 2-H (Helm Path)
Phase 1.7: Configuration Review (MANDATORY)
This phase MUST NOT be skipped regardless of how the user responded to previous phases.
## Configuration Review
Before I proceed, let me confirm the deployment configuration:
**Environment Type:**
| Type | Characteristics |
|------|-----------------|
| **Development** | `latest` tags, lower resources, quick iteration |
| **Staging** | Version tags, moderate resources, testing |
| **Production** | Pinned versions, higher resources, HA-ready |
**Which environment is this deployment for?**
1. Development
2. Staging
3. Production
---
**Configuration Approach:**
| Approach | When to Use |
|----------|-------------|
| **Runtime config** | Need to change settings without rebuilding (Recommended for prod) |
| **Build-time config** | Simpler, settings baked into image (OK for dev) |
**How should environment variables be handled?**
1. Runtime (ConfigMap mount)
2. Build-time (baked into image)
---
**Resource Settings:**
| Setting | Dev Default | Prod Default |
|---------|-------------|--------------|
| Replicas | 1 | 2+ |
| CPU limit | 200m | 400m+ |
| Memory limit | 256Mi | 512Mi+ |
**Use defaults for your environment, or customize?**
1. Use defaults
2. Customize resources
WAIT for user to answer ALL questions above before proceeding.
Store: ENVIRONMENT_TYPE, CONFIG_APPROACH, RESOURCE_PROFILE in session state.
Phase 2: OpenShift Connection
## Phase 2: Connecting to OpenShift
Checking cluster connection...
**Current Context:**
| Setting | Value |
|---|---|
| Cluster | [cluster-api-url] |
| User | [username] |
| Namespace | [current-namespace] |
**Is this the correct cluster and namespace?**
- yes - Continue to build
- no - I need to change this
[If no]
**To change context:**
1. Run `oc login <new-cluster-url>` in your terminal
2. Or run `oc project <namespace>` to switch namespace
3. Then tell me to continue
**Available namespaces you have access to:**
[List first 10 namespaces/projects]
Which namespace should I deploy to?
Store confirmed NAMESPACE in session state.
S2I/PODMAN PATH (If DEPLOYMENT_STRATEGY is "S2I" or "Podman")
Phase 3: Git Repository Check
## Git Repository
I need a Git URL for the S2I build.
**Detected from .git/config:**
- Remote: `[git-url]`
- Branch: `[current-branch]`
**Is this correct?** (yes/no)
[If no git config found]
**Please provide:**
1. Git repository URL (e.g., https://github.com/user/repo.git)
2. Branch name (default: main)
Store GIT_URL and GIT_BRANCH in session state.
Phase 4: Pre-Build Summary
## Phase 3: Build Configuration
Here's what I'll create on OpenShift:
**Target:**
- Cluster: [cluster]
- Namespace: [namespace]
**Resources to Create:**
1. **ImageStream** `[app-name]`
- Stores built container images
2. **BuildConfig** `[app-name]`
- Source: [git-url] (branch: [branch])
- Builder: [builder-image]
- Output: [app-name]:latest
---
**Would you like to see the full YAML?** (yes/no)
[If yes, show both YAML manifests]
---
**Proceed with creating these resources and starting the build?**
- yes - Create resources and start build
- modify - I need to change something
- cancel - Stop here
Phase 5: Execute Build
## Creating Build Resources...
[x] ImageStream created: [app-name]
[x] BuildConfig created: [app-name]
## Starting Build...
**Build:** [app-name]-1
**Status:** Running
---
**Build Logs:**
[Stream S2I build output]
---
[When complete]
## Build Successful!
**Build:** [app-name]-1
**Duration:** [X]m [Y]s
**Image:** [image-reference]
**CRITICAL: Wait for the build to reach 'Complete' status before proceeding.**
Continue to deployment? (yes/no)
Phase 6: Pre-Deploy Summary
## Phase 4: Deployment Configuration
**Image ready!** Now let's deploy it.
**Resources to Create:**
1. **Deployment** `[app-name]`
- Image: [app-name]:latest
- Replicas: 1
- Port: [detected-port]
2. **Service** `[app-name]`
- Internal load balancer
- Port: [port]
3. **Route** `[app-name]`
- External HTTPS access
- URL: https://[app-name]-[namespace].[domain]
---
**Would you like to see the full YAML?** (yes/no)
[If yes, show all three YAML manifests]
---
**Proceed with deployment?**
- yes - Deploy the application
- modify - I need to change something
- cancel - Stop here (build artifacts preserved)
Phase 7: Execute Deployment
## Deploying Application...
[x] Deployment created: [app-name]
[x] Service created: [app-name]
[x] Route created: [app-name]
## Waiting for Rollout...
**Pod Status:**
| Pod | Status | Ready |
|-----|-----|---|
| [app-name]-xxx-yyy | Running | 1/1 |
Rollout complete!
If rollout fails (pods not ready, CrashLoopBackOff, ImagePullBackOff, etc.):
## Deployment Failed
The deployment did not complete successfully.
**Pod Status:**
| Pod | Status | Ready | Restarts |
|-----|--------|-------|----------|
| [app-name]-xxx-yyy | [status] | 0/1 | [count] |
---
**Would you like me to diagnose the issue?**
1. **Debug Pod** (`/debug-pod`) - Investigate pod failures
2. **Debug Network** (`/debug-network`) - Check service/route connectivity
3. **Debug Build** (`/debug-build`) - Re-check build if image issues
4. **View logs manually**
5. **Rollback and stop**
Select an option:
- If user selects a debug option → Invoke the corresponding skill
- After debugging → Offer to retry deployment
HELM PATH (If DEPLOYMENT_STRATEGY is "Helm")
Phase 2-H: Helm Deployment
If user selected Helm in Phase 1.5, execute this path instead of Phases 3-7.
## Helm Deployment
Switching to Helm deployment workflow...
The `/helm-deploy` skill will handle:
1. Validate the Helm chart
2. Review and customize values
3. Install/upgrade the release
4. Monitor deployment
5. Present results
Proceeding with Helm deployment...
Delegate to /helm-deploy skill:
- Pass
APP_NAME, NAMESPACE, HELM_CHART_PATH from session state
- The helm-deploy skill handles chart detection, values review, and installation
- After helm-deploy completes → Go to Phase 8 (Completion)
If user chose "Create Helm chart":
- Generate chart using templates from templates/helm/
- Replace
${APP_NAME} placeholders with detected app name
- Set
${CONTAINER_PORT} based on detected port
- Then proceed with helm-deploy workflow
COMPLETION (Both paths converge here)
Phase 8: Completion
Present a summary including:
- Application name, namespace, language, framework
- Access URLs (external route, internal service DNS)
- Resources created with status (ImageStream, BuildConfig, Deployment, Service, Route)
- Quick commands: view logs, scale, rebuild, delete
- Next steps: open app URL, set up webhooks, add env vars, configure autoscaling
Dependencies
Required MCP Servers
openshift - cluster resource management for OpenShift deployments
Related Skills
/debug-pod - Pod failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff)/debug-build - S2I or Podman build failures/debug-network - Service connectivity issues (no endpoints, 503 errors)/debug-rhel - RHEL deployment failures (systemd, SELinux, firewall)
Reference Documentation
