一键在 Manus 中运行任何 Skill

api-design-reviewer

星标1

分支0

更新时间2026年7月14日 05:59

Use when reviewing public APIs, package exports, custom-element properties/events/slots, or cross-package contracts in PIE Players.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

pie-framework

pie-framework/pie-players

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

API Design Reviewer

Review only public or cross-package surfaces. Skip purely internal refactors unless they change a contract consumed outside the module.

PIE API Checklist

Identify the consumer: package import, custom element host, authored content, tool host, demo app, or release tooling.
Preserve the PIE tag/id contract: never mutate authored versioned pie-* tags or model/session IDs. A host may substitute its package version only on a cloned runtime config; the caller's authored config must remain unchanged.
Treat versioned tags as runtime namespaces. Concurrent versions coexist under distinct tags because an existing custom-element definition cannot be replaced.
Keep the established version encoder backward compatible. Do not propose an alternate encoding or content migration for theoretical prerelease collisions.
Keep custom-element APIs property-first; attributes are not the main model/session update path.
Check whether shadow: "open" vs shadow: "none" changes the public styling, DOM hook, or host-integration contract.
For light-DOM custom elements, require stable pie-* or data-pie-* hooks and avoid exposing generic class names as accidental API.
Check package exports against built dist artifacts, not source-only convenience paths.
Require framework-neutral declaration closure for custom-element entrypoints: consumers must not need Svelte or another implementation framework to typecheck an import.
Verify that public runtime exports and declarations expose the same names, and that policy or contract-only subpaths remain inert when imported.
Verify emitted events are named, typed, cancelable/bubbling/composed only when the contract needs it, and documented from the consumer perspective.
Keep TypeScript exports usable without importing package internals.
Treat element package registries as executable-content trust boundaries when attacker-influenced config can reach them; prefer opt-in, host-controlled policy.
Avoid compatibility shims unless they preserve the external pie-item client contract and include the required inline comment plus tests.
For release-facing changes, remember this repo is lockstep and patch-only pre-1.0; do not suggest per-package semver bumps.

Review Output

Lead with contract risks, then note missing tests or docs. Prefer concrete file/symbol references over broad style advice.

同仓库更多 Skills

同仓库

ce-package-packaging

pie-framework/pie-players

Workflow for adding or modifying a custom-element package — registration entrypoints, package `exports`, build artifacts, and pre-flight checks. Use when creating a new `@pie-players/*` CE package, adding a new `*-element.ts` registration entry, modifying the `exports` map of a publishable package, or validating CE consumer wiring. Trigger on cues like "register custom element", "add CE entry", "package exports", "components/*-element", "publishable package", "CE registration".

2026-07-141

accessibility-reviewer-assessments

pie-framework/pie-players

Reviews educational assessment interfaces for WCAG 2.2 Level AA compliance and assessment-specific accessibility needs. Use when implementing new interactions, reviewing UI changes, or conducting accessibility audits of test-taking interfaces.

2026-06-221

grill-with-docs

pie-framework/pie-players

Use when the user asks to grill or stress-test a plan/design, especially when terminology, domain language, CONTEXT.md, or ADR updates may matter.

2026-06-221

prd-author

pie-framework/pie-players

Use when the user asks to draft, update, or turn a conversation/plan into a PIE Players PRD under docs/prds/ for a public contract, cross-package feature, architecture decision, or implementation-ready contract.

2026-06-221

releases-and-changesets

pie-framework/pie-players

Author changesets and prepare releases under the fixed (lockstep) versioning policy. Use whenever creating a `.changeset/*.md`, scoping a release, choosing a bump level, running `bun run version` / `bun run release` / `bun run release:with-version`, or adding a new publishable package. Trigger on cues like "changeset", "release", "publish", "version bump", "patch", "minor", "major", "fixed versioning", "lockstep".

2026-06-221

API Design Reviewer

Review only public or cross-package surfaces. Skip purely internal refactors unless they change a contract consumed outside the module.

PIE API Checklist

Identify the consumer: package import, custom element host, authored content, tool host, demo app, or release tooling.

Preserve the PIE tag/id contract: never mutate authored versioned pie-* tags or model/session IDs. A host may substitute its package version only on a cloned runtime config; the caller's authored config must remain unchanged.

Treat versioned tags as runtime namespaces. Concurrent versions coexist under distinct tags because an existing custom-element definition cannot be replaced.

Keep the established version encoder backward compatible. Do not propose an alternate encoding or content migration for theoretical prerelease collisions.

Keep custom-element APIs property-first; attributes are not the main model/session update path.

Check whether shadow: "open" vs shadow: "none" changes the public styling, DOM hook, or host-integration contract.

For light-DOM custom elements, require stable pie-* or data-pie-* hooks and avoid exposing generic class names as accidental API.

Check package exports against built dist artifacts, not source-only convenience paths.

Require framework-neutral declaration closure for custom-element entrypoints: consumers must not need Svelte or another implementation framework to typecheck an import.

Verify that public runtime exports and declarations expose the same names, and that policy or contract-only subpaths remain inert when imported.

Verify emitted events are named, typed, cancelable/bubbling/composed only when the contract needs it, and documented from the consumer perspective.

Keep TypeScript exports usable without importing package internals.

Treat element package registries as executable-content trust boundaries when attacker-influenced config can reach them; prefer opt-in, host-controlled policy.

Avoid compatibility shims unless they preserve the external pie-item client contract and include the required inline comment plus tests.

For release-facing changes, remember this repo is lockstep and patch-only pre-1.0; do not suggest per-package semver bumps.

Review Output

Lead with contract risks, then note missing tests or docs. Prefer concrete file/symbol references over broad style advice.

name	api-design-reviewer
description	Use when reviewing public APIs, package exports, custom-element properties/events/slots, or cross-package contracts in PIE Players.