repo-readiness-review

Reviews repository safety, structure, docs, dependencies, and runnability before publishing or handoff.

1|Updated Jun 3, 2026
One-click install
npx skills add https://github.com/tanveerriaz/Skillz --skill repo-readiness-review-tanveerriaz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: repo-readiness-review
Source: https://github.com/tanveerriaz/Skillz/tree/main/skills/repo-readiness-review
Command: npx skills add https://github.com/tanveerriaz/Skillz --skill repo-readiness-review-tanveerriaz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Repositories accumulate stray files, missing documentation, committed secrets, and "works on my machine" gaps that make them unsafe or impossible for others to run. This Skill provides a single checkpoint that decides whether a repo is ready to publish, hand off, or release — and exactly what to fix first if it is not. ## Core Features & Use Cases - Five-Area Readiness Pass: Checks safety (secrets, private data, .gitignore), structure (no committed artifacts or vendored deps), docs (README, .env.example), dependencies (pinned manifest, lockfile), and runnability (clone-and-run from README alone). - Go / Fix-First Verdict: Returns a clear verdict with a prioritized punch list, blockers listed before nice-to-haves. - Edge-Case Handling: Adjusts the bar for private handoffs, prototypes, monorepos, and repos without tests. - Use Case: Before open-sourcing a side project, run this review to catch a committed .env file and a missing run command in the README, fix them, and then ship with confidence. ## Quick Start Review this repository for readiness before I make it public and give me a go or fix-first verdict with a prioritized punch list.

Frequently Asked Questions about repo-readiness-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my repository is ready to make public?▼

Run a readiness review covering five areas: safety (no secrets or private data), structure (no committed artifacts), docs (README with setup and run steps), dependencies (pinned manifest and lockfile), and runnability (a newcomer can run it from the README alone). Any safety failure is a blocker.

What should a README include before open-sourcing a project?▼

A README should explain what the project is, who it is for, how to set it up, and how to run it. Pair it with a .env.example documenting required configuration so a new person can reach a running app without insider knowledge.

How do I check a repo for committed secrets before publishing?▼

Scan for secrets, .env files, private URLs, internal IPs, personal data, and employer or client references, and confirm .gitignore is strong. Treat any finding as a blocker — remove the secret, rotate it, and never give a go verdict while it is unresolved.

Does a repo readiness review differ for private handoffs versus public release?▼

Yes. For private internal handoffs the safety bar is lower than for public repos, but secrets still do not belong in git and are flagged. For prototypes, the review scopes down to handoff runnability and skips polish items.

Is missing test coverage a blocker for releasing a repository?▼

No. Missing tests are noted as a risk and called out in the review, but they are not necessarily a blocker for handoff or release. Safety issues like committed secrets are the true blockers.