This skill should be used when the user asks to "open source this project", "prepare this repository for public release", "make this repo public", "check open-source readiness", "choose a license for this project", or "set up release automation" ahead of a public launch. Provides a release-readiness workflow covering secrets hygiene, licensing, documentation, CI, and language-specific packaging.
SkillScore95Maintained
Automatic
◆DevOps & SRE pack
Last verified 8/7/2026
What it changes
Passed 20 of 21 test cases with the skill, and 12 of 21 without it.
Without skill59%
With skill95%
Checks it passed that the model alone missed
Designates Apache 2.0 as the permissive default license
Mentions executing detect_org.sh to check organizational context
Mentions executing detect_org.sh to identify organizational policy
and 7 more in the full report
8 fixed13 passed either way1 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+73%
Agent turns
0%
Response time
-51%
Model gemini-3.6-flashMeasured 8/7/2026v121 of 22 cases passed with skill · 21 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
We are preparing a Go repository for open-sourcing. The project currently uses an older linter configuration that works and passes in CI. Should we replace it with the newest recommended default linter and rule set as part of the open-sourcing task?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends keeping the existing working linter rather than replacing it during open-sourcing
Passed
Passed
Advises leaving tool replacement decisions to maintainers unless a linting category is missing entirely
Missed
Passed
case-09 · gemini-3.6-flash · 8/7/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md219 lines11 filesincludes scripts
Open-Sourcing a Repository
Prepare a repository for public release so that an outsider with no prior
context can build, use, and contribute to it — and so that nothing sensitive
ships with it. Work through the steps in order; the secrets audit comes first
because its outcome (keeping vs. recreating the repository) affects
everything after it.
When to Use
Making a private repository public
Auditing an existing public repository for release quality ("make it
official")
Choosing a license for a project
Setting up packaging, versioning, or release automation ahead of a public
launch
When NOT to Use
Routine development on an already-released project (no release event)
Auditing third-party code for vulnerabilities (use a security-review skill)
Publishing a package from a repository that will stay private — only the
release-management steps apply; skip the rest
Workflow
Step 1: Detect the organization profile
bash {baseDir}/scripts/detect_org.sh
The script inspects git remotes and recent committer emails, and prints a
profile name. If it prints trailofbits, read
references/trailofbits.md now and apply its
license policy, publishing accounts, and process notes throughout the
remaining steps. If it prints generic, proceed with the generic guidance
alone. If the user says the detection is wrong, trust the user.
Parses and processes SARIF files from static analysis tools like CodeQL, Semgrep, or other scanners. Triggers on "parse sarif", "read scan results", "aggregate findings", "deduplicate alerts", or "process sarif output". Handles filtering, deduplication, format conversion, and CI/CD integration of SARIF data. Does NOT run scans — use the Semgrep or CodeQL skills for that.