[Feature]: Add basic GitHub daily management capabilities (labels, views, milestones, projects)

[easonLiangWorldedtech]

Problem

Currently Roomote's GitHub integration focuses on core dev workflows — PR reviews, code fixes, and task sessions. However, developers also spend significant time on routine GitHub housekeeping tasks that are not covered: managing labels, creating/querying saved views, setting up milestones for tracking, and interacting with project boards. These are daily operations that could be handled through Roomote's natural language interface, reducing context switching between the GitHub web UI and the agent workspace.

Current workaround

Users manually navigate to GitHub's web UI to:

• Create/edit labels across repositories
• Build saved views with complex filter combinations (is:issue label:bug author:@me)
• Set up milestones and assign issues to them
• Move items between project board columns
  All of these require leaving the Roomote conversation context.

Proposed behavior

Roomote should support natural language commands for four core GitHub management surfaces:

1. Labels — create, edit, delete, list labels; suggest label names based on issue content; apply labels to issues/PRs via command
2. Views — create saved views with filter conditions (e.g., is:issue label:bug assignee:@me), query existing views, share view links
3. Milestones — create milestones with due dates, add issues to milestones, check milestone progress/completion status
4. Projects — list project boards, move items between columns (e.g., "move [Chore] Clear develop CI lint and knip failures after automation work items flatten #123 to In Progress"), basic board state queries

These should work via Roomote's existing GitHub integration surface (GitHub channel/agent), using the GitHub REST/GraphQL API under the hood.

Affected surfaces

• GitHub
• Generalist agent
• API

Alternatives considered

A more comprehensive "GitHub CLI" mode that exposes all GitHub API endpoints, but that's scope for a future enhancement. This proposal focuses on the 4 most commonly used daily management features first.

Documentation impact

• Update GitHub integration docs to cover new commands
• Add examples in existing GitHub section (labels, views, milestones, projects usage)

[roomote-roomote]

I'd like to help with this issue, but need a little clarification before it can be scoped into an implementation plan.

The current provider-neutral source-control API supports issue and pull-request reads/writes only, while GitHub-specific access is split between Octokit helpers and task-local GitHub CLI calls. Labels and milestones map to repository issue APIs, but “saved views” and project boards have several materially different GitHub models.

• When you say saved views, do you mean GitHub issue search URLs that Roomote should generate/share, GitHub Projects views, or Roomote-managed named views? Please share one or two existing GitHub URLs or workflows that represent the intended result.
• For projects, are the target boards GitHub Projects (V2), and which field should be changed for “move [Chore] Clear develop CI lint and knip failures after automation work items flatten #123 to In Progress” (for example a single-select Status field)? Please share an example project configuration if available.
• Are these operations expected to work only within the repository mapped to the task, or should a single request be able to name another installed repository or organization project?
• What confirmation/audit behavior is expected for destructive mutations such as deleting labels or moving project items?

For maintainers, I recommend treating repository labels and milestones as a first increment, then adding Projects V2 via GraphQL with explicit project/field selection. The answer on saved views determines whether this is URL generation, project-view discovery, or a new Roomote persistence feature.

Please tag @roomote-roomote with the requested details, and I'll prepare a concrete implementation plan.

[easonLiangWorldedtech]

@roomote-roomote Thanks for asking — here are my answers:

Saved views:
I mean GitHub's native Views feature . These are named, filterable queries like is:issue label:bug assignee:@me that users can save and revisit. Roomote should be able to:

• Create a saved view with a given name + filter expression
• Query existing views by name or list them
• Open/share the resulting URL

This is not about GitHub Projects V2 views — it's purely about the issue/PR search Views feature in the Issues tab. Think of it as "save your common filters so you don't have to type them every time."

Projects:
Targeting GitHub Projects (V2) via GraphQL. The "move #123 to In Progress" example refers to updating a single-select field (e.g., Status column) on a project item. Roomote should:

• List available projects for the repo
• Show current status of an issue in a project board
• Update the Status field value

I don't have a specific project config to share — this is meant to work with any standard GitHub Project V2 board that has a Status single-select field. The exact project name and field name should be configurable or discoverable via API.

Scope:
Repository-scoped by default. Roomote operates within the context of a task session which already knows which repo it's working on. So labels, milestones, views, and projects should all apply to that mapped repository. No need for cross-repo references unless explicitly specified (e.g., "create milestone in org/foo").

Confirmation/audit:

• Low risk (read-only / non-destructive): list labels, query views, check milestone progress — no confirmation needed
• Medium risk (mutations that are reversible): create/edit labels, add issues to milestones, move project items — Roomote should confirm the action before executing (e.g., "Moving [Chore] Clear develop CI lint and knip failures after automation work items flatten #123 to In Progress on Project X. Confirm?")
• High risk (destructive): delete label, delete milestone, delete view — explicit confirmation required, and Roomote should show what will be deleted

[roomote-roomote]

I saw the mention, but I need your GitHub account linked to Roomote before issue and PR comments can start work here. Link it from Settings -> Linked Accounts and then mention me again.

[mrubens]

@roomote-roomote please answer. @easonLiangWorldedtech we're working on way to add contributors to our Roomote, stay tuned!

[roomote-roomote]

I'm on it. I started a task for this issue, and I'll keep updates here.

See task

[roomote-roomote]

Thanks for the detailed answers, @easonLiangWorldedtech. The proposed scope is now clear.

A sensible delivery sequence is:

1. Repository labels and milestones, with confirmation for mutations and explicit confirmation for deletes.
2. Native GitHub issue-search views: create/list/share named filter views.
3. GitHub Projects V2 support through GraphQL: discover projects and fields, inspect an item's status, and update a configurable single-select Status field.

All operations will default to the task's mapped repository; read-only actions can run directly, while reversible and destructive changes follow the confirmation model you described. We will share an implementation update as this moves forward.

[daniel-lxs]

@roomote-roomote are these not supported through our Github integration right now? it seems like we just would have to extend the scope of the MCP right?

[roomote-roomote]

I'm on it. I routed this request into the existing task for this issue so follow-up work stays on one Roomote thread, and I'll keep updates here.

See task

[roomote-roomote]

Yes, that is largely the right direction, but these capabilities are not exposed through the task-facing GitHub integration today.

The current GitHub MCP policy is intentionally read-only and allowlists repository, issue, and pull-request context tools. Labels, milestones, and Projects V2 would require expanding the upstream tool surface, Roomote's allowlist, and the mutation/confirmation layer. Labels and milestones can build on the GitHub App's existing issues: write permission; Projects V2 additionally needs GraphQL support plus project/field discovery and the appropriate project permission model.

Native GitHub saved views are the exception. They are user-scoped rather than repository-scoped, while Roomote tasks deliberately use repository-scoped GitHub App installation tokens instead of a linked user's full OAuth token. The current linked-account OAuth flow only requests identity access. Supporting native saved views therefore needs an explicit delegated-user authorization path (or a Roomote-managed view model), not just an MCP allowlist extension.

So: labels, milestones, and most Projects operations are primarily an MCP/API-scope expansion with confirmation safeguards; native views need a small auth/product decision as well.