Claude Skills API + ThreadGrab: X Archive Skill

Anthropic shipped the Skills API out of beta on August 20, 2026, alongside an updated computer-use tool, a new browser-use tool, and a Files API that now offers 5× higher rate limits and 1 TB of storage per organization. The Skills API is the part that matters most if you build anything that touches social content: it lets you upload a folder of instructions, scripts, and templates, then ask Claude to load that folder only when a task calls for it. The folder runs inside Claude’s code-execution sandbox, so there is nothing for you to host.

ThreadGrab is a natural target for that pattern. ThreadGrab exposes a public /api/profile/{username} endpoint that turns any X (formerly Twitter) account into structured JSON, with a 10-request-per-per-IP rate limit and no login required. Wrapping that endpoint as a Claude Skill gives an agent a single tool it can call whenever a prompt mentions archiving, citing, or pulling posts from X. The result is a reusable building block: ask Claude once, version the skill, and the same archive flow is available across the Claude API, Claude Code, and claude.ai — with no per-prompt glue code.

What the Skills API actually shipped

The August 20 launch post, titled “Build production agents with computer use, the Skills API, and the Files API,” is the canonical reference. The post makes four things generally available on the Claude Platform:

The post pairs the announcement with a worked example: a claims agent that reads an intake document from the Files API, follows a Skill that encodes the team’s filing procedure, completes the submission in an insurer’s web portal with the browser-use tool, and saves the confirmation back as a file. The same loop fits ThreadGrab almost exactly — swap the insurer portal for the X profile endpoint, swap the intake document for a username, and you have an agent that archives X accounts on demand.

Why a ThreadGrab Skill is the right size

Skills API calls expect a single repeatable workflow — a Skill is a folder of instructions, scripts, and templates that Claude loads only when a task calls for it. The ThreadGrab profile archive is a clean fit for that shape:

• Single HTTPS call: GET https://threadgrab.com/api/profile/{username} returns the full structured profile.
• No auth, no OAuth: no token to store in the Skill, no client-credentials block to manage.
• Predictable JSON shape: the response is well-formed user data — safe to feed straight into the Files API as a downloadable artifact.
• Bounded inputs: {username} matches /^[a-zA-Z0-9._]{1,30}$/, so there is no prompt-injection surface to defend.
• Reusable across prompts: “Archive @threadgrab’s last 100 posts,” “Pull the bio from @naval,” “Compare the follower counts of these three accounts” — all run the same Skill.

Compared to building the same flow inside computer-use tooling, the Skills-API version is roughly one-twentieth of the code. The computer-use tool now supports multi-action turns (a single model call can drive several clicks and types), and the browser-use tool reads page structure, not just pixels. Both are great for tasks that have no API. ThreadGrab does have an API, so the Skills path wins on token cost, latency, and reliability.

The Skill directory layout

Anthropic’s Skills docs are explicit about the layout. Every Skill is a directory with a SKILL.md file at the root. The SKILL.md carries YAML frontmatter that names it and tells Claude when to load it, plus a markdown body that holds the actual procedural knowledge — the workflow, the scripts, the gotchas. Optional bundled files (schemas, templates, example inputs) sit beside SKILL.md and are loaded on demand when SKILL.md references them. The body of SKILL.md only enters the context window when Claude decides the Skill matches the user’s task; the rest of the files stay on disk and cost zero tokens until referenced.

For a ThreadGrab archive Skill, the frontmatter needs three pieces of information: the name, the description (which doubles as the trigger — “use this when the user asks about X, Threads, Twitter, social archives, follower counts, or any @username”), and any optional config. A working skeleton looks like this:

threadgrab-archive/
└── SKILL.md
└── scripts/
    └── fetch_profile.py

The Anthropic name rules are short: lowercase letters, numbers, and hyphens only, 64 characters max, no XML tags, no reserved words (anthropic, claude). The description maxes out at 1,024 characters and cannot contain XML tags. Both are validated at upload time, so a malformed value returns a 4xx before the Skill is created. The docs warn that the description is what the model uses to decide whether to load your Skill, so be explicit about when it applies.

SKILL.md — the body that Claude loads

The body is plain markdown and reads like a procedure document. For a ThreadGrab archive, it should tell the model how to validate the username, what to do when the rate-limit error returns 429, and how to surface the saved JSON to the user. The skeleton below is a tight, working version — the real Skill can grow with more gotchas as you encounter them:

---
name: threadgrab-archive
description: Archive X (Twitter) profiles as structured JSON via the ThreadGrab
  API. Use when the user asks for an X archive, a follower count, a bio,
  recent posts from an account, or any reference to @username. Triggers on
  phrases like "archive @handle", "pull profile data",
  "compare X accounts". Do not use for Threads (Meta) or Bluesky
  posts.
---

# threadgrab-archive

## When to load me
Load this Skill whenever the user asks about an X / Twitter account
(@username) and asks for profile data, follower counts,
recent posts, or a downloadable archive. Do not load me for Threads
(Meta), Bluesky, or LinkedIn — those are different surfaces.

## Inputs
- username: an X handle without the leading @.
  Must match /^[a-zA-Z0-9._]{1,30}$/.

## Endpoint
GET https://threadgrab.com/api/profile/{username}

- No authentication required.
- Rate limit: 10 requests per minute per client IP. If you get HTTP
  429, wait 60 seconds and retry.
- Username validation runs server-side; an invalid username returns
  HTTP 400 with {"error": "Invalid username"}.

## Output
The response is a JSON object with the X user profile: id, handle,
display name, bio, follower count, following count, post count,
verification status, profile image URL, and recent posts (where the
upstream exposes them).

## Procedure
1. Strip any leading @ from the username.
2. Validate against /^[a-zA-Z0-9._]{1,30}$/. If invalid,
   ask the user for a corrected handle.
3. Call the endpoint with a 15-second timeout.
4. On 200, save the response body via the Files API and return the
   resulting file_id as a downloadable Markdown bundle.
5. On 429, sleep 60 seconds and retry once.
6. On 404, tell the user the handle does not resolve.
7. Never invent fields. If the response does not include
   follower_count, do not estimate it.

scripts/fetch_profile.py — the helper Claude runs

The script lives beside SKILL.md and is loaded on demand only when SKILL.md tells Claude to use it. Because Skills on the Claude API run in a sandboxed container with no network access, you cannot pip install at runtime — the script must use only the packages the code-execution sandbox already has. For a thin HTTPS client that means the standard library:

# scripts/fetch_profile.py
# Loaded on demand by SKILL.md; no network packages to install.
import json
import sys
import urllib.request
import urllib.error

BASE = "https://threadgrab.com/api/profile/"

def fetch(username: str, timeout: int = 15) -> dict:
    url = BASE + username
    req = urllib.request.Request(url, headers={"User-Agent": "claude-skill/1.0"})
    try:
        with urllib.request.urlopen(req, timeout=timeout) as resp:
            return {"status": resp.status, "body": json.loads(resp.read())}
    except urllib.error.HTTPError as e:
        return {"status": e.code, "error": e.reason}
    except urllib.error.URLError as e:
        return {"status": 0, "error": str(e.reason)}

if __name__ == "__main__":
    user = sys.argv[1].lstrip("@")
    print(json.dumps(fetch(user), indent=2))

When Claude loads the Skill and decides to run the helper, it issues bash: python scripts/fetch_profile.py naval — only the script’s output enters the context window. The script’s own code never does, which is the central efficiency claim of the architecture: a Skill can ship dozens of reference files and the cost stays bounded by what the task actually reads.

Uploading and version-pinning the Skill

Once the directory is built, upload it through the Skills API. The endpoint accepts multipart form-data, with all files in a single top-level directory and SKILL.md at the root. Anthropic’s API reference shows the shape:

curl https://api.anthropic.com/v1/skills \
  -H 'Content-Type: multipart/form-data' \
  -H 'anthropic-version: 2023-06-01' \
  -H "X-Api-Key: $ANTHROPIC_API_KEY" \
  -F files='["SKILL.md", "scripts/fetch_profile.py"]'

The response includes a Skill object with an id (the format is skill_01AbCdEfGhIjKlMnOpQrStUv) and a latest_version_id. Subsequent uploads create new versions; the API lets you pin to a specific version in a /v1/messages call or default to latest. Versioning is the part that makes Skills production-grade — you can roll a Skill forward, then pin a workflow to an older version if a newer one regresses, without rewriting the calling code.

To attach the Skill to a request, add the skill_id to the container.skills array and pair it with the code-execution tool. Up to 20 Skills can ride along on one request, which is the documented ceiling:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    container={
        "skills": [
            {
                "type": "custom",
                "skill_id": "skill_01AbCdEfGhIjKlMnOpQrStUv",
                "version": "latest",
            }
        ]
    },
    messages=[
        {
            "role": "user",
            "content": (
                "Archive @threadgrab as Markdown. Save the full profile JSON "
                "and summarize the bio in three bullets."
            ),
        }
    ],
    tools=[{"type": "code_execution_20250825", "name": "code_execution"}],
)

The response’s container object carries an id and an expires_at timestamp; reuse the same container across follow-up messages to keep the Skill loaded and the code-execution sandbox warm. Files the Skill writes (the saved profile JSON, the Markdown summary) come back as file_id attributes inside bash_code_execution_tool_result blocks — download those through the Files API and surface them to the user.

Where Skills can and cannot run

Skills API has three surfaces, and they do not share state:

• Claude API — workspace-wide. Any member of your workspace can call the Skill you upload. Skills run in a sandboxed container with no network access and no runtime package installation. Plan accordingly: bundle everything your Skill needs into the upload.
• Claude Code — filesystem-based. Skills live in ~/.claude/skills/ (personal) or .claude/skills/ (project). They have full network access and can install packages, but only locally — Anthropic explicitly warns against global package installs.
• claude.ai — per-user. You upload Skills as zip files via Settings > Features, and they’re available on Pro, Max, Team, and Enterprise plans. They are not shared across your org, and they cannot be centrally managed by admins.

For a ThreadGrab archive Skill you intend to share with a team, the Claude API is the most useful surface: workspace-wide, version-controlled, and auditable. For solo work in your own terminal, Claude Code with a local Skill is faster to iterate. The two paths use the same SKILL.md layout, so a Skill authored once works in both places — the docs explicitly note that Skills uploaded to one surface are not automatically available on the others, so plan to upload separately if you want it everywhere.

Security considerations before you ship

Skills give Claude new capabilities through instructions and code, which also means a malicious or compromised Skill can direct Claude to invoke tools or execute code in ways that don’t match the stated purpose. The docs lay out four risks worth a hard look before any Skill goes into production:

1. Audit thoroughly. Review every file in the Skill: SKILL.md, scripts, templates, schemas. Anthropic calls out unexpected network calls, unusual file-access patterns, and operations that don’t match the Skill’s stated purpose.
2. External sources are risky. Skills that fetch data from external URLs pose particular risk, because fetched content can contain malicious instructions. The ThreadGrab endpoint returns JSON — not HTML — so the prompt-injection surface is much smaller than a Skill that scrapes a web page.
3. Tool misuse. A Skill with bash, file, or code-execution tools can be steered to do other things. Pair a Skill with the smallest set of tools it actually needs.
4. Data exposure. Skills can read documents in your workspace. For enterprise orgs, Anthropic offers Skills content scanning for uploads through claude.ai and Claude Cowork — but not for Skills uploaded through the API.

The Skills launch post includes a telling line: “treat like installing software.” For a ThreadGrab archive Skill that runs in a sandboxed container with no network access, the surface is small — but if you add skills to a workflow that already handles sensitive documents, the audit work scales with what the Skill can reach.

How ThreadGrab fits into the broader agent stack

ThreadGrab is a read-only archive endpoint. It does not write to X, does not require OAuth, and exposes one JSON shape per call. That makes it a natural building block for Skills, MCP servers, and hosted agent harnesses that need social data without the compliance overhead of holding user tokens. The same endpoint powers the public ThreadGrab web app — the read-side complement to the new hosted X MCP, which we covered earlier this month for write-side automation.

If you are building a Skills-based agent that touches X, the practical pattern is: ThreadGrab for read-side archives (this Skill), the hosted X MCP for write-side automation (separate surface), and the Files API for handing artifacts back to the user. All three compose inside one /v1/messages call — Skills and the code-execution tool ride in the container block, the hosted MCP rides in mcp_servers, and the Files API surfaces the saved JSON.

FAQ