neon-pilot-admin-cli

Neon Pilot CLI

Use the unified Neon Pilot command surface instead of direct runtime-file edits, standalone model tools, or MCP. External/other agents use the public neon-pilot CLI. Internal Neon Pilot agents use the canonical neon_pilot tool when available. These are dual interfaces over the same control-plane command semantics, but the public CLI should stay human/task-oriented.

Workflow

1. Choose commands by intent before inspecting contracts:

   neon-pilot ask "Summarize this repo"                         # one-off agent work
   neon-pilot conversations run-turn <id> --text "Continue."    # existing conversation
   neon-pilot background-commands start --command "pnpm test"   # detached shell work
   neon-pilot tasks list                                        # scheduled behavior
   neon-pilot extensions list                                   # extension admin
   

   Use neon-pilot commands, neon-pilot commands --brief, and neon-pilot help <command> for command discovery. Use --json only when you are writing a script, need stable ids/schema fields, or must parse output mechanically.

2. From an internal Neon Pilot conversation, prefer the canonical tool for the same command surface:

   { "command": "list_admin_commands" }
   

   Use the shell CLI when the task is explicitly about external-user behavior, install/bootstrap from a terminal, or validating what a human will see.

3. Pick the conversation surface by intent. Use human output for orientation; add --json only when parsing:

   neon-pilot extensions list
   neon-pilot settings list
   neon-pilot conversations workspace      # open/sidebar state, usually what "active threads" means
   neon-pilot conversations open list      # ergonomic open/sidebar view
   neon-pilot conversations list           # persisted conversation history page, not open/active threads
   neon-pilot cli status
   neon-pilot control-plane doctor
   

4. Inspect before mutating shared state. For conversation/sidebar state, read the workspace first: