菜单
Use when packaging, publishing, versioning, deprecating, or changing compatibility for a reusable library; extends core release rules with package formats, public API compatibility, support matrices, and consumer verification.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/blackprince001/skills --skill libraries-ship-publishing-and-compatibility命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Always-on coding style and organization rules for naming, file shape, comments, types, module boundaries, pattern use, errors, and avoiding unnecessary abstraction across languages and tracks.
Use when setting up or modifying CI pipelines — the quality-gate sequence every change passes, shift-left ordering, feeding failures back to agents, and keeping the pipeline under 10 minutes.
Use when designing any public interface — REST/GraphQL endpoints, module contracts, component props — Hyrum's Law, contract-first, consistent error semantics, validate at boundaries, extend rather than break.
基于 SOC 职业分类
正在显示 SKILL.md
| name | libraries-ship-publishing-and-compatibility |
| description | Use when packaging, publishing, versioning, deprecating, or changing compatibility for a reusable library; extends core release rules with package formats, public API compatibility, support matrices, and consumer verification. |
Apply core-ship-release-pipeline and core-ship-versioning-and-change-communication first.
Libraries require stricter compatibility because consumers deploy on their own schedules.
Version exported symbols and types, import paths, runtime behavior, errors, defaults, side effects, serialization, peer requirements, supported runtimes, and documented extension points. A type-only break can still be a breaking change. Fixing behavior that consumers may rely on requires explicit risk assessment under Hyrum's Law.
Publish a support matrix and test its minimum and current versions. Keep peer ranges as broad as verified and direct dependencies as narrow as ownership allows. Drop a platform only with a major release or the project's documented compatibility policy.
Build from a clean tagged revision, run tests against the packed artifact in representative consumer projects, attach provenance/checksums when supported, and use a prerelease channel for uncertain changes. Never overwrite an existing published version.
Deprecate with a reason, replacement, migration example, and planned removal boundary. For a breaking release, provide a migration guide and codemod when mechanical changes are substantial. Keep the previous supported line available long enough for the stated policy.
The packed artifact, public exports, types, install path, consumer examples, support matrix, size, provenance, changelog, and compatibility classification must be verified before publication.
