GitHub logo

Skill

reusable-workflow-patterns

implement reusable CI/CD workflow patterns

Published by GitHub Updated May 27
Covers GitHub Actions Automation CI/CD

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

SystemFile patterns
GitHub Actions.github/workflows/*.yml
GitLab CI/CD.gitlab-ci.yml
Azure DevOpsazure-pipelines.yml, .azure-pipelines/*.yml
JenkinsJenkinsfile, .jenkins/*.groovy
CircleCI.circleci/config.yml
Travis CI.travis.yml
Drone CI.drone.yml
OthersBitbucket, 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 inputScope
org-nameAll repositories in that organization
org-name/repo-nameThat specific repository only
Mixed listUnion 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:

  1. Scope resolution
    • For each org-name entry: use mcp_github_search_repositories to enumerate all repos in that org.
    • For each org-name/repo-name entry: use that repo directly โ€” no enumeration needed.
    • Deduplicate if a repo appears both via org scan and explicit reference.
  2. Universal pipeline discovery โ€” search each repo for CI/CD files across all supported systems (see table above).
  3. Cross-platform content analysis โ€” retrieve and parse configurations.
  4. Universal pattern extraction โ€” identify common structures and steps.
  5. 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.
  6. Translation scoring โ€” rank by frequency, complexity reduction, and GitHub Actions conversion feasibility.
  7. 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:

  1. .github/workflows/reusable-<name>.yml โ€” the reusable workflow (workflow_call trigger only)
  2. 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-core guardrails)
  • Trigger: workflow_call only
  • Location: .github/workflows/reusable-<name>.yml
  • Validation: every workflow must pass actionlint

More from GitHub

View publisher

ยฉ 2026 YourAI.tools. Every skill from an identity-verified publisher.

Independent catalog. Not affiliated with, endorsed by, or sponsored by Anthropic or any listed publisher. All trademarks belong to their respective owners.