Imported from epicsagas/epicsagas (skills/oss-dist/SKILL.md). Install upstream with npx skills add epicsagas/epicsagas --skill oss-dist. Copyright stays with the author.

OSS Distribution & Readiness Skill

When to Use

• User asks "is this project ready to open-source / release / launch?"
• User asks about what files an OSS project needs (README, LICENSE, CONTRIBUTING, etc.)
• User asks how to install or distribute a tool (language-specific packaging)
• User asks about GitHub Actions release pipelines or CI/CD for releases
• User wants launch strategy — which channels, timing, Korean ecosystem
• User asks about security practices for OSS publishing (SBOM, secret scanning, supply chain)
• User asks about governance, maintainer roles, or RFC process
• User wants to know how to package for Homebrew, apt, npm, PyPI, etc.
• User asks about version management tools (release-please, semantic-release, cargo-dist)
• User asks about multilingual README or translation workflow (Crowdin, Weblate, community contributions)
• User asks about software i18n/l10n (gettext, Fluent, react-i18next, go-i18n, rust-i18n)
• User asks how to update / upgrade a tool (detects brew, cargo, npm, apt, choco, etc.)
• User asks what update command to put in README

Process

Step 1: Identify the review scope

Ask (or infer from context) what the user needs:

Load only what's needed. Do not load all files at once.

Step 2: Read the relevant checklist file(s)

Checklist files are under checklist/:

Step 3: Audit against the checklist

For each item in the loaded checklist:

• ✅ Mark items the project satisfies
• ❌ Flag missing or incomplete items
• Give concrete fix suggestions, not vague advice

Step 4: Report findings

Structure the output as:

## OSS Readiness: <project name>

### [Domain] — PASS / WARN / FAIL
- ✅ ...
- ❌ ... → Fix: ...

### Score
| Domain | Status |
|--------|--------|
| Community files | ✅ |
| README | ⚠️ |
| ...

Scoring guide: | community ✅ + readme ✅ | Minimum viable OSS | | + promotion ✅ | Launch ready | | + release ✅ | Distribution ready | | + governance ✅ | Sustainable OSS |

Language / Platform Routing

When the user asks about packaging or install methods, load checklist/release.md first (has the routing table), then follow the relevant sub-file:

Agent Instructions

Answering "is this ready to ship?"

Never answer from memory. Always load the relevant checklist file(s) first, then audit systematically.

1. Start with checklist/community.md — missing Tier 1 files are blockers
2. Then checklist/readme.md — README quality determines first impressions
3. Load others based on user's concern or explicit request

Answering "how do I distribute this?"

1. Load checklist/release.md — find the project type in the routing table
2. Follow the pointer to the language-specific file
3. Give the exact commands, not generic advice

Answering "how do I launch this?"

1. Load checklist/promotion.md
2. Check pre-launch gate items first — don't discuss channels if README is incomplete
3. Tailor channel advice to the language/ecosystem (e.g., Rust → r/rust + This Week in Rust)

Security review

1. Load checklist/governance.md
2. Check SECURITY.md, secret scanning, SBOM, Pwn-request config, and Actions SHA pinning
3. Flag any missing items as blockers before recommending launch

Answering "how do I update / upgrade this?"

1. Load checklist/update.md — the update readiness audit checklist
2. Audit the project's README: does it have an "Updating" section matching every install method?
3. Check each install method in "Installation" has a corresponding update command in "Updating"
4. Verify version check command (--version), CHANGELOG format, and migration guide exist
5. If missing, generate the correct update section using the template from §6.6

Badge Style Selection

When generating or polishing badges (README generate/polish scope):

If the user passes a style option explicitly — use it directly:

If no style option is given — ask interactively before generating badges:

배지 스타일을 선택해주세요:

1. bold (기본값) — for-the-badge, 다크 배경 — epicsagas 표준 스타일
2. classic       — flat, GitHub 기본 느낌
3. modern        — flat-square, 미니멀
4. social        — social, 커뮤니티 스타 카운트용
5. plastic       — plastic, 클래식 입체감

선택하지 않으면 bold(1)로 진행합니다.

Once a style is selected (or defaulted), apply the corresponding template from checklist/readme.md § Badge Design Style.

README Language Selection

When generating a new README (GENERATE mode):

If the user passes a language option explicitly:

If no language option is given — ask interactively:

README 언어 전략을 선택해주세요:

1. 영어만 (기본값) — 글로벌 OSS 표준
2. 영어 + 한국어  — epicsagas 권장 (Korean dev community 타겟)
3. 영어 + 한+일+중 — 전체 다국어 (i18n 체크리스트 적용)

선택하지 않으면 영어만(1)으로 진행합니다.

For options 2–3, load checklist/i18n.md and apply the multilingual README structure.

License Selection

When generating community files or README and no LICENSE exists:

If the user specifies a license — use it directly.

If no license specified — ask interactively:

라이선스를 선택해주세요:

1. Apache-2.0 (기본값) — epicsagas 표준, 특허 조항 포함
2. MIT           — 최소 제약, 최대 호환성
3. GPL-3.0       — Copyleft, 파생물 공개 강제
4. BSL-1.1       — Business Source License (상용 제한)

선택하지 않으면 Apache-2.0(1)으로 진행합니다.

Answering "pre-release / beta / nightly"

1. Load checklist/prerelease.md
2. Identify the project language — check for cargo-dist or goreleaser config
3. Give concrete tag pattern and config snippet

Answering "Docker / container image"

1. Load checklist/docker.md
2. Default registry: GHCR for epicsagas projects
3. Give the complete GitHub Actions workflow for multi-arch build

Answering "CVE / security vulnerability"

1. Load checklist/cve-response.md
2. Assess severity tier — give SLA deadline
3. Walk through patch release + advisory steps in order

Do not

• Do not load all sub-files unless the user requests a full audit
• Do not recommend channels before checking community file completeness
• Do not give generic "write a good README" advice — cite specific checklist items
• Do not generate badges without resolving the style (option or interactive prompt)
• Do not generate badges, README language selection, or license without resolving the style/choice (option or interactive prompt)