github

name	github
description	Triage and orient GitHub repository, pull request, and issue work through the connected GitHub app. Use when the user asks for general GitHub help, wants PR or issue summaries, or needs repository context before choosing a more specific GitHub workflow.

GitHub

Overview

Use this skill as the umbrella entrypoint for general GitHub work in this plugin. It should decide whether the task stays in repo and PR triage or should be handed off to a more specific review, CI, or publish workflow.

This plugin is intentionally hybrid:

• Prefer the GitHub app from this plugin for repository, issue, pull request, comment, label, reaction, and PR creation workflows.
• In Bluex agent workspaces, prefer registered atomic tools when they exist: git.status, git.current_branch, git.changed_files, git.create_branch, git.stage, git.commit, git.push, github.issues.comment, github.issues.create, github.pull_requests.find_for_branch, github.pull_requests.create, github.pull_requests.get, github.pull_requests.comment, github.pull_requests.review, github.pull_requests.diff, github.pull_requests.checks, and github.actions.failed_logs.
• Issue-level Bluex handoffs are not generic GitHub issue comments. Use comments.create_issue_handoff; if it fails, block with the exact failure instead of posting through the GitHub app, github.issues.comment, or raw gh.
• Use local git and gh only for gaps that no connector or registered atomic tool covers, such as gh auth status, raw branch checkout, ad hoc repository inspection, or a GitHub API field missing from the registered tools.
• Keep connector state and local checkout context aligned. If the request is about the current branch, resolve the local repo and branch before acting.

Once the intent is clear, stay inside the current bundled role skill and the registered tools for that role. Do not assume external GitHub plugin specialist skills exist in a materialized Bluex agent workspace.

Connector-First Responsibilities

Handle these directly in this skill when the request does not need a narrower specialist workflow:

• repository orientation once the repo, PR, issue, or local checkout is identified
• recent PR or issue triage
• PR metadata summaries
• PR patch inspection
• PR comments, labels, and reactions
• issue lookup and summarization
• PR creation after a branch is already pushed

Prefer the GitHub app from this plugin for those flows because it provides structured PR, issue, and review-adjacent data without depending on a local checkout. If the repository is not already identifiable from the user request or local git context, ask for the repo instead of pretending there is a repo-search flow that may not exist.

Routing Rules

1. Resolve the operating context first:
   • If the user provides a repository, PR number, issue number, or URL, use that.
   • If the request is about "this branch" or "the current PR", resolve local git context with git.current_branch and use github.pull_requests.find_for_branch where available.
   • If the repository is still ambiguous after local inspection, ask for the repo identifier.
2. Classify the request before taking action:
   • repo or PR triage: summarize PRs, issues, patches, comments, labels, reactions, or repository state
   • review follow-up: unresolved review threads, requested changes, or inline review feedback
   • CI debugging: failing checks, Actions logs, or CI root-cause analysis through github.pull_requests.checks and github.actions.failed_logs
   • publish changes: create or switch branches, stage changes, commit, push, and open a draft PR through the registered git.* and github.pull_requests.* tools where available
3. When the category is clear, follow the current bundled role skill for review follow-up, CI debugging, or publishing changes using the registered Bluex tools. Materialized Bluex workspaces do not bundle external GitHub specialist skills such as review-comment, CI-fix, or publish workflows.
4. Keep the hybrid model consistent after routing:
   • connector first for PR and issue data
   • local git and gh only for the specific gaps neither the connector nor registered atomic tools cover

Default Workflow

1. Resolve repository and item scope.
2. Gather structured PR or issue context through the GitHub app from this plugin.
3. Decide whether the task stays in connector-backed triage or should be handled by the current bundled role workflow.
4. Continue through the current role workflow when the work becomes review follow-up, CI debugging, or publish workflow.
5. End with a clear summary of what was inspected, what changed, and what remains.

Output Expectations

• For triage requests, return a concise summary of the repository, PR, or issue state and the next likely action.
• For mixed requests, tell the user which specialist path you are taking and why.
• For connector-backed write actions, restate the exact PR, issue, label, or reaction target before applying the change.
• Never imply that raw shell is required for GitHub Actions logs when github.actions.failed_logs covers the workflow run. If raw gh remains necessary, state the missing field or API shape.

Examples

• "Use GitHub to summarize the open PRs in this repo and tell me what needs attention."
• "Help with this PR."
• "Review the latest comments on PR 482 and tell me what is actionable."
• "Debug the failing checks on this branch."
• "Commit these changes, push them, and open a draft PR."