Files
everything-claude-code/docs/ja-JP/skills/opensource-pipeline/SKILL.md
Claude ec9ace9c54 docs: add native Japanese translation of ECC documentation (ja-JP)
Translate everything-claude-code repository to Japanese including:
- 17 root documentation files
- 60 agent documentation files
- 80 command documentation files
- 99 rule files across 18 language directories (common, angular, arkts, cpp, csharp, dart, fsharp, golang, java, kotlin, perl, php, python, ruby, rust, swift, typescript, web)
- 199 skill documentation files

Total: 455 files translated to Japanese with:
- Consistent terminology glossary applied throughout
- YAML field names preserved in English (name, description, etc.)
- Code blocks and examples untouched (comments translated)
- Markdown structure and relative links preserved
- Professional translation maintaining technical accuracy

This translation expands ECC accessibility to Japanese-speaking developers and teams.

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
2026-05-17 02:31:40 -04:00

256 lines
9.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
name: opensource-pipeline
description: "オープンソースパイプライン: プライベートプロジェクトをフォーク、サニタイズし、安全な公開リリースのためにパッケージ化する。3つのエージェントフォーカー、サニタイザー、パッケージャーを連鎖させる。トリガー: '/opensource'、'open source this'、'make this public'、'prepare for open source'。"
origin: ECC
---
# オープンソースパイプラインスキル
3段階のパイプラインを通じて任意のプロジェクトを安全にオープンソース化する: **フォーク**(シークレット除去)→ **サニタイズ**(クリーンな状態を確認)→ **パッケージ**CLAUDE.md + setup.sh + README
## アクティベートするタイミング
- ユーザーが「このプロジェクトをオープンソース化する」または「これを公開する」と言うとき
- ユーザーがプライベートリポジトリを公開リリースのために準備したいとき
- ユーザーがGitHubにプッシュする前にシークレットを除去する必要があるとき
- ユーザーが`/opensource fork``/opensource verify`、または`/opensource package`を呼び出すとき
## コマンド
| コマンド | アクション |
|---------|--------|
| `/opensource fork PROJECT` | 完全なパイプライン: フォーク + サニタイズ + パッケージ |
| `/opensource verify PROJECT` | 既存のリポジトリにサニタイザーを実行 |
| `/opensource package PROJECT` | CLAUDE.md + setup.sh + READMEを生成 |
| `/opensource list` | ステージングされたすべてのプロジェクトを表示 |
| `/opensource status PROJECT` | ステージングされたプロジェクトのレポートを表示 |
## プロトコル
### /opensource fork PROJECT
**完全なパイプライン — メインワークフロー。**
#### ステップ1: パラメータを収集する
プロジェクトパスを解決する。PROJECTに`/`が含まれる場合、パス(絶対または相対)として扱う。それ以外の場合: 現在の作業ディレクトリ、`$HOME/PROJECT`をチェックし、見つからない場合はユーザーに尋ねる。
```
SOURCE_PATH="<解決された絶対パス>"
STAGING_PATH="$HOME/opensource-staging/${PROJECT_NAME}"
```
ユーザーに尋ねる:
1. 「どのプロジェクト?」(見つからない場合)
2. 「ライセンスMIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause
3. 「GitHubのorgまたはユーザー名デフォルト: `gh api user -q .login`で検出)
4. 「GitHubリポジトリ名デフォルト: プロジェクト名)
5. 「READMEの説明提案のためにプロジェクトを分析
#### ステップ2: ステージングディレクトリを作成する
```bash
mkdir -p $HOME/opensource-staging/
```
#### ステップ3: フォーカーエージェントを実行する
`opensource-forker`エージェントをスポーン:
```
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
"""
)
```
完了を待つ。`{STAGING_PATH}/FORK_REPORT.md`を読む。
#### ステップ4: サニタイザーエージェントを実行する
`opensource-sanitizer`エージェントをスポーン:
```
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.
"""
)
```
完了を待つ。`{STAGING_PATH}/SANITIZATION_REPORT.md`を読む。
**FAILの場合:** 結果をユーザーに表示する。「これらを修正して再スキャンしますか、それとも中止しますか?」と尋ねる。
- 修正する場合: 修正を適用し、サニタイザーを再実行する最大3回の再試行 — 3回のFAIL後、すべての結果を提示しユーザーに手動で修正するよう依頼する
- 中止する場合: ステージングディレクトリをクリーンアップする
**PASSまたはWARNINGS付きPASSの場合:** ステップ5に進む。
#### ステップ5: パッケージャーエージェントを実行する
`opensource-packager`エージェントをスポーン:
```
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)
"""
)
```
#### ステップ6: 最終レビュー
ユーザーに提示する:
```
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)
```
#### ステップ7: GitHubへの公開ユーザーの承認後
```bash
cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{description}"
```
---
### /opensource verify PROJECT
サニタイザーを独立して実行する。パスを解決: PROJECTに`/`が含まれる場合、パスとして扱う。それ以外の場合は`$HOME/opensource-staging/PROJECT``$HOME/PROJECT`、現在のディレクトリを確認する。
```
Agent(
subagent_type="opensource-sanitizer",
prompt="Verify sanitization of: {resolved_path}. Run all 6 scan categories and generate SANITIZATION_REPORT.md."
)
```
---
### /opensource package PROJECT
パッケージャーを独立して実行する。「ライセンス?」と「説明?」を尋ねてから:
```
Agent(
subagent_type="opensource-packager",
prompt="Package: {resolved_path} ..."
)
```
---
### /opensource list
```bash
ls -d $HOME/opensource-staging/*/
```
FORK_REPORT.md、SANITIZATION_REPORT.md、CLAUDE.mdの存在でパイプラインの進捗を各プロジェクトと共に表示する。
---
### /opensource status PROJECT
```bash
cat $HOME/opensource-staging/${PROJECT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJECT}/FORK_REPORT.md
```
## ステージングレイアウト
```
$HOME/opensource-staging/
my-project/
FORK_REPORT.md # フォーカーエージェントから
SANITIZATION_REPORT.md # サニタイザーエージェントから
CLAUDE.md # パッケージャーエージェントから
setup.sh # パッケージャーエージェントから
README.md # パッケージャーエージェントから
.env.example # フォーカーエージェントから
... # サニタイズされたプロジェクトファイル
```
## アンチパターン
- ユーザーの承認なしにGitHubにプッシュすることは**絶対にしない**
- サニタイザーをスキップすることは**絶対にしない** — これは安全ゲートである
- 重大な結果をすべて修正せずにサニタイザーのFAIL後に続行することは**絶対にしない**
- ステージングディレクトリに`.env``*.pem`、または`credentials.json`を残すことは**絶対にしない**
## ベストプラクティス
- 新しいリリースには常に完全なパイプライン(フォーク → サニタイズ → パッケージ)を実行する
- ステージングディレクトリは明示的にクリーンアップされるまで持続する — レビューに使用する
- 公開前に手動修正後にサニタイザーを再実行する
- 削除ではなくシークレットをパラメータ化する — プロジェクトの機能を維持する
## 関連スキル
サニタイザーが使用するシークレット検出パターンについては`security-review`を参照。