Teach

Teach this collection to someone else

What to explain, in what order, and session plans you can run as they are.

Start with what a skill is

A skill is a folder with a SKILL.md in it: written instructions the agent follows for a particular kind of work. It is plain text, so anyone can read it, change it or write one. Here is the outline of one from this hub, shortened:

---
name: skill-writer
description: Guide users through creating Agent Skills for Claude Code.
  Use when the user wants to create, write, author, or design a new Skill...
---

# Skill Writer

## When to use this Skill
## Instructions
### Step 1: Determine Skill scope
...

Two points carry most of the explanation:

The description is the trigger. The agent reads it to decide whether to load the rest, so that is where a skill most often succeeds or fails.
The body is a process, not a persona. It gives steps to follow and says what counts as done.

Then the collections

Collection	Skills	Character
Personal decloudz	1	Skills I wrote myself.
Agent Skills Addy Osmani	25	Production-grade workflows and quality gates across the whole lifecycle, from spec to ship.
Skills for Real Engineers Matt Pocock	31	Small, composable skills: grilling, spec and ticket flows, TDD, domain modelling, code review.
pstack Lauren Tan	58	Rigorous agent workflows and engineering principles: go deep first, write less, verify more.

Which one do I use?

This is the question people ask first, because collections overlap. Here are three common cases:

Tests first

/addy:test-driven-development	Any logic, bug fix or behavior change.
/pocock:tdd	Building test-first, with guidance on which tests are worth keeping.
/pstack:tdd	Only when asked for, or when the bug has an obvious, cheap test target.

Being questioned about a plan

/addy:interview-me	The ask is underspecified and you need to find out what is really wanted.
/pocock:grill-me	You have a plan or design and want it stress-tested.
/pocock:grill-with-docs	The same interview, also writing ADRs and a glossary as it goes.

Reviewing a change

/addy:code-review-and-quality	A general multi-axis review before merging.
/pocock:code-review	Checking against your repo standards and the originating spec.
/pstack:interrogate	Adversarial: only findings proven by a run survive.