daymade/claude-code-skills: a plugin marketplace for Claude Code skills

What daymade/claude-code-skills is for

Claude Code skills are folders of instructions and scripts that the agent loads on demand. The awkward part is distribution: you either copy a folder into the right place yourself or you rebuild it from a blog post. This repository turns that into a plugin marketplace. The README describes it as a "professional Claude Code skills marketplace featuring production-ready skills for enhanced development workflows," and the top-level directory listing backs that up with roughly fifty skill folders, including daymade-docs, git-safety-net, llm-eval-harness, promptfoo-evaluation, fact-checker and github-review-pr.

The audience is narrow and specific. You need Claude Code installed, and you need to be comfortable with slash commands or the claude CLI. The repository is written in Python, licensed MIT, and its most recent push was on 2026-06-13, which is the same date as the v1.64.0 release. That is more than six months before today, so treat this as a project whose last recorded activity is that push, not as something under continuous development.

The centerpiece is not a single skill but skill-creator, a fork of Anthropic's official skill-creator. The README frames the difference bluntly: the official version tells you what to build, while this fork also tells you what not to try and why. That framing matters because the rest of the repository is downstream of it. If you only want a document converter, you are paying the complexity cost of a marketplace for one folder.

How the marketplace and skill-creator actually work

A marketplace in Claude Code is a JSON manifest that maps plugin names to repositories. Here the manifest is marketplace.json, and it declares the marketplace name as daymade-skills. That name is the one you use in install commands. The README warns explicitly that using the repository path as a marketplace name, for example @daymade/claude-code-skills, will fail. This is a real failure mode rather than a documentation quirk: the manifest name and the GitHub path diverge, and the error you get is not obviously about naming.

Plugins group skills. The daymade-skill suite carries skill-creator, and daymade-docs is described as a shared namespace for document workflows, exposing skills such as /daymade-docs:doc-to-mark. So the install unit is a plugin, and the invocation unit is a namespaced skill. That two-level structure is what lets the repository hold dozens of skills without every name colliding.

Inside skill-creator, the README lists a set of mechanisms that go beyond prose instructions: an ordered search protocol with an Adopt / Extend / Build decision matrix, structured AskUserQuestion checkpoints, an inline versus fork architecture guide, a structural validator, a security_scan.py script with gitleaks integration as a hard gate before packaging, and concurrency handling for multiple sessions editing one skill repo (git-ref baselines, re-read-before-write, a HEAD check before commit, own-paths-only staging). The concurrency list is the most interesting part, because it implies the authors hit those problems while building skills in parallel. The README also separates risk tier from evaluation spend, so paired benchmarks require explicit authorization rather than running by default.

Installing it and running your first skill

There are three documented install paths. Inside Claude Code, the marketplace is added with a slash command. The README gives this exact form, after which you select Browse and install plugins, then the marketplace, then the plugin, then Install now.

/plugin marketplace add daymade/claude-code-skills

From a terminal, the equivalent uses the claude CLI. The README notes the marketplace name comes from marketplace.json and is daymade-skills, so the install target is daymade-skill@daymade-skills.

claude plugin marketplace add https://github.com/daymade/claude-code-skills
claude plugin install daymade-skill@daymade-skills

There is also an automated script for macOS and Linux that pipes install.sh into bash, and a PowerShell equivalent for Windows. Piping a remote script into a shell is a decision you should make deliberately, since it runs whatever the branch currently contains.

curl -fsSL https://raw.githubusercontent.com/daymade/claude-code-skills/main/scripts/install.sh | bash

Once skill-creator is installed, the README shows the interaction pattern as plain requests to Claude Code rather than CLI flags. You ask for a skill to be created, validated or packaged, and the skill drives the process.

"Create a new skill called my-awesome-skill in ~/my-skills"
"Validate my skill at ~/my-skills/my-awesome-skill"
"Package my skill at ~/my-skills/my-awesome-skill for distribution"

For the documentation suite, the install target changes to daymade-docs@daymade-skills, and the skills are then invoked under that namespace, for example /daymade-docs:doc-to-mark.

The fork collision problem and the supersede kit

The README addresses a situation most skill collections ignore: installing this fork alongside Anthropic's official skill-creator. The two descriptions are near-identical, so trigger selection is a coin flip. The repository's answer is to detect the clash on trigger and offer a one-command, reversible SessionStart routing hook. That hook is only ever installed when both coexist, and the official plugin stays usable by explicit request.

The same machinery generalizes. generate_supersede_kit.py stamps the conditional routing kit into your own skill when it collides with an installed plugin, and the README pairs it with a measured precedence decision guide: rename first, then a description tiebreaker, then the hook, then disabling. Presenting that as an ordered ladder rather than a single fix is the honest framing, because renaming is cheap and a routing hook is not.

The trade-off is transparency versus magic. A SessionStart hook that rewrites routing is invisible at the moment you use it. If you are debugging why a request landed on the wrong skill, you need to know the hook exists. The README documents it, but nothing in the skill invocation output necessarily reminds you.

Where this repository is the wrong choice

The install surface is entirely Claude Code's plugin system. There is no standalone binary, no library you import, and no server. If your team runs a different agent runtime, or if you want skills consumed by a CI job without Claude Code present, this marketplace does not give you a path. The search results around installing skills in opencode or in VS Code point at the same gap: the README documents in-app slash commands and the claude CLI, and nothing else.

The security gate is another constraint. security_scan.py uses gitleaks and acts as a hard gate before packaging. That means packaging fails when the scan fails, and it means gitleaks has to be available in your environment. For a personal skill that only reads local files, a hard gate is friction. The repository treats that friction as the point, which is defensible for shared skills and annoying for throwaway ones.

Finally, the breadth is a cost. Around fifty top-level skill folders with overlapping concerns, several of them tied to specific services, means the marketplace is a catalog you search rather than a curated set you adopt wholesale. The README's own structure reflects this: it leads with skill-creator and pushes everything else into an "Other Available Skills" section.

How it compares to Anthropic's official skill-creator

The direct alternative is the upstream project this fork is based on, Anthropic's official skill-creator in the anthropics/skills repository. The difference is scope of guidance, not capability. Upstream, per the README's comparison table, tells you to check available MCPs before building and performs a basic YAML check on validation. This fork replaces the first with an ordered search protocol and an Adopt / Extend / Build decision matrix, and the second with an expanded structural validator plus a provenance-checked old-versus-new capability audit.

Two additions have no upstream counterpart at all. The first is security tooling: upstream has no scanner, this fork gates packaging on security_scan.py. The second is distillation of past conversations and approved artifacts into skill behavior, with an explicit local manifest, a message-level time window, redaction, opaque source IDs, an ignored .enrich/ staging directory, and manual promotion into references/scripts. The artifact path adds a script-measured pattern extraction step with a three-artifact threshold and an invariant-versus-register boundary.

If you only need to scaffold a skill folder and a SKILL.md, upstream is smaller and has no hook machinery to reason about. If you need the failure patterns, the security gate and the concurrency rules, the fork is the one that documents them.

Maintenance, licensing and upgrade cost

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the plain reading of the identifier in the README badge and the LICENSE file at the repository root; it is not legal advice, and if you redistribute the skills inside a product you should read the file itself.

The maintenance picture is bounded by two facts. The repository is not archived, and the last push was on 2026-06-13, more than six months before today. The release history shows v1.64.0 on that same date, v1.60.1 on 2026-06-04 with the note "Harden macos-cleaner safety," and pdf-creator v1.3.1 on 2026-04-10. Those dates cluster in the first half of 2026.

Upgrade cost depends on which plugin you installed. The daymade-skill suite and the daymade-docs suite version independently, and the version numbers in the release list are not uniform: a suite release and a single-skill release use different schemes. If you build your own skill on top of skill-creator, the concurrency rules in the README (one bump per outcome, own-paths-only staging, a HEAD check before commit) are the ones that determine whether your next pull is clean.

Editorial conclusion

Adopt it if you already run Claude Code and want skills installed through the plugin mechanism rather than copied by hand, and if you intend to build your own skills on top of a documented methodology. Skip it if you do not use Claude Code, since every install path goes through the plugin system. Before committing, read the SKILL.md for the specific skill you plan to use, confirm the marketplace name daymade-skills in marketplace.json, and check that the security_scan.py gate and its gitleaks dependency fit your environment.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes