
Skill
reusable-workflow-patterns
implement reusable CI/CD workflow patterns
Description
Catalog of common CI/CD patterns (build, test, deploy, security, quality), scan scope resolution (org-wide or specific repos), the reusable workflow template, selection criteria, and usage-documentation template. Load when detecting recurring CI/CD patterns across GitHub orgs and/or repositories to generate standardized `reusable-*.yml` workflows with corresponding `docs/<name>-usage.md` files.
SKILL.md
Reusable Workflow Patterns
This skill provides the catalog, template, and documentation standards used by the Reusable Workflow Builder agent to detect cross-platform CI/CD patterns and produce standardized GitHub Actions reusable workflows.
Supported CI/CD systems for pattern discovery
| System | File patterns |
|---|---|
| GitHub Actions | .github/workflows/*.yml |
| GitLab CI/CD | .gitlab-ci.yml |
| Azure DevOps | azure-pipelines.yml, .azure-pipelines/*.yml |
| Jenkins | Jenkinsfile, .jenkins/*.groovy |
| CircleCI | .circleci/config.yml |
| Travis CI | .travis.yml |
| Drone CI | .drone.yml |
| Others | Bitbucket, TeamCity, Bamboo, Buildkite |
Pattern categories
- ๐๏ธ Build โ npm/Maven/Docker/language-specific build processes
- ๐งช Test โ unit, integration, E2E, security, performance testing
- ๐ Deploy โ cloud (AWS/Azure/GCP), containers, serverless, infrastructure
- ๐ Security โ SAST/DAST, dependency scanning, compliance checks
- ๐ Quality โ code coverage, linting, quality gates
Selection criteria
A pattern becomes a reusable workflow when it shows:
- High frequency โ 10+ repositories
- Significant complexity โ 5+ steps
- Low variation โ standardizable
- Clear parameters โ configurable inputs
Scan scope
The user controls the scope of analysis. Three modes are supported and can be freely combined:
| User input | Scope |
|---|---|
org-name | All repositories in that organization |
org-name/repo-name | That specific repository only |
| Mixed list | Union of all specified orgs and repos |
Always respect the stated scope โ never crawl repos or orgs not explicitly provided.
Pattern-recognition workflow
Adapt these steps to the input scope:
- Scope resolution
- For each
org-nameentry: usemcp_github_search_repositoriesto enumerate all repos in that org. - For each
org-name/repo-nameentry: use that repo directly โ no enumeration needed. - Deduplicate if a repo appears both via org scan and explicit reference.
- For each
- Universal pipeline discovery โ search each repo for CI/CD files across all supported systems (see table above).
- Cross-platform content analysis โ retrieve and parse configurations.
- Universal pattern extraction โ identify common structures and steps.
- Cross-system frequency analysis โ count pattern occurrences across the resolved repo set.
- When scope is a single repo or a small explicit list, lower the frequency threshold (see Selection criteria) โ a pattern present in 3+ files within a monorepo is still worth extracting.
- Translation scoring โ rank by frequency, complexity reduction, and GitHub Actions conversion feasibility.
- Platform mapping โ map equivalent concepts to GitHub Actions.
Reusable workflow template
name: Reusable Node.js Build Workflow
on:
workflow_call:
inputs:
node-version:
description: 'Node.js version to use'
required: false
default: '18'
type: string
build-command:
description: 'Custom build command'
required: false
default: 'npm run build'
type: string
outputs:
build-success:
description: 'Build success status'
value: ${{ jobs.build.outputs.success }}
jobs:
build:
runs-on: ubuntu-latest
steps:
# โ
Only verified actions from trusted publishers
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: ${{ inputs.node-version }}
cache: 'npm'
- run: npm install
- run: ${{ inputs.build-command }}
Output file rules
For every reusable workflow produced, create exactly two files:
.github/workflows/reusable-<name>.ymlโ the reusable workflow (workflow_calltrigger only)docs/<name>-usage.mdโ the usage documentation (one per workflow, 1:1)
Never create: README.md, WORKFLOWS.md, consolidated docs, scripts (.sh, .bat, .ps1, .py, .js), custom actions, caller workflows, or workflow templates.
Usage documentation template
Each docs/<name>-usage.md must contain:
# Reusable [Workflow Name] Usage Guide
## Pattern Analysis Summary
- **Frequency**: Found in X repositories across Y organizations
- **Source CI/CD Systems**: [List systems: GitHub Actions, GitLab CI, Jenkins, etc.]
- **Complexity Reduction**: [Explain how this replaces X previous steps]
## Migration Benefits
- **From GitLab CI**: [If applicable, before/after]
- **From Jenkins**: [If applicable, before/after]
- **From Azure DevOps**: [If applicable, before/after]
- **Standardization**: [Consistency improvements]
## Basic Usage Example
```yaml
name: Example Workflow
on: [push, pull_request]
jobs:
job-name:
uses: ./.github/workflows/reusable-[name].yml
with:
param1: 'value1'
param2: 'custom-value'
```
## Advanced Usage Example
```yaml
name: Production Workflow
on:
push:
branches: [main]
jobs:
job-name:
uses: ./.github/workflows/reusable-[name].yml
with:
param1: 'production-value'
param2: 'advanced-setting'
secrets:
SECRET_NAME: ${{ secrets.SECRET_NAME }}
```
## Input Parameters Reference
| Parameter | Description | Required | Default | Example |
| --------- | ------------- | -------- | ----------- | ---------- |
| param1 | [Description] | Yes | - | `'value'` |
| param2 | [Description] | No | `'default'` | `'custom'` |
## Output Reference
| Output | Description | Type |
| ------- | ------------- | ------ |
| output1 | [Description] | string |
## Migration Examples
### From GitLab CI
**Before (.gitlab-ci.yml):**
```yaml
[Show original GitLab CI configuration]
```
**After (GitHub Actions):**
```yaml
[Show how to use this reusable workflow instead]
```
### From Jenkins
**Before (Jenkinsfile):**
```groovy
[Show original Jenkins configuration]
```
**After (GitHub Actions):**
```yaml
[Show how to use this reusable workflow instead]
```
## Best Practices
- [Specific best practices for using this workflow]
- [Security considerations]
- [Performance tips]
Quality and security requirements
- Verified publishers only: prioritize
actions/*,azure/*,aws-actions/*,google-github-actions/* - Latest stable versions of all actions, pinned to commit SHA (see
migration-coreguardrails) - Trigger:
workflow_callonly - Location:
.github/workflows/reusable-<name>.yml - Validation: every workflow must pass
actionlint
More skills from the actions-migrations-via-copilot repository
View all 11 skillsactionlint
lint and fix GitHub Actions workflows
May 27CI/CDCode AnalysisGitHub ActionsQAazure-devops-migration
migrate Azure DevOps pipelines to GitHub Actions
May 27Azure DevOpsCI/CDGitHub ActionsMigrationbamboo-migration
migrate Bamboo pipelines to GitHub Actions
May 27CI/CDDeploymentEngineeringGitHub Actions +1bitbucket-migration
migrate Bitbucket Pipelines to GitHub Actions
May 27CI/CDGitHubGitHub ActionsMigrationcircleci-migration
migrate CircleCI pipelines to GitHub Actions
May 27CI/CDDeploymentGitHub ActionsMigrationdroneci-migration
migrate Drone CI pipelines to GitHub Actions
May 27CI/CDGitHub ActionsMigration
More from GitHub
View publisherqdrant-horizontal-scaling
guide Qdrant horizontal scaling decisions
awesome-copilot
Apr 18AI InfrastructureArchitectureCapacity PlanningDatabase +1qdrant-indexing-performance-optimization
optimize Qdrant indexing performance
awesome-copilot
Apr 18Data EngineeringDatabaseETLPerformance +1qdrant-memory-usage-optimization
optimize Qdrant memory usage
awesome-copilot
Apr 18Cost OptimizationDatabaseObservabilityPerformance +1qdrant-minimize-latency
minimize Qdrant query latency
awesome-copilot
Apr 18ArchitectureDatabasePerformanceQdrant +1qdrant-monitoring-debugging
debug Qdrant production issues with metrics
awesome-copilot
Apr 18DebuggingMonitoringObservabilityPerformance +1qdrant-monitoring-setup
set up Qdrant monitoring and alerting
awesome-copilot
Apr 18AI InfrastructureMonitoringObservabilityQdrant +1