ワンクリックでManusで任意のスキルを実行

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 リポジトリを開く Creator のリポジトリを見る

ダウンロード

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.