deploy

skills/repo-inspection-review/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: repo-inspection-review
+description: "Review repository inspection summaries for architecture, production readiness, and prioritized fixes using cited evidence. Use after deterministic GitHub file classification and risk scanning are complete."
+---
+# repo-inspection-review
+
+# Repository Inspection Review
+
+When reviewing a repository inspection summary:
+
+1. Preserve exact citations from the deterministic scanner. Never invent files, line numbers, vulnerabilities, dependencies, or source snippets.
+2. Summarize architecture from observed files only: tech stack, entrypoints, modules/services, data stores, integrations, deployment model, CI/CD flow, runtime/configuration model, and likely request/data flow.
+3. Score production readiness conservatively. Security, dependency hygiene, test coverage, CI/CD, observability, configuration, deployment, docs, reliability, maintainability, and CI/CD should all be grounded in evidence.
+4. Prioritize recommended fixes by risk and blast radius. Each fix should include severity, rationale, cited files, effort estimate, and implementation guidance.
+5. If evidence is incomplete because large or binary files were skipped, say so explicitly and avoid overclaiming.
+6. Secret-like snippets must remain redacted. Do not reconstruct or expose credentials.
+
+Return concise JSON-compatible prose fields only. Do not include markdown fences.

skills/repository-inspection/SKILL.md

@@ -0,0 +1,32 @@
+---
+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.