How these repositories actually fit into Claude Code.

Skill-authoring tools transform a source—such as a design system, book, specification, or workflow—into one or more agent-ready skill packages. The generator is not itself the skill you ultimately install.

This distinction separates a one-time authoring workflow from persistent runtime context. It also makes review possible before generated instructions become part of every matching Claude Code task.

Run the authoring tool separately, inspect its generated `SKILL.md` content and triggers, then copy only the approved output into user or project skill scope.

Catalogs and reading lists are discovery indexes. They collect links to skills, plugins, MCP servers, prompts, examples, or other repositories but do not provide all of those capabilities themselves.

A useful catalog accelerates research, yet its inclusion of a project is not proof that the project is maintained, compatible, secure, or appropriate for your stack.

Browse the index, open the original repository and its primary documentation, then evaluate and install an individual item separately if it passes your requirements.

External CLIs and libraries are utilities used alongside a coding agent. They prepare inputs, package repositories, retrieve documents, or perform work without becoming a persistent Claude Code extension.

They can be valuable precisely because they remain independent: you decide when to run them and what output to share, without adding another always-available trigger or tool surface.

Install and run the utility through its own command-line or library workflow, then pass its output, files, or references to Claude Code when useful.

Infrastructure sits between clients and model providers. A gateway or router can centralize provider selection, model routing, fallbacks, observability, privacy rules, and cost controls.

It changes how requests reach models rather than how Claude Code reasons about a task. That makes it an operational dependency and trust boundary, not a skill, hook, or plugin.

Run the service locally or deploy it separately, then configure supported clients to use its endpoint and authentication instead of connecting directly to each model provider.

Desktop GUIs wrap Claude Code with a visual interface for sessions, projects, agents, terminals, files, or task boards. They sit around the host rather than installing a new capability inside it.

A wrapper can make work easier to see and manage, but it changes the interaction layer—not the underlying extension mechanism. Running several wrappers rarely produces additive capability.

Install and launch the separate desktop application, grant the local access it requires, and point it at Claude Code or its session and project data.

Standalone applications are complete products, platforms, models, or workflows with their own runtime and purpose. They may be built with, called by, or discussed with Claude Code, but they are not Claude Code extensions.

Keeping them separate prevents an inflated extension count and clarifies architecture. A backend platform, automation server, deployment platform, or video system is usually a project dependency or destination.

Deploy or run the application independently. Connect it to an agent only through a documented API, CLI, MCP server, SDK, or project workflow when such an integration exists.

Dead or archived repositories remain in the catalog as historical evidence, redirects, or migration references. They are not current installation candidates.

Preserving the record prevents broken provenance and helps explain older recommendations, while the explicit status keeps an obsolete project out of a new stack.

Follow an official successor or migration path when the archived repository documents one. Otherwise treat the repository as read-only reference material.