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.

> Quick Answer: SKILL.md templates are configuration files that define how an AI agent should perform specific tasks like code review, test generation, documentation, or DevOps, using YAML for metadata and Markdown for instructions to guide AI behavior.

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

```markdown --- 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. ```

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

```markdown --- 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. ```

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

```markdown --- 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. ```

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

```markdown --- 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 ```

Use this for React/Vue/Svelte component generation.

```markdown --- 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 ```

If none of the above fit, start here:

```markdown --- 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. ```

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.*