Skills Library Design – Three-Tier Architecture#
Overview#
Skills are structured workflows Claude can invoke as complete procedures. Each skill needs a SKILL.md file with YAML frontmatter (name, description) and markdown instructions. The name becomes the /slash-command, and the description helps Claude decide when to load it automatically.
Tier 1: Organization Skills (Global, All Developers)#
Distributed via plugin marketplace (internal) or symlink from a shared repo. Installed to ~/.claude/skills/ on each developer machine.
Start with 5–8 org-wide skills at launch. Don’t build 30.
/security-review – Highest-Value Enterprise Skill#
---
name: security-review
description: >
Performs a structured security review of staged changes.
Use when preparing code for PR review, after completing a feature,
or when asked to check for security issues.
allowed-tools: Bash, Read, Grep, Glob
---
# Security Review Procedure
Review the current staged changes (or working tree if nothing staged)
against this checklist. For each category, state PASS, FAIL, or N/A
with a one-line explanation.
## Input Validation
- Are all external inputs validated before use?
- Are SQL queries parameterized (no string concatenation)?
- Are file paths validated against path traversal?
## Authentication & Authorization
- Do new endpoints require authentication?
- Are authorization checks present for resource access?
- Are there any privilege escalation vectors?
## Secrets & Configuration
- Are there any hardcoded secrets, API keys, or passwords?
- Are credentials read from environment/vault, not config files?
- Are there any secrets in log statements?
## Dependencies
- Do new dependencies have known CVEs? Run: `npm audit` or `go vuln check`
- Are dependencies pinned to specific versions?
## Output
Produce a summary table and flag any FAIL items for the developer
to address before opening the PR. Do NOT auto-fix -- explain the issue
and let the developer decide./pr-description – Standardizes PR Quality#
---
name: pr-description
description: >
Generates a PR description from the current branch's changes
following the org template. Use when preparing to open a pull request.
allowed-tools: Bash, Read, Grep
---
# Generate PR Description
1. Run `git log main..HEAD --oneline` to understand the commit history
2. Run `git diff main --stat` to see files changed
3. Read the PR template at `.github/PULL_REQUEST_TEMPLATE.md` if it exists
Generate a PR description with these sections:
## Summary
Two to three sentences explaining WHAT changed and WHY.
## Changes
Bullet list of specific changes, grouped by area.
## Testing
How were these changes tested? List specific test commands run
and their outcomes.
## Risk Assessment
- What could break?
- What downstream services are affected?
- Is a database migration involved?
- Does this require a config change in any environment?
## Rollback Plan
If this change causes issues in production, what's the rollback procedure?Additional Org-Wide Skills#
- /test-scaffold – Generates test files following org testing conventions for the current file
- /onboard-repo – Reads agent_docs/ and gives a new developer a codebase walkthrough
- /incident-doc – Structured incident documentation template
- /changelog-entry – Generates changelog entries from recent commits
Design Properties of Good Org Skills#
- Opinionated about process, generic about technology. The /security-review works whether the project is Go, TypeScript, or Java because it focuses on categories of issues, not language-specific checks.
- Procedural, not declarative. Skills tell Claude what to do step by step. Conventions and constraints belong in rules.
- Self-contained. Each skill should work without requiring the developer to provide additional context.
Tier 2: Team/Project Skills (Per-Repo, Version-Controlled)#
Checked into each repo at .claude/skills/. Team-specific workflows and patterns.
Examples#
- /deploy-staging – Team’s specific deployment workflow including environment-specific configs
- /new-endpoint – Scaffolds an API endpoint following this project’s patterns, using actual shared middleware and types
- /db-migration – Generates a migration file following the team’s ORM conventions with correct naming scheme
- /new-component – For frontend teams: scaffolds a React component with team’s state management, styling, and test patterns
Skills with Supporting Files#
.claude/skills/
└── new-endpoint/
├── SKILL.md # Instructions
├── templates/
│ ├── handler.ts.md # Handler template
│ ├── handler.test.ts.md # Test template
│ └── openapi.yaml.md # OpenAPI fragment
└── examples/
└── sample-crud.md # Example of a well-structured endpointThe SKILL.md references these files: “Use the template in templates/handler.ts.md as your starting structure. See examples/sample-crud.md for a complete working example.”
This turns tribal knowledge into executable procedures. The senior engineer who always scaffolds endpoints the right way – their knowledge is now codified in a skill that any developer on the team can invoke.
Tier 3: Personal Skills (Individual Developer)#
Stored in ~/.claude/skills/. Not managed by the org, not shared in repos. Personal workflows: code review checklists, note-taking conventions, learning workflows. The org shouldn’t try to control these.
Skill Description Budget#
Skill descriptions are loaded into context so Claude knows what’s available. The budget scales dynamically at 2% of the context window, with a fallback of 16,000 characters.
If each skill description is ~100 characters, you can have ~160 skills before hitting the budget. In practice, keep descriptions to one sentence and you’ll be fine with 30–50 skills across all tiers.
Run /context to check for warnings about excluded skills.
Skill Naming Conflicts#
When skills share the same name across levels, higher-priority locations win: enterprise > personal > project. Plugin skills use a plugin-name:skill-name namespace, so they cannot conflict with other levels.
If a skill and a slash command share the same name, the skill takes precedence.