open-sourcing

Prepares repositories for public release with secrets audits, licensing, and CI-driven release automation.

6.9k|598|Updated Jan 14, 2026
One-click install
npx skills add https://github.com/trailofbits/skills --skill open-sourcing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: open-sourcing
Source: https://github.com/trailofbits/skills/tree/main/plugins/open-sourcing/skills/open-sourcing
Command: npx skills add https://github.com/trailofbits/skills --skill open-sourcing

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

Making a private repository public involves irreversible risks (leaked secrets in git history) and many easy-to-miss requirements (licensing, SECURITY.md, branch protection, trusted publishing). This Skill provides an ordered release-readiness workflow so nothing sensitive ships and outsiders can build, use, and contribute to the project.

Core Features & Use Cases

  • Secrets and history audit: Scans full git history with gitleaks or trufflehog, flags tracked files that commonly hold credentials, and recommends a fresh repository when secrets were ever committed.
  • Readiness checklist: Runs check_readiness.sh to verify README, LICENSE, CONTRIBUTING, SECURITY.md, CI, tests, and semver tags, treating gaps as discussion prompts.
  • Licensing and per-language release guidance: Applies organization license policy (with a Trail of Bits profile auto-detected from git remotes) and provides packaging, publishing, and quality tooling references for Python, C/C++, Rust, Go, JavaScript, and Ruby.
  • Use Case: A team asks to "make this repo public" — the Skill audits history for secrets, fixes documentation and licensing gaps, hardens GitHub Actions workflows, and sets up OIDC trusted publishing before the visibility switch is flipped.

Quick Start

Ask the assistant to prepare this repository for public release and check its open-source readiness.

Frequently Asked Questions about open-sourcing

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

FAQPage Schema
How do I prepare a private repository for public release?

Follow an ordered workflow: audit git history for secrets first, then verify README, LICENSE, SECURITY.md, CI, and tests, then configure branch protection and CI-driven releases. The check_readiness.sh script prints presence indicators for each readiness item.

How do I check a git repository for leaked secrets before open-sourcing?

Scan the full history with gitleaks or trufflehog rather than eyeballing, and also check GitHub Actions logs, releases, issues, and the wiki. If secrets were ever committed, create a fresh repository instead of rewriting history, since rewrites miss forks and caches.

What license should I choose for an open-source project?

Apply your organization's policy first; otherwise default to Apache 2.0 for libraries and tools, AGPLv3 when competitors could privately modify a hosted service, and Creative Commons for non-code work. Add a LICENSE file, set SPDX identifiers in package metadata, and state the license in the README.

Does this workflow support publishing Python packages to PyPI?

Yes, the Python reference covers uv builds, ruff, ty, and PyPI trusted publishing via OIDC from GitHub Actions instead of API tokens. Equivalent trusted-publishing guidance exists for Rust (crates.io), Ruby (RubyGems), and JavaScript (npm).

When should I not use an open-sourcing readiness workflow?

Skip it for routine development on already-released projects and for security audits of third-party code. If the repository stays private and you only publish a package, only the release-management steps apply.