Skip to content

Conversation

@JackYPCOnline
Copy link

@JackYPCOnline JackYPCOnline commented Dec 12, 2025

  • Add GitHub Actions workflow for automated issue processing
  • Implement project field management for GitHub Projects v2
  • Add task labeller action for issue categorization
  • Enhance GitHub tools with optimized project operations
  • Add automation configuration for issue metadata

Description

Screenshot 2025-12-12 at 16 25 11

This RP helps add issue metadata, help identify and summerize the issue, then tag the area of expert in the comments.

Tested in my fork.

Related Issues

Hack day feature.

Documentation PR

Type of Change

Bug fix
New feature
Breaking change
Documentation update
Other (please describe):

Testing

How have you tested the change?

  • [x ] I ran npm run check

Checklist

  • [x ] I have read the CONTRIBUTING document
  • [x ] I have added any necessary tests that prove my fix is effective or my feature works
  • [x ] I have updated the documentation accordingly
  • [x ] I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
  • [x ] My changes generate no new warnings
  • [x ] Any dependent changes have been merged and published

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

- Add GitHub Actions workflow for automated issue processing
- Implement project field management for GitHub Projects v2
- Add task labeller action for issue categorization
- Enhance GitHub tools with optimized project operations
- Add automation configuration for issue metadata
- Remove automatic Status field setting to Todo
- Only update the specifically requested project field
- Remove debug logging and incomplete functions
- Update system prompt to tag only the 2 most related experts
- Prioritize experts most closely related to specific issue content
- Reduce notification noise while maintaining relevant expertise
@JackYPCOnline JackYPCOnline changed the title feat: add GitHub issue automation with project fields and labeling feat: Add GitHub issue automation with issue metadata Dec 12, 2025
@JackYPCOnline JackYPCOnline marked this pull request as ready for review December 12, 2025 15:29
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have some examples of this working? I'd like to evaluate it before adding this

Copy link
Author

@JackYPCOnline JackYPCOnline Dec 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"name": "Gemini Model Provider",
"github_usernames": ["notgitika"]
},
"litellm": {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be better to list the the label associated with the category? Or are we allowing any label?

Right now all of our "area" label start with "area-"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For labels, the agent will only use existing labels. It will @ the person in this list in the comment, thus the expert will receive an email noticification. We can do assign the expert directly, but personally I think this is a little aggressive.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, we shouldn't assign. I like mentioning more.

But we do have to be concerned with user-submitted content possibly spamming the repository via the agent. Some sort of guard rails around what the agent can do I think would be ideal.

Returns:
Result of the operation
"""
result = _github_request("POST", f"issues/{issue_number}/labels", repo, {"labels": labels})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar question to above, I wonder if we should be validating that the label is allow-listed to the subset of "known" labels.

Alternatively, we should validate/require that the label already exists

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This agent pull existing labels only and apply them, it can create labels if we adjust system prompt.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This agent pull existing labels only and apply them

Can you trick it into applying 200 new labels? And on unrelated issues?

types: [opened,reopened]
permissions:
contents: write
issues: write
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be architecting this similar to the existing agents. Right now, we have two stages:

  1. Agent runs in a readonly sandbox
  2. A sub-subsequent job/stage takes the output of (1) and updates writable things as appropriate. This is to help avoid the agent from having too many permissions, like updating unrelated PRs & Issues. I think we should be doing the same thing here.


on:
issues:
types: [opened,reopened]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't currently have any workflows that run agents automatically and on arbitrary issues. We'll have to evaluate how we do this. Right now all agents are "opt-in" while this is "automatic on all" which has some security concerns I think

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is an interesting topic we need to think about since we want an agent to be automated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants