Claude Skills, Google Gems, and AI Loops Are One Pattern With Five Names

Claude Skills, Google Gems, custom GPTs, Projects, and the autonomous loops are five names for one idea. In every version, a repeatable procedure leaves the live prompt and lands in a file the model reads only when the task calls for it. Anthropic calls that file a Skill, Google calls it a Gem, and a loop calls it a spec that reruns itself on a schedule. Although the vendor names differ, the mechanism does not, and naming it plainly is what lets a solo practitioner judge whether an implementation earns its complexity. Because I run several enterprise clients at once with no one behind me, my real question is narrower than “which vendor’s version is more powerful”: which of these patterns still runs unattended in six months, and which one quietly assumes a company standing behind you.

Anthropic’s own documentation puts the always-loaded cost of an installed Skill at about 100 tokens, which is what lets a whole library of them sit dormant until one actually matches a task.¹

Which of Anthropic’s own internal patterns actually transfer to a team of one?

Some of Anthropic’s internal patterns transfer cleanly. Everything else assumes a company standing behind it, and Anthropic’s own report on how its internal teams use Claude Code sorts into both once read against a team-of-one filter. Across 10 of its own departments, from data infrastructure to legal, Anthropic published what each one actually does with the tool.³

Persisted context files that document a codebase or a workflow, and slash commands built for a task that recurs weekly, transfer directly, since both are cheap to write once and need no coordination to use. Because its codebase is big enough to need internal governance, the Security Engineering team reports using half of all custom slash command implementations in the entire company monorepo.³ A solo operator has no monorepo to govern, and does not need one.

The report’s most useful data point is the team that describes itself the way I would describe myself. Anthropic’s own words for its Growth Marketing group are “a non-technical team of one,” and the workflow it built is a CSV of underperforming ad copy split across two narrow sub-agents, one for headlines and one for descriptions, running in minutes instead of requiring manual work across campaigns.³ Inside a company that also runs Kubernetes debugging sessions and cross-team demo culture, that CSV workflow was the plainest pattern in the whole report, needing no shared infrastructure. My read, and I will label it as inference rather than Anthropic’s own conclusion: the report’s more ambitious patterns work fine when four other engineers can pick up the pieces later, but handing an entire unfamiliar codebase to Claude and shipping the result without personally understanding the code is a different bet. For the only person a client can call, an artifact you cannot debug yourself is a liability wearing a shortcut’s clothes.

What do Claude Skills, Google Gems, and working loops actually have in common?

Claude Skills, Google Gems, and working loops all solve the same problem: a person keeps retyping the same instructions into a fresh conversation, because the model has no memory of the last one. OpenAI’s custom GPTs and Projects follow the same shape: saved instructions plus attached files that outlive a single conversation. Naming aside, what separates them is how each one decides to load, and what happens when it should have loaded and did not.

How does a Claude Skill actually decide to load itself?

A Claude Skill loads in three stages. Claude always reads every installed Skill’s name and description at startup, a combined cost Anthropic puts at roughly 100 tokens per Skill.¹ When a task matches that description, Claude reads the full SKILL.md file, capped by convention at under 5,000 tokens, and only then does procedural detail enter the conversation.¹

Anthropic’s Agent Skills documentation states the idle figure directly, as an approximation covering only the always-loaded metadata layer.

Beyond that, reference files, templates, and scripts load only if the SKILL.md body points to them by name. A script’s own code never enters context at all; Claude runs it and reads back only the output.² Anthropic’s engineering write-up frames the whole thing as an onboarding folder for a new hire: a table of contents up front, fine print read only when a task actually calls for it.² Claude does the triggering itself, matching the task against the stored description with no person choosing anything. Anthropic published Skills as an open standard for cross-platform portability on December 18, 2025, a sign it expects other vendors to converge on roughly this shape.² Custom Skills do not sync across surfaces, though: a Skill installed in Claude Code is invisible to claude.ai and the API, and each has to be set up on its own.¹

Why does a Google Gem need you to pick it, instead of triggering itself?

A Gem is a saved persona you select from a list before you start typing, not a file Gemini matches against your request the way a Claude Skill is. At launch, Google’s own product lead for Gems described the mechanic plainly: a Gem is saved instructions, plus whatever files or context you attach, that you revisit on purpose whenever you want that exact expert back.⁵

You open the Gem manager, choose a premade option like Career Guide or a custom one you built, and every message in that conversation inherits its instructions from that point forward.⁴ Because a Skill’s matching happens inside a judgment call nobody sees, it can silently fail to trigger even when its description looked like an obvious match. A Gem cannot fail that way, since you are looking directly at which one is selected before you send anything. What it can do instead is get forgotten: opening a plain Gemini chat out of habit skips the Gem entirely and still returns a competent-sounding answer, the same shape of silent miss through a different mechanism.

What is a “working loop,” and does it fit the same pattern?

A loop applies the same load-on-demand pattern as Skills and Gems, with the live human removed from the trigger. Without a person reopening a chat and retyping a request, a standing spec re-invokes the agent on a schedule or a condition, and what that spec persists is not domain knowledge so much as the stop condition and the escalation rule: when to keep going, when to hand back to a person.

Boris Cherny, who leads Claude Code at Anthropic, said as much on stage a few days before the term caught on more widely: “I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops,” a quote reported in a newsletter I read but have not independently checked against the original recording.⁶ Peter Steinberger, who built OpenClaw, made the same point about coding agents: “You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”⁶ Both quotes come from the free preview of a paywalled piece, so the deeper mechanics, the anatomy of a loop and the roadmap the newsletter promises, stay unverified here and are not repeated.

Why does whether a skill fired matter more than whether the answer was good?

A missed Skill or Gem trigger is silent in exactly the way a bad answer is not. When a Skill or a Gem should have loaded and did not, the model does not error out or hedge. It answers from general training instead, and that answer often reads as perfectly fine, since a competent model sounds competent even when it skipped the specialized procedure entirely.

Given that, the metric worth tracking is whether the file actually loaded on a task that should have triggered it, measured separately from answer quality, since the two disagree more often than a demo would suggest. For exactly that reason, I instrument this on my own library of Skills, because that is what catches the cases where the right procedure never got read, the exact miss a quality check on the answer alone would let through. The existence of that check and the reasoning behind it are worth reporting, not the specific pass rate or how it's wired, because a number like that is only meaningful against a setup nobody reading this can inspect.

How do you check whether a skill or Gem actually fired on your last response?

Look at the transcript, not the answer. In Claude Code or through the API, a triggered Skill leaves a visible trace, because Anthropic’s own architecture description states that Claude invokes a bash command to read the SKILL.md file directly, and that call sits in your session transcript as an ordinary tool use.²

Load rate is measured on its own evidence, separately from whether the answer read well.

Search your transcript for a file read pointing at a SKILL.md path. If it is not there, the instructions never entered context, regardless of what the description promised. Gemini is simpler to check, because Gems load by selection rather than by matching. Look at which Gem, if any, is shown as active in the side panel before you sent the message; a Gem you did not select cannot have shaped the answer that came back. For a custom GPT or a Project, confirm the named GPT or Project shown at the top of the conversation rather than trusting that the right context was in play. In every case, the honest answer lives in a place you can look, not in how confident the response sounds.