Pi Extension Intake

Help the user choose the right ownership model for a third-party pi extension, then give a concrete intake plan that matches their control, maintenance, and security goals.

Default bias: if the extension is small, weakly maintained, likely to be customized, or raises trust concerns, prefer vendoring the source into the user's repo over patching a published package.

Goals

Do three things well:

1. Identify the real dependency and trust boundary.
2. Recommend the right strategy: direct dependency, patch-package, internal fork, or vendored copy.
3. If the user wants to adopt it, produce a practical import and hardening plan.

Core idea

A copied wrapper is not the same as owned behavior. If an extension shells out to another CLI, downloads binaries, auto-installs npm packages, or fetches code at runtime, that downstream tool is part of the real trust boundary and must be analyzed explicitly.

Workflow