Claude Code Skills: 10 Must-Install Skill Frameworks for Developers

1. Why do Claude Code Skills exist?

Claude Code is a terminal Agent: it reads your repo, runs shell, edits files. Its weakness is equally obvious — every session starts from zero unless you paste team norms into the prompt again and again. Skills fix that: put "when, how, which tools, which output format" into SKILL.md, let Claude load it when relevant, or trigger manually with /skill-name.

If you have ever onboarded a teammate onto an AI-assisted repo, you know the pattern. Week one they ask, "What do I paste before a PR review?" Week three they copy someone else's prompt from Slack. Week six someone "fixes" the prompt and nobody notices until a release checklist gets skipped. Skills move that knowledge out of chat history and into files your team can diff, review, and revert — the same way you treat application code.

Compared with older .claude/commands/*.md, Skills follow the Agent Skills open standard, with allowed-tools scoping, disable-model-invocation guardrails, and sub-agent execution. That matters when a workflow needs Bash but should not touch network tools, or when a release Skill must never fire because the model guessed you wanted a deploy. Official reference: Claude Code Skills documentation.

For Hashvps readers, Skills add a practical layer: once Xcode signing, Fastlane, and CI probes are written as project Skills, the same runbook runs on your local Mac and on a Cloud Mac mini dev node — swap machines without re-teaching the AI. If you are still mapping how Claude Code fits the broader agent landscape, see why Anthropic overtook OpenAI in 2026 through Claude Code.

2. How are Skills classified? (What)

Separate three layers before picking "which 10":

2.1 Built-in Skills (out of the box)

Anthropic ships /code-review, /debug, /batch, /loop, /claude-api, and more — available every session, no directory setup. Best for solo devs validating Agent behavior fast. Treat built-ins as reference implementations: read how they structure steps, what context they assume, and which tools they call before you author a custom Skill.

2.2 Project Skills (.claude/skills/)

Travel with the repo — commit to Git. Team PR norms, release checklists, security audit templates. New hires run /skills after git clone and see the same playbooks. This is where company-specific language belongs: internal service names, required JIRA prefixes, "never merge on Friday without on-call," ASC bundle ID conventions.

2.3 Personal Skills (~/.claude/skills/)

Cross-project habits: your commit message style, note cleanup flows, personal research summarizers. Not tied to one repo; iterate faster without a team PR. Keep personal Skills generic — if three repos need the same Skill, promote it to project level.

The mistake most teams make is jumping straight to personal Skills because the file path is easier. That works until the best engineer leaves and takes half the workflow with them. Project Skills are how you institutionalize good prompts without turning every standup into prompt therapy.

3. Ten must-install Skills compared (How Compare)

Unified columns: tool × entry × execution × context × audience. Two built-ins plus eight recommended custom Skills (names are yours; keep the logic). Before you rename anything, map each Skill to a repeatable task you already do weekly — if you cannot name the last three times you needed it, it is not a Skill yet; it is a wish.

code-review and debug are the on-ramps. Most teams stop there and wonder why Claude still feels inconsistent. The next inflection is commit and test-runner, because they anchor the Agent to verifiable artifacts (Git history, test output) instead of prose. xcode-release and ci-fix are where macOS execution becomes non-negotiable — plan the host before you write the Skill body.

3.1 Built-in vs custom: quick split

When validating iOS monetization, stack xcode-release with product Skills — see our Claude Code iOS app 7-day validation checklist.

4. Scenario matrix: what to install first

Use the matrix below as an install order, not a shopping list. Each row assumes you will run /skills after adding a Skill and watch whether auto-trigger fires too often or not at all — tuning description is part of the rollout, not a one-time write.

5. Recommended stacks

Stacks are intentional overlap: one Skill handles review quality, another handles commit hygiene, a third handles execution on the right OS. Avoid installing all ten on day one — pick one stack, live with it for two weeks, then add the next Skill only when you catch yourself retyping the same instructions.

Stack A — minimum viable (day one)

• Built-in /code-review + custom commit (description + five lines of body is enough)
• Keep Claude Code in terminal; review right after edits
• Success signal: PR comments shrink because review checklist is consistent

Stack B — iOS release

• xcode-release (manual) + test-runner (auto after Swift changes)
• Execution node: local M4 or Hashvps Cloud Mac — Windows/Linux cannot Archive
• Success signal: Archive + upload steps complete headless with the same Skill on laptop and remote node

Stack C — team standards

• Project security-review + docs-sync + ci-fix
• PR template line: "Run /security-review before merge"
• Success signal: new contributors pass review without asking for the secret prompt

Stack D — Skill factory

• Personal create-skill — any prompt repeated three times becomes a Skill
• Quarterly /skills cleanup: delete unused for 30+ days
• Success signal: Skill count stays flat while repo complexity grows

6. Common pitfalls

Most Skill failures look like "the model got dumber" when the real issue is overlapping descriptions, missing tool limits, or running macOS-only steps on the wrong host. Scan this list before you add Skill number eleven.

• "More Skills = better" → overlapping description fields fight for triggers and bloat context; ten or fewer with clear boundaries wins.
• "Longer body = stronger" → keep main SKILL.md around 500 lines; park details in references/.
• "Personal folder is enough for teams" → team norms belong in .claude/skills/ and Git.
• "Auto-trigger everything" → release, delete, prod config: set disable-model-invocation: true.
• "Skills replace CI" → Skills assist at dev time; gates stay hard-coded in GitHub Actions / Xcode Cloud.
• "xcode-release without a Mac" → Archive and codesign need macOS — local or cloud Mac node.
• "Copy-paste a Skill from a blog without editing description" → generic descriptions never auto-trigger; rewrite for your repo's file types and commands.

7. Seven steps: install Skills starting today

Treat this as a one-week rollout, not a weekend hackathon. Day one: built-ins only. Day three: first custom Skill from a repeated task. Day seven: bind macOS execution if you ship Apple-platform builds.

1. Upgrade Claude Code to a 2026 build with Agent Skills; run claude doctor in terminal. Fix any missing CLI or auth issues before authoring Skills — debugging Skills on a broken install wastes hours.
2. List repeats: did you type the same review checklist three times last week? Candidate Skill. If you cannot find three repeats, you are not ready for custom Skills yet.
3. Create dirs: mkdir -p .claude/skills/commit/SKILL.md (project) or ~/.claude/skills/ (personal). One Skill per folder; do not nest unrelated workflows in one file.
4. Write frontmatter: description with verb + scene; high-risk Skills get disable-model-invocation: true. Test the description by paraphrasing your trigger phrase — if it would not match, rewrite.
5. Verify: /skills lists entries; test auto-trigger and manual /name on real work. Log false positives (Skill fired when it should not) separately from misses.
6. Commit to Git: project Skills in the same PR as code; reviewers audit Skill changes too. A Skill PR should be small enough to read in five minutes.
7. Bind execution node: Skills with Xcode / launchd need a macOS host (local or cloud Mac); SSH in and run the same /xcode-release. Document the host in your README so CI and humans use the same node.

mkdir -p .claude/skills/commit
cat > .claude/skills/commit/SKILL.md <<'EOF'
---
description: Write Conventional Commits message from staged git diff. Use when user asks to commit or /commit.
allowed-tools: Bash, Read
---
# Commit Skill
1. Run `git diff --staged`
2. Output subject <= 72 chars, body with bullet points if needed
3. Do not commit until user confirms
EOF
claude
/skills

8. Conclusion

In 2026, Claude Code Skills turn "what senior engineers keep in their heads" into a versioned, shareable, permission-scoped Skill Framework. Install the five bases first — code-review, debug, commit, security-review, test-runner — then stack xcode-release, ci-fix, docs-sync, refactor-plan, create-skill by stack.

If you are choosing between another model subscription and finishing your first project Skill, pick the Skill. Subscriptions change token prices; Skills change how often you repeat yourself. A team with mediocre models and excellent Skills ships more predictably than a team with frontier models and ad-hoc prompts.

Remember the asymmetric line: model scores are not the dividing line — workflow entry and execution boundaries are. Bake Skills into SKILL.md before debating a pricier subscription.

Further reading: Claude Code Skills official docs · Anthropic pricing