Claude skill, self-hosted: overview and architecture

The claude-skills-agent-creator skill turns an existing Claude skill into a containerized HTTP service. Inside the container, Anthropic's claude-agent-sdk loads the skill and runs it. You build the image and host the container yourself. There is no Foundry hosting on this path.

The creator is itself a Claude Code skill. You hand it a skill folder (one that contains a SKILL.md) and answer a few questions. It copies its own templates into a new agent directory and fills in the placeholders. It does not build the image or deploy anything.

Two host surfaces: pick one

A generated agent serves exactly one of two HTTP surfaces. The creator always asks which one you want.

Architecture

AMC  ──HTTP + JSON + SSE──▶  app.py  (amc_sdk.build_app, port 8080)
                               │
                               ▼
                     claude_skills_agent.py   (the SDK core)
                               │  query(prompt, options)
                               ▼
                     claude-agent-sdk  ──▶  bundled Claude Code CLI  ──▶  Claude
                               │                                (Anthropic API or Microsoft Foundry)
                               ▼
                     /app/.claude/skills/<skill-name>/SKILL.md   (baked into the image)

The core is the same for both surfaces. It runs claude-agent-sdk with cwd=/app and setting_sources=["project"], so the SDK discovers the skill at /app/.claude/skills/<skill-name>/. Only the host layer around it changes: http_agent_server.py for plain HTTP, or amc_sdk for AMC.

• •Brain: claude-agent-sdk>=0.2.138. The Claude Code CLI ships inside the wheel as a native binary, so the image needs no Node.js.
• •Credentials: Anthropic API direct, or Claude on Microsoft Foundry. Both come in at runtime as environment variables, never baked into the image.
• •Skill: copied unchanged into the image. When the skill expects a particular filesystem, the Dockerfile reshapes the filesystem instead of patching the skill.
• •Permissions: permission_mode="dontAsk" denies any tool outside the allowlist instead of prompting, and the container runs as a non-root user.

How this differs from the Foundry-hosted path

The same skill can also run inside Microsoft Foundry, hosted by Microsoft Agent Framework. Both paths use claude-agent-sdk as the brain and turn an existing skill into a deployed agent. They differ only in where the agent runs: here it runs in a container you operate and expose over HTTP. For the Foundry variant, see Claude skill on Microsoft Foundry.

What the creator asks you

It does not ask for a port. A plain-HTTP agent takes the next free port from the port convention; the AMC variant always uses 8080.

The generation pipeline

1. 1Analyze the skill. Read SKILL.md and scripts/: the frontmatter name: and description:, hardcoded paths (grep -r "/sessions/" scripts/), third-party Python imports, binaries the scripts call, credential needs, and where outputs go.
2. 2Decide naming. Directory, class, package, and image names derive from the skill's name:. See Project layout and placeholders.
3. 3Generate the scaffold. Copy verbatim files unchanged. Fill each .tpl file and write it without the .tpl suffix.
4. 4Patch the skill-specific blocks: the prompt strategy, Dockerfile prep, tool labels, and outputs handling.
5. 5Verify that the generated Python parses, and optionally run tests/test_run.py if credentials are available.
6. 6Record the port for a plain-HTTP agent.

Rules the generated agent keeps

• •Never modify http_agent_server.py. It is the shared transport contract.
• •Never bake secrets into the image. .env is excluded by .dockerignore.
• •Never patch the source skill. Match the filesystem to what it expects.
• •Never ship tests/ in the image. .dockerignore excludes it.

For how agents connect to AMC in general, read How agents connect and The integration contract. To compare build paths, see Choose a build path.