تشغيل أي مهارة في Manus بنقرة واحدة

api-design-reviewer

النجوم١

التفرعات٠

آخر تحديث١٤ يوليو ٢٠٢٦ في ٠٥:٥٩

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

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

SKILL.md

readonly

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

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.

المزيد من هذا المستودع

نفس المستودع

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.