菜单
Reviews reusable package craft: exports, layout, naming, tests, docs, compatibility, and release shape. Use for npm packages, SDKs, framework utilities, reusable modules, or public APIs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.
Builds and sharpens a project's domain model in `.agents` docs. Use when the user wants to pin down domain terminology, record an ADR, or another skill needs to maintain project language.
A relentless interview to sharpen a plan or design. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
A relentless interview that turns a plan or design into a user-requested artifact. Use when the user wants to stress-test a direction and explicitly capture the result in project documentation.
Interview the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, uses a grill trigger phrase, or another skill needs a grilling session.
Writes a compact continuation handoff for another agent or future session. Use when the user asks to hand off, compact context, continue later, or preserve next steps.
| name | library-craft |
| description | Reviews reusable package craft: exports, layout, naming, tests, docs, compatibility, and release shape. Use for npm packages, SDKs, framework utilities, reusable modules, or public APIs. |
Use this skill when the work affects a reusable package, public API, package exports, or maintainer-facing source organization.
Example trigger: library-craft this package before we publish
Default posture: analysis first. Do not edit source files unless the user explicitly asks to implement.
Default scope: review the whole library contract unless the user gives a narrower scope.
Breaking changes are welcome when they make the library cleaner, smaller, or more honest. If the user opts out of breaking changes, preserve compatibility and name the trade-off.
surface - exports, subpaths, types, defaults, runtime guarantees.shape - folders, helpers, generated files, fixtures, build output.names - user-facing concepts, options, files, helpers.tests - public API, fixtures, examples, type tests, regression checks.comments - public docs, rationale, compatibility notes, noisy narration.release - semver impact, migration path, shims, deprecations.keep - preserve a pattern that is earning its cost.rename - a name hides the concept or leaks implementation.move - file or folder placement fights the scan path.narrow - public surface or options are broader than needed.split - one entrypoint or file owns multiple public concepts.merge - separation creates ceremony without a real concept.comment - comments are missing, stale, noisy, or API-significant.test - contract, fixture, type, or example coverage is missing.break - compatibility is making the package worse.For every break, include what breaks, why it is worth it, the migration path, and whether a compatibility shim should exist.
keep short; spend most of the report on pressure.package.json exports, README examples, and generated types as API.improve-codebase-architecture.grill-with-docs; do not update project context by default.