Repository navigation
ci: auto-label AI-assisted PRs with claude-assisted (#272) - #276
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughAdds a GitHub Actions workflow that labels qualifying newly opened pull requests as ChangesClaude-assisted PR labeling
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant PullRequest
participant GitHubActions
participant GitHubAPI
PullRequest->>GitHubActions: Open pull request
GitHubActions->>GitHubActions: Check author or Claude footer
GitHubActions->>GitHubAPI: Add claude-assisted label
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Preview DeploymentPreview URL: https://c8abd7c5.bestax.pages.dev |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/auto-label-claude-prs.yml (1)
35-39: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winRemove the redundant
pull-requests: writepermission.The workflow uses the Issues label API, which accepts either
Issues: writeorPull requests: write; granting both violates least privilege. (docs.github.com)permissions: - pull-requests: write issues: write🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/auto-label-claude-prs.yml around lines 35 - 39, Remove the redundant pull-requests: write entry from the workflow permissions block, retaining issues: write for the label API used by the workflow.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/auto-label-claude-prs.yml:
- Around line 9-11: Ensure the workflow creates the `claude-assisted` label
before attempting to apply it: move the `gh label create ... --force` step ahead
of the label-add call, preserving the intended color and description.
---
Nitpick comments:
In @.github/workflows/auto-label-claude-prs.yml:
- Around line 35-39: Remove the redundant pull-requests: write entry from the
workflow permissions block, retaining issues: write for the label API used by
the workflow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 099cee7d-3cc4-4fad-9a05-f5497c42e8b7
📒 Files selected for processing (3)
.github/workflows/auto-label-claude-prs.ymlCLAUDE.mddocs/docs/guides/getting-started/ai-development.md
| # The addLabels API auto-creates the label on first application; suggested | ||
| # cosmetics once it exists: color #7057ff, description "PR authored or | ||
| # assisted by Claude (auto-applied)". |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
git ls-files .github/workflows/auto-label-claude-prs.yml
echo '---'
wc -l .github/workflows/auto-label-claude-prs.yml
echo '---'
cat -n .github/workflows/auto-label-claude-prs.yml | sed -n '1,140p'Repository: allxsmith/bestax
Length of output: 2540
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Search for label creation / add-label usage in the repo.
rg -n "claude-assisted|label create|add-label|addLabels|labels\\[]" .github -SRepository: allxsmith/bestax
Length of output: 1758
🌐 Web query:
GitHub REST API add labels to an issue create missing labels documentation
💡 Result:
The GitHub REST API does not provide a single operation to "add labels to an issue and create them if they are missing." [1][2] The API operations for adding labels to an issue specifically require that the labels already exist in the repository [1][2]. If you attempt to add a label that does not exist, the operation will fail or the label will be silently ignored [3][2]. To achieve this functionality, you must implement a multi-step process in your code: 1. Check for the existence of the label using the Get a label endpoint (GET /repos/{owner}/{repo}/labels/{name}). 2. If the label does not exist (the API returns a 404 Not Found), create the label first using the Create a label endpoint (POST /repos/{owner}/{repo}/labels). 3. Once you have confirmed the label exists, use the Add labels to an issue endpoint (POST /repos/{owner}/{repo}/issues/{issue_number}/labels) to assign it to the issue [1][4]. This "check-then-create" pattern is commonly required when automating repository management, as demonstrated in various tools and workflows [5][6]. Note that only users with push access to the repository have the permissions required to create new labels or assign them to issues; without sufficient permissions, label changes are typically ignored [3][2].
Citations:
- 1: https://docs.github.com/en/rest/issues/labels
- 2: https://docs.github.com/en/rest/issues/issues
- 3: [BUG]: New label is not created on creating a new github issue octokit/rest.js#479
- 4: https://docs.github.com/en/enterprise-server@3.20/rest/issues/labels?apiVersion=2022-11-28
- 5: https://github.com/integrations/terraform-provider-github/blob/b691d8f9/github/resource_github_issue_label.go
- 6: https://til.simonwillison.net/github-actions/creating-github-labels
Create claude-assisted before adding it. The add-label API expects the repository label to already exist, so the first matching PR can be left unlabeled unless the workflow creates claude-assisted first. Move the gh label create ... --force step before the label-add call.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/auto-label-claude-prs.yml around lines 9 - 11, Ensure the
workflow creates the `claude-assisted` label before attempting to apply it: move
the `gh label create ... --force` step ahead of the label-add call, preserving
the intended color and description.
|
@claude perform deep review Generated by Claude Code |
|
Claude encountered an error after 3m 58s —— View job Deep review in progress
|
Add auto-label-claude-prs.yml: on PR open, apply the claude-assisted provenance label when the author is bestaxbot or the body carries the Claude Code attribution footer. pull_request_target is safe here — the workflow never checks out PR code. Not gated on AI_LOOP_ENABLED so provenance survives the kill switch. Document the label in the ai-development guide table and the root CLAUDE.md. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Pohc8xLkdx4gwXkW3xd7up
a560283 to
1660341
Compare
Preview DeploymentPreview URL: https://62836882.bestax.pages.dev |
There was a problem hiding this comment.
Deep review — 0 finding(s)
| # | Severity | Area | Finding | Location |
|---|---|---|---|---|
| — | — | — | No blocking defects found. | — |
Overall: This is a tight, well-reasoned CI addition that faithfully mirrors the already-vetted on-slop.yml model — permissions: {} at the top with a minimal per-job grant, no PR-code checkout, so pull_request_target is genuinely safe. I verified the load-bearing pieces: the gh api -f "labels[]=…" array syntax is officially supported (confirmed in gh api --help) and serializes to {"labels":["claude-assisted"]}; bestaxbot is the correct machine-account login used consistently by claude-implement.yml and bestaxbot-reply.yml; and the docs table + root CLAUDE.md are updated in lock-step. The riskiest single assumption is that POST /issues/{n}/labels auto-creates the claude-assisted label on first use — the label doesn't exist in the repo yet (404) and nothing else pre-creates it, so the very first triggering PR is what proves this out. That claim matches the documented REST-vs-GraphQL distinction the inline comment cites, so I'm not flagging it as a defect — just the one line to glance at in the Actions log the first time it fires.
🏄 Clean little labeling curl, no gnarly checkout, permissions trimmed down real tight — this one's glassy, brah. Only thing to watch is whether that first label spawns itself outta the foam; everything else is cruisin'. Send it. 🌊
…90-day closer (#275) Addresses the deep-review Major on PR #279: the generic stale.yml closed every PR at day 44, so the dedicated 90-day bestaxbot closer could never fire and the documented 90-day bot leash was inaccurate. actions/stale has no author exemption, so the fix keys off the claude-assisted label that auto-label-claude-prs.yml (PR #276) applies: - stale.yml adds claude-assisted to exempt-pr-labels, so AI-assisted PRs skip the 30/14 sweep. - close-stale-bestaxbot-prs.yml now sweeps the union of author:bestaxbot and label:claude-assisted (deduped), so labeled human-authored Claude-assisted PRs don't escape both layers, and pre-labeler bot PRs are still covered by the author query. - CLAUDE.md and the docs label table describe the two-layer split. Until #276 merges and labels new bot PRs, unlabeled bestaxbot PRs remain under the generic 30/14 sweep — an acceptable transition state. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0142miDJt2AX9QUw5fNJt2xu
…assisted # Conflicts: # CLAUDE.md # docs/docs/guides/getting-started/ai-development.md
Preview DeploymentPreview URL: https://dcd81293.bestax.pages.dev |
There was a problem hiding this comment.
Deep review — 0 findings
| # | Severity | Area | Finding | Location |
|---|---|---|---|---|
| — | — | — | No blocking defects found. | — |
Overall: Sound, low-risk change — a single-purpose labeling workflow plus two doc updates. I verified the load-bearing pieces: bestaxbot is the correct machine-account login (matches claude-implement.yml/claude-pr-loop.yml), the pull_request_target: opened trigger is safe because it never checks out or runs PR code and no PR-controlled data reaches the shell (contains() runs in the expression context; the label is hardcoded), and -f "labels[]=claude-assisted" is valid gh api array syntax hitting the right endpoint. The one operational assumption to watch: the claude-assisted label does not exist in the repo yet, so the first run relies on the add-labels API auto-creating it (with a random color — the intended #7057ff/description still need a one-time manual set, as the workflow comment already notes). That is established API behavior, so nothing to block on. Minor non-blocking future-proofing: the trigger only fires on opened, so a PR that gains the Claude footer via a later body edit will not be labeled, and pull-requests: write is redundant since label writes go through the issues scope.
🏄 Totally chill little PR, dude — one clean labeling wave, no gnarly checkout, no injection riptide. Ship it and go catch the next set.
|
🎉 This PR is included in version 3.2.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 5.4.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
🎉 This PR is included in version 1.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |

Pull Request
Description
Adds
.github/workflows/auto-label-claude-prs.yml(mirroring oven-sh/bun's workflow of the same name): onpull_request_target: opened, if the PR author isbestaxbotor the PR body contains the Claude Code attribution footer (🤖 Generated with), a plainghstep applies theclaude-assistedprovenance label.pull_request_targetis safe here because the workflow never checks out or executes PR code — it is a single labeling API call (same rationale ason-slop.yml). Workflow-levelpermissions: {}; the job takespull-requests: writeplusissues: write(labels on PRs go through the issues API, and auto-creating the missing label requires it). Deliberately not gated onvars.AI_LOOP_ENABLED— this workflow uses zero Claude, so provenance survives the kill switch. Also documents the label in the ai-development guide's label table and the rootCLAUDE.md.@allxsmith/bestax-bulma)create-bestax)@allxsmith/bestax-docs)Related Issue(s)
Closes #272
Type of Change
Checklist
CLAUDE.mdfiles are updatedScreenshots / Demos
Not applicable — CI workflow + docs only.
Additional Context
docs/docs/guides/getting-started/ai-development.md, so trivial merge conflicts on that table are expected; this PR adds exactly one row to keep them minimal.claude-assistedlabel auto-creates on first application (the addLabels API creates missing labels); suggested cosmetics afterward: color#7057ff, description "PR authored or assisted by Claude (auto-applied)".prettier --checkpasses on both changed markdown files.🤖 Generated with Claude Code
https://claude.ai/code/session_01Pohc8xLkdx4gwXkW3xd7up
Generated by Claude Code
Summary by CodeRabbit
claude-assistedlabel to newly opened pull requests when AI-assisted provenance is detected, improving visibility and tracking.claude-assistedlabel in the autonomous loop label lifecycle.deep-reviewlabel description and adjacent kill-switch instructions for improved readability.