agentleFS
payne0420payne0420/claude-skills/llm-endpoint/SKILL.md

llm-endpoint

Skill0 starsChanged 5 months agoMITView on GitHub

Call a configured OpenAI-compatible (`/v1/chat/completions`) or Anthropic-compatible (`/v1/messages`) HTTP endpoint as a lightweight model backend — a raw completion call, not an autonomous agent. Use as an alternative to the codex/cursor/opencode CLI harnesses when you want to hit an arbitrary model behind a gateway/router/proxy (e.g. for a second opinion, a quick review of pasted/piped context, or text generation), or to plug such an endpoint into an ultracode workflow. The base URL and API key are read from local config and are never hardcoded. Works with any `/v1` chat or `/v1/messages` endpoint.

  • Reads credentials

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 1 is distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Use it when you want a specific model behind a gateway/router/proxy for: a second opinion, a review of a diff/snippet you provide, …

    line 27
  2. Very specific:

    Use llm-endpoint: when you just need a model's answer over some context you already have (paste/pipe it): second opinions, reviewing a …

    line 87
  3. Distinctive:

    Not an agent: No file/repo access — it only sees the prompt you send.

    line 104
  4. Very specific:

    Secrets are local-only: Never hardcode or commit the URL/key.

    line 106

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

llm-endpoint — call a configured chat/messages API

This skill calls an OpenAI- or Anthropic-compatible HTTP endpoint and returns the reply text. It is a raw model call, not an agent: it sends one prompt and gets one completion. Unlike codex / cursor-agent / opencode, it does not read files, run commands, or explore a repo — you must feed it the context (put it in the prompt, or pipe it in).

Use it when you want a specific model behind a gateway/router/proxy for: a second opinion, a review of a diff/snippet you provide, classification, or text generation — without the overhead (or autonomy) of a full coding-agent CLI.

Setup — secrets stay local, never in git

The base URL and API key live in a local config file outside any repo so they are never committed:

mkdir -p ~/.config/llm-endpoint
cp ~/.claude/skills/llm-endpoint/config.example.sh ~/.config/llm-endpoint/env
chmod 600 ~/.config/llm-endpoint/env
$EDITOR ~/.config/llm-endpoint/env     # fill in BASE_URL, API_KEY, MODEL, KIND

The script reads, in order: existing env vars → $LLM_ENDPOINT_ENV_FILE → ~/.config/llm-endpoint/env. Vars:

VarMeaning
LLM_ENDPOINT_BASE_URLendpoint base, including /v1 (e.g. https://host/v1)
LLM_ENDPOINT_API_KEYbearer / api key
LLM_ENDPOINT_MODELdefault model id (--model overrides)
LLM_ENDPOINT_KINDdefault shape: chat or messages (--kind overrides)

The script itself, config.example.sh, and this doc contain no secrets — they are safe to publish. The real ~/.config/llm-endpoint/env is the only place the key lives; keep it out of version control.

Usage

scripts/llm-call.sh (needs curl + jq):

S=~/.claude/skills/llm-endpoint/scripts/llm-call.sh

# Prompt as arg or via stdin; model/kind default to config
"$S" "Explain optimistic locking in two sentences."
printf 'Summarize this repo in one line.' | "$S"

# Pipe context in — e.g. review the current diff
{ echo "Review this diff for bugs, cite the line:"; git diff; } | "$S"

# Pick model / shape explicitly
"$S" --model provider/model --kind messages "your prompt"
"$S" --kind chat --model some-openai-model "your prompt"

# Options
"$S" --system "You are a terse code reviewer." --max-tokens 800 --temperature 0.2 "..."
"$S" --models          # list available model ids
"$S" --raw "..."       # full JSON response instead of just the text

--kind chat → POST {base}/chat/completions (OpenAI shape, Authorization: Bearer). --kind messages → POST {base}/messages (Anthropic shape, x-api-key

  • anthropic-version). The script extracts the assistant text from either.

When to use this vs a CLI harness

  • Use llm-endpoint when you just need a model's answer over some context you already have (paste/pipe it): second opinions, reviewing a provided diff, Q&A, generation, classification — especially for a model only reachable via your gateway.
  • Use codex / cursor-agent / opencode (see those skills) when you need an agent that explores the repo, runs commands, or edits files autonomously. This endpoint can't do that — it only sees what you send it.

In an ultracode workflow

The ultracode-external-agents skill ships an llmCmd() helper so a workflow can delegate a step to this endpoint (the Claude adapter runs the script and relays the answer). Because it's not an agent, gather the context in the command — e.g. pipe git diff in. See that skill's "Raw LLM endpoint backend" section.

Gotchas

  • Not an agent. No file/repo access — it only sees the prompt you send. Pipe or paste the context.
  • Secrets are local-only. Never hardcode or commit the URL/key; they belong in ~/.config/llm-endpoint/env.
  • chat vs messages per model. A gateway may serve a given model on only one shape — if one returns an error, try the other and set LLM_ENDPOINT_KIND. The chat path sends "stream": false because some gateways stream SSE by default (which can't be parsed as a single object — and a streaming failure can even surface as a 502 stream_early_eof that non-streaming avoids). The script still falls back to reassembling SSE if a gateway streams anyway.
  • Reasoning/"thinking" models + --max-tokens. Models that emit a hidden thinking block spend the token budget on reasoning first; a low --max-tokens can be consumed entirely by thinking (stop_reason: length), leaving the answer text empty. Raise --max-tokens (default 1024) if a reasoning model returns nothing. The script returns only the final answer text, not the thinking.
  • HTTP errors are surfaced. A non-2xx response prints HTTP <code> plus the error body to stderr and exits non-zero (instead of silently returning empty).
  • Needs curl and jq.
  • Don't leak secrets into prompts — you're sending them to a third-party model.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.