Claims last verified 2026-07-2822 confirmed · 6 documented · 1 stale riskverification log →
Anthropic's policies and products change frequently —
always confirm current specifics with your Anthropic contact before relying on this for a compliance decision.
Skills
A Skill is how you teach Claude your organization's way of doing a repeatable task — once — instead of re-explaining it every conversation. No coding required for a simple one. This domain covers what Skills are, how to build them, and what the working group could build together.
Where this comes from: the findings below are drawn from the working group's
own document (its “§” numbers are that document's sections) and, where marked
✓Confirmed,
checked against Anthropic's primary pages — see the verification log.
This module is a teaching aid, not compliance or legal advice — patient-data
decisions belong to your organization, its counsel, and its Anthropic contact.
How to read the chips
✓Confirmedchecked against Anthropic’s own page on the date shown, and the receipt kept.
▪Documentedcarried from the working group’s document (context as of July 2026), not re-checked since.
⚠︎Stale riskknown-volatile, or the check found a discrepancy — treat as a question, not a fact.
⚑compliancea claim a patient-data decision could hang on — always confirm with your Anthropic contact first.
✎our practicethe group’s recommended practice, not an Anthropic product fact.
What we found
Each finding opens with the plain-language version; the detail, the source, and the related
claims sit one click below. The chips tell you how much to lean on it.
✓ checked against Anthropic's page · ▪ carried from the group's doc, not re-checked · ⚠ treat as a question
A Skill is a folder built around a single SKILL.md
A Skill is a folder — centered on one `SKILL.md` file, optionally with scripts and reference material — that gives Claude reusable, domain-specific instructions: your workflows, your context, your best practices, loaded automatically when relevant instead of re-explained every conversation.
Detail, source & related
Detail
The definition, per the Help Center via the source doc: a Skill packages instructions (and optionally supporting scripts/reference files) around a single SKILL.md, and Claude loads it automatically when it judges the skill relevant to the task at hand. The payoff is consistency: the org’s way of doing a task, written once, applied every time. Self-demonstration: this vault’s own SKILL.md is a live instance — a Skill that teaches an agent how to answer from this very graph.
Status: CONFIRMED — re-verified 2026-07-28 (receipts R4, R22, R28, R39): the moved docs page loads (it was a 404 at the old /agents-and-tools/skills path; the current path is /agents-and-tools/agent-skills/overview) and states directly — “Every Skill requires a SKILL.md file with YAML frontmatter” — packaging instructions plus optional scripts and resources, loaded on demand (progressive disclosure). The source doc’s SKILL.md description is corroborated verbatim.
Custom instructions follow you into every conversation. Skills are task-specific — they only switch on when Claude decides they're relevant. That makes Skills the better home for specialized, repeatable workflows (like "how our org formats a grant report").
Detail, source & related
Detail
The distinction, per the source doc: custom instructions apply broadly to every conversation you have; Skills are task-specific and load only when Claude judges them relevant — which suits them to specialized, repeatable workflows. Rule of thumb for the working group: always-true preferences (tone, role, general context) → custom instructions; how we do this particular task (report formats, review rubrics, intake templates) → a Skill. The House-style Skill for reports, updates, decks, and comms use case is the canonical example of the latter.
Status: CONFIRMED — re-verified 2026-07-27 (receipts R4, R27): “Custom instructions apply broadly to all your conversations. Skills are task-specific and only load when relevant, making them better for specialized workflows.”
Before building anything, know what's already there: Anthropic provides pre-built Skills for Word, Excel, PowerPoint, and PDF document creation. In the Claude apps (claude.ai) they work automatically, with no setup. On the API they exist too, but a developer has to enable them first; and in Claude Code they are not available at all.
Detail, source & related
Detail
Anthropic ships prebuilt Skills for the office-document formats (Word, Excel, PowerPoint, PDF). For the working group this covers a surprising share of day-to-day output — board decks, budget spreadsheets, formatted reports — before any custom Skill is written. But “no setup” is a per-surface statement, and the surfaces differ (receipt R35):
claude.ai — the docs’ own words: “These Skills are active when you create documents. Claude uses them with no setup required.” This is where the no-setup claim is true.
The API — the prebuilt Skills exist (pptx, xlsx, docx, pdf by skill_id) but have stated prerequisites: “Using Skills through the API requires the code execution tool, whose container Skills run in, and one beta header: skills-2025-10-02” (plus a second header, files-api-2025-04-14, when files move in or out of the container). A member’s developer building on the API does not get them for free.
Claude Code — “The pre-built document Skills (PowerPoint, Excel, Word, PDF) are not available in Claude Code.”
Status: CONFIRMED — re-verified 2026-07-28 (receipts R4, R27, R35): “Anthropic skills created and maintained by Anthropic, such as enhanced document creation for Excel, Word, PowerPoint, and PDF files.” The surface qualifier was added 2026-07-28: the Help Center page is app-facing, and the platform docs scope the no-setup behavior to claude.ai while the API path carries prerequisites and Claude Code carries no prebuilt document Skills at all (receipt R35). The prebuilt list is the kind of detail that grows over time.
A simple custom Skill is just a Markdown file describing what the skill does and when Claude should use it — no programming. An interactive helper called `skill-creator` circulates in write-ups of Skills — but no Anthropic documentation page we can find describes it at all, let alone as a built-in feature. Do not plan a training session around it being already there.
Detail, source & related
Detail
The no-code part is solid. Anthropic’s Help Center states it plainly: “Anyone can create skills by writing instructions in Markdown—no coding required for simple skills.” A simple Skill is a Markdown file saying what the skill does and when to use it, optionally with scripts for more advanced behavior. That genuinely puts Skill authorship inside reach of non-technical advocacy staff — the exact audience of this vault.
The skill-creator part needs a correction, and it changes the plan. This node previously described skill-creator as built in. An enumerated search of all three of Anthropic’s Skills pages — the Help Center article, the platform overview and the enterprise guide — found zero mentions of the tool on any of them. (One near-hit, recorded for precision: the enterprise page says “Authoring guidance for Skill creators”, which refers to people who write Skills, not to a tool.)
What follows from that search is a negative claim only: no Anthropic page documents skill-creator as a built-in feature. It is not evidence for where the tool does come from. The platform documentation does say “Anthropic also publishes open-source Skills in the skills repository” — but the one skill that section names is the Claude API skill, not this one. So: where skill-creator is obtained is not established by anything this node cites, and this node will not tell you to go and fetch it from somewhere its own sources do not place it.
The practical consequence for the working group’s live-build-session ask (A live, guided Skill-building session as training) is a question to settle before the call rather than a setup instruction we can hand you: ask Anthropic whether skill-creator is available on the surface the session will use, and if so how it is obtained. Plan the session so it works without it — the no-code Markdown path is documented and sufficient — and treat the helper as a bonus. Note too that Skills CAN be provisioned org-wide on Team and Enterprise — and one Anthropic page still says otherwise establishes Skills do not sync across surfaces, so whichever surface you pick is the one you get. The session itself is still very practical: one call, one shared Skill, the pattern learned by doing. Candidate first build: Registry / biorepository intake formatting template.
Status: CONFIRMED 2026-07-27 (receipts R27, R28) — the no-code claim is verbatim on the Help Center page. Corrected at CG4, in both directions at once, which is why the chip could move. This node was simultaneously too optimistic about availability — calling skill-creator “built-in” when no Anthropic page documents it at all — and too pessimistic about provenance, carrying ▪ because the builder “stands as documented in the source doc” and had never been checked. The enumerated search settles the negative half only — no Anthropic page documents the tool — and the node no longer asserts the positive half. Corrected again at the CG4 source-check leg, which caught this node replacing one unsourced claim (“built-in”) with a differently unsourced claim (“fetch it from the open-source repository”) and raising the chip to ✓ across the transition. The repository section names exactly one skill, and it is not this one. Every claim the node now makes is on a cited page. An overstatement of what a product gives you for free is a real cost to a nonprofit planning a training session around it.
You upload a custom Skill as a zip file through Settings > Features. It's available on Pro, Max, Team, and Enterprise plans, with code execution enabled.
Detail, source & related
Detail
The upload mechanics, verbatim from the source: “Custom Skills: Upload your own Skills as zip files through Settings > Features. Available on Pro, Max, Team, and Enterprise plans with code execution enabled.”
That is the whole of what this node now claims — the mechanical path and its plan availability, both directly quotable.
Status: CONFIRMED 2026-07-25 (receipt R15) — the quoted sentence verified verbatim on the live page this date. Chip upgraded from DOCUMENTED: at the last check the upload path could not be found on the page then cited (the Help Center article), so the claim was carried from the working-group document. It is now directly receipted against primary documentation — with the governance half, which is not settled, removed to its own node.
On Team and Enterprise, an organization owner can push a Skill to everyone, and members can share Skills with colleagues or publish them to an organization directory. All of that is documented. One Anthropic page — the platform Agent Skills overview — still says custom Skills "cannot be centrally managed by admins", and that sentence is out of date. If your IT lead reads that page and concludes org-wide Skills are impossible, they have the wrong answer.
Detail, source & related
Detail
What is actually available (Team and Enterprise).“Organization-wide skill management is available to Team and Enterprise plans.” There are three distinct paths, and they are different objects — which is what an earlier version of this node missed:
Owner-provisioned
Shared peer-to-peer
Shared org-wide
Who can share
Owners only
Any member (if enabled)
Any member (if enabled)
Where it appears
Everyone’s skills list
Recipient’s “Shared with you”
Organization directory
Can recipients remove it?
Disable only
Disable or delete
Disable only
“When you upload a skill through organization settings, it becomes available to everyone in your organization in Customize > Skills. Individual members no longer need to upload the same skill themselves.” Provisioned skills are “enabled by default for everyone, but members can toggle individual skills off.” To reach only part of the organization, “bundle your skills into a plugin and assign that plugin to a group.”
Two governance facts to decide before switching sharing on. Both member-sharing toggles are “off by default”, and the reason to keep the second one off is stated plainly: “There’s no approval workflow for org-wide sharing. If you enable Share with organization, any member can publish a skill to the directory without review.” And the audit trail has a hole worth knowing about — “The audit log doesn’t capture the contents of shared skills—only the share event itself. There’s no admin dashboard to browse or inspect the contents of skills shared between members.” For a group whose Skills may encode registry-intake or patient-facing procedures, that is the difference between “we can see who shared something” and “we can see what they shared.”
Why this node still carries a flag. Anthropic’s platform documentation continues to state, of claude.ai custom Skills: “They are not shared organization-wide and cannot be centrally managed by admins.” Against the admin documentation, the first half is false as stated — a member can publish to the organization directory — and true only of the default configuration. The second half half-survives: no admin dashboard inspects shared-skill contents, but owners do control both toggles and share events reach the audit log and the Compliance API. The platform page carries no freshness string; the two Help Center articles are dated and fresher. Believe the admin documentation, and expect to have to say so to anyone who found the other page first.
What changed here, and why it is on the record. This node previously presented the two pages as an unresolved contradiction and told readers to “assume a custom Skill one person builds reaches only that person” and not to plan around org-wide provisioning. That was wrong in the restrictive direction — it withheld a capability a Team-plan group already has, on a register carried into a vendor call. The reconciling document existed the whole time, and this node named it — as a freshness signal — without anyone opening it. Charter §4.4 exists to forbid exactly that: an absence may not be asserted until the document where the answer would live has been searched. Caught by an adversarial reviewer, not by us.
Status: ⚠ STALE-RISK — re-scoped 2026-07-27 (receipts R15, R16, R27, R28, R29, R32). The flag no longer marks “we cannot tell whether this is possible” — it is possible, and documented. It now marks a narrower and still-live hazard: one current Anthropic page states the opposite, and a reader or IT lead who lands there will conclude a capability is unavailable when it is. That is a discrepancy between the vendor’s own surfaces, which is what this chip is for.
⚑ Compliance-relevant: how Skills are governed across an organization decides where working-group material travels — and org-wide sharing has no approval step. Confirm current specifics with your Anthropic contact before designing a sharing workflow. This is a teaching aid, not compliance or legal advice.
A Skill the working group could build that applies one standardized rubric whenever abstracts or posters are reviewed, so every reviewer scores against the same criteria instead of improvising each cycle.
Detail, source & related
Detail
The working group frequently reviews conference abstracts or judges poster competitions and would benefit from a Skill built around a standardized template or rubric — criteria, scoring scale, and format — that Claude applies automatically whenever this kind of review task comes up. This turns an ad hoc, reviewer-dependent process into a consistent, repeatable one across however many abstracts or posters come in each cycle.
Source & currency
Source: working-group idea (source doc §5, “Good potential use cases”).
Status: idea for a Skill the working group could build — not yet built.
A Skill the working group could build that takes a scientific article and produces a plain-language summary, a next-steps note, and a ready-to-post social update in one pass, so translating research for patients and families doesn't start from a blank page each time.
Detail, source & related
Detail
A recurring task across rare-disease advocacy organizations is translating a scientific article into material non-technical audiences can use: a lay summary, a plain statement of what it means for patients and families next, and a short social-media post announcing it. A Skill built around this workflow would produce all three outputs consistently from a single article, in whatever format and tone the organization prefers.
Source & currency
Source: working-group idea (source doc §5, “Good potential use cases”).
Status: idea for a Skill the working group could build — not yet built.
House-style Skill for reports, updates, decks, and comms
source: working-group doc
A Skill the working group could build that encodes an organization's house style — tone, sections, formatting — so grant reports, funder updates, decks, and patient-facing pieces come out consistent without re-explaining preferences every time.
Detail, source & related
Detail
Organizations in the working group each have their own conventions for grant reports, funder updates, presentation decks, and patient-facing communications — tone, required sections, formatting. A house-style Skill would encode those conventions once, so future drafts of any of these document types start from a consistent, on-brand baseline rather than the author re-specifying style preferences in every conversation.
Source & currency
Source: working-group idea (source doc §5, “Good potential use cases”).
Status: idea for a Skill the working group could build — not yet built.
A Skill the working group could build that formats newly collected natural-history, registry, or biorepository data the same way every time, so intake structure doesn't drift as different staff enter data over months or years.
Detail, source & related
Detail
Natural history studies, patient registries, and biorepositories collect data over long periods, often from different staff at different times — a real risk for structural drift (inconsistent fields, labels, or formatting) that complicates later analysis. A Skill built around a fixed intake template would apply the same structure to new data every time it’s used, regardless of who is entering it.
Source & currency
Source: working-group idea (source doc §5, “Good potential use cases”).
Status: idea for a Skill the working group could build — not yet built.
Scientific advisory board minutes format, per foundation
source: working-group doc
A Skill the working group could build that turns raw meeting notes into a foundation's own standard scientific-advisory-board summary format automatically, removing the manual reformatting step after every meeting.
Detail, source & related
Detail
Each foundation in the working group likely has its own preferred structure for summarizing scientific advisory board meetings — sections, level of detail, distribution format. A Skill built per foundation would take raw notes and produce that foundation’s standard summary format consistently, without staff manually reformatting after every meeting.
Source & currency
Source: working-group idea (source doc §5, “Good potential use cases”).
Status: idea for a Skill the working group could build — not yet built.
This module's open questions for the Anthropic contact — also in the
consolidated printable register.
Existing Skills from other advocacy nonprofits to adapt compliance-critical ⚑
Before building from scratch, ask whether other nonprofits in similar situations have already built — and would share — a Skill the group could adapt.
A live, guided Skill-building session as training
Ask whether Anthropic would run a hands-on session building a real Skill together with the group, rather than the group learning solely from documentation.
Sharing Skills across an org or working group
Ask exactly how a Skill built by one person gets shared with teammates or other organizations — is it a simple export and import, or does it require an Enterprise/Team admin to deploy it org-wide?
Retention considerations specific to Skills, outside ZDR compliance-critical ⚑
Even an organization with a Zero Data Retention agreement should know that Skills are the exception — ask what that actually means in practice for anything built into a Skill.