A folder, an instruction file, optional scripts, an inferred trigger. A reasonable answer for a stateless agent.
An Anthropic Skill is a directory. Inside it sits a SKILL.md describing what the skill does and how the model should approach the task. Alongside it are whatever supporting files the skill needs — scripts to execute, templates to reference, asset files to pull from. The model loads the skill when triggering conditions match (the user's request, the file types in scope, the configured invocations). Once loaded, the model follows the SKILL.md's instructions and may execute the bundled scripts in a sandboxed code environment.
This shape is well-suited to the problem it solves. A user has built up specialized procedures — how their organization formats financial reports, how their team writes commit messages, how their codebase wants Python type hints — and wants Claude to follow those procedures consistently across many tasks. Bundling the procedure as a folder the model can load is a clean solution. The folder format is portable. The instruction file is human-authorable. The execution sandbox is well-understood. Many users will reach for Skills exactly because they want this affordance, exactly this way.
The architecture being described here is not a critique of Skills as a product decision. Anthropic is solving for an audience whose substrate is the user's filesystem, whose execution is a stateless agent invocation, whose composition unit is the model conversation. Within those constraints, Skills are the right answer. The question this essay asks is different. If the substrate is something else — if the substrate is already a graph database with ingestion and normalization and access control and audit — what does the equivalent of Skills look like there? The answer is not "the same thing, ported." The answer is that you've already built it, and calling it Skills makes it look smaller than it is.
Brand voice, code conventions, vocabulary, tone — these are things a community knows. Things the community has accumulated. Things that should live where everything else the community knows lives.
Look at what people actually put in Skills. A skill that enforces a firm's brand voice is the firm's brand book in a different file format. A skill that produces SQL in a particular dialect with particular naming conventions is the team's database style guide encoded for a model to consume. A skill that writes meeting notes in the org's preferred structure is the org's meeting-notes template, lifted out of whatever system stores it and re-expressed as instructions a model can follow. The substance of nearly every useful skill is knowledge the community already has, expressed in a form Claude can use.
Once you see this, the question changes. The question is no longer "should our system support Skills." The question is "where does the community's knowledge actually live, and can a model read it from there." If the answer is "in a graph database that the community has been accumulating into for years, with access control and provenance and audit trails baked in," then the answer to the first question is no — the community's knowledge does not need to be re-packaged into folders for Claude to find. The community's knowledge needs to be ingested into the form Claude already knows how to read, and looked up at task time by tools that already exist.
This is what Grokers does. Grokers is the ingest layer in the architecture — a system whose job is to take source material in any form a community happens to use (PDFs, markdown documents, codebases, transcripts, structured data) and produce streams in the substrate's native form. A community's brand book is uploaded; Grokers reads it; structured convention streams emerge. A team's coding standards file is committed; Grokers reads it; the conventions become part of the team's knowledge graph. A SKILL.md authored against a different system arrives; Grokers reads it; what was a skill becomes graph nodes a tool can find via the same retrieval path as anything else the community knows. The form of the source doesn't matter. The destination is uniform.
Safer because the action contract is bounded by the tool, not the skill. More reusable because normalization makes one community's knowledge legible to another. More organizable because the graph is already searchable, accessible, auditable.
This is the part worth being precise about, because it's where the architecture's existing investment pays its largest dividend. In the Skills model, a skill bundles instructions and scripts. The scripts execute in a sandbox. The skill author decides what the scripts do; the sandbox decides what the scripts can do. The user's confidence that the skill behaves safely depends on the sandbox's bounds being correctly drawn and on the user reading or trusting the skill before installing it.
In this architecture, that whole question is collapsed. Tools — the things that actually execute, the things that propose actions and call language models — are first-class registered code, audited at install time, signed with a deterministic hash, gated by a contract judgment that checks every action proposal against the tool's declared bounds. A tool can propose Streams/relate only if its handler entry says so. A tool can write to a particular community's namespace only if its access permits it. A tool calls the language model only if the workflow stage allows it. None of this is convention; all of it is enforced.
Knowledge from the graph — what would, in the Skills model, be the SKILL.md prose — flows into the tool as read-only context. The tool's prompt assembly walks the relevant convention streams and includes them in the system prompt. Those streams cannot expand the tool's action contract. A brand-guidelines stream that says "always send a Slack notification when a customer signs up" does not give the tool the ability to send Slack notifications. The tool either has a declared Streams/relate entry pointing at a Slack-outbound category or it doesn't. The prose in the graph is a knob on intent within the existing surface; it is never a new surface.
Skill prose plus skill scripts together define what runs. The sandbox bounds the scripts. The user audits the prose by reading it.
The tool defines what runs and what actions are allowed. The graph supplies prose context only. The contract judgment audits every action proposal mechanically.
The implication is that adding new convention streams to the graph never expands the system's capability surface. A community can ingest hundreds of convention documents and the only thing that changes is what tools say back. The contract of what they do is stable. This is the property that lets a community trust ingestion. New material arriving in the graph cannot suddenly grant new powers to anything operating against that graph. The audit boundary is at the tool, not at the prose.
The Skills model is essentially per-author. A skill written for one organization carries that organization's vocabulary, that organization's task structure, that organization's specific naming. Reusing it across organizations means cloning and modifying — the skill becomes a starting template, not a shared resource. There is no obvious affordance for two organizations with similar but non-identical brand-voice rules to converge on a shared spine while specializing the differences. There is no obvious affordance for an industry-standard skill to exist that organizations adopt with overrides.
Grokers normalizes across communities. The same Python style conventions, ingested from twenty different teams' style guides, produce convention streams under a uniform structure: Safebots/convention/code/python with a small set of attribute-keyed rules. The teams' source material differs — one wrote a wiki page, another committed a PEP-8-with-overrides document, a third uses inline comments in their codebase — but the normalized form is the same shape across all of them. A team that wants to extend an industry-standard convention publishes their override stream into their own community's graph; the substrate's federation layer makes the upstream convention readable as a fallback.
This is the move that turns conventions from per-organization artifacts into a reusable resource. A widely-followed standard ingested once by one community can be referenced by any other community that wants to inherit it. Specialization happens through additional streams that override or extend, and the graph carries the relationships between them. The substrate already supports this — it is what stream-publisher cascades and access-controlled visibility have always been for. Conventions just become another thing organized through the same machinery as everything else.
A folder full of SKILL.md files is searchable by filename and grep. That is not nothing, but it is meaningfully less than what a graph substrate offers. The substrate has been organizing community knowledge for years through facets, categories, relations, tags, and full-text search across attributes — all of these accessible through a uniform query API. Convention streams enter that API the same way every other stream does. A tool generating customer-facing copy can ask the substrate "what conventions apply to customer-facing text in this community" and receive a ranked, access-filtered, freshness-aware result set. There is no separate index for conventions. There is no special-case retrieval. The same query language that finds project documents finds the project's conventions.
This matters for discoverability, but it matters more for composability. Conventions in the graph have relations to the things they apply to. A brand voice convention can be related to the marketing-content category. A code style convention can be related to a particular language and a particular team's codebase. A naming convention can be related to an ontology. When a tool runs against an artifact, the convention streams that surface are precisely the ones whose relations match the artifact's context — not because the convention's author specified that match, but because the substrate's relation graph encodes it once and uses it everywhere. Two conventions that should compose are visible as composing because they're connected to compatible nodes; two that should not compose are filtered out because they're not.
Conventions live as streams in the community's graph, not as files in a folder. Same primitive as everything else the community stores.
Tools find applicable conventions via standard relation walks. No new index, no special-case lookup.
Conventions are read-only context. The tool's action contract bounds what can happen. Adding conventions to the graph cannot expand capability.
Communities arrive with whatever they already have. Grokers reads it and produces graph streams in the form the rest of the system already knows how to use.
The architecture's third leg, after Safebots and Safebox, is Grokers. Grokers's role in the system is to ingest source material and produce relations — turning a codebase into a graph of symbols and references, turning a corpus of documents into a graph of entities and citations, turning a community's accumulated material into the substrate's native form. This is what makes the graph grow over time. It is also what makes the Skills question dissolve.
A community arrives with a folder of SKILL.md files from previous Anthropic work. Grokers reads them. Each SKILL.md becomes one or more convention streams in the community's graph, normalized into the structure the rest of the system uses. The community's investment in their existing skills is preserved — the source material is not thrown away, the prose the team wrote is intact in the graph — but the form is now one the substrate's tools can use without any bridge or adapter. A second community arrives with a brand book PDF. Grokers reads it and produces convention streams under the same structure. A third community arrives with a wiki of internal style guides. Grokers reads it and the same structure emerges. Three different sources, one consistent form, one retrieval path, one audit boundary.
The normalization step is where Grokers earns its place. It is not just text extraction; it is a principled mapping from a heterogeneous source into a structured stream type. SKILL.md frontmatter becomes attributes; SKILL.md headings become category memberships; SKILL.md prose becomes content. Brand book voice descriptors become structured tone attributes; banned terminology becomes a vocabulary stream; preferred-pattern examples become reference streams the tool can cite. The normalization rules are part of Grokers, versioned and auditable. A community can re-ingest under newer rules to take advantage of finer-grained extraction. The source material stays unchanged. The graph grows richer.
What this gives a community is the ability to keep its existing investments while gaining the substrate's affordances. The team that wrote forty SKILL.md files over two years does not throw them away. They are ingested. They become discoverable through the substrate's search, governable through the substrate's access controls, federatable across the community's network. The team gains audit trails on conventions they did not previously have, version history they did not previously have, ability to fork and override they did not previously have. The work the team already did becomes part of the substrate's accreting library — to use the framing from the companion essay, becomes wisdom in Da'at's vault rather than skills in a folder.
The model is not that Skills are wrong. The model is that Skills are right when the substrate is the user's filesystem, and a different shape is right when the substrate is a graph.
It would be cheap to argue that Anthropic's Skills are inferior to the graph approach in absolute terms. They aren't. The Skills shape exists for reasons that make sense: most users do not have a graph substrate. Most users have a filesystem and a stateless model and a need for the model to behave consistently across many invocations. For that audience, Skills are exactly the right primitive — local, portable, simple to author, simple to inspect. The reading the model takes from a SKILL.md file when triggered is the obvious answer to the obvious problem in that environment.
The argument is comparative and conditional. If a community has invested in a substrate that already holds its knowledge, if that substrate already enforces access and audit and federation and provenance, if there is already an ingest layer producing graph nodes from arbitrary source material, if tools running against that substrate already operate within machine-checked action contracts — then the Skills shape is solving a problem the substrate has already solved. The local folder is redundant with the graph the community already maintains. The instruction-file format is a less-expressive alternative to the structured streams the substrate already supports. The triggering convention is a flatter version of the relation walks the substrate already does. The execution sandbox is a parallel mechanism to the contract judgment that already gates every action.
It is not that Skills are bad. It is that they are duplicative. A community running this architecture and also installing Skills would have two stores of conventions, two retrieval paths, two audit boundaries, two trust models. The simpler answer is one store, one retrieval, one audit, one trust model — the one the community has already chosen by building on this substrate. Ingest the SKILL.md files into the graph. Let the substrate be what it is. Do not stack a second mechanism on top of the first.
There is one case where direct Skills support would earn its place, and it is worth naming. If a community wants to consume Anthropic's evolving library of community-authored Skills directly — pulling from a public skill marketplace, tracking updates, contributing back — then native Skills compatibility becomes the right answer. The cost of ingestion before use is too high if the skills are changing weekly and the community wants to ride the public stream. For that case, the right move is an importer that reads a SKILL.md and produces an in-memory tool wrapper, sidestepping ingest entirely. The wrapper still operates within the architecture's bounded action contract; the imported skill cannot grant capabilities the wrapper doesn't already have. This is a pragmatic accommodation, not an architectural commitment, and it sits cleanly alongside the graph-native approach for everything the community owns itself.
The reason to build on a graph substrate in the first place is that it answers questions about access, audit, history, federation, and accumulation once, in a way that lets every subsequent design decision inherit those answers rather than reinvent them. Knowledge representation is one of those subsequent decisions. The community's brand voice, code conventions, vocabulary, tone — these are not separate from the rest of what the community knows. They are part of it. They should be stored where the rest of it is stored, retrieved how the rest of it is retrieved, governed how the rest of it is governed.
The Skills shape says: knowledge for the model is special. It needs its own folder, its own format, its own retrieval, its own sandbox. The graph approach says: knowledge for the model is just knowledge. It already lives in the graph. The model reads it through the same retrieval path as everything else. There is no special category. There is no separate trust boundary. There is one substrate, accumulating what the community knows, available to be drawn upon by anything operating within the community's audit and access surface.
This is also what makes the architecture safer in a way that matters. The Skills model couples instruction with capability — a skill bundles what the model should do and what scripts should run. Auditing the bundle requires reading both. The graph approach decouples them: the tool is the capability, audited at install time, signed and contract-checked; the graph is the instruction surface, growing freely as the community accumulates knowledge, never expanding what the tool can do. New material in the graph cannot give a tool new powers. The audit boundary stays at the tool. This property — that ingestion is safe-by-construction — is what lets the community trust Grokers to keep growing the graph without running a security review on every new document.
The architectural inversion is worth holding onto. Where the Skills model puts capability inside the knowledge unit, the graph approach puts capability inside the tool and lets knowledge flow freely. Where the Skills model needs an audit boundary at every skill, the graph approach has one audit boundary at the tool registration. Where the Skills model relies on per-skill review, the graph approach makes review unnecessary for prose because prose cannot expand the system's reach. The community ends up with more knowledge in the system, less audit overhead, no new safety surface, and uniform retrieval — and gets there by leaning harder on the substrate it has already built.
The companion essay describes the three faculties. This essay describes a corollary. When a community has invested in a substrate that already does what knowledge needs done — store, retrieve, govern, federate, audit, accumulate — then knowledge for AI is just knowledge. There is no special folder for it. There is no special trust model for it. There is the graph the community has been building all along, and a tool that knows how to read from it.