Review

Skill 2389-research/git-repo-prep/skills/review

Prepare codebases for public/open-source release and audit them for openness - full lifecycle prep or standalone review

Install

npx -y skills add 2389-research/git-repo-prep --skill review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when auditing a codebase for openness, checking for secrets, missing docs, or gaps before public release. Re-runnable at any point.

SKILL.md

5.4 KB, as published. Nobody here has run it

Review Repo for Openness

Announce: "I'm using git-repo-prep:review to audit this repo for openness."

Setup

Create a TodoWrite checklist for all audit categories:

Secrets scan
Personal info scan
License check
Documentation check
Gitignore check
CI/CD check
Metadata check
Present findings and summary

Mark each task in_progress before starting, completed immediately after.

Scope

This is an openness audit, not a code quality review. Stay focused on what matters for making the repo public. Do NOT comment on error handling, architecture, performance, code style, test coverage quality, or design patterns.

Ecosystem Detection

Detect the ecosystem to tailor checks:

File	Ecosystem
`package.json`	Node.js
`pyproject.toml` / `setup.py` / `setup.cfg`	Python
`Cargo.toml`	Rust
`go.mod`	Go
`.csproj` / `.sln`	.NET
`Gemfile`	Ruby
`pom.xml` / `build.gradle`	Java/Kotlin

Audit Categories

Scan every category below. Classify each finding as Critical, Recommended, or Nice-to-have using the severity definitions in this table exactly. Do not invent your own categories, and do not upgrade or downgrade severity — use the column where the issue appears.

Category	Critical	Recommended	Nice-to-have
Secrets	API keys, passwords, tokens, .env committed	.env in gitignore	git history scan
Personal info	Real names/emails in source code	Author field review	Username cleanup
License	No LICENSE file	Mismatch between LICENSE file and package metadata; no license section in README	License headers in source files
Documentation	No README or empty README	Missing install/usage sections	CONTRIBUTING.md, SECURITY.md, CLAUDE.md
Gitignore	Sensitive files tracked/committed	Missing common patterns for ecosystem	IDE/OS files
CI/CD	—	No CI pipeline; no tests at all (CI cannot function)	No dependabot, no hooks, no coverage
Metadata	—	No repo URL in package metadata	Missing engine/version, keywords, description

Scanning Process

Work through each category in order.

1. Secrets

Grep source files for patterns: sk_live, sk_test, ghp_, AKIA, password\s*=, secret\s*=, token\s*=, api_key, -----BEGIN.*PRIVATE KEY, connection strings with embedded credentials.
Check for .env files in the repo (any level).
Check .gitignore for .env and .env.* exclusion patterns.
Look for .pem, .key, or credential files.

2. Personal Info

Check author fields in package metadata (package.json author, pyproject.toml authors, Cargo.toml authors).
Grep for email patterns (\b\S+@\S+\.\S+\b) in source files (not node_modules, not vendor, not lock files).
Look for hardcoded usernames in config or source (DEFAULT_USER, AUTHOR, usernames in URLs or paths).

3. License

This is the most commonly missed area. Check all three locations and compare:

LICENSE file — Does it exist? What license does it contain?
Package metadata — What does the license field say in package.json / pyproject.toml / Cargo.toml?
README — Is there a license section? Does it name the same license?

Flag any mismatch between these three. Flag if any location is missing.

4. Documentation

README: Does it exist? Is it non-empty? Does it have: project description, installation/getting started, usage, license section?
CONTRIBUTING.md: Present or missing?
SECURITY.md: Present or missing?

5. Gitignore

Does .gitignore exist?
Compare against ecosystem best practices:
- Node.js: node_modules/, .env, dist/, coverage/
- Python: __pycache__/, *.pyc, .env, *.egg-info/, dist/, .venv/
- Rust: target/, .env
- Go: vendor/ (if not vendoring), .env
- General: .env, .env.*, *.log, .DS_Store, *.pem, *.key
Check if any sensitive files are already tracked by git (git ls-files for .env, credentials, keys).

6. CI/CD

Look for .github/workflows/, .gitlab-ci.yml, Jenkinsfile, .circleci/, etc.
Check for Dependabot config (.github/dependabot.yml) or Renovate (renovate.json).

7. Metadata

Check ecosystem-specific metadata completeness:

Node.js: repository, engines, keywords, description in package.json
Python: [project.urls], classifiers, requires-python, keywords, description in pyproject.toml
Rust: repository, keywords, categories, description in Cargo.toml
Go: module path matches repo URL, package doc comment

Presenting Findings

Present findings conversationally — do NOT write a report file.

Group by severity, starting with the most urgent:

Critical — issues that must be fixed before going public
Recommended — issues that should be addressed for a quality release
Nice-to-have — improvements for polish

For each finding:

Describe the issue concisely.
Explain why it matters for openness (one sentence).
Offer to fix it right now.

Summary

End with a tally: "X critical, Y recommended, Z nice-to-have findings."

If critical findings exist, recommend addressing them before release. If none, say the repo looks ready and suggest tackling recommended items for polish.