SKILL.md Templates You Can Copy and Customize

Starting a SKILL.md file from a blank page is harder than it needs to be. These templates give you a working starting point for the most common skill types. Copy the one closest to your use case, customize the instructions, and drop it into your skills folder.

Every template follows the same structure: YAML frontmatter for metadata, then markdown instructions that tell your AI agent what to do.

Template 1: Code review skill

Use this when you want Claude Code to review pull requests or code changes against your team's standards.

---
name: code-review
description: Reviews code changes for bugs, security issues, and style violations. Triggers on code review requests, PR reviews, and "review this code" prompts.
---

# Code Review Standards

When reviewing code, check for these issues in order of priority:

## Critical (must fix)
- Security vulnerabilities: SQL injection, XSS, hardcoded secrets, unvalidated input
- Data loss risks: missing error handling on writes, no transaction boundaries
- Breaking changes: modified public API signatures without deprecation

## Important (should fix)
- Performance: N+1 queries, missing indexes, unnecessary re-renders
- Error handling: swallowed exceptions, missing error boundaries, unclear error messages
- Type safety: any types, missing null checks, implicit type coercion

## Style (nice to fix)
- Naming: unclear variable names, abbreviations, inconsistent conventions
- Structure: functions over 50 lines, deeply nested conditionals, duplicated logic
- Documentation: missing JSDoc on public functions, outdated comments

Format your review as a list grouped by file. For each issue, quote the specific line, explain the problem, and suggest a fix.

Template 2: Test generation skill

Use this when you want Claude to generate tests that match your existing patterns.

---
name: test-generator
description: Generates unit and integration tests matching project conventions. Triggers on test writing, test generation, and coverage requests.
---

# Test Generation Guidelines

When writing tests:

## Framework detection
- Check package.json for the test framework (Jest, Vitest, Mocha, Playwright)
- Match the assertion style used in existing test files
- Use the same file naming convention (*.test.ts, *.spec.ts, etc.)

## Test structure
- Use describe blocks grouped by function or component
- Write test names that describe the expected behavior, not the implementation
- Follow Arrange-Act-Assert pattern in each test

## Coverage requirements
- Test the happy path first
- Add tests for: null/undefined inputs, empty arrays/strings, boundary values
- Test error cases: invalid input, network failures, permission errors
- For async functions: test both resolved and rejected states

## Mocking
- Use the project's existing mock patterns (check __mocks__ folders)
- Prefer dependency injection over global mocks when possible
- Reset mocks between tests

Do not generate snapshot tests unless explicitly asked.

Template 3: Documentation skill

Use this for generating and maintaining docs that follow your format.

---
name: doc-writer
description: Writes and updates documentation for code, APIs, and projects. Triggers on documentation requests, README generation, and API doc tasks.
---

# Documentation Standards

## README files
Structure every README with these sections in order:
1. One-line description of what the project does
2. Quick start (3 steps or fewer to get running)
3. Installation with prerequisites
4. Usage examples with actual code
5. Configuration options in a table
6. Contributing guidelines (link to CONTRIBUTING.md if it exists)

## Code documentation
- Add JSDoc comments to all exported functions
- Include @param with types and descriptions
- Include @returns with type and description
- Include @throws if the function can throw
- Add @example with a realistic usage example

## API documentation
For each endpoint:
- HTTP method and path
- Request body schema with types and required/optional
- Response schema with example JSON
- Error responses with status codes and descriptions
- Authentication requirements

Keep language direct. Avoid "This function is used to..." — just say what it does.

Template 4: DevOps and deployment skill

Use this when working with CI/CD pipelines, Docker, and infrastructure.

---
name: devops-assistant
description: Helps with Docker, CI/CD, infrastructure-as-code, and deployment tasks. Triggers on DevOps, deployment, Docker, CI/CD, and infrastructure prompts.
---

# DevOps Standards

## Docker
- Use multi-stage builds to minimize image size
- Pin base image versions (no :latest tags)
- Order Dockerfile layers from least to most frequently changed
- Run as non-root user in production
- Include a .dockerignore that excludes node_modules, .git, and test files

## CI/CD
- Keep pipeline files in .github/workflows/ (GitHub Actions) or .gitlab-ci.yml
- Run linting and tests before build steps
- Use caching for dependencies (npm cache, Docker layer cache)
- Pin action versions to specific SHAs, not tags
- Include a manual approval step before production deploys

## Infrastructure as Code
- Use variables for anything environment-specific
- Tag all resources with project, environment, and owner
- Store state remotely (S3 + DynamoDB for Terraform)
- Never hardcode credentials — use environment variables or secret managers

## Deployment checklist
Before deploying, verify:
- [ ] All tests pass
- [ ] Environment variables are set
- [ ] Database migrations are ready
- [ ] Rollback plan is documented
- [ ] Monitoring and alerts are configured

Template 5: Frontend component skill

Use this for React/Vue/Svelte component generation.

---
name: frontend-components
description: Generates frontend components following project conventions. Triggers on component creation, UI development, and frontend generation tasks.
---

# Frontend Component Standards

## Component structure
- Use functional components with TypeScript
- Define props with an interface (not inline types)
- Export as named export from an index file
- Co-locate styles, tests, and stories with the component

## File organization

ComponentName/ index.ts (re-export) ComponentName.tsx (component) ComponentName.module.css (styles) ComponentName.test.tsx (tests)

## Styling rules
- Use CSS modules for component-scoped styles
- Use design tokens from the theme (colors, spacing, typography)
- Mobile-first responsive design
- No inline styles except for dynamic values

## Accessibility
- All interactive elements must be keyboard accessible
- Images need alt text
- Form inputs need associated labels
- Use semantic HTML elements (nav, main, section, article)
- Include aria attributes where semantic HTML is insufficient

## State management
- Keep state as local as possible
- Lift state only when two sibling components need it
- Use context for theme, auth, and locale — not for all shared state

Template 6: Minimal skeleton

If none of the above fit, start here:

---
name: your-skill-name
description: A one-sentence description of when this skill should activate. Be specific about the trigger — what task or prompt activates this skill.
---

# Skill Title

Brief context about what this skill does and when to apply it.

## Rules
- Rule 1
- Rule 2
- Rule 3

## Output format
Describe how Claude should structure its output when this skill is active.

Tips for customizing templates

The description field is the most important part. This is what Claude reads to decide whether to activate the skill. Be specific. "Helps with code" is too vague. "Reviews Python code for security vulnerabilities and OWASP Top 10 compliance" is specific enough to trigger correctly.

Instructions should describe what to do, not how AI works. Write them like you're briefing a senior developer. "Check for SQL injection by looking for string concatenation in queries" is better than "Use your language understanding capabilities to identify potential injection points."

Keep skills focused. A skill that tries to handle code review, testing, documentation, and deployment will do none of them well. Better to have four focused skills than one bloated one.

For more on writing effective skill descriptions, see How to Write a SKILL.md Description That Actually Triggers. For the complete format specification, see the SKILL.md Format Reference.

---

Browse ready-made skills or publish your own on Agensi.