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.

Template 1: Code review skill

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

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.

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.

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.

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.

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:

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.