Claude Skills API: Building Reusable Workflows

A Claude skill is a named, reusable set of instructions that tells Claude how to approach a specific task — reviewing code, drafting a document in a particular style, summarizing meetings in a consistent format. Skills can be created in the Claude app and, through the API, invoked programmatically so the same workflow runs reliably every time.

Skills work best when the instructions behind them are agreed, tested, and maintained. A tool like fenbs is a natural home for that: store the approved skill instructions as Decisions alongside the project tasks they serve, so the team always runs the right version and knows who approved it.

What a skill is in Claude

In Claude.ai, a skill is a saved workflow with a name, a description, and a system prompt that defines how Claude should behave for that task. Once created, a skill can be invoked by name without re-entering the instructions each time. Skills live in your account or, for team accounts, in the shared workspace.

Skills are different from Artifacts (documents and code Claude creates) and from Projects (shared memory with documents and instructions). A skill is closer to a reusable job description: it says how to do a specific kind of work, not what work is being done right now. The claude projects vs skills vs artifacts article maps out how the three relate.

Run a skill through the Anthropic API

The Anthropic API accepts a system parameter — the system prompt — that sets Claude's behavior for a conversation. Running a skill through the API means passing the skill's instructions as the system prompt. This is how the same workflow that works in the Claude app can be invoked from your own code:

import anthropic

client = anthropic.Anthropic()

# The skill's instructions become the system prompt
CODE_REVIEW_SKILL = """
You are a code reviewer. For each piece of code the user shares:
1. Identify any bugs or logic errors.
2. Note style issues against the project's coding standards.
3. Suggest one concrete improvement.
Be concise and specific.
"""

message = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=1024,
    system=CODE_REVIEW_SKILL,
    messages=[
        {"role": "user", "content": "Please review this function:\n\n" + code_to_review}
    ]
)
print(message.content)

For the latest SDK installation and authentication steps, see the Anthropic API documentation↗ (opens in a new tab). The claude-opus-4-6 model is the most capable option as of October 2026; choose the model that fits your latency and cost needs.

Keep skill instructions consistent across users and sessions

The value of a skill is consistency: every invocation follows the same instructions. That consistency breaks down when different people maintain different versions of the skill prompt in different places — a shared doc, a local file, a team wiki. When someone updates the instructions, the update may not reach all the places the skill is called.

Treat the skill's system prompt as a Decision in your project management. Record who approved the current version, what it does, and when it was last reviewed. That way the API call always uses the version the team agreed on, and any change goes through the same review as any other project decision.

Test a skill before sharing it

Before adding a skill to a shared library, test it on at least three real examples. Compare its output against what you would expect from a careful human applying the same instructions. Look for cases where the skill over-specifies (producing more detail than the task needs) and where it under-specifies (missing something the instructions say to check). A skill that behaves differently on different inputs may need narrower instructions or a more specific example in the prompt.

Run the same tests each time you change the skill. An update that fixes one gap can introduce another. A small set of test inputs stored alongside the skill instructions is easier to maintain than relying on memory. Include at least one example where the skill should produce a refusal or a short answer, not just cases where a full output is expected.

Version and review skill instructions

Skill instructions should be treated like other important project text: changed deliberately, reviewed before deploying, and tracked across versions. A skill that worked well six months ago may produce different results if the underlying task or codebase has changed.

When a skill is not the right fit — for example, when the task is exploratory rather than repeatable — a plain conversation without a skill system prompt is often better. Skills add value when the task is well-defined, the expected output has a clear shape, and consistency matters more than flexibility.

How to do this with fenbs

1. Create a free account and add your project. Add the skill's system prompt as a Skill or as a Decision — whichever the team will look for first.
2. Connect Claude or Claude Code to fenbs over MCP from Integrations. The connected AI can list and read shared skills at the start of a session.
3. When a skill instruction changes, record the new version and who approved it as a Decision in fenbs. Note what the change is and why it was made.
4. In your API code, load the skill instruction from the agreed source rather than hardcoding it. This ensures every invocation uses the current approved version.
5. After sessions that use a skill, record any lessons — where the instructions worked well and where they produced unexpected results — in fenbs for the next review.

The agent harness topic hub has more on building repeatable AI workflows. The claude skills examples article shows common skill patterns for different use cases.