You learned what skills are in Chapter 4. Now you build them.
This is a hands-on lesson. By the end, you will have 3-5 skills tailored to your actual workflow — not generic templates, but skills built from how you actually work.
The three skills every project needs
Regardless of your stack, your language, or your team size, these three workflows show up in every project. They are the right place to start.
Skill 1: Deploy
The pre-deployment checklist. Every step you run before pushing to production, captured so Claude never skips one.
---
name: deploy
description: Pre-deployment checklist and production verification
---
## Pre-deploy checklist
1. Run `pnpm build` — must pass with zero errors
2. Run `pnpm lint` — no warnings allowed
3. Run `pnpm test:e2e` — all tests must pass
4. Check for console.log in modified files: `git diff main --name-only | xargs grep -l 'console.log' || echo "Clean"`
5. Verify environment variables are set for production
6. Run `git diff main...HEAD` — review all changes with the user
7. Confirm with user before pushing
## If any step fails
Stop. Fix the issue. Do not skip steps. Do not push with known failures.Notice: every step is an action. "Run X" or "Check Y" or "Verify Z." Not "consider running" or "you might want to." Skills are instructions, not suggestions.
Skill 2: Review
Your code review workflow. What to check, in what order, and how to report findings.
---
name: review
description: Code review workflow with severity levels and structured output
---
## Review process
1. Read the full diff: `git diff main...HEAD`
2. Check each file against these criteria:
### Critical (must fix before merge)
- Security issues (exposed secrets, SQL injection, XSS)
- Broken imports or missing dependencies
- Runtime errors or unhandled exceptions
- Data loss risk
### Warning (should fix, discuss with author)
- Missing error handling
- Performance concerns (N+1 queries, unnecessary re-renders)
- Missing TypeScript types or any usage
- Convention violations from CLAUDE.md
### Suggestion (nice to have)
- Code style improvements
- Naming clarity
- Documentation gaps
3. Output a structured review with severity labels
4. If critical issues found, do not approveSkill 3: Commit
The commit workflow. Stage, message, verify, commit. Simple enough to skip — important enough not to.
---
name: commit
description: Stage changes, generate commit message, verify, and commit
---
## Commit workflow
1. Run `git status` to see all changes
2. Run `git diff` to review what will be committed
3. Stage relevant files (prefer specific files over `git add .`)
4. Generate a commit message:
- First line: type + short description (under 72 chars)
- Types: feat, fix, refactor, docs, test, chore
- Body: explain WHY, not WHAT (the diff shows what)
5. Run `pnpm lint` on staged files
6. Run `pnpm build` to verify nothing is broken
7. Create the commit
8. Show the commit hash and summary to the userAdvanced skills for your stack
Once you have the basics, add skills specific to your stack. Here are two patterns I use daily.
Skill 4: Migration
Database migrations are dangerous. One wrong migration can corrupt production data. This skill turns a risky manual process into a guided checklist.
---
name: migration
description: Database migration workflow for Supabase with safety checks
---
## Migration workflow
1. Create migration file: `supabase/migrations/YYYYMMDD_description.sql`
2. Write the SQL — include both UP logic and a comment with DOWN logic
3. Check for destructive operations:
- DROP TABLE / DROP COLUMN — requires explicit user confirmation
- ALTER TYPE — may need data migration first
- DELETE / TRUNCATE — never in migrations
4. Test locally: `supabase db reset` and verify
5. Regenerate types: `pnpm gen:types`
6. Update any TypeScript code that depends on changed schema
7. Run `pnpm build` to verify type safety
## Safety rules
- Never modify an existing migration file — create a new one
- Always include IF EXISTS / IF NOT EXISTS guards
- Test the migration on a fresh database before PRSkill 5: Feature
The new feature workflow — from branch creation to pull request. This is the broadest skill, and it ties together several others.
---
name: feature
description: End-to-end workflow for implementing a new feature
---
## Feature workflow
1. Confirm the spec with the user — what exactly are we building?
2. Create a feature branch: `git checkout -b feature/description`
3. Plan the implementation:
- Which files need to change?
- Which packages are involved?
- Are there database changes?
4. Implement in small steps — commit after each logical unit
5. After each change: run build + lint to catch issues early
6. When complete: run the full verification
- `pnpm build` — zero errors
- `pnpm lint` — zero warnings
- `pnpm test:e2e` — all passing (if applicable)
7. Create PR with summary of changes
## Rules
- Follow CLAUDE.md boundary rules for all new files
- Check "Where Does New Code Go?" table for file placement
- One feature per branch. If scope grows, split into multiple PRsThe ECC skill landscape
The ECC framework ships 65+ skills organized by domain. You do not need 65 skills. But seeing the categories helps you identify what you are missing.
Workflow
Deploy, verify, commit, release, changelog. The skills that govern how code moves from your editor to production.
Development
TDD, refactor, debug, feature, prototype. The skills for writing and improving code.
Quality
Code review, security scan, performance audit, accessibility check. The skills that catch problems.
Infrastructure
Docker, CI/CD, monitoring, database. The skills for operational tasks.
Most individual developers need 5-10 skills. Teams might need 15-20. If you have more than 20, you probably need the trigger-table pattern from Chapter 4 to manage lazy loading.
The verification skill
One skill deserves special attention. I call it /verify, and it catches more issues than any other skill in my setup.
---
name: verify
description: 6-phase verification pipeline — run before every commit and PR
---
## Verification pipeline
Run each phase in order. Stop on first failure.
### Phase 1: Build
`pnpm build`
Must complete with zero errors.
### Phase 2: Types
`pnpm tsc --noEmit`
No type errors allowed.
### Phase 3: Lint
`pnpm lint`
No warnings, no errors.
### Phase 4: Tests
`pnpm test:e2e` (if applicable to changes)
All tests passing.
### Phase 5: Security
Check for: hardcoded secrets, exposed API keys, .env files in git.
`git diff --cached --name-only | grep -E '\.env|secret|credential' && echo "BLOCKED" || echo "Clean"`
### Phase 6: Diff review
`git diff --cached`
Review all staged changes. Flag anything unexpected.
## Result
Report: X/6 phases passed. If any phase failed, list the failures.This single skill replaces a dozen ad-hoc checks. Instead of hoping you remembered to lint, hoping you ran the build, hoping you checked for secrets — you run /verify and get a complete report.
Skill design principles
After building dozens of skills, I have found four principles that separate useful skills from ones that gather dust.
One skill, one purpose. A skill that covers "everything about deployment and testing and reviewing" is three skills pretending to be one. Split them. Each skill should complete one workflow.
Actions, not advice. Every line should tell Claude what to do. "Run X." "Check Y." "Create Z." If a line says "consider" or "you might want to," rewrite it as a concrete action.
Include expected output. When a step produces output, say what the output should look like. "Must complete with zero errors" is better than "run the build." It tells Claude what success looks like.
Stay under 100 lines. If a skill is longer than 100 lines, it is doing too much. Split it into multiple skills, or create a parent skill that references sub-skills.
Testing your skills
Creating a skill is half the work. Testing it is the other half.
For each skill you build, invoke it on a real task. Type /deploy and actually walk through a deployment. Type /review and review a real diff. Watch what happens.
Did Claude follow every step? Did it skip any? Did it misinterpret something? Did it add steps that are not in the skill?
If Claude skipped a step, the step was probably not actionable enough. Make it more specific. If Claude misinterpreted something, the language was ambiguous. Rewrite it. If Claude added extra steps, the skill might be missing something important — consider adding those steps.
Skills improve through use, not through planning. Build them, test them, refine them. That is the loop.