Conversation
- claude-pr-triage.yml: labels PRs on open/edit/sync based on changed files and PR content (type, area, size labels) - claude-ci-autofix.yml: triggers on test/build/lint failures, checks the actor has write/maintain/admin access, then attempts a minimal fix on a new branch and opens a PR with the changes Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- claude.yml: restrict @claude mentions to maintainers via collaborator permission check - claude-pr-triage.yml: use author_association for pr-from-maintainers label; remove size labels; drop ZK-rollup description Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…n checks getCollaboratorPermissionLevel requires admin token access which GITHUB_TOKEN does not have. Switch to author_association from the event payload (claude.yml) and pulls.get() (claude-ci-autofix.yml) which only require read access. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mmagician
added
the
no changelog
|
You have run out of free Bugbot PR reviews for this billing cycle. This will reset on March 10. To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial. |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Restrict workflow_run trigger to PRs from the same repository (not forks) to prevent untrusted code execution in a privileged context (CWE-829, CodeQL alert #14). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
mmagician
force-pushed
the
add-claude-github-actions-1771770168827
branch
from
b0e9853 to
86a04e3
Compare
mmagician
added
the
pr-from-maintainers
Shouldn't PR author be pretty well positioned to know what labels to attach to the PR? And it should be relatively low effort (shouldn't take more than a few seconds).
I'm a bit weary of having the committed code automatically modified. Wouldn't it cause more work to verify that the automated changes were correct than to make CI fixes in the first place?
Why do we need this? Couldn't the PR author run Claud locally to get the same results? |
Indeed, although I think if we can remove as much friction from mundane tasks, it would be to an overall benefit of faster development.
Two points to this:
Absolutely, but again to my points above I'd like to remove as many manual steps as possible. Furthermore, this will allow reviewers to trigger claude workflows. See e.g. how I asked copilot to address nits on Philipp's PR, prompting him to simply accept the changes, rather than triggering that same workflow locally and waiting for completion. This significantly cuts out dev cycles in my (limited so far, but still positive overall) experience with prompting agents from GitHub UI. |
2 participants
Would be good to try and automate some things: