Skip to content
Hoody.com

The agent skill bundle is the machine-readable manual that teaches an AI agent how to drive Hoody. It is published as static files at hoody.com/SKILLS/, so agents can fetch it without any authentication, embed URLs into prompts, and load deeper detail on demand.

The bundle is built around progressive disclosure: an agent loads the combined full skill for its preferred mode, then fetches a single per-namespace file on demand when it needs the exact signatures and payloads for one service.

Combined full skill (per mode)

SKILL-HTTP-FULL.md, SKILL-SDK-FULL.md, and SKILL-CLI-FULL.md. Each is the everything-in-one-file reference for that mode: what Hoody is, the auth model, the public-URL story, and every namespace inlined. Pick the one that matches your runtime.

Per-namespace, per-mode

Fetched on demand. Files named SKILL-HTTP/<ns>.md (HTTP), SKILL-SDK/<ns>.md (SDK), and SKILL-CLI/<ns>.md (CLI), each with the actual signatures, payloads, examples, and gotchas for that one surface.

The complete bundle is served under /SKILLS/:

/SKILLS/
├── SKILL-HTTP.md ← basic skill, HTTP mode (intro + core ops + index)
├── SKILL-HTTP-FULL.md ← combined full skill, HTTP mode (every namespace inlined)
├── SKILL-HTTP/<ns>.md ← per-namespace deep dive, HTTP mode
├── SKILL-SDK.md / SKILL-SDK-FULL.md / SKILL-SDK/<ns>.md ← SDK mode
├── SKILL-CLI.md / SKILL-CLI-FULL.md / SKILL-CLI/<ns>.md ← CLI mode
├── SKILL.md ← mode-blend chooser
├── SKILL.lite.md ← condensed mode-blend skill
├── INDEX.md ← the whole surface at a glance
└── ONBOARDING.md ← first-run orientation

All three modes cover the same 19 service namespaces (a namespace with no CLI surface ships a short pointer instead of commands). Per-namespace links inside the combined skills are absolute URLs, so a file copy-pasted into a prompt can still resolve deeper detail.

A typical request flow:

  1. Pre-loaded. The agent has the combined full skill for its mode in context. It already knows what Hoody is, how to authenticate, and which namespaces exist.
  2. On a fresh request, the agent identifies which namespace owns the task from the combined skill’s namespace overview.
  3. For a deeper drill-down on one service, the agent fetches the matching per-namespace file — SKILL-HTTP/<ns>.md, SKILL-SDK/<ns>.md, or SKILL-CLI/<ns>.md — to read the actual method signatures and payload shapes for the chosen mode.

For most one-shot operations the combined skill alone is enough; the per-namespace files are there when an agent wants a focused, lower-noise view of a single service.

If the agent’s runtime is…Use
JavaScript/TypeScript with the hoody-sdk packageSKILL-SDK-FULL.md / SKILL-SDK/<ns>.md
Any language with an HTTP clientSKILL-HTTP-FULL.md / SKILL-HTTP/<ns>.md
A shell, or hoody CLI is on the pathSKILL-CLI-FULL.md / SKILL-CLI/<ns>.md

The three modes describe the same operations — they only differ in how to call them. Load the combined full skill for your mode and reach for the matching per-namespace file when you need a single service in detail.

The skill bundle is generated deterministically in hoody-sdk from three sources:

SourceLives inWhat it contributes
Handwritten prosehoody-sdk-generator/hoody-sdk/skills-source/The intros, the per-namespace gotchas, and the appendices.
SDK and CLI mappingssdk-mappings.json, cli-mappings.jsonMethod names, signatures, parameter tables, command syntax — auto-emitted into the per-namespace deep dives.
OpenAPI documentgenerated/openapi.jsonHTTP endpoint paths, request/response schemas, body shapes for the HTTP per-namespace files.

Same inputs → byte-identical output (no LLM). A reviewer can diff two builds to see exactly what a prose change altered.

  • URL paths are stable. https://hoody.com/SKILLS/SKILL-HTTP-FULL.md (and the SKILL-SDK-FULL.md, SKILL-CLI-FULL.md equivalents) and the SKILL-HTTP/<ns>.md / SKILL-SDK/<ns>.md / SKILL-CLI/<ns>.md files are considered a public surface. Renaming or moving files in this bundle is treated as a breaking API change for agents.
  • Output is committed and reproducible. The published bundle is a set of static files generated in hoody-sdk, so serving it never invokes an LLM. The same source-of-truth inputs reproduce byte-identical files, so a given commit always ships the same bytes.