🇺🇸English

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:

1. Secrets scan
2. Personal info scan
3. License check
4. Documentation check
5. Gitignore check
6. CI/CD check
7. Metadata check
8. 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:

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.

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 and exclusion patterns.

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:

1. LICENSE file — Does it exist? What license does it contain?
2. Package metadata — What does the license field say in package.json / pyproject.toml / Cargo.toml?
3. 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/

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

Presenting Findings

Present findings conversationally — do NOT write a report file.

Group by severity, starting with the most urgent:

1. Critical — issues that must be fixed before going public
2. Recommended — issues that should be addressed for a quality release
3. 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.

Weekly Installs

1

Repository

2389-research/c…-plugins

GitHub Stars

25

First Seen

1 day ago

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1