33 lines
2.3 KiB
Markdown
33 lines
2.3 KiB
Markdown
---
|
|
name: repository-inspection
|
|
description: "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.
|