xpod-cli

name	xpod-cli
description	Use when LinX or Secretary needs to inspect, import, export, or update Solid Pod resources through the xpod command line; especially user-owned files, RDF resources, descriptor-backed objects, JSON output, and secret-safe operations. This skill is for using xpod CLI in product workflows, not for maintaining the xpod CLI implementation.

Xpod CLI

Use xpod as the default terminal surface for Solid Pod operations in LinX. This replaces ad-hoc pod_read / pod_write style tools: the product should prefer one shared CLI contract for Pod files, RDF resources, objects, and secrets.

When To Use

• Inspect Pod files or containers before answering questions about stored data.
• Import, export, or link descriptor-backed objects such as chats, tasks, sessions, agents, skills, reports, or evidence.
• Read or write RDF resources when the user asks for Pod-level state.
• Manage AI/provider credentials through secret-safe flows.
• Verify that LinX, xpod, or another Solid app wrote the expected resource.

Do not use this skill for xpod CLI repository maintenance. If the task is to change xpod command behavior or release xpod itself, use the xpod project docs and maintainer-facing skill in that repository.

Command Choice

• Use xpod obj ... for model/descriptor-backed resources. Prefer this for LinX product data because schemas, URI templates, and links belong to @undefineds.co/models.
• Use xpod get, xpod list, xpod put, xpod patch, xpod delete, and xpod head for raw Pod resources when the user is asking about files, containers, or exact URLs.
• Use xpod rdf ... for graph, subject, and triple-level inspection.
• Use xpod secret ... for credentials. Never print secret values by default.
• Use xpod server ... only when the user asks about the local/server xpod process.

Prefer --json when the result will be parsed or used to make a decision. Summarize human-facing output instead of pasting large raw payloads.

Safety Rules

• Read before write unless the user already gave an exact target and content.
• For destructive operations, explain the target and require explicit user confirmation.
• Never expose access tokens, refresh tokens, client secrets, cookies, or authorization headers.
• Authentication has one Solid-app source: $SOLID_HOME/auth/credentials.json (default ~/.solid/auth/credentials.json). Old ~/.xpod/config.json / ~/.xpod/secrets.json files are app-local stale files, not Solid auth; if only those exist, report unauthenticated.
• For product resources, do not guess paths. Use model-backed xpod obj commands or inspect existing links first.

Useful Patterns

xpod --help
xpod list <pod-url-or-container> --json
xpod get <resource-url> --json
xpod rdf subject <resource-url> --json
xpod obj export <type-or-resource> --json
xpod obj import <file-or-stdin> --json
xpod obj link <source> <predicate> <target> --json
xpod secret list --json

If xpod is not available on PATH, report that exact blocker and avoid pretending Pod state was checked.