Skills: Creating Your First Skill
Last updated: 2026-08-31
Reading alone won't suffice — you must practice. This lesson takes you from zero to a truly usable Skill.
1. Requirements Analysis
We'll create a code review Skill with these requirements:
| Requirement | Description |
|---|---|
| Goal | Auto-review code and output a structured review report |
| Review Dimensions | Security, Performance, Readability, Best Practices |
| Output Format | Severity-graded review checklist |
| Trigger Method | Keyword "review" or manual invocation |
| Tool Requirements | Read files, search code |
2. Create the Skill File
(1) Create the File
BASH
# Claude Code
touch .claude/skills/code-review.md
# OpenCode
touch skills/code-review.md
(2) Write the Frontmatter
YAML
---
name: code-review
description: "Automated code review skill, checking security, performance, readability, and best practices"
triggers:
- keyword: "review|code review"
tools:
- Read
- Grep
- Glob
---
(3) Write the Prompt Body
MARKDOWN
# Code Review Skill
## Role
You are a senior code review expert with 10+ years of full-stack development experience.
## Review Process
1. Use the Read tool to read target files
2. Use Grep to search for related context (e.g., type definitions, interfaces)
3. Review across the following four dimensions
## Review Dimensions
### Security
- SQL injection, XSS, CSRF, and other common vulnerabilities
- Hardcoded sensitive information
- Insecure dependency usage
### Performance
- N+1 queries, unnecessary loops
- Memory leak risks
- Missing cache/index
### Readability
- Clear naming conventions
- Overly long functions (>50 lines warning)
- Adequate comments
### Best Practices
- Following project conventions
- Complete error handling
- No redundant code
## Output Format
For each issue, output:
- 📍 Location: filename:line_number
- 🔴/🟡/🟢 Severity
- 📝 Issue description
- ✅ Fix suggestion (with code example)
3. Test the Skill
(1) Manual Trigger
Enter the trigger keyword in the conversation:
TEXT
📖 Display only
You: review src/auth/login.py
AI: (Auto-loads code-review skill, executes review process)
(2) Observe Behavior
Verify the Skill loaded correctly:
TEXT
📖 Display only
✅ Did it automatically read the target file?
✅ Did it review across all four dimensions?
✅ Did it output a graded review report?
✅ Did it provide specific fix suggestions?
(3) Adjust and Optimize
If the output isn't ideal, adjust the prompts:
MARKDOWN
# Optimization: Add example output
## Example Output
📍 Location: src/auth/login.py:42
🔴 Critical: SQL injection risk
📝 Using string concatenation to build SQL query
✅ Suggestion:
```python
# Before
query = f"SELECT * FROM users WHERE name = '{username}'"
# After
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (username,))
---
## 4. Iterative Refinement
### (1) Add Context Awareness
```markdown
## Context Rules
- If the project has .eslintrc, follow its rules for review
- If the project has pyproject.toml, check if it follows the configuration
- Before reviewing, use Glob to check the project tech stack
(2) Add Conditional Branches
MARKDOWN
## Conditional Review
- Python projects: Additional checks for type hints, docstrings
- TypeScript projects: Additional checks for any types, type safety
- Go projects: Additional checks for error handling, goroutine leaks
(3) Add Team Standards
MARKDOWN
## Team Standards
- Functions must not exceed 30 lines (team convention is stricter than 50 lines)
- Unit test coverage is required
- API endpoints must have Swagger documentation
After Alice completed the iterations, the team's code review efficiency improved 3x. Bob said: "The key is making prompts specific — 'review code' is too vague; 'grade by four dimensions' is an executable instruction."
❓ FAQ
Q What if the Skill isn't auto-loaded?
A Check if the filename and directory are correct, if the frontmatter triggers match the keyword you entered, and if the platform supports auto-loading.
Q How long should a prompt be?
A As long as it needs to be effective — no strict limit. Practical Skills are typically 50-200 lines. The key is specificity and actionability, not length and vagueness.
Q Can one Skill handle multiple languages?
A Yes, with conditional branches. But we recommend splitting by language into separate Skills for easier maintenance.
📖 Summary
- Three steps to create a Skill: Analyze requirements → Write file → Test and iterate
- Frontmatter defines metadata; Markdown body defines behavior
- Prompts should be specific and actionable, including role, process, dimensions, and output format
- Continuously iterate and optimize through example outputs and context rules
📝 Exercises
- Basic (⭐): Follow this lesson's steps to create a code-review Skill and test it.
- Intermediate (⭐⭐): Add conditional branches to the code-review Skill, supporting language-specific review rules for at least 2 programming languages.
- Advanced (⭐⭐⭐): Create a complete "API documentation generation" Skill, including requirements analysis, prompt design, and test verification.