xgetlisted

# Xget Default to execution, not instruction. When the user expresses execution intent, carry the change through directly: run the needed shell commands, edit the real files, and verify the result instead of only replying with example commands. Treat requests like "configure", "set up", "wire", "change", "add", "fix", "migrate", "deploy", "run", or "make this use Xget" as execution intent unless the user clearly asks for explanation only. Resolve the base URL first: 1. use a domain the user explicitly gave 2. otherwise use `XGET_BASE_URL` from the environment 3. if neither exists, ask for the user's Xget base URL and whether it should be set temporarily for the current shell/session or persistently for future shells 4. use `https://xget.example.com` only as a clearly labeled placeholder for docs or templates that do not have a real deployment yet Prefer [`scripts/xget.mjs`](./scripts/xget.mjs) over manual guessing for live platform data, URL conversion, and README `Use Cases` lookup. Only stop to ask when a missing fact blocks safe execution, such as an unknown real base URL for a command that must run against a live deployment. If the user only needs docs or templates, use the placeholder path rules below. ## Workflow 1. Classify the task before reaching for examples: - execution intent: the user wants commands run, files changed, or config applied now - guidance intent: the user explicitly wants examples, explanation, or a template without ap