Menú
Browse repos, triage issues end-to-end, inspect PRs, and read files on GitHub.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Hand a task to another agent window via send_to_window.
Spawn a sub-agent, or hand off to another profile window.
Search the live web for current information, facts, and documentation.
Read, create, and update events on the user's Google Calendar.
Read, search, send, and label-manage Gmail messages for the user.
Browse and manage Linear issues, projects, teams, and workflow states.
Basado en la clasificación ocupacional SOC
| 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:
q: "is:open is:issue assignee:@me"q: "is:issue author:@me"q: "is:open is:pr author:@me"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.