feat: Github pull request labeler

[tjirab]

Adds a labeler CI workflow to categorize pull requests.

Summary by CodeRabbit

• Chores
  • Implemented automated pull request labeling to organize and categorize pull requests based on modified files, improving PR tracking and organization.

[coderabbitai]

Walkthrough

Two new configuration files establish automated PR labeling: .github/labeler.yml defines labels with glob patterns for project components (agents-core, plugins, examples, tests, docs, etc.), and .github/workflows/labeler.yml is a GitHub Actions workflow that applies these labels based on modified files in pull requests.

Changes

Cohort / File(s)	Summary
PR Labeling Setup ​.github/labeler.yml, ​.github/workflows/labeler.yml	Adds GitHub labeler configuration defining 14+ label groups with glob patterns for filtering project components (core, plugins, examples, tests, docs, CI, CLI, dependencies, etc.). Introduces GitHub Actions workflow triggered on pull request events to automatically apply matching labels using the labeler action v5.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

Poem

Labels bloom like careful wounds,
each pull request sorted into its skin—
automation's neat geometry,
chaos filed away with precision.
The workflow hums. Order settles.
Categorization has never been so final.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The pull request title "feat: Github pull request labeler" directly and clearly describes the main changes in the PR. The changeset introduces two files that together implement GitHub pull request labeling: a labeler configuration file (.github/labeler.yml) that defines label groups and patterns, and a GitHub Actions workflow file (.github/workflows/labeler.yml) that automates label application. The title accurately captures this primary objective in a concise, specific manner that would allow a teammate reviewing commit history to understand the change without ambiguity or vagueness.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (3)

.github/labeler.yml (3)

146-152: Consider scoping asset patterns to avoid over-labeling.

The asset glob patterns (*.png, *.jpg, *.gif, *.mp4, *.wav, *.mp3, etc.) will match media files at any directory level in the repository. This may incorrectly label test fixtures, example assets, or build artifacts as "assets."

Consider narrowing these patterns to a specific directory:

- assets:
-   - assets/**
-   - '*.png'
-   - '*.jpg'
-   - '*.jpeg'
-   - '*.gif'
-   - '*.mp4'
-   - '*.wav'
-   - '*.mp3'
+ assets:
+   - assets/**
+   - assets/*.png
+   - assets/*.jpg
+   - assets/*.jpeg
+   - assets/*.gif
+   - assets/*.mp4
+   - assets/*.wav
+   - assets/*.mp3

Alternatively, keep root-level media files if they're expected at the repo root.

---

96-110: Clarify intent of overlapping config and CI patterns.

Both the config label (lines 96–101) and ci label (lines 108–110) include *.yml and *.yaml patterns. This means workflow files and other YAML files will receive both labels.

Is this intended—i.e., are YAML files expected to be tagged with both labels? If so, consider documenting this behavior. If not, consider refining the patterns:

• Option 1: Remove *.yml and *.yaml from config to avoid overlap.
• Option 2: Add an exclusion rule to config to exclude files matching ci patterns.

This is a minor clarity/hygiene issue since GitHub's labeler applies multiple labels correctly; just ensure the behavior matches your intent.

---

83-86: Minor: Redundant test pattern.

The pattern **/tests/** on line 84 subsumes the pattern tests/** on line 83. Consider removing line 83 for clarity:

  tests:
-   - tests/**
    - '**/tests/**'
    - '**/test_*.py'
    - '**/*_test.py'

Both patterns work correctly; this is just a minor efficiency and clarity improvement.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between fc032bf and fea101a.

📒 Files selected for processing (2)

• .github/labeler.yml (1 hunks)
• .github/workflows/labeler.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: unit / Ruff & mypy
• GitHub Check: unit / Test "not integration"

🔇 Additional comments (2)

.github/workflows/labeler.yml (1)

1-12: Workflow setup looks good.

Clean and correct configuration: pull_request_target is the appropriate trigger for PR labeling (safer than pull_request for workflows with write permissions), and permissions are scoped appropriately. The labeler action will automatically discover .github/labeler.yml.

.github/labeler.yml (1)

1-165: Comprehensive label structure.

The labeler configuration is well-organized and covers a broad range of project components: core framework, 13 specific plugins, examples, tests, documentation, configuration, CI/CD, infrastructure layers, CLI tools, dependencies, assets, legal documents, and project metadata. The use of inclusion and exclusion patterns (e.g., !plugins/**/tests/**, !agents-core/**/__pycache__/**) is thoughtful and will keep PR labels focused on meaningful code changes. The per-plugin labels will be valuable for maintainability and team workflows.

[yarikdevcom]

LGTM