一键在 Manus 中运行任何 Skill

pi-extension-development

星标81

分支12

更新时间2026年6月1日 20:15

Use when creating or modifying Pi extensions, built-in extension wiring, prompt shims, package scaffolds, package READMEs, or packages/pi-* implementation in this monorepo.

安装

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

在 Manus 中运行

来源

spences10

spences10/my-pi

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

下载

在 Manus 中运行

Pi Extension Development

Use this workflow for packages/pi-* implementation work in this repo.

Workflow

Identify the package boundary first: root app, src/extensions/*, or a packages/pi-* workspace package.
For new built-ins, add a package under packages/, wire root package.json optional dependencies, and register in src/extensions/builtin-registry.ts.
Keep extension entrypoints small: export a default extension function and pure helper functions for testable trigger logic.
Put user-facing injected prompt text in one obvious template block; gate injection by selected tools/options when possible.
Update package README and Changeset when behavior changes.
Validate with the package script first, then root checks if registry/root files changed.

Project conventions

Prefer @spences10/pi-* workspace packages with workspace:* links.
Tests live beside source as *.test.ts and should cover trigger/gating helpers.
Avoid importing another package's src/* or dist/*; use public package entrypoints.
Use references/checklist.md for the exact file checklist when adding a package.

同仓库更多 Skills

同仓库

execute-harness

spences10/my-pi

Use when running an existing /tmp Pi task harness. Executes inside the active contract, records status, respects enforcement, and loops through validation.

2026-07-0481

create-harness

spences10/my-pi

Use when creating executable /tmp Pi task harnesses for ambiguous or high-risk coding work. Builds contract, prompts, validation, logs, and enforcement rules.

2026-06-2881

review-harness

spences10/my-pi

Use when reviewing implementation work that ran through a /tmp Pi task harness. Checks contract drift, unsafe shortcuts, validation evidence, and status honesty.

2026-06-2881

pi-observability-local-dev

spences10/my-pi

Use when developing or reviewing packages/pi-observability dashboard/server changes locally, especially rebuilding dist, restarting the 43190 server, validating UI behavior, or keeping the local dashboard in sync with source edits.

2026-06-2581

pi-primitive-check

spences10/my-pi

Use when evaluating proposed Pi customisation work against built-in Pi primitives before implementation, especially extensions, packages, slash commands, and workflow ideas.

2026-06-0781

pi-package-sandbox-test

spences10/my-pi

Use when verifying that published Pi packages install and load for normal users, including pi.dev package compatibility checks, release validation, Daytona sandbox tests, and package installability audits.

2026-06-0181

name	pi-extension-development
description	Use when creating or modifying Pi extensions, built-in extension wiring, prompt shims, package scaffolds, package READMEs, or packages/pi-* implementation in this monorepo.
compatibility	Requires the Pi coding-agent monorepo and extension API.

Pi Extension Development

Use this workflow for packages/pi-* implementation work in this repo.

Workflow

Identify the package boundary first: root app, src/extensions/*, or a packages/pi-* workspace package.
For new built-ins, add a package under packages/, wire root package.json optional dependencies, and register in src/extensions/builtin-registry.ts.
Keep extension entrypoints small: export a default extension function and pure helper functions for testable trigger logic.
Put user-facing injected prompt text in one obvious template block; gate injection by selected tools/options when possible.
Update package README and Changeset when behavior changes.
Validate with the package script first, then root checks if registry/root files changed.

Project conventions

Prefer @spences10/pi-* workspace packages with workspace:* links.
Tests live beside source as *.test.ts and should cover trigger/gating helpers.
Avoid importing another package's src/* or dist/*; use public package entrypoints.
Use references/checklist.md for the exact file checklist when adding a package.