Claude Code Artifacts

Overview

Claude Code Artifacts is a public, MIT-licensed library of reusable Claude Code artifacts — environment configurations, skills, rules, hooks, agents, and slash commands — where every entry is a self-contained building block that drops into any Claude Code setup. The full source is on GitHub, organized as a catalog by artifact type rather than as one monolithic framework: a reader meets the actual, useful pieces first, then learns how to consume them, and takes only the ones they need.

Each artifact is a plain file addressable by its raw URL, and it is designed to work on its own, with no assumption about the environment it lands in — so however you choose to install one, it behaves the same. One question decides what earns a place in the catalog: could someone install this file alone and get value from it? Anything that only makes sense wired into something larger — a shared helper module, a bundled runtime file — is described inside the entry of the artifact it serves rather than listed as a thing to install, and a category shows up in the catalog only once it holds something real.

The Problem

Claude Code is powerful precisely because it is extensible: you can add skills, hooks, rules, subagents, and slash commands, and describe whole environments declaratively. What it does not do — and is not meant to do — is ship every convenience out of the box. It hands you the extension points and leaves the extensions themselves to you.

So everyone ends up rebuilding the same small, universal pieces. A hook that pings you when the agent goes idle and is waiting for input. A richer status line that shows the model, the branch, and how close the session is to filling its context window. A skill that captures, once and properly, how to drive a multi-agent workflow instead of hand-rolling one from memory every time. A ready-made setup that gives the agent real code intelligence — semantic navigation over a language server instead of grepping for a symbol — without a day of wiring to get there. None of these is exotic; all of them are the kind of thing you solve once, privately, and then leave trapped in your own dotfiles — where the next person who hits the same wall can neither find it nor reuse it.

The missing thing was never extensibility. It was a shared, vetted, genuinely drop-in library of those universal pieces — extensions written to belong to no single environment, so anyone can install one and have it simply work.

The Solution

Claude Code Artifacts is that library. It is a catalog grouped by the kind of thing Claude Code lets you extend — environment configurations, skills, rules, hooks, agents, and slash commands — and it fills in with real, usable artifacts as they prove themselves, never with empty placeholders. The published entries run from whole pre-assembled setups down to single files that do one thing well.

Environment configurations are the pre-assembled tier: a single YAML that declares a complete setup — artifacts, MCP servers, settings, dependencies — and stands the whole capability up in one command.

• serena.yaml gives any Claude Code install IDE-grade code intelligence. It registers the Serena MCP server in a curated mode that exposes only the language-server-backed tools — semantic symbol navigation, LSP diagnostics, and symbol-aware editing — and leaves the server's own file I/O, shell, memory, onboarding, and dashboard tools switched off, because a tool server that duplicates the host's capabilities does not add intelligence; it adds ambiguity about which tool to reach for. For the same reason it blanks Serena's own system prompt, so the host application keeps sole authority over how the agent behaves. The rest of the configuration exists to make those tools the ones the agent actually reaches for, which is not a matter of writing the rule down once: a bundled tool-selection skill carries the routing protocol — when a symbol lookup beats a text search, where the language server itself falls short, and which searches need a cross-validating grep to catch what its reference search misses — and two steering tiers sit on the same search event. The deterministic tier is fast, advisory, and never blocks; it lets the search run and injects a nudge toward the semantic tool. Above it an LLM gate does deny, but only when three signals line up at once: a definition-site search pattern, a code file extension, and an identifiable symbol name. Everything else is allowed, explicitly including the cases where the gate is unsure, because a steering mechanism that strands the agent when it misjudges is worse than no steering at all. The deterministic tier is just as deliberate about staying quiet on bare-symbol searches, since those are exactly the cross-validating greps the skill asks for. The skill, both hooks, and the Serena runtime files travel with the configuration and are installed by it, which is what makes the whole thing one command rather than a checklist.

Skills carry the protocols an agent should follow rather than rediscover.

• dynamic-workflow-patterns codifies how to run Claude Code's dynamic multi-agent workflows well: which of the workflow patterns fits a task, which agent roles to combine, which model to route to each role, how large to cut a single agent's unit of work, and how to keep a run alive and inside its token budget across the several distinct ways one can fail. The six patterns it catalogs come from Anthropic's write-up "A harness for every task" — classify-and-act, fan-out-and-synthesize, adversarial verification, generate-and-filter, tournament, and loop until done — and what the skill adds is the reasoning for choosing among them: the shape follows from the failure mode a run has to defend against, so it diagnoses the threat first. One of those failure modes is a model favoring its own output when asked to verify or judge it, which is why verification never returns to the agent that produced the work — a refuter is prompted to disprove, so a claim that survives means evidence rather than agreement, and a tournament's pairwise comparisons go to fresh judges that never grade their own attempt, comparative judgment being more reliable than absolute scoring. Sizing gets as much attention as shape, because what goes wrong in a wide fan-out is usually a badly cut unit of work rather than a weak model: the mechanical joins and correlations stay in the script, where they are exact and instant, and only the judgment goes to an agent; work splits along the data's own structure rather than into equal counts; and both the exploration budget and the length of the answer belong in the prompt, since an unbounded answer is its own way of never finishing. Failure gets the same discrimination — an agent that returns an error is not an agent that has gone silent, and neither is a model tier the session's settings will not accept, which fails instantly and identically on every attempt and so is rerouted rather than retried — and recovery starts with a diagnosis: a run that died early is replayed from its cache, while a run that died late is harvested, its finished results read straight out of the run's journal rather than paid for twice. The same role vocabulary covers lightweight evaluation runs: parallel attempts in isolated worktrees, each confirming it is really looking at the commit it was meant to, then comparison agents grading the outputs against a fixed rubric. It is the difference between reaching for the right workflow shape deliberately and improvising one under pressure.

Hooks are the small runtime pieces that shape a session while it runs.

• status_line.py is the operational readout of a long agent session: model, project, git branch with protected branches flagged, session id, added and removed line counts, how much of the context window is consumed and colored as auto-compaction approaches, the reasoning-effort level, rate-limit usage, and an update indicator. Block order, visibility, color, and weight are all configurable, and a block appears only when it is enabled and has something to say.
• idle_notification.py sends a desktop notification when Claude Code needs you — waiting on your input by default, and optionally when it hits a permission prompt, opens an elicitation dialog, or finishes a run — so you can step away from a long run and be pulled back at the right moment. It falls back gracefully across notification backends per platform.

The design rule that keeps every one of these reusable is that an artifact ships behavior, not environment assumptions. The hooks all read their optional configuration through one shared loader, so they run with or without a config file and never presume a particular setup around them, and a companion helper emits the documented hook JSON schemas wherever one of them has to answer Claude Code in a structured form. Skills are progressively disclosed, so they cost nothing until they are actually needed. An environment configuration brings along the third-party runtime files it depends on and its own post-install notes, so "one command" means one command. That is what lets a single file live in many unrelated Claude Code setups and behave correctly in every one of them.

Using an Artifact

Because every artifact is just a file at a raw GitHub URL, installing one is deliberately low-ceremony. The path I reach for most is Claude Code Toolbox: a single environment YAML lists the artifacts I want — by raw URL, or by a shared base URL plus relative paths — and one command sets up Claude Code and everything the config references on Windows, macOS, or Linux. Re-running that command later picks up any change to the hosted artifact, so updates propagate instead of drifting. When I only want one piece and no environment around it, copying the file into ~/.claude/ directly works just as well.

The larger artifacts get routes that match their shape. A skill installs through the skills CLI from a configuration's dependency block, which resolves whatever the skill directory contains instead of making you hand-list its files — hand-listing is the simple route, and it stops scaling the moment a skill grows past one file. An environment configuration can be installed as it stands or composed into your own with inherit, so you can take the Serena setup wholesale or fold it into a larger environment you maintain yourself. Because artifacts can include executable hooks and setup commands, the repository's own guidance is worth heeding: review an artifact before you install it.

Proven First, Then Generalized

The artifacts here are not hypothetical conveniences — they are the ones I run every day, and my own hardened agentic environment, AEGIS, consumes them straight from this library. A real, demanding setup is what puts the reusability promise to the test: an artifact that quietly depended on its home environment would break the first time I dropped it in somewhere else, and I would feel it immediately.

But nothing in the library assumes AEGIS, or any other environment. Generalization is a step an artifact goes through before it is published, not a hope: whatever was specific to the setup it grew in comes out, every configuration read gets a working default so the file behaves with no config file at all, and the documentation is rewritten to stand on its own rather than to be read alongside a larger system. The version that lands here is the universal one. The library is a collection of building blocks for the whole Claude Code community, not a private toolkit wearing a public badge; that any given piece also happens to serve my own environment is a consequence of the universality, not a limit on it.

My Role

I design, build, and maintain Claude Code Artifacts end-to-end as a solo open-source project — the catalog structure and per-type conventions, each environment configuration, skill, and hook, the shared helpers they depend on, the quality gate, and the documentation that lets a stranger install any piece with confidence. The gate is deliberately strict for a specific reason: these files execute on other people's machines. Every hook script clears a stack of linters and type checkers before it lands, skill and agent Markdown is checked for balanced semantic tags, and every environment configuration is validated against a schema on each pull request. It is the same reasoning behind the private-disclosure security policy and the standing advice to read an artifact before installing it. The catalog is held to the same bar — adding, renaming, or removing an artifact and updating its catalog entry is one change, never a code change now and a documentation fix later. It lives on my personal GitHub under an MIT license, and I accept issues and contributions from the wider Claude Code community.

It grows out of the same open-source instinct behind Claude Code Toolbox, the installer that delivers these artifacts, and my Hugo work on Hugo Artifacts: build the missing primitive once, build it to be genuinely reusable, and give it back rather than rebuilding it in every project. If a drop-in Claude Code extension sounds useful for your own setup — or you want to talk through the design — the contact page is the best way to reach me.