GitHub Repository Fetcher and Analyzer

Problem

When working with GitHub repositories, models may infer file structure, README content, dependencies, or behavior from repo names, paths, or prior memory. That can produce plausible but unverified conclusions, especially when the default branch is not main, the file path is uncertain, or the task requires inspecting a specific file.

How It Works

github-repo-analyzer follows the core rule: fetch first, then analyze. Given a GitHub URL or repo name, it extracts OWNER and REPO; for example, github.com/foo/bar maps to OWNER=foo and REPO=bar. It then uses curl to retrieve actual file content instead of guessing.

Key steps include:
- Target specific files by resolving repository structure and requesting the relevant path.
- Handle branch differences by trying master when main returns 404, or using ?ref=BRANCH for a specified branch.
- Analyze only retrieved content before drawing conclusions about code, documentation, or configuration.

Boundaries and Notes

The skill is useful for reading public GitHub files and making fact-based observations, such as reviewing configuration files, scripts, documentation, or dependency declarations. It is not suited for authenticated access, private repositories, full-repository scans, or high-frequency API calls. Unauthenticated GitHub API access has a 60 req/hour rate limit. Use it with a clear target file, branch, and analysis question, and avoid treating missing or unfetched content as confirmed evidence.