---
name: opensource-pipeline
description: "Prepare a private project for a safe public release. Copy it to a clean staging folder, remove secrets and private data, check the result, and add release files. Use for '/opensource', 'open source this', 'make this public', 'prepare for open source', or checks before a public GitHub release."
origin: ECC
---

# Open Source Pipeline

> **Original skill by ECC. This version keeps ECC credited as the author.**

Use three agents in this order:

1. **Forker:** Copy the project and remove private data.
2. **Sanitizer:** Check that the copy is safe.
3. **Packager:** Add files needed for a public release.

Never change the source project. Work only in a staging copy.

## When to Use This Skill

Use this skill when the user:

- Wants to make a private project public.
- Wants to prepare a project for open source.
- Needs a secret and private data check.
- Runs `/opensource fork`, `/opensource verify`, `/opensource package`, `/opensource list`, or `/opensource status`.

## Commands

| Command | Action |
|---|---|
| `/opensource fork PROJECT` | Run the full pipeline. |
| `/opensource verify PROJECT` | Check an existing project copy. |
| `/opensource package PROJECT` | Add public release files. |
| `/opensource list` | List staged projects and their state. |
| `/opensource status PROJECT` | Show reports for one staged project. |

## Core Safety Rules

- Never push or create a public repo without clear user approval.
- Never skip the sanitizer during the full pipeline.
- Never publish a project after a failed check.
- Never copy `.git`, `.env`, private keys, tokens, cookies, or login files.
- Treat symlinks with care. Do not follow a link outside the source folder.
- Do not overwrite an old staging copy without approval.
- Do not print secret values in reports or chat.
- If a real secret was stored in Git, tell the user to revoke and replace it. Removing it from files is not enough.
- Do not remove copyright or license notices from third-party code.
- Do not add analytics, tracking, telemetry, or new network calls.

## Resolve the Project Path

If `PROJECT` contains `/`, treat it as a path. Resolve it to a full path.

Otherwise, check these places in order:

1. The current folder.
2. A child named `PROJECT` in the current folder.
3. `$HOME/PROJECT`.
4. `$HOME/opensource-staging/PROJECT`.

If more than one path matches, ask the user which one to use. If none match, ask for the path.

Set:

```bash
SOURCE_PATH="<full source path>"
PROJECT_NAME="<source folder name>"
STAGING_PATH="$HOME/opensource-staging/$PROJECT_NAME"
```

Quote all paths in shell commands. This keeps paths with spaces safe.

## Full Pipeline

### 1. Gather the Needed Facts

Ask only for facts that are missing:

1. Project path.
2. License: MIT, Apache-2.0, GPL-3.0, or BSD-3-Clause.
3. GitHub owner or group.
4. Public repo name. Default to the project name.
5. Short README text.

If the user is not sure about the license, stop and explain that license choice can affect how others use the code. Do not choose one without approval.

If the project has third-party code, check its license before packaging.

### 2. Prepare the Staging Folder

Create the parent folder:

```bash
mkdir -p "$HOME/opensource-staging"
```

If `STAGING_PATH` already exists, do not merge into it. Ask the user to choose one action:

- Use the old copy and run a new check.
- Move the old copy to a named backup.
- Stop.

Do not delete the old copy unless the user clearly asks.

### 3. Run the Forker

Start the `opensource-forker` agent with this task:

```text
Make a safe open-source copy.

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

Rules:
1. Copy normal project files.
2. Do not copy .git, node_modules, __pycache__, .venv, build output, cache files, or editor temp files.
3. Do not follow symlinks outside the source folder.
4. Find and remove secrets, keys, tokens, cookies, private URLs, private host names, personal data, and login data.
5. Replace needed secret values with clear environment variables.
6. Create .env.example with fake values only.
7. Replace private names and paths with safe examples.
8. Check text files, config files, notebooks, logs, test data, images, and other binary files.
9. Do not change the source folder.
10. Start fresh Git history in the target. Do not copy old commits.
11. Write FORK_REPORT.md in the target.

The report must list:
- What was copied
- What was skipped
- What was changed
- Each kind of private data found
- Files that need a human check

Never put a real secret value in the report.
```

Wait for the agent. Then read `FORK_REPORT.md`.

If the report is missing, stop. Do not run the next stage.

### 4. Run the Sanitizer

Start the `opensource-sanitizer` agent with this task:

```text
Check this open-source copy.

Project: {STAGING_PATH}
Source: {SOURCE_PATH}

Run all checks:
1. Secrets
2. Personal data
3. Private names, URLs, paths, host names, and account IDs
4. Unsafe files, links, archives, logs, backups, and binary files
5. Missing config examples
6. Git history and tracked files
7. Third-party license notices
8. Build, test, and setup steps that still point to private systems

Write SANITIZATION_REPORT.md in the project.

Use one final result:
- PASS
- PASS WITH WARNINGS
- FAIL

For each finding, give the file path, line when known, risk, and safe fix.
Never copy a secret value into the report.
```

Wait for the agent. Then read `SANITIZATION_REPORT.md`.

If the report is missing or has no final result, treat it as `FAIL`.

#### If the Result Is FAIL

Show the findings without secret values. Ask whether to:

- Fix the staged copy and scan again.
- Stop and keep the staged copy for review.
- Stop and remove the staged copy.

Only remove the copy after clear approval.

Run at most three fix and scan rounds. After three failed rounds, stop and ask the user to fix the listed items by hand.

#### If the Result Is PASS WITH WARNINGS

Show every warning. Ask the user to accept the warnings or fix them. Do not hide warnings.

#### If the Result Is PASS

Continue to packaging.

### 5. Run the Packager

Start the `opensource-packager` agent with this task:

```text
Package this project for a public release.

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

Create or improve:
1. CLAUDE.md with key files, build steps, test steps, and common commands
2. setup.sh with safe setup steps
3. README.md with purpose, install steps, use steps, config, tests, and limits
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/bug_report.md
7. .github/ISSUE_TEMPLATE/feature_request.md
8. .gitignore

Rules:
- Keep valid parts of old docs.
- Do not add secret values.
- Do not add analytics, tracking, telemetry, or new network calls.
- Do not claim that tests pass unless they were run.
- Make setup.sh executable.
- Make setup.sh stop on errors.
- Do not make setup.sh send data or publish code.
- Keep all third-party notices.
```

### 6. Run the Final Check

Run the sanitizer again after packaging. Packaging may add unsafe text or files.

Do not call the project ready unless this last check is `PASS` or the user accepts each warning.

Also check:

- `setup.sh` has valid shell syntax.
- The project build works when tools are present.
- Tests pass, or failed tests are listed.
- `.env.example` has fake values only.
- No source folder files changed.
- Git only tracks files meant for release.

### 7. Show the Result

Use this form:

```text
Open-Source Copy Ready: {PROJECT_NAME}

Location: {STAGING_PATH}
License: {license}
GitHub target: {github_owner}/{github_repo}

Files added or updated:
- CLAUDE.md
- setup.sh
- README.md
- LICENSE
- CONTRIBUTING.md
- .gitignore
- Issue templates
- .env.example ({N} names)

Final check: {result}
Tests: {result}
Warnings: {count}

Next:
1. Review the staged copy.
2. Create the public repo.
3. Push the code.

Create and push the GitHub repo now? yes / no / review first
```

### 8. Publish Only After Approval

Only after a clear `yes`, run:

```bash
cd "{STAGING_PATH}"
gh repo create "{github_owner}/{github_repo}" \
  --public \
  --source=. \
  --push \
  --description "{description}"
```

Before this command, confirm that:

- The final scan passed.
- The target repo name is right.
- The target owner is right.
- The user knows the repo will be public.

If the repo already exists, stop and ask before adding or changing a remote.

## Verify One Project

For `/opensource verify PROJECT`:

1. Resolve the path.
2. Run all sanitizer checks.
3. Write `SANITIZATION_REPORT.md`.
4. Show the final result and all findings.
5. Do not edit files unless the user asks for fixes.

## Package One Project

For `/opensource package PROJECT`:

1. Resolve the path.
2. Ask for the license and short description if missing.
3. Run the packager.
4. Run the sanitizer after packaging.
5. Do not publish anything.

If the folder is the only copy of the project, warn the user before editing it. Offer to make a staging copy first.

## List Staged Projects

For `/opensource list`, inspect:

```text
$HOME/opensource-staging/
```

For each folder, show whether these files exist:

- `FORK_REPORT.md`
- `SANITIZATION_REPORT.md`
- `CLAUDE.md`
- `README.md`
- `LICENSE`

Do not fail when the staging folder is empty or missing. Say that no staged projects were found.

## Show Project Status

For `/opensource status PROJECT`, read:

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

If a report is missing, say which stage has not finished. Do not use `cat` on a path until the path has been checked and quoted.

## Example

User:

```text
/opensource fork ./weather-tool
```

Expected flow:

1. Resolve `./weather-tool` to a full path.
2. Ask for the license, GitHub owner, repo name, and short text.
3. Create `$HOME/opensource-staging/weather-tool`.
4. Run the forker.
5. Read `FORK_REPORT.md`.
6. Run the sanitizer.
7. Fix only the staged copy if the user approves.
8. Run the packager.
9. Run the sanitizer one last time.
10. Show the files, tests, warnings, and final result.
11. Ask before creating or pushing the public GitHub repo.

## Staging Layout

```text
$HOME/opensource-staging/
  weather-tool/
    FORK_REPORT.md
    SANITIZATION_REPORT.md
    CLAUDE.md
    setup.sh
    README.md
    LICENSE
    CONTRIBUTING.md
    .env.example
    .gitignore
    .github/
      ISSUE_TEMPLATE/
        bug_report.md
        feature_request.md
    ...
```

## Stop Conditions

Stop the pipeline when:

- The source path is not clear.
- The staging target may overwrite files.
- A secret or private key may still be valid.
- The sanitizer returns `FAIL`.
- A third-party license blocks the planned release.
- The final scan report is missing.
- The user has not approved a public push.

Keep the staged copy for review unless the user asks to remove it.

## Related Skill

Use `security-review` for its secret check rules when that skill is available. The sanitizer still remains the required safety gate.