菜单
Use when setting up a new repo, auditing an existing one for hygiene issues, or before publishing a project. Covers .gitignore, .env.example, README, LICENSE, CONTRIBUTING, and detecting committed secrets.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when making git operations, handling secrets, committing code, or dealing with credentials. Enforces git safety rules (no force-push to main, no amend of published commits), secret-handling discipline (never commit .env, use .env.example), and destructive-command caution.
Use when implementing features spanning 3+ files, when requirements are unclear, or when structuring multi-step work. Covers when to plan vs just code, plan structure, interview-then-execute, and prototype-over-spec patterns.
Use when reviewing code changes, examining PRs, or checking your own work before submitting. Covers what to look for (correctness, security, performance, style), how to review systematically, and how to give actionable feedback.
Use when preparing to ship a feature -- opening a PR, writing release notes, cutting a version, or coordinating a deploy. Covers PR hygiene, commit messages, release process, and post-ship verification.
Use when completing a task, before claiming work is done, or before creating a PR. Enforces verification beyond "tests pass" -- actually run the code, hit the endpoints, open the browser. Prevents premature completion claims.
| name | audit |
| description | Use when setting up a new repo, auditing an existing one for hygiene issues, or before publishing a project. Covers .gitignore, .env.example, README, LICENSE, CONTRIBUTING, and detecting committed secrets. |
| File | Purpose | Why It Matters |
|---|---|---|
README.md | Project overview, quick start | First impression, onboarding |
LICENSE | Legal terms for use | Without one, code is "all rights reserved" by default |
.gitignore | Files to exclude from git | Prevents committing secrets, build artifacts |
.env.example | Template for env vars | Shows structure without revealing secrets |
CONTRIBUTING.md | How to contribute | Reduces friction for contributors |
CHANGELOG.md | Version history | Users track what changed |
CODE_OF_CONDUCT.md | Community expectations | Required for many registries |
Minimum patterns for any repo:
# Secrets
.env
.env.local
.env.*.local
# OS
.DS_Store
Thumbs.db
desktop.ini
# Editors
.vscode/
.idea/
*.swp
*.swo
*~
# Logs
*.log
logs/
# Dependencies (language-specific)
node_modules/
__pycache__/
*.pyc
.venv/
venv/
target/
vendor/
# Build artifacts
dist/
build/
out/
*.egg-info/
# Coverage
coverage/
.coverage
htmlcov/
Language additions:
node_modules/, dist/, .next/, .turbo/__pycache__/, *.pyc, .venv/, venv/, .pytest_cache/, .mypy_cache/target/, Cargo.lock (for libs, commit for bins)vendor/, bin/.terraform/, *.tfstate*, *.tfvars (if contains secrets)target/, .gradle/, *.classMinimum sections:
# Project Name
One-line tagline.
## Why
What problem does this solve?
## Install
Exact commands to install.
## Quick Start
Minimal working example.
## Usage
Common use cases with code examples.
## License
License name with link to LICENSE file.
Nice to have:
# Database
DATABASE_URL=postgresql://user:password@localhost:5432/dbname
# Auth
JWT_SECRET=change-me-to-a-long-random-string
OAUTH_CLIENT_ID=your-oauth-client-id
OAUTH_CLIENT_SECRET=your-oauth-client-secret
# External APIs
OPENAI_API_KEY=sk-...
AWS_REGION=us-east-1
# Feature flags
ENABLE_BETA_FEATURES=false
Rules:
Before publishing a repo publicly, scan for leaked secrets:
# Check git history for common patterns
git log -p | grep -iE 'api[_-]?key|secret|password|token|bearer' | grep -v example
# Dedicated tools
gitleaks detect --source=. --verbose
trufflehog git file://. --only-verified
# GitHub's own scanner runs automatically on public repos
If secrets are found in history:
git filter-repo or BFG to remove from history| License | When to Use |
|---|---|
| MIT | Permissive, short, widely used. Best default for most projects |
| Apache 2.0 | Like MIT but with patent protection. Larger projects, corporate use |
| GPL-3.0 | Copyleft -- derivatives must also be GPL. Strong software freedom |
| BSD-3-Clause | Very permissive, slightly different from MIT |
| Unlicense / CC0 | Public domain, no restrictions |
| Proprietary | Internal/commercial code. No file = "all rights reserved" |
Generate: https://choosealicense.com
package.json, requirements.txt, Dockerfile, tsconfig.json.env.example, config.example.yml.env, config.yml (with real values), node_modules/, build artifactspackage-lock.json, yarn.lock, Cargo.lock, poetry.lock): commit for apps, skip for libs1. Check for .gitignore -- does it cover your stack?
2. Check for README -- is it accurate and useful?
3. Check for LICENSE -- is there one?
4. Check for .env.example -- if app uses env vars
5. Scan for committed secrets (gitleaks)
6. Check for outdated dependencies
7. Check CI status -- is it green?
8. Check stale branches -- prune or merge
9. Check for TODO/FIXME density -- tech debt signal
10. Check commit message quality -- conventional commits?
| Anti-Pattern | Problem | Do Instead |
|---|---|---|
| No README | Users can't onboard | Even a 5-line README helps |
| README listing what code does | Duplicates the code | Focus on WHY and HOW TO USE |
| No LICENSE | "All rights reserved" by default -- users can't legally use it | Pick one from choosealicense.com |
Committing .env | Secrets leaked forever | Use .env.example, add .env to .gitignore |
| Broken links in README | Unprofessional, frustrating | Test links periodically |
| Outdated dependencies with CVEs | Security risk | Automated updates (Renovate, Dependabot) |
| Empty CONTRIBUTING.md | Signals unmaintained | Either write one or remove file |