Using Skills

Skills are reusable workflows Claude can apply when a task matches them well. They are useful because they package a pattern without forcing the team to memorize that pattern every time.

This tutorial is meant to make skills feel normal before you ever try to standardize them in the repo.

1. See what skills are available

Run:

/skills

What you should see: the skills or skill namespaces currently available in your environment.

If your environment has very few skills, that is fine. This tutorial still matters because it teaches how to think about them.

2. Ask Claude to match the task to a skill

Prompt:

We need to add a small validation change.
If there is a relevant skill for this, use it.
If not, tell me that directly and continue with the normal workflow.

What you should see: Claude either uses a relevant skill or tells you no good skill applies.

3. Be explicit when you want to test the behavior

Prompt:

Use the most relevant available skill for a verification-first implementation and explain why it fits this task.

What you should see: Claude names the skill or the workflow pattern it is using instead of hiding the choice.

4. Notice the difference between helpful and noisy skills

Ask yourself:

• Did the skill make the task clearer?
• Did it reduce repeated prompting?
• Did it add a workflow the team already believes in?

If the answer is no, the skill probably should not become shared project configuration yet.

5. Decide when a skill belongs in the repo

A skill is ready for the repo when:

• the team already repeats the workflow successfully
• the skill saves prompt overhead
• the behavior is simple enough to explain in plain English

If it is still experimental, keep it personal for now.

Advanced: Match the Starter Files

The starter project ships one explicit shared skill: test-forward.

---
name: test-forward
description: Verification-first development for any feature, bug fix, or behavior change.
autoInvoke: true
globs: ["**"]
---

# Test-Forward Development

You are in verification-first mode.

## Process
1. **Define** the behavior being changed in one sentence.
2. **Create** the smallest failing verification artifact:
   - Backend: failing unit or integration test
   - Frontend: failing E2E, screenshot test, or repro script
   - Ops/config: failing smoke command or health check
3. **Run** the verification and confirm RED (failure).
4. **Record** the RED state:
   `echo '{"red":true,"time":"'$(date -Iseconds)'"}' > .claude/state/test-forward.json`
5. **Implement** the minimal production code change.
6. **Run** verification again and confirm GREEN (pass).
7. **Review** with /simplify or manual code review.
8. **Gate** by running the project's full gate command.

## Refusals
- Do NOT write production behavior-changing code before RED exists.
- Do NOT claim something works unless verification command output supports it.
- Do NOT skip the RED recording step.

## Exceptions
- Pure refactors with no behavior change: existing tests serve as verification.
- Documentation-only changes: no test required.
- Test infrastructure setup: no test-for-the-test required.

This is the workflow memory the starter project shares across the repo:

• CLAUDE.md states the policy.
• test-forward teaches the actual process.
• .claude/state/test-forward.json records the RED token.
• require-test-first.sh checks that token before source edits.
• the Stop gate makes sure Claude cannot declare success while the final repo gate is still failing.

Skills and hooks are different:

• skills teach and reinforce process
• hooks enforce specific lifecycle events

The starter project uses both because the six-step loop needs both.

What to repeat in real work

/skills

Prompt:

If there is a relevant skill for this task, use it and explain why. Otherwise continue normally.

Next step

Continue with Using MCP Tools if the repo needs external tool access, or jump to Your First Hook if the next lesson you need is repo-level automation.