opensource-release-edho-ferdian

Sanitize, audit, and package a private project for open-source release in three gated phases.

2|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/edhoferdian/EEF --skill opensource-release-edho-ferdian-edhoferdian
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: opensource-release-edho-ferdian
Source: https://github.com/edhoferdian/EEF/tree/main/.agents/skills/opensource-release-edho-ferdian
Command: npx skills add https://github.com/edhoferdian/EEF --skill opensource-release-edho-ferdian-edhoferdian

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Publishing a private project publicly risks leaking secrets, credentials, PII, and internal references hidden in code, config files, and git history. This Skill runs a three-phase pipeline — fork/prep, independent adversarial audit, and packaging — so a project only gets packaged after a verifier that never trusted the sanitizer's own report confirms it is clean. ## Core Features & Use Cases - Secret extraction, not deletion: Detects credentials, tokens, and connection strings, moves them into .env.example as configurable placeholders, and replaces internal domains, IPs, and personal paths using a shared pattern file. - Independent adversarial audit: Phase 2 re-derives every finding from the filesystem and git history without trusting Phase 1's report, returning PASS, FAIL, or PASS-WITH-WARNINGS, with FAIL hard-blocking packaging. - Release packaging: Generates a verified CLAUDE.md (under 100 lines), executable setup.sh, enhanced README.md, LICENSE, CONTRIBUTING.md, and GitHub issue templates. - Use Case: You have a private side project with hardcoded database URLs and your personal email in configs. Ask to open-source it, and the Skill stages a sanitized copy, audits it independently, gets your explicit decision on any warnings, then produces a ready-to-publish repository. ## Quick Start Ask the assistant to open-source the project at a given path, specifying the target directory and intended license, and let it run the three-phase release pipeline.

Frequently Asked Questions about opensource-release-edho-ferdian

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

FAQPage Schema
How do I safely open-source a private project with secrets in it?

Run a staged sanitization pipeline: copy the project to a separate directory, extract secrets into .env.example as placeholders, replace internal references, and reset git history. Then run an independent audit before generating any packaging files.

How to remove secrets from git history before publishing a repo?

The safest approach is creating a fresh repository with a single initial commit on the sanitized copy, since deleted secrets persist in old commit objects. The audit phase still re-scans the new history's diff content to confirm nothing leaked through.

What files should never be published in an open-source repo?

Dangerous files include .env variants, private keys (.pem, .key, .p12), credentials.json, service-account JSON files, .secrets/ directories, session data, and source maps. The existence of any of these in the staged copy is an automatic audit failure.

Can the release proceed if the audit finds warnings?

Yes, but only after an explicit user decision. PASS-WITH-WARNINGS findings like high-entropy strings are presented for review, and the user's accept-or-fix choice is recorded in a decision register or the sanitization report before packaging begins.

What files get generated when packaging a project for open source?

Packaging generates a CLAUDE.md under 100 lines with verified commands, an executable setup.sh bootstrap script, an enhanced README.md, a user-chosen LICENSE, CONTRIBUTING.md, and GitHub issue templates for bugs and feature requests.