Auto Labeler

You are a GitHub Actions workflow automation expert. The user wants to automatically label pull requests based on the file paths that were changed.

What to check first

• Verify your repository has GitHub Actions enabled (Settings > Actions)
• Confirm you have write permissions to add labels (required for the workflow to function)
• Check existing labels in your repo (Settings > Labels) — you'll reference these in the workflow

Steps

1. Create .github/workflows/auto-labeler.yml in your repository root
2. Use the github.event.pull_request.files context to access changed files in the PR
3. Define a mapping of file patterns (regex or glob) to label names in the workflow
4. Parse the changed files list and match against your patterns using conditional logic
5. Use the actions/github-script@v7 action to dynamically add labels via the GitHub API
6. Test the workflow by creating a test PR with files matching your patterns
7. Add the workflow permissions section to allow the action to write labels
8. Monitor the Actions tab to verify the labels are applied correctly on test PRs

Code

name: Auto Labeler
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  pull-requests: write
  contents: read

jobs:
  labeler:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/github-script@v7
        with:
          script: |
            const { owner, repo } = context.repo;
            const prNumber = context.issue.number;

            // Get list of changed files
            const { data: files } = await github.rest.pulls.listFiles({
              owner,
              repo,
              pull_number: prNumber
            });

            const changedFiles = files.map(f => f.filename);
            const labelsToAdd = new Set();

            // Define file patterns and corresponding labels
            const patterns = {
              'docs': /^docs\//,
              'backend': /^(src\/server|api)\//,
              'frontend': /^(src\/components|pages|ui)\//,
              'dependencies': /^(package\.json|package-lock\.json|requirements\.txt|Gemfile)$/,
              'tests': /\.(test|spec)\.(js|ts|py|rb)$/,
              'ci-cd': /^\.github\/workflows\//,
              'config': /^(\.env|\.editorconfig|tsconfig|jest\.config)/ 
            };

            // Match files against patterns
            changedFiles.forEach(file => {
              Object.entries(patterns).forEach(([label, regex]) => {
                if (regex.test(file)) {
                  labelsToAdd.add(label);
                }
              });
            });

            // Add labels to PR
            if (labelsToAdd.size > 0) {
              await github.rest.issues.addLabels({
                owner,
                repo,

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change