Claims last verified 2026-09-1932 confirmed · 10 documented · 2 stale riskverification log →
the tally counts the 44 findings; the 6 connection notes also carry chips outside it
Anthropic's policies and products change frequently —
always confirm current specifics with your Anthropic contact before relying on this for a compliance decision.
✓ checked against an Anthropic page on the date shown ·
▪ not checked against a page — the working group's document, or our own practice recommendation ·
⚠ treat as a question, not a fact ·
⚑ a patient-data decision could hang on this
· ✎ our own practice rule, not an Anthropic product fact
— the counts tally the 44 findings; the 6 connection notes also carry chips and sit outside that tally
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.
This module is a teaching aid, not compliance or legal advice — patient-data
decisions belong to your organization, its counsel, and its Anthropic contact.
Where this comes from: the findings below are drawn from the working group's
own document (its “§” numbers are that document's sections), from this curriculum's own practice
recommendations, and, where marked
✓Confirmed,
checked against Anthropic's primary pages — see the verification log.
How to read the chips
✓Confirmedchecked against Anthropic’s own page on the date shown, and the receipt kept.
▪Documentednot checked against an Anthropic page this round — either carried from the working group’s document, or this curriculum’s own practice recommendation. The source chip says which.
⚠︎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 practicea practice recommendation — this curriculum’s or the working group’s — 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 · ▪ the group's doc or our own practice, not re-checked against Anthropic · ⚠ 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, with groups, or submit them to an organization library. All of that is documented — and since this node was first written, Anthropic has added a review workflow: an owner-controlled Publishing policy that can require approval before anything a member submits is published. 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 now four distinct paths, and they are different objects:
Owner-provisioned
Shared peer-to-peer
Shared with a group
Published to organization
Who can share
”Owners only"
"Any user (if enabled)"
"Any user (if enabled)"
"Any user (if Publishing is on)“
Can recipients remove it?
”Disable only"
"Disable or delete"
"Disable only"
"Depends on how an owner offers it”
“When you upload a skill through organization settings, it becomes available to everyone in your organization …” — individual members no longer need to upload the same skill themselves. To reach only part of the organization, bundle skills into a plugin and assign it to a group.
Governance facts to decide before relying on any of this — re-grounded 2026-09-19; the model changed.
Publishing now has a review workflow. The earlier page said flatly that there was “no approval workflow for org-wide sharing”; that sentence is gone. The current model is a three-state, owner-set Publishing policy: Requires review (“Users can submit skills and plugins, and an owner must approve each one before it’s published” — and “every later version goes through the same review”; “You can’t approve your own.”), Open (“Skills and plugins that users submit are published to the organization library without review”), or Off (“Users don’t see the ‘Publish to org’ button. Owners can still add skills and plugins to the organization directly.”). The publish-without-review hazard this node used to teach is now configuration-dependent: real only under “Open”. Dated fact:“If you haven’t chosen a setting, it switches to ‘Requires review’ on October 2, 2026.”
The sharing default reversed in the direction that matters. This node used to quote both member-sharing toggles as “off by default”. Today: “The Skill sharing toggle is on by default for Team plans and for Enterprise plans that haven’t set a skills preference.” A Team-plan working group must now assume sharing is on unless someone turned it off. The regulated-configuration carve-out matters for this audience: “For organizations with HIPAA readiness or other regulated configurations, skills and skill sharing are off by default.”
The audit trail’s hole is unchanged.“The audit log doesn’t capture the contents of shared skills or plugins—only the share event itself. There’s no admin dashboard to browse or inspect the contents of skills shared between users.” Share events do land in the record — “Skill sharing events are captured in the audit log and Compliance API as role_assignment events” — so the situation remains “we can see who shared something”, not “we can see what they shared.”
New since the last read: an org-level kill-switch (“Turn off User-created skills”), and security scanning of skills and plugins — “Scanning is off by default until October 2, 2026. From that date it’s on by default, where available, for Enterprise organizations that haven’t set it” — with an exclusion directly relevant to this working group: “Scanning isn’t available for organizations using customer-managed encryption keys (CMEK), zero data retention (ZDR), or HIPAA configurations.”
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” — re-verified still live 2026-09-19. Against the admin documentation, the first half is false as stated, and the management claim is now wronger than before: owners control provisioning, sharing toggles, a Publishing review queue, a kill-switch, and (from October 2026) scanning. The platform page carries no freshness string; the 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. (1) 2026-07-27: this node previously presented the two pages as an unresolved contradiction and told readers to assume a Skill reaches only its builder — wrong in the restrictive direction; the reconciling admin article existed, was named here, and had not been opened (Charter §4.4; caught by an adversarial reviewer). (2) 2026-09-19 (C6 r3, finding A3-1): the admin article replaced its own governance model — the “no approval workflow” language this node quoted as current is gone, superseded by the Publishing policy above, and the sharing default flipped to on-by-default for Team plans. The STALE-RISK chip fired exactly as designed — the movement happened on the page it points at — and the body was re-grounded on the current language rather than silently re-stamped. Note the two dated defaults above: on 2026-10-02 unset orgs flip to “Requires review” and unset Enterprise scanning turns on — this node must be re-checked against the post-flip page after that date.
Status: ⚠ STALE-RISK — re-grounded 2026-09-19 (C6 r3 accuracy leg, finding A3-1; direct re-fetch of all three sources — receipts R91, R92, R93). The flag marks the same live hazard as before: one current Anthropic page states the opposite of the admin documentation, and a reader who lands there will conclude a capability is unavailable when it is. It now also marks a time-bound: two vendor defaults flip on 2026-10-02 (unset-org Publishing → “Requires review”; unset-Enterprise scanning → on), so this node’s description of defaults expires that day and is scheduled for re-verification after it. (Earlier: re-scoped 2026-07-27, receipts R15, R16, R27, R28, R29, R32.)
⚑ Compliance-relevant: how Skills are governed across an organization decides where working-group material travels. Whether publishing requires review is now an owner setting — confirm which Publishing state and which sharing defaults your organization runs (and note HIPAA/regulated configs default everything off) with your Anthropic contact before designing a sharing workflow. This is a teaching aid, not compliance or legal advice.
A Skill you write is a plain folder in a published, open format — so it is not locked to Claude, and a growing list of other companies' AI tools can read the same folder. But "open standard" does not mean you need a software kit: there is nothing to install to write a Skill — it is a folder with a SKILL.md file, and the only tool the specification names is a small checker that tells you whether your folder is valid. (Anthropic does now mention a "reference Python SDK" — that kit is for companies building platforms that run Skills, not for people writing them; see below.)
Detail, source & related
Detail
Two halves, and the second one is the half people get wrong.
(a) It is genuinely published as an open standard. The specification lives at agentskills.io, under a section headed “Open development”, which states: “The Agent Skills format was originally developed by Anthropic, released as an open standard, and has been adopted by a growing number of agent products. The standard is open to contributions from the broader ecosystem.” Anthropic’s engineering blog says the same from its own side: “We’ve published Agent Skills as an open standard for cross-platform portability.” The format’s own summary line calls it “a lightweight, open format for extending AI agent capabilities with specialized knowledge and workflows,” and names portability as a design goal: “Cross-product reuse: Build a skill once and use it across any skills-compatible agent.”
Portability is materially verified, not just asserted. The site’s client showcase lists real, non-Anthropic products that read the format. Verified present on 2026-07-28: OpenAI Codex, Gemini CLI (Google), GitHub Copilot, VS Code, Cursor, Mistral AI Vibe, Junie (JetBrains), Databricks Genie Code, Snowflake Cortex Code, Goose (Block), and Spring AI — alongside roughly thirty more. That an OpenAI product and a Google product both consume a format Anthropic authored is the strongest available evidence that the openness claim is doing real work rather than marketing work. For the working group the practical consequence is modest but real: a Skill encoding your house style or your intake template is written in a format several vendors already read, so it is less of a one-vendor bet than most things you will build this year.
(b) There is no SDK to install to write a Skill — and the two similarly-named things are something else. The specification names exactly one piece of tooling, and it is a validator, not a kit: “Use the skills-ref reference library to validate your skills”, invoked as skills-ref validate ./my-skill, which “checks that your SKILL.md frontmatter is valid and follows all naming conventions.” That is the whole of it. There is nothing to install in order to write a Skill — a Skill is a folder with a SKILL.md file in it, and the format is deliberately small enough that a text editor is the only tool required.
Vendor-surface divergence, on the record (C6 r3, 2026-09-19). An earlier version of this node stated categorically “there is no Agent Skills SDK.” Anthropic’s What-are-skills Help Center page now says: “A reference Python SDK is also available for developers implementing skills support in their own platforms.” Meanwhile agentskills.io’s home and specification pages — this node’s grounding sources — still contain zero occurrences of “SDK” (both re-fetched 2026-09-19). So the categorical sentence was retired and the claim narrowed to what both surfaces support: the kit the vendor names is for platform implementers (people building agent products that run Skills), and a skill author still installs nothing. The practical teaching is unchanged. (Whether that Help Center sentence predates this node’s first writing could not be determined from this seat; it is live today.)
A second source of confusion is the Claude Agent SDK, a real product with a genuinely similar name. Anthropic’s blog places it in a list of consumers of the format: “Agent Skills are supported today across Claude.ai, Claude Code, the Claude Agent SDK, and the Claude Developer Platform.” Read that carefully — the Claude Agent SDK is Anthropic’s kit for building agents, and it happens to support Skills, in the same way Claude Code and claude.ai support them. It is not an SDK for the standard, and nothing in the standard depends on it. If someone tells your group it needs an SDK before it can start writing Skills, that is not correct.
Where the openness claim actually lives — and where it does not. This is worth knowing before anyone cites the standard in a grant application or a vendor-diligence answer. The openness statement appears on the overview page and on Anthropic’s blog. It does not appear in the normative specification itself. An enumerated search of the specification’s own source on 2026-07-28 found zero occurrences of “open standard”, “open-standard”, “openness”, “open source”, “governance”, “steering”, “committee”, “working group”, “consortium”, “foundation”, “maintainer”, or “contribut-”; no specification version number (the only version strings on the page are version: "1.0" inside an example of the optional per-skill metadata field); and no licence for the specification — the word license appears only as an optional per-skill frontmatter field, described as “License name or reference to a bundled license file” that “specifies the license applied to the skill.” So: the format is open in practice and described as open by its publishers, but the specification document itself carries no version, no named governance body, and no licence grant. That is a normal state for a young standard, and it is not a reason to avoid the format. It is a reason not to over-claim in writing — say “published as an open standard, adopted across multiple vendors”, not “governed by an independent standards body”, because only the first is supported.
Consistent with a real hand-off to a neutral home, the specification’s tooling and discussion now live under the agentskills/agentskills GitHub organization rather than under anthropics/. Anthropic’s own anthropics/skills repository still exists and still carries a ./spec folder and example Skills, but its README now points readers outward for the standard itself: “This repository contains Anthropic’s implementation of skills for Claude. For information about the Agent Skills standard, see agentskills.io.”
Do not confuse this with MCP.MCP — Model Context Protocol describes the Model Context Protocol as an open standard too. Both statements are true, and they are about entirely different things — a distinction worth holding, because the two terms turn up in the same sentence constantly:
Agent Skills
MCP (Model Context Protocol)
What it standardises
the format of a folder of instructions and resources an agent reads
the protocol by which an agent talks to an external tool or data source
What you produce
a SKILL.md file plus optional scripts, references, assets
a running server that exposes tools or data
What it does at run time
supplies knowledge and procedure — how to do the task your way
supplies reach — access to a system outside the conversation
Safety weight for this group
low on its own: text an agent reads
higher: a local MCP server “runs on your computer with the same permissions as any other program you run” (MCP — Model Context Protocol)
The short version: a Skill changes what Claude knows how to do; an MCP connection changes what Claude can reach. Writing a Skill is close to writing a document. Installing an MCP server is close to installing software. Both are called open standards; only one of them expands your exposure surface by being switched on.
Status: CONFIRMED — narrowed and re-verified 2026-09-19 (C6 r3, finding A3-2; ⛩-ruled: qualify and keep CONFIRMED on the narrowed claim; receipts R92, R94, R95). The claim is now “there is no SDK to install to write a Skill”, which both vendor surfaces support: agentskills.io home + specification re-fetched 2026-09-19 with zero “SDK” occurrences, while Anthropic’s What-are-skills page names a “reference Python SDK … for developers implementing skills support in their own platforms” — an implementer’s kit, noted in Detail (b), not an author’s. (Original: CONFIRMED 2026-07-28, receipts R53–R58 — every quoted passage verified on the live pages that date; the enumerated negatives rest on a term search against the specification’s .md source endpoint, terms and counts in receipt R55. The engineering-blog source was not re-fetched on 2026-09-19 — its quotes stand on the 07-28 receipt.)
What is most likely to move: the client showcase grows continuously, and a young standard acquiring a version number, a licence, or a governance body would be an ordinary next step rather than a surprise. Re-check the specification page before citing the absence of any of those in writing.
MCP — Model Context Protocol — the other open standard, and a different thing entirely: MCP standardises how Claude reaches an outside system, this standardises the folder format Claude reads
Ideas for Skills, not product facts, and none of them built yet. Each card's chip says where the
idea came from: the working group's own document, or the clinician track
added in July 2026 — proposals of ours, written to tool posture and not clinician-reviewed.
The clinician track supplements the document's own use cases; nothing was removed.
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.
House-style Skill for reports, updates, decks, and comms
✎the group's idea
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
✎the group's idea
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.
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.
Literature triage, with the source-opening step made mandatory
✎our proposal, not reviewed
source: clinician-track proposal
Hand Claude a stack of papers and ask it to sort them — which ones bear on the question you are actually asking, and what each one appears to claim. Then open every paper you intend to rely on and read the passage yourself. The triage is the tool's job; the reading is not, and a Skill built for this should make the reading step impossible to skip rather than merely recommended.
Detail, source & related
Detail
What the tool does well here. Ranking, grouping and first-pass relevance across more papers than a person will read in a sitting; extracting a stated endpoint, cohort size or inclusion criterion into a comparable shape; and noticing that two papers use the same term differently.
What this Skill must be built to force. The failure mode is not that Claude ranks badly — it is that a plausible one-line summary substitutes for the paper. A generated summary can be fluent, well-formatted, correctly cited and wrong about what the paper says, and nothing downstream will flag it. So the Skill’s output format should carry, per paper, the passage it is relying on and the step “opened and read: ☐” as an unticked box the human ticks — not a sentence in a preamble.
Tool posture, not clinical posture. Which papers matter to a given patient, how strong a body of evidence is, and what any of it implies for care are clinical judgments. This node does not address them and no Skill built from it should present itself as addressing them.
Where this stops
Everything past “here is what this paper appears to say, and here is the passage” belongs to the clinician. The working group’s clinician review (S3) has not yet convened; when it does, the question to put to it is whether a triage output format like this one helps or quietly encourages the substitution it is designed to prevent.
Source & currency
Source: clinician-track proposal, authored at SC5 CG6 under the ⛩ CG3 audience ruling (parallel clinician track on the shared graph) and adr_001_audience_and_growth.md, accepted 2026-07-28. Not from the working-group document — the document contains no clinical use cases.
Status: a proposal for a Skill this group could build. Not built, and not clinician-reviewed.
Register: our proposal, not an Anthropic product fact and not a clinical recommendation.
Case summarization from notes that are already de-identified
✎our proposal, not reviewed
⚑compliance — confirm with your contact
source: clinician-track proposal
Turning long clinical notes into a structured summary is something Claude does well. The whole question is what you put in. The title of this use case is the constraint: the notes are de-identified before they reach Claude, not by Claude — and on most surfaces, on most plans, patient data is never covered at all.
Detail, source & related
Detail
The order of operations is the entire safety property. De-identify, then summarize. Not summarize, then redact. A model asked to remove identifiers is doing a best-effort text transformation with no guarantee and no audit trail; the de-identification has to have happened before the text leaves your control. A de-identification pre-flight — the checks to run before anything is pasted is the checklist this use case assumes has already been run.
Rare disease erodes de-identification faster than most fields. A diagnosis with a few hundred known cases worldwide, plus an age and a region, can identify a person even with every name and number stripped. That is not a hypothetical for this working group — it is the ordinary case. De-identification carries the point; treat “de-identified” as a judgment you made and can defend, not a state a tool conferred.
Tool posture, not clinical posture. What belongs in a case summary, what a summary omits at its peril, and whether a summary is fit to inform care are clinical judgments. This node addresses the data-handling posture only.
Where this stops
The de-identification threshold — how much detail is too much for a given rare condition — is an open question this group has already logged for its Anthropic contact and its own counsel (Anthropic's safe de-identification threshold before data is PHI). It is not settled here and this use case does not settle it. S3 clinician review has not convened; this is among the items most in need of it.
Source & currency
Source: clinician-track proposal, authored at SC5 CG6 under the ⛩ CG3 audience ruling and adr_001_audience_and_growth.md (accepted 2026-07-28). Not from the working-group document.
Status: a proposal. Not built, not clinician-reviewed. The HIPAA and de-identification claims it leans on are the graph’s own established nodes, each with its own chip and receipt.
Register: our proposal. Marked compliance-critical because a patient-data decision could hang on reading it carelessly.
✎our proposal, not reviewed
⚑compliance — confirm with your contact
source: clinician-track proposal
Families on a long diagnostic odyssey accumulate letters — referrals, insurer appeals, summaries for the next specialist, requests for records from the last one. Drafting these is repetitive, and Claude drafts well. Two things do not change: patient detail is governed by the same surface and plan rules as anything else, and a letter that goes out over a clinician's name is that clinician's letter.
Detail, source & related
Detail
What the tool does well here. Holding a consistent structure across many letters; restating the same history for different readers at different levels of technicality; producing a first draft of an appeal that cites the criteria the payer published; keeping a house style (House-style Skill for reports, updates, decks, and comms) across correspondence written by different people.
The data question comes first, as always. A referral letter is dense patient detail by construction. If the surface is not covered (Most ways of using Claude are never covered by Anthropic's BAA — and on two cloud platforms, coverage is someone else's call), it is not covered for this either. Where the work can be done on de-identified or synthetic material — drafting the template, the standard paragraphs, the appeal skeleton — that is the version of this use case available to everyone regardless of plan, and it is where most of the repetitive labor actually is.
Tool posture, not clinical posture. What to say in a referral, which specialist to route to, how to characterize a differential, and what an appeal ought to argue clinically are clinical judgments. This node addresses the drafting posture only.
Where this stops
Correspondence that goes to a family, rather than to another clinician, sits closest to the line this site draws: it is the point at which an unchecked output reaches someone with no way to check it. That is exactly the case Check every output before it reaches a person; never put credentials or PHI on an uncovered surface names, and it is a question for S3 clinician review, which has not yet convened.
Source & currency
Source: clinician-track proposal, authored at SC5 CG6 under the ⛩ CG3 audience ruling and adr_001_audience_and_growth.md (accepted 2026-07-28). Not from the working-group document.
Status: a proposal. Not built, not clinician-reviewed.
Register: our proposal. Marked compliance-critical: referral correspondence is patient data by default.
✎our proposal, not reviewed
source: clinician-track proposal
Protocols and IRB packets are long, highly structured, and mostly boilerplate around a small core of genuinely study-specific reasoning. Claude is good at the structure and the boilerplate. The study-specific core is yours, and so is every regulatory citation the packet makes.
Detail, source & related
Detail
What the tool does well here. Producing a complete section skeleton against a template your institution already uses; keeping terminology consistent between the protocol, the consent form and the statistical plan (a common source of IRB queries); drafting lay-language consent sections from technical text; and checking a draft for internal contradictions — a genuinely good fit, because it is a comparison task over text you supply rather than a knowledge claim.
The regulatory-citation hazard is the sharp edge. A protocol that cites a regulation, a guidance document or an institutional policy is making a checkable claim, and a fluent wrong citation here costs a review cycle at best. Every such reference is opened and read before submission — the third step of The three checks: available, eligible, checked, in the setting where it is least optional.
Boilerplate is not free of judgment. Standard paragraphs carry commitments — about data handling, retention, withdrawal, and what happens to samples. Carrying one over because it was in the last protocol is a decision, whether or not it is made deliberately.
Tool posture, not clinical posture. Study design, endpoint selection, risk–benefit reasoning, eligibility criteria, and whether a protocol is ethically sound are the investigator’s and the IRB’s. This node addresses drafting only, and nothing in it should be read as guidance about what a protocol ought to contain.
Where this stops
The boundary here is unusually clear and worth stating plainly: an IRB exists to exercise judgment that cannot be delegated. Drafting support is drafting support. S3 clinician review has not convened; a reviewer with IRB experience is the right reader for whether this framing is the useful one.
Source & currency
Source: clinician-track proposal, authored at SC5 CG6 under the ⛩ CG3 audience ruling and adr_001_audience_and_growth.md (accepted 2026-07-28). Not from the working-group document.
Status: a proposal. Not built, not clinician-reviewed.
Register: our proposal, not an Anthropic product fact and not regulatory advice.
✎our proposal, not reviewed
⚑compliance — confirm with your contact
source: clinician-track proposal
Rare-disease natural-history data arrives as prose — clinic letters, parent accounts, referral summaries — and has to become fields before it can become evidence. Claude is good at proposing that structure and at applying an agreed structure consistently. Two constraints bind: the schema itself must not carry patient detail, and a field Claude filled is a field a human has not yet checked.
Detail, source & related
Detail
Distinct from the intake template already on this site.Registry / biorepository intake formatting template is the advocacy-side idea: a Skill producing a consistent intake form. This node is the step after — taking accumulated unstructured records and proposing the longitudinal structure a natural-history study needs. Related, deliberately not merged, and cross-linked so neither is read as the other.
The schema is not a safe place for examples. Do not put patient detail into field descriptions, enum values, or example payloads. This is a documented product-level point, not a stylistic one: Never put PHI in a JSON schema — cached schemas are not protected like message content carries it. A schema circulates far more widely than the data it describes — into tickets, into vendor conversations, into repositories — and it circulates without the protections the data has.
Longitudinal structuring is where quasi-identification compounds. A single record may be de-identifiable; a longitudinal series of the same person, in a disease with a few hundred known cases, frequently is not. De-identification and A de-identification pre-flight — the checks to run before anything is pasted apply with more force here than in any other use case on this site, because the identifying power grows with exactly the thing that makes the dataset valuable.
Every extracted field is unverified until read. Extraction from prose is the task most likely to produce confidently wrong structured output, because the output looks like data. A registry populated from unchecked extraction is worse than no registry: it carries the authority of a table. The third step of The three checks: available, eligible, checked is the control, applied per field, not per document.
Tool posture, not clinical posture. Which variables a natural-history study should collect, how to define an outcome, what constitutes a phenotype, and whether a dataset can support a given analysis are research and clinical judgments. This node addresses the structuring and data-handling posture only.
Where this stops
Whether a longitudinal rare-disease dataset can be de-identified at all, for a given condition and cohort size, is an open question this group has logged (Anthropic's safe de-identification threshold before data is PHI) and not answered. It is the question this use case most depends on and least resolves. S3 clinician review has not convened.
Source & currency
Source: clinician-track proposal, authored at SC5 CG6 under the ⛩ CG3 audience ruling and adr_001_audience_and_growth.md (accepted 2026-07-28). Not from the working-group document.
Status: a proposal. Not built, not clinician-reviewed.
Register: our proposal. Marked compliance-critical: registry work is patient data by construction.
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.