Catalog
affaan-m/opensource-pipeline

affaan-m

opensource-pipeline

Open-source pipeline: fork, sanitize, and package private projects for safe public release. Chains 3 agents (forker, sanitizer, packager). Triggers: '/opensource', 'open source this', 'make this public', 'prepare for open source'. Use when a private project must be forked, stripped of secrets, and packaged for public release.

NewUpdated Sep 9, 2026

Open-Source Pipeline Skill

Safely open-source any project through a 3-stage pipeline: Fork (strip secrets) → Sanitize (verify clean) → Package (CLAUDE.md + setup.sh + README).

When to Activate

  • User says "open source this project" or "make this public"
  • User wants to prepare a private repo for public release
  • User needs to strip secrets before pushing to GitHub
  • User invokes /opensource fork, /opensource verify, or /opensource package

Commands

Command Action
/opensource fork PROJECT Full pipeline: fork + sanitize + package
/opensource verify PROJECT Run sanitizer on existing repo
/opensource package PROJECT Generate CLAUDE.md + setup.sh + README
/opensource list Show all staged projects
/opensource status PROJECT Show reports for a staged project

Protocol

/opensource fork PROJECT

Full pipeline — the main workflow.

Step 1: Gather Parameters

Resolve the project path. If PROJECT contains /, treat as a path (absolute or relative). Otherwise check: current working directory, $HOME/PROJECT, then ask the user.

SOURCE_PATH="<resolved absolute path>"
STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"

Ask the user:

  1. "Which project?" (if not found)
  2. "License? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
  3. "GitHub org or username?" (default: detect via gh api user -q .login)
  4. "GitHub repo name?" (default: project name)
  5. "Description for README?" (analyze project for suggestion)

Step 2: Create Staging Directory

mkdir -p $HOME/opensource-staging/

Step 3: Run Forker Agent

Spawn the opensource-forker agent:

Agent(
  description="Fork {PROJECT} for open-source",
  subagent_type="opensource-forker",
  prompt="""
Fork project for open-source release.

Source: {SOURCE_PATH}
Target: {STAGING_PATH}
License: {chosen_license}

Follow the full forking protocol:
1. Copy files (exclude .git, node_modules, __pycache__, .venv)
2. Strip all secrets and credentials
3. Replace internal references with placeholders
4. Generate .env.example
5. Clean git history
6. Generate FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md
"""
)

Wait for completion. Read {STAGING_PATH}/FORK_REPORT.md.

Step 4: Run Sanitizer Agent

Spawn the opensource-sanitizer agent:

Agent(
  description="Verify {PROJECT} sanitization",
  subagent_type="opensource-sanitizer",
  prompt="""
Verify sanitization of open-source fork.

Project: {STAGING_PATH}
Source (for reference): {SOURCE_PATH}

Run ALL scan categories:
1. Secrets scan (CRITICAL)
2. PII scan (CRITICAL)
3. Internal references scan (CRITICAL)
4. Dangerous files check (CRITICAL)
5. Configuration completeness (WARNING)
6. Git history audit

Generate SANITIZATION_REPORT.md inside {STAGING_PATH}/ with PASS/FAIL verdict.
"""
)

Wait for completion. Read {STAGING_PATH}/SANITIZATION_REPORT.md.

If FAIL: Show findings to user. Ask: "Fix these and re-scan, or abort?"

  • If fix: Apply fixes, re-run sanitizer (maximum 3 retry attempts — after 3 FAILs, present all findings and ask user to fix manually)
  • If abort: Clean up staging directory

If PASS or PASS WITH WARNINGS: Continue to Step 5.

Step 5: Run Packager Agent

Spawn the opensource-packager agent:

Agent(
  description="Package {PROJECT} for open-source",
  subagent_type="opensource-packager",
  prompt="""
Generate open-source packaging for project.

Project: {STAGING_PATH}
License: {chosen_license}
Project name: {PROJECT_NAME}
Description: {description}
GitHub repo: {github_repo}

Generate:
1. CLAUDE.md (commands, architecture, key files)
2. setup.sh (one-command bootstrap, make executable)
3. README.md (or enhance existing)
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
"""
)

Step 6: Final Review

Present to user:

Open-Source Fork Ready: {PROJECT_NAME}

Location: {STAGING_PATH}
License: {license}
Files generated:
  - CLAUDE.md
  - setup.sh (executable)
  - README.md
  - LICENSE
  - CONTRIBUTING.md
  - .env.example ({N} variables)

Sanitization: {sanitization_verdict}

Next steps:
  1. Review: cd {STAGING_PATH}
  2. Create repo: gh repo create {github_org}/{github_repo} --public
  3. Push: git remote add origin ... && git push -u origin main

Proceed with GitHub creation? (yes/no/review first)

Step 7: GitHub Publish (on user approval)

cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"

/opensource verify PROJECT

Run sanitizer independently. Resolve path: if PROJECT contains /, treat as a path. Otherwise check $HOME/opensource-staging/PROJECT, then $HOME/PROJECT, then current directory.

Agent(
  subagent_type="opensource-sanitizer",
  prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
)

/opensource package PROJECT

Run packager independently. Ask for "License?" and "Description?", then:

Agent(
  subagent_type="opensource-packager",
  prompt="Package: {resolved_path} ..."
)

/opensource list

ls -d $HOME/opensource-staging/*/

Show each project with pipeline progress (FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md presence).


/opensource status PROJECT

cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md

Staging Layout

$HOME/opensource-staging/
  my-project/
    FORK_REPORT.md           # From forker agent
    SANITIZATION_REPORT.md   # From sanitizer agent
    CLAUDE.md                # From packager agent
    setup.sh                 # From packager agent
    README.md                # From packager agent
    .env.example             # From forker agent
    ...                      # Sanitized project files

Anti-Patterns

  • Never push to GitHub without user approval
  • Never skip the sanitizer — it is the safety gate
  • Never proceed after a sanitizer FAIL without fixing all critical findings
  • Never leave .env, *.pem, or credentials.json in the staging directory

Best Practices

  • Always run the full pipeline (fork → sanitize → package) for new releases
  • The staging directory persists until explicitly cleaned up — use it for review
  • Re-run the sanitizer after any manual fixes before publishing
  • Parameterize secrets rather than deleting them — preserve project functionality

See security-review for secret detection patterns used by the sanitizer.

Files1
1 files · 1.0 KB

Select a file to preview

Overall Score

77/100

Grade

B

Good

Grades are signals, not a certification. Always review a skill yourself before use.

Safety

78

Quality

75

Clarity

82

Completeness

72

Summary

This skill orchestrates a 3-stage pipeline (fork, sanitize, package) to safely open-source private projects by stripping secrets, verifying cleanliness, and generating public-facing artifacts (CLAUDE.md, setup.sh, README). It chains three sub-agents and manages a staging directory in $HOME/opensource-staging/ with explicit anti-patterns to prevent publishing secrets or skipping security verification.

Static Analysis Findings

2 findings

Patterns detected by deterministic static analysis before AI scoring. Hover over any finding code for detailed information and remediation guidance.

Credential Exposure
SEC-020Direct .env File Access4x in 1 file

Direct .env file access

SKILL.md.env4x
SEC-022SSH/Credentials File AccessMax: B

SSH key or credentials file access

SKILL.mdcredentials.json

Detected Capabilities

filesystem readfilesystem writedirectory traversalenvironment variable readsub-agent invocationgit operationsGitHub API calls (gh cli)structured reportinguser input prompt

Trigger Keywords

Phrases that agents use to match this skill to user intent.

open source thismake project publicstrip project secretsprepare for github releasesanitize credentialspublish private repo

Risk Signals

INFO

SEC-020: Direct .env file access — skill references reading .env files during sanitization and generating .env.example

SKILL.md: Step 2 (forker agent), Anti-Patterns section
INFO

SEC-020: Direct .env file access — skill explicitly lists removal of .env and generation of .env.example in anti-patterns and forker workflow

SKILL.md: Anti-Patterns section
INFO

SEC-020: Direct .env file access — mentioned in Step 3 forker protocol and in Step 6 final review (.env.example output)

SKILL.md: Steps 3 and 6
INFO

SEC-020: Direct .env file access — skill documents .env handling as part of sanitization process

SKILL.md: Step 4 (sanitizer scans) and Anti-Patterns
WARNING

SEC-022: SSH key or credentials.json file access — skill explicitly lists credentials.json as anti-pattern (must never be left in staging)

SKILL.md: Anti-Patterns section

Use Cases

  • Prepare private codebase for public GitHub release
  • Strip secrets and credentials from legacy projects before open-sourcing
  • Verify a forked project is clean of sensitive data before publication
  • Generate bootstrap scripts and contributor documentation for open-source projects
  • Audit existing staged projects for sanitization status before publishing
  • Repackage an open-source fork with new license or documentation

Quality Notes

  • Strength: Clear 3-stage pipeline architecture (fork → sanitize → package) with explicit boundaries and anti-patterns
  • Strength: Comprehensive anti-patterns section that explicitly prohibits unsafe practices (publish without approval, skip sanitizer, ignore FAIL verdicts)
  • Strength: Well-structured command table and step-by-step protocols for each operation
  • Strength: Staging directory pattern allows persistent review and multiple retry attempts (up to 3) for sanitization failures
  • Strength: User prompts for critical inputs (license, GitHub org, description) with sensible defaults
  • Strength: Sanitizer acts as explicit safety gate with PASS/FAIL verdicts before proceeding
  • Limitation: Sub-agent descriptions (opensource-forker, opensource-sanitizer, opensource-packager) are assumed to exist but not documented — skill depends on these agents being properly configured
  • Limitation: No error handling documented for failed sub-agent invocations or network failures during GitHub API calls
  • Limitation: Retry logic limited to 3 attempts; no guidance on escalation if sanitizer repeatedly fails
  • Limitation: No documentation of how to manually fix findings or which files are safe to delete vs. must be parameterized
  • Limitation: GitHub push step (Step 7) runs `gh repo create` with `--push`, which could silently push unsanitized code if staging directory was manually modified
  • Edge case: No guidance on handling very large projects that might time out during sanitization scans
Model: claude-haiku-4-5-20251001Analyzed: Sep 9, 2026

Reviews

Add this skill to your library to leave a review.

No reviews yet

Be the first to share your experience.

Version History

  1. v2.0

    Contract changed: description

    ✦ AIDescription extended to clarify when to use the skill for private-to-public project transitions.

    triggering2026-09-09

    LATEST
  2. v1.2

    Content updated

    ✦ AINo behavioral changes detected.

    2026-07-14

    View This Version
  3. v1.1

    Content updated

    ✦ AIAdds LICENSE file.

    2026-04-20

    View This Version
  4. v1.0

    2026-04-12

    View This VersionInitial version

Use affaan-m/opensource-pipeline in your dev environment

Command Palette

Search for a command to run...