github-repo-inspector/skills/repository-inspection/SKILL.md

name, description

name	description
repository-inspection	Apply conservative GitHub repository inspection heuristics, citations, scoring, and issue-ready recommendations. Use when inspecting source trees, configs, CI/CD, Docker, dependencies, tests, docs, infra, scripts, hidden files, and security/config risks.

repository-inspection

Repository Inspection Rules

Use deterministic evidence first. Every finding and recommendation must cite one or more repository files with line ranges and redacted snippets. Do not claim a vulnerability unless the cited file content shows the risky pattern. Prefer phrasing such as "possible", "appears", or "review" when the evidence is heuristic.

Inspection phases:

1. Authenticate and enumerate repositories/branches.
2. Fetch the complete recursive tree metadata, including dotfiles and hidden paths.
3. Record skipped folders and files explicitly. Skip only binary files and common vendor/build/cache folders unless limits require additional truncation.
4. Fetch supported text blobs within byte/file limits.
5. Classify every tree entry by role: source, config, CI/CD, Docker/container, tests, docs, package/dependency, infra/IaC, scripts, hidden/dotfiles, assets/other.
6. Analyze every fetched text file line-by-line for secrets patterns, risky configuration, TODO/FIXME/HACK/XXX, dependency hygiene, CI/CD and Docker risks, docs/tests gaps, and architecture clues.
7. Produce both machine-readable JSON and a markdown summary.

Citation rules:

• Include path, line_start, line_end, and a redacted snippet/excerpt whenever content is available.
• Redact likely secrets in snippets; never echo full tokens.
• If a finding is based only on file presence/absence, cite the nearest relevant file if possible or mark evidence_type as "repository-structure".

Scoring rules:

• Start from 100 and subtract conservative penalties for evidenced risks and missing repo capabilities.
• Include sub-scores for security, maintainability, testing, docs, CI/CD, deployability, dependency hygiene, and observability/configuration.
• Explain score drivers in markdown.

Issue payload rules:

• Each recommendation should include an issue_payload with title, body, and labels suitable for the create_issue skill.
• The body should include citations and concise remediation steps.