GitHub Navigator
Use gh for GitHub work. Prefer command discovery over memorizing flags.
This is an execution skill. Use gh instead of generic web fetching for GitHub tasks, inspect gh --help when syntax is uncertain, then execute with tight guardrails. Keep the main flow lean and load REFERENCES.md only when you need concrete examples, installation steps, or GraphQL details.
When to Use
Activate when:
- the user gives a
github.comURL - the user names a repo path like
facebook/reactorowner/repo - the user asks about repository files, issues, PRs, releases, workflows, or metadata
- the user wants to understand the architecture or structure of a GitHub-hosted codebase
Core Rules
- Always prefer
ghoverWebFetchfor GitHub content and operations. - Use
gh apifor raw file content, directory listings, and API-only endpoints. - Use
ghsubcommands (issue,pr,release,run,workflow,repo) when a dedicated command exists. - Use
gh <domain> --helpbefore guessing flags or subcommands. - Limit each command pattern to 2 attempts; if it still fails, stop and report the error.
Command Routing
| User Intent | Primary Command Path |
|---|---|
| fetch file or list directory | gh api repos/OWNER/REPO/contents/... |
| inspect issues | gh issue ... |
| inspect pull requests | gh pr ... |
| inspect releases | gh release ... |
| inspect Actions runs or workflows | gh run ... or gh workflow ... |
| inspect repo metadata or clone/fork | gh repo ... |
| endpoints without a dedicated subcommand | gh api ... |
Use dedicated subcommands first. Fall back to gh api only when needed.
Execution Pattern
- Identify the command domain from the request.
- Check the relevant help output if the exact syntax is not already obvious.
- Substitute the user's repo, path, issue number, PR number, or other arguments.
- Run the command.
- If it fails, adjust once based on the error message.
- If it fails again, stop and report the error instead of trying blind variations.
Deep Analysis Mode
When the user wants to understand a codebase deeply, clone it locally for inspection instead of making many remote API calls.
Default flow:
-
Clone with depth 1 to
/tmp/github-navigator/OWNER-REPO/git clone --depth 1 https://github.com/OWNER/REPO.git /tmp/github-navigator/OWNER-REPO -
Inspect the repository for:
- tech stack signals (
package.json,go.mod,Cargo.toml,pom.xml,requirements.txt, etc.) - high-level directory structure
- entry points and primary modules
- README, docs, examples, and contribution files
- architectural patterns worth calling out
- tech stack signals (
-
Summarize the findings in plain language.
-
Keep the clone for follow-up questions unless cleanup is requested.
Use a full clone only if the user explicitly needs commit history or deeper git analysis.
Safety
Always confirm before executing state-changing or destructive commands, including:
- creating, closing, or reopening issues
- creating, merging, or closing pull requests
- deleting, archiving, or transferring repositories
- setting secrets or triggering workflows
- any use of
--force,--yes, or similar bypass flags
Authentication and Recovery
- Check
gh auth statuswhen the task touches private repos or write operations. - Use
gh auth loginif the client is not authenticated. - If permissions are insufficient, use
gh auth refresh -s repo -s workflow -s read:orgas appropriate. - If a command fails, read the error, check help, retry once, then stop.
- If
ghis not installed, point the user to REFERENCES.md for installation guidance.
Reference Handoff
Use REFERENCES.md when you need:
- concrete example commands for common tasks
- install and auth setup details
- troubleshooting reminders
- GraphQL examples or other lower-frequency patterns
License: MIT See also: REFERENCES.md