github

name	github
description	Browse repos, triage issues end-to-end, inspect PRs, and read files on GitHub.
scope	agent
requires	["github"]

Owner vs. repo: every tool with an owner/repo pair takes them as SEPARATE fields. owner is the user or org (e.g. cokokerems), repo is the repository name alone (e.g. workos) — never cokokerems/workos in a single field. The only place owner/name appears combined is inside a github_search_issues query string (repo:owner/name).

Typical flows:

Discover repos → github_list_repos when the user hasn't specified a repo. Pick the most relevant one or ask to confirm before proceeding.

Triage issues (batch) → github_list_issues (filter by label/state if the user specifies) → group by theme → propose labels, priorities, or owners. Don't auto-create issues unless the user confirmed.

Triage one issue end-to-end → github_get_issue for full body and labels → analyze → either draft a comment with github_comment_issue, or close/update with github_update_issue. Always confirm with the user before closing or relabelling.

My open work across repos → prefer github_search_issues over listing each repo. Examples:

• "my open issues": q: "is:open is:issue assignee:@me"
• "issues I filed": q: "is:issue author:@me"
• "my open PRs": q: "is:open is:pr author:@me"
• Scope to a repo: add repo:owner/name to the query.

Create an issue → github_create_issue with a concrete title (not "bug") and a body that includes reproduction steps or acceptance criteria.

Update or close an issue → github_update_issue with only the fields you're changing. Setting state: 'closed' closes it; pair with state_reason: 'completed' or 'not_planned' when relevant. labels and assignees REPLACE the existing list — don't pass them unless you intend to overwrite.

Browse pull requests → github_list_pulls to see what's open. Suggest which to dig into; reading PR bodies/diffs is a follow-up (separate tool, not yet available — stop after listing).

Read a file → github_get_file for READMEs, config files, package.json, etc. The response content field is base64-encoded — decode it before summarising. Pass ref to read from a specific branch or commit; omit it for the default branch.

Understand a repo → github_get_repo for metadata (description, stars, language); otherwise infer from issues/PRs before asking.

Always show issue and PR numbers (#123) when referring back.