Create, update, and publish Pi extensions. Use when working on Pi extension packages, custom tools, commands, providers, hooks, TUI components, skills, prompts, or themes.
Create, update, and publish Pi extensions. Use when working on Pi extension packages, custom tools, commands, providers, hooks, TUI components, skills, prompts, or themes.
Pi Extension Development
Use this skill to build and maintain Pi packages. Read the reference file for the area you are changing before editing.
Package Namespace
Pi core packages are moving from @mariozechner/* to @earendil-works/*.
Prefer @earendil-works/* for new or migrated code once the target package exists on npm.
Keep legacy @mariozechner/* imports when the target version is not published under the new namespace yet.
Do not mix namespaces inside one package unless you are deliberately supporting a staged migration.
If using the legacy namespace, replace @earendil-works/* with the matching @mariozechner/* package.
Workflow
Creating a new extension
Read references/structure.md for layout, package metadata, config, event bus, and entry-point rules.
Create src/config/ with types.ts, defaults.ts, loader.ts, and migration/.
Create src/events.ts with event bus constants and payload types.
Create the main extension under extensions/my-domain/ (config, settings, feature discovery).
Create sub-extensions under extensions/ for each feature (tools, providers, etc.).
Read feature-specific references:
Tools: read references/tools.md.
Commands: read references/commands.md.
Hooks/events: read references/hooks.md.
Providers: read references/providers.md.
For TUI work, read references/components.md and Pi docs/tui.md.
For mode-sensitive UI, read references/modes.md.
For persistent state or custom messages, read references/state.md and references/messages.md.
For publishing, read references/publish.md and references/documentation.md.
Modifying an existing extension
Read package.json to find Pi entry points.
Read the entry point and the relevant reference file.
Follow the extension's existing structure, even if it differs from the recommended multi-extension pattern. Do not restructure unless the user explicitly asks.
Check the current Pi docs/changelog if changing Pi APIs.
pi-obsidian (/Users/alioudiallo/code/src/pi.dev/pi-obsidian/): CLI wrapper with separate core package and pi.exec() usage.
Critical Rules
When modifying an existing extension, preserve its current structure. Do not migrate to the multi-extension pattern unless the user explicitly asks.
src/ is Pi-agnostic in new extensions: no imports from @earendil-works/pi-*. All Pi registration code lives under extensions/.
One Pi extension entry point per domain directory under extensions/. The main extension owns config, settings, and feature discovery.
Use the event bus (src/events.ts) for main-sub-extension communication: domain:feature:request, domain:feature:register, domain:config:updated.
Config in src/config/ with types.ts, defaults.ts, loader.ts, and migration/. Use per-feature nested sections.
Define type MyToolParams = Static<typeof parameters> for helper/action APIs, but prefer inference inside defineTool callbacks.
Tool execute signature is (toolCallId, params, signal, onUpdate, ctx). Signal comes before onUpdate.
Always call onUpdate?.(...) with optional chaining.
Every tool needs label. Add promptSnippet when the tool should appear in Available tools.
Every promptGuidelines bullet must name the exact tool. Do not say this tool.
Use StringEnum from pi-ai for model-facing string enums. Do not use Type.Union([Type.Literal(...)]) for enums.
Handle renderResult partial state first with a stable tool-scoped message.
Detect tool errors by missing expected details fields or context.isError; thrown tools receive details: {}.
Use ToolCallHeader, ToolBody, and conditional ToolFooter for tool rendering.
Use existing TUI components before creating custom components.
ctx.ui.custom() needs RPC/print fallback. Interactive close paths must not rely on done(undefined).
Dialog methods that gate behavior need checks; fire-and-forget UI methods do not.
Completion Checklist
package.json lists extension entry points under extensions/ and package resources.
src/ has no @earendil-works/pi-* imports.
Config in src/config/ with types.ts, defaults.ts, loader.ts, migration/.
Event bus in src/events.ts with domain-prefixed event names.
Main extension owns config loading, settings, and feature discovery.
Sub-extensions register via event bus.
Imported Pi core packages are optional peers and exact dev deps.
Tools use defineTool, labels, prompt metadata where appropriate, correct execute order, optional onUpdate, and signal forwarding.
promptGuidelines bullets name the exact tool.
Tool renderers return components, handle partial/error states, and use compact collapsed views.
Custom UI has RPC/print fallback and explicit sentinels.
Providers use current provider/model fields (name, authHeader, thinkingLevelMap, OAuth where needed).
State is reconstructible across reload/fork/compaction.
No child_process, no homedir() for Pi paths, no .js import suffixes, no @sinclair/typebox.
tsconfig.json includes both src/ and extensions/.
README documents setup, tools, commands, providers, env vars, and limitations.
ctx.hasUI
Forward abort signals to fetch, pi.exec, SDK clients, and long-running work.
Use pi.exec() for normal shell commands. Do not use Node child_process unless a documented long-lived streaming process requires it.
File-mutating tools must normalize leading @ paths and use withFileMutationQueue() for the full read-modify-write window.
Large output tools must truncate output, report truncation, and save full output to a temp file.
Store branch-aware tool state in tool result details and reconstruct from ctx.sessionManager.getBranch().
After ctx.newSession(), ctx.fork(), or ctx.switchSession(), do post-switch work only in withSession.
Treat await ctx.reload(); return; as terminal in a command handler.
Provider dynamic model discovery belongs in an async extension factory, not session_start.
Use SDK helpers for Pi paths instead of homedir() when helpers exist.
No .js extensions in TypeScript imports.
Pi core packages you import belong in optional peerDependencies; use "*" by default, or ">=x.y.z" only when code needs an API introduced after Pi 0.74.0. Keep exact target versions in devDependencies.
tsconfig.json must include both src/**/*.ts and extensions/**/*.ts.
