coleam00/skills: Cole Medin's 34 agent skills for the PIV loop

The problem: a 2,000-line CLAUDE.md does not scale

The README states the premise directly: a skill is a folder with a SKILL.md in it, holding a name, a description of when to use it, and the procedure the agent should follow. The agent loads the description at startup and pulls in the full skill only when the work matches. That is the whole design, and it is why the author argues skills scale where a 2,000-line CLAUDE.md does not.

The audience is narrow and specific. These are skills for people who drive a coding agent through a ticket, not for people who want the agent to write a whole product from a prompt. The repository describes them as the AI Layer from the author's Agentic Coding course, and they are built around one loop: prime, plan, implement, validate, review, commit, PR. Around that loop sit the pieces that feed it (PRD, architecture, epic slicing), the pieces that run it in parallel (worktrees), and the meta-skills for building more of your own AI Layer.

The README is explicit that this is not a framework. Each skill is a plain markdown file you can read in two minutes, disagree with, and edit. That framing matters for adoption: there is no runtime, no dependency graph to resolve, and no upgrade path to break. There is also no compatibility guarantee, which is the trade you accept.

How the PIV loop is split across skills

The loop is decomposed rather than monolithic. `piv-plan-implementation` does deep codebase analysis plus research into what the README calls a one-pass-ready implementation plan. `piv-implement` executes that plan task-by-task, validating at every step. `piv-validate` runs the project's full suite and returns one PASS/FAIL verdict. Then `piv-review-changes` performs a pre-commit technical review, `piv-fix-review-findings` triages what came back so you decide what gets fixed now versus deferred, `piv-commit` produces one atomic conventionally-tagged commit, and `piv-create-pr` pushes the branch and opens the PR with a real body.

Two details are worth noting. First, the validation step is deliberately binary: one PASS/FAIL verdict rather than a narrative report. Second, the review and the fix are separate skills, which keeps the decision about what to fix with the human instead of the agent. `piv-run-full-loop` chains the core loop end-to-end from a single feature description, and `piv-review-pr` acts as an agentic gate on an open PR, described as fresh eyes, severity-ranked, posted to GitHub.

Around the loop, the feeding skills are `plan-create-prd` (interviews you into a problem-first PRD, intent and never engineering decisions), `plan-architecture` (a working session on how to build it: stack, data shape, trade-offs, risks), `piv-slice-epic` (slices an epic plus its architecture into PIV-sized tickets with a dependency graph), and `plan-create-stories` (turns a PRD into a backlog in Jira or GitHub). The prime skills load context: `prime-codebase`, `prime-backend` scoped to API routes, services and the data layer, and `prime-frontend` scoped to components, routing, state and styling.

Installing the plugin and running a first skill in Claude Code

The README calls the plugin route the easiest and the one that stays updated. Run these two commands inside Claude Code:

/plugin marketplace add coleam00/skills
/plugin install skills@cole-medin

After that the skills are managed and read-only, and the README states that `/plugin marketplace update` pulls new ones as they are added. Plugin skills are namespaced, so you invoke them as `/skills:piv-implement`. The README notes the whole set costs roughly 4,400 tokens of always-on context, counting only the descriptions, since bodies load only when a skill fires. To see the per-skill breakdown, run `claude plugin details skills`, and the plugin can be disabled at any time with `/plugin`.

There is a documented failure mode on the first command. If it fails with `Permission denied (publickey)`, the `owner/repo` shorthand prefers SSH and your key is not authenticating to GitHub. The README says recent Claude Code versions detect that and fall back to HTTPS on their own; if yours does not, pass the HTTPS URL directly, which needs no key:

/plugin marketplace add https://github.com/coleam00/skills.git

Setting `CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1` in your environment makes the shorthand use HTTPS permanently, according to the README. If you would rather own the files, install them with the skills CLI. Listing first is the safer habit, because it shows you what is in the repository before anything is written into your project:

npx skills add coleam00/skills --list
npx skills add coleam00/skills --skill piv-plan-implementation piv-implement piv-validate

Adding `-g` installs globally into `~/.claude/skills/` instead of into the current project. This route writes real files into your repository, so you can edit them, which the README says is what the author would actually recommend once you know which ones you keep reaching for. For the last two routes, restart your session or run `/skills` and the skills will show up.

The meta-skills are the part worth arguing about

Most of the 34 skills execute work. Nine of them instead maintain the AI Layer itself, and that is where the repository has a distinct point of view. `rules-create-global` derives a lean root `CLAUDE.md` from your codebase or your specs, described as the customizable `/init`. `rules-check-drift` checks whether your rules file is still true after recent changes. `ablate-ai-layer` tests whether your rules still earn their place: it strips them, reruns the same task, and diffs the two. `skills-create` authors a new skill or refactors a fat one into `SKILL.md` plus a `references/` directory. `hooks-create` turns a rule like never let the agent touch my migrations into a working hook wired into settings. `opportunity-scan` reads how you actually work and recommends what to encode next. `system-execution-report` reflects on a just-finished implementation and reports what diverged from the plan. `system-evolution-review` looks for bugs in your process rather than your code. `second-brain-audit` finds facts in your notes that quietly stopped being true and restructures so they stop.

The ablation skill is the strongest idea here. Instruction files tend to accumulate because nobody measures whether a given rule changes the output. Stripping the rules and rerunning the same task is a crude experiment, but it is a real one, and it produces a diff rather than an opinion. The drift check is the natural companion: a rules file that was accurate in March can be actively misleading in September, and nothing in most setups notices.

The counterargument is equally clear. These skills assume you have a rules file, notes, and a stable enough workflow that measuring drift is meaningful. On a two-week prototype, running an ablation is overhead with no payoff.

Parallel work with worktrees, and the dark factory

Two skills handle parallel work. `worktree-create` spins up N git worktrees, each configured, installed, and health-checked. `worktree-merge` integrates those branches through one safe integration branch. The health-check step in the create skill is the notable part: a worktree that has not had its dependencies installed is a trap that surfaces much later as a confusing failure.

The autonomy end is a single skill called `build-dark-factory`. The README describes it as taking a PRD and building a repo around it that ships validated code with nobody at the keyboard: all five components, in construction order, plus a deterministic audit of what you built. Two constraints are stated plainly. It encodes the AI coding process you already run rather than replacing it, and it deliberately does not write the PRD. You bring one, or make one with `plan-create-prd` first.

That refusal is a design decision worth respecting. The PRD is where intent lives, and the skill declines to invent it. Note also that the README does not describe what the five components are, nor what the deterministic audit checks. If you are evaluating the autonomy path specifically, that gap is the first thing to read the skill file for.

Limits: agent lock-in, context cost, and a README that stops early

The most concrete limitation is compatibility. The plugin route is Claude Code specific, and the README's own instructions assume that agent: the `/plugin` commands, the namespaced invocation, and `claude plugin details skills` all belong to it. The file route is broader, and the README says the editable installs work in any agent, but it does not state which agents load a SKILL.md folder or what they do when they do not. That is a question the README leaves open, and it is the first thing to verify for your own setup.

The second constraint is the always-on cost. Roughly 4,400 tokens of descriptions load at startup whether or not you use a skill that session. That is the price of the design, and it only pays off if you actually run the loop. Someone who occasionally asks an agent to rename a variable is carrying a lot of description text for nothing. The README offers `claude plugin details skills` and the ability to disable the plugin, which is the mitigation, but the default is all 34.

The third issue is documentation completeness. The README is truncated where the tools section begins with `agent-browser`, so any skill listed after that point is not described. There is also no changelog and no releases retrieved, so the only maintenance signal is the last push, which was on 2026-09-15. That is recent, and the repository is not archived, but a recent push is not a compatibility guarantee for an agent that ships changes on its own schedule.

Finally, the skills encode one person's process. The commit skill produces one atomic conventionally-tagged commit, and `piv-fix-review-findings` hands the triage decision back to you. If your team squashes differently, or reviews before validating, you will be editing these files, which the README anticipates and encourages.

Alternatives: a rules file, or a framework

The nearest alternative is the one the README argues against: a single long `CLAUDE.md` or equivalent rules file at the repository root. The difference is loading behavior, not content. A rules file is always in context in full, so every token is paid on every request, and it grows until someone prunes it. A skill directory keeps only the description resident and loads the body on match. That is why the README claims skills scale where a 2,000-line rules file does not. The cost of the skill approach is indirection: you cannot see the procedure in your context window unless the skill fires, so a skill that matches the wrong situations is harder to notice.

The other alternative is a framework that owns the whole loop with a stable interface. This repository explicitly is not that. The README says nothing here is a framework, and that each skill is a plain markdown file you can read in two minutes, disagree with, and edit. A framework gives you versioned behavior and someone else handling the breakage. Markdown files give you total editability and no compatibility promise at all. Which one you want depends on whether your process is settled or still moving.

Within the same family, the meta-skills overlap with tooling that generates or lints instruction files. The distinguishing feature here is the ablation test: stripping the rules and rerunning the same task to see whether the rules changed anything. That is a measurement, not a generator, and few instruction-file tools attempt it.

Editorial conclusion

Adopt this if you run a coding agent on real tickets and want the plan and validation steps written down as files you can edit, rather than as a chat habit. Skip it if you want a framework with a stable API, or if your agent cannot load a SKILL.md folder at all. Before committing, verify three things: that your agent supports skills, that roughly 4,400 tokens of always-on descriptions is acceptable in your context budget, and that the individual skills match how your team actually reviews and commits code. The `npx skills add coleam00/skills --list` command shows what is there before anything is written into your repository.

Frequently asked questions

Official sources

1. coleam00/skills on GitHub
2. Issues
3. License: MIT
4. README