Claude Custom Skills: Build a Museum Label Checker With Source-Only Rules

A volunteer museum publishes short object labels from a curator-approved catalog. A well-meaning AI rewrite could turn an uncertain acquisition date into a confident claim or replace ‘bronze’ with ‘gold’ because that sounds more impressive. Claude custom skills provide a way to define a repeatable editing workflow with instructions and supporting resources. This hypothetical tutorial makes one narrow skill: propose clearer exhibit labels, attach source references and stop whenever the catalog does not support a fact. It does not claim to have installed a skill or verified an actual museum record.

Decide what the skill may and may not do

Write the scope in one sentence: simplify a supplied label without altering historical claims, quantities, provenance, materials or uncertainty markers. The skill may flag problems and draft alternatives; it cannot approve a label, identify an object from an image or search for replacement dates without permission. In the imaginary catalog, an item is listed as bronze, dated 1924, with one provenance gap. The desired output must retain all three elements. Assign a curator as the final authority. When the source is silent, use ‘not established in the supplied catalog’ instead of filling the blank with plausible background history.

Verify Claude Skills prerequisites and access

Anthropic’s help states that Skills require code execution and can be used across supported Claude plans, subject to account and organization settings. Team or Enterprise administrators may control creation, sharing or provisioning. Before uploading any skill, confirm the feature is enabled and that the library is authorized to process the chosen material. A museum with restricted donor records should not place confidential scans in a personal skill package. If Skills are unavailable, the same editorial policy can be applied manually through an ordinary checklist. Do not promise that installing a skill changes the underlying model’s knowledge or makes every generated assertion true.

Prepare a minimal skill directory

Anthropic documents a skill folder with a `skill.md` file beginning with required YAML frontmatter fields `name` and `description`. Use a specific name such as ‘Museum Label Evidence Check’ and a description saying when it should be invoked: when rewriting exhibit labels against an attached approved catalog excerpt. Add instructions that request a claim-to-source table, preserve uncertain wording, reject unreferenced changes and stop before any publication action. Keep the skill focused; do not combine it with visitor marketing, ticket sales or image generation in one package. Prefer no executable scripts for this straightforward text workflow.

Treat attached reference files as controlled inputs

A skill may include a resource file, but an attached catalog extract must be licensed and approved for the intended account. Use a small, non-sensitive sample with document title, edition date and page identifiers. Distinguish source metadata from object facts; a PDF upload date is not the artifact creation date. Put the approved wording and citation requirements in a reference file that reviewers can read directly. Avoid adding private donor contact information, credentials or museum collection-management exports. A custom skill is a set of instructions and resources, not an evidence database whose contents are automatically authenticated.

Package and inspect before uploading

According to Anthropic, custom skills can be packaged as a ZIP containing the named skill folder at the root. Inspect each file before packaging; reject unfamiliar scripts, network instructions, requests for secrets or hidden actions. In the Claude interface, the documented path uses Customize, then Skills, then creation or upload controls; settings can differ by plan and organization. After uploading, check that the skill is present and enabled. Do not assume it was shared with colleagues; the help describes separate sharing and organization provisioning controls. Keep a local version number for any later change to the skill.

Test one label against an approved excerpt

Give the skill a fictional catalog fragment: ‘Object 14, bronze medallion, attributed to 1924, provenance incomplete, catalog page 7.’ Ask it to produce a visitor-friendly label of no more than fifty words plus a claim-evidence matrix. An acceptable draft preserves ‘attributed to’ instead of turning it into ‘made in 1924’; it does not state that the medallion was owned by a famous person. Reject unsupported adjectives about rarity or value. This is a proposed editorial test case, not evidence that a live skill passed. Store both the test input and reviewer observations so later versions can be compared.

Probe failures with adversarial examples

Add deliberate traps to the test set: a conflicting date in an outdated draft, an object title that resembles another collection item, and an instruction embedded inside a catalog excerpt telling the assistant to ignore its policy. Source text is untrusted task data, not an authority to override the skill’s editorial boundaries. The output should flag conflicting evidence and ask the curator for a decision. A different example can omit the material entirely; the correct label should not invent one. If the model changes a factual statement without citation, adjust the instructions and retest rather than claiming a flawless automated rule.

Make evidence visible in the output

Require a compact table of proposed sentence, original source phrase, page or file reference, confidence boundary and reviewer action. A page number without a matching document is not a citation. For interpretive prose such as ‘used during celebrations,’ demand explicit support or remove it. Curators should compare at least one apparently harmless wording change and every historical number against the catalog. Retain caveats like ‘possibly’ or ‘attributed’ in the public label when appropriate. When the label is translated later, apply a separate language review; a source-only rewriting skill does not automatically certify translation accuracy.

Control sharing, revisions and approval

A volunteer can suggest changes to the skill, but an authorized maintainer should compare the old and new instructions and test the same reference examples. Anthropic explains personal skills, sharing with colleagues and provisioning by organization owners, but availability varies by plan and role. Do not publish a skill package containing private files to a public directory. Keep signed-off label text in the museum’s established content system, not as a transient conversation answer. Record the skill version used for drafting, the source edition reviewed and the curator who approved the final label. Editing traceability comes from that process, not from AI fluency.

Recognize custom-skill limits

A skill can make a workflow more consistent, but it cannot guarantee historical truth or override organizational policy. It may be skipped if the task does not match its description, and its instructions may be imperfect. This guide is grounded in Anthropic’s published setup steps; all artifact details and results are illustrative rather than observed tests. For public collection data, a catalog professional should verify provenance and wording, while an accessibility editor checks readability. Where source documents disagree, note the dispute and escalate it rather than choosing the smoother-sounding story. A useful skill makes uncertainty visible instead of hiding it.

How We Research

Our research used the following named official vendor documentation: Claude Help Center — Use skills in Claude; Claude Help Center — How to create custom skills. We checked the existence and intended purpose of each named feature, documented availability or configuration requirements, and explicit limitations. The workflows were then written around a fictional example that exposes common editorial risks, not around an account we operated. No hands-on product benchmark, real output file, recorded participant, measured accuracy score or legal/compliance review is claimed. All diagrams are independently drawn explanatory illustrations; they are not screenshots. A real project must verify live settings, permissions, source documents, relevant policy and human approval before release.

Frequently Asked Questions