SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsopen-source-prep

open-source-prep

Deployment & operations

View repository

Updated 10-15 22:16

About this skill

Open Source Prep

Turn a private project into a repository that is safe to open-source. Execute serially in 5 phases,Secret scanning must pass firstbefore proceeding to subsequent steps.

Use cases

The user says:

  • "Help me open-source this project"
  • "What needs to be done before preparing to open-source"
  • "Choose an open-source license"
  • "Check for leaks before uploading to GitHub"

Important principles

  1. Secret scanning is a gating step — when a real secret is found, you must stop and have the user clean it up first; you cannot simply continue
  2. Generated documents should be in English — aimed at international contributors; converse with the user in Chinese
  3. The LICENSE file must be named LICENSE(uppercase, no extension) for GitHub to recognize it
  4. All real token examples must use the ...REDACTED... placeholder — even if the user pasted it in themselves
  5. Do not directly push or switch to public — first have the user review the diff, then manually commit+push+switch visibility

Workflow

Phase 1: Secrets & sensitive file scanning (BLOCKING)

This must be done first; if problems are found, stop. Scan three places:

  1. Current workspace files(including untracked ones)
  2. Staged / committed content
  3. All git history（git log --all -p）

See scanning patterns in references/secrets-patterns.md. Key patterns include:

Type Pattern
JWT eyJhbGc[0-9A-Za-z_-]{20,}
GitHub token gh[posur]_[0-9A-Za-z]{36,}
OpenAI / Anthropic sk-[a-zA-Z0-9]{20,}, sk-ant-[a-zA-Z0-9-]{40,}
AWS access key AKIA[0-9A-Z]{16}
Google API key AIza[0-9A-Za-z_-]{35}
Slack token xox[baprs]-[0-9A-Za-z-]{10,}
Stripe sk_live_[0-9A-Za-z]{20,}
Private key PEM -----BEGIN.*PRIVATE KEY-----
Generic password password\s*[:=]\s*["'][^"']{8,}

Sensitive file names (alert when staged):

  • .env, .env.local, .env.production
  • credentials.json, secrets.json
  • *.pem, *.key, *.p12, *.pfx
  • id_rsa, id_ed25519

Execute commands(adapt to project size):

# 工作区扫描（含未追踪）
git ls-files --others --exclude-standard -z | xargs -0 grep -lE "<pattern>" 2>/dev/null

# 已追踪文件
git grep -nE "<pattern>" 2>/dev/null

# Git 历史
git log --all -p 2>/dev/null | grep -cE "<pattern>"

# 敏感文件名
git ls-files | grep -E "(^|/)(\.env|credentials\.json|.*\.(pem|key|p12|pfx))$"

Distinguish real secrets vs placeholders：

  • ✅ Placeholder: contains ... / REDACTED / example / test / xxx / dummy
  • ❌ Real secret: no obvious placeholder marker and matches the real format (e.g., a JWT is three dot-separated base64url segments, AWS is 20 characters all uppercase + digits, etc.)

When a real secret is found：

  1. List the file + line number + truncated display (eyJhbGc...[12 chars]...abcd first and last 4 characters each, with the middle omitted)
  2. Provide remediation suggestions:
    • If in the workspace → move to .env and add to .gitignore
    • If already committed but not pushed → git filter-repo or git reset --soft HEAD~1
    • If already pushed → the token must be revoked immediately(this tool cannot delete a leaked commit from GitHub), then git filter-repo --invert-paths + force push
  3. Stop subsequent steps, have the user handle it and then rerun

Phase 2: License selection (interactive)

Recommend based on a decision tree; do not ask all questions right away:

First question: What is the nature of the project?

  • Personal tool / small library / application → continue to question two
  • Commercial product open-sourced externally / want enterprises to use it with confidence → Apache 2.0
  • Want all derivative works to also be open-source → continue to question three

Second question(For personal projects): Does it involve patentable novel technology?

  • No → MIT ⭐
  • Yes → Apache 2.0

Third question(For copyleft preference): SaaS form (users use it over the network without downloading)?

  • Yes → AGPL v3
  • No → GPL v3

Default recommendation: MIT — suitable for 95% of personal projects. Generated LICENSE uses the templates/LICENSE-MIT.txt template, the copyright holder is read from git config user.name , and the year is the current year.

License comparison quick reference:

License Length Patent Trademark copyleft Scenario
MIT 20 lines None None None Top choice for personal tools
Apache 2.0 200 lines Explicit Protection None Enterprise/patent scenarios
GPL v3 Long Yes - Strong Viral open source
AGPL v3 Long Yes - Very strong SaaS scenarios

Phase 3: Essential documentation generation

Generate the following files (if they already exist, show a diff, and only change them after the user confirms):

  1. LICENSE — License text, fill in copyright holder + year
  2. CONTRIBUTING.md — Development environment, PR process, test commands (use templates/CONTRIBUTING.md）
  3. SECURITY.md — Vulnerability reporting process (use templates/SECURITY.md）
  4. README.md supplements(insert with the Edit tool):
    • Top: Third-party disclaimer (if the project involves third-party services)
    • Privacy & Security section (if sensitive data is processed)
    • License section points to the LICENSE file

Phase 4: Configuration audit

Check and suggest changes:

  1. .gitignore — Ensure it includes:

    src-tauri/target/   # Tauri
target/             # Rust 通用
node_modules/       # Node
dist/ build/ out/   # 构建产物
.env*               # 环境变量
.DS_Store Thumbs.db # OS
coverage/ *.lcov    # 覆盖率报告

  2. Bundle identifier / package name check：

    • src-tauri/tauri.conf.json 's identifier field
    • package.json 's name field
    • Cargo.toml 's [package] name
    • If it contains a third-party company name (such as com.google.*、com.factory.*) → warn about trademark risk
    • Suggest changing to com.<github-username>.<project-name>

  3. Third-party service references：

    • grep the project name for trademarks ("Google X", "Apple X", etc.)
    • Does the README state that this is unofficial third-party tool

Phase 5: Optional enhancements

Ask the user whether to do:

  • CHANGELOG.md (generate an initial version from git log)
  • GitHub Actions release workflow（.github/workflows/release.yml）
  • Issue/PR templates (.github/ISSUE_TEMPLATE/）
  • Repository visibility switch (gh repo edit --visibility public）

Note: Switching to public isirreversible information disclosure, and it must only be executed after explicit user confirmation, and Phase 1 secret scanning must be run again.

Output format

After each phase, report to the user:

## Phase N: xxx

✅ 通过：[...]
⚠️ 警告：[...]
❌ 需处理：[...]

下一步：[...]

Finally, provide a complete checklist.

Tool files

  • templates/LICENSE-MIT.txt — MIT license template (use {{YEAR}} {{AUTHOR}} placeholder)
  • templates/LICENSE-Apache-2.0.txt — Apache 2.0 template
  • templates/LICENSE-GPL-3.0.txt — GPL v3 template (longer; you can use gh api to fetch the official text)
  • templates/LICENSE-AGPL-3.0.txt — AGPL v3 template
  • templates/CONTRIBUTING.md — Contribution guidelines template
  • templates/SECURITY.md — Security policy template
  • references/secrets-patterns.md — Complete list of secret regex patterns
  • references/disclaimer-templates.md — Disclaimer examples for different scenarios