/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

• docs/builder-images.md - Language detection, S2I builder images
• docs/image-selection-criteria.md - Image variant selection, LTS timelines
• docs/python-s2i-entrypoints.md - Python S2I configuration
• docs/rhel-deployment.md - RHEL host deployment
• docs/debugging-patterns.md - Common error patterns and troubleshooting
• docs/prerequisites.md - All required tools by skill