원클릭으로 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.