pi-tian-ask-user
Ask the user a multiple-choice question (with a free-form fallback) from the pi coding agent.
Package details
Install pi-tian-ask-user from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:pi-tian-ask-user- Package
pi-tian-ask-user- Version
0.1.2- Published
- Jul 23, 2026
- Downloads
- 100/mo · 100/wk
- Author
- tian.zuo
- License
- MIT
- Types
- extension
- Size
- 18.6 KB
- Dependencies
- 0 dependencies · 3 peers
Pi manifest JSON
{
"extensions": [
"./index.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
pi-tian-ask-user
Let the model ask you a multiple-choice question from pi.
pi install npm:pi-tian-ask-user
Registers an ask_user tool. The model supplies a question and 2–5 options; a
free-form "Write my own answer" option is always added, and you can dismiss
the question without answering.
In interactive mode the options render as a popup: ↑↓ or number keys to move,
Enter to confirm, Esc to dismiss.
While it waits for your answer, the tool reports the input requirement on pi's
shared event bus (pi.events). This is pi's in-process mechanism for tool ↔
integration communication: an integration subscribes with pi.events.on(...),
aggregates active requests into its own agent state, and bridges that state to
its client.
The canonical event is agent:input_required. Its versioned payload has a
stable id so consumers can handle duplicate and concurrent requests safely:
{
version: 1,
id: string, // ask_user tool-call ID
source: "ask_user",
active: boolean, // true before waiting, false in finally
label: string // normalized question, always present
}
The same payload is temporarily also emitted as herdr:blocked for compatibility
with version 6 of Herdr's shipped pi integration. New
consumers should subscribe to agent:input_required; the producer reports why
it is waiting, while clients such as Herdr own final status precedence and
notification behavior.
Pi core has no native "blocked" status (only working while a tool call is in
flight vs idle), and can't distinguish an autonomous long-running tool from
one waiting on a human. Emitting is best-effort, balanced active→inactive via
try/finally, and a harmless no-op when nothing listens. No event is emitted in
non-UI modes.
See the collection repository for full documentation.