Skills
Skills 是 Claude Code 的自定义命令增强版，允许你通过 Markdown 文件定义可复用的自动化工作流。每个 Skill 定义了一组 AI 应该遵循的步骤，让复杂的开发流程变成一条斜杠命令。
什么是 Skills？
Skills 是用 Markdown 编写的可执行指令集，是插件系统的最小功能单元。
Skills 分为两类：
- Commands（命令）：位于
commands/目录，作为 Markdown 文件，由用户通过/command显式调用 - Agent Skills（代理技能）：位于
skills/目录，包含SKILL.md文件，可由 Claude 根据任务上下文自动调用
与 Plugins 和 Marketplace 的关系
Skills 是最小功能单元，可独立使用也可打包进 Plugins 进行分发，通过 Marketplace 供社区发现和安装。三者是互补的层级关系。
Skills vs Plugins vs Marketplace 对比
| 特性 | Skills | Plugins | Marketplace |
|---|---|---|---|
| 定位 | 最小功能单元 | 完整扩展包 | 分发与发现平台 |
| 粒度 | 单个命令/技能 | 多个 Skills + Agents + Hooks + MCP | 多个 Plugins 的目录 |
| 命名空间 | 无（独立配置时） | 有（plugin-name:command） | 有（plugin@marketplace） |
| 安装方式 | 复制 SKILL.md 到项目 | --plugin-dir 或市场安装 | /plugin install |
| 版本管理 | 手动 | 语义版本 (plugin.json) | 自动更新 |
| 适用场景 | 个人工作流、快速实验 | 团队共享、跨项目复用 | 社区分发、企业内部 |
| 冲突处理 | 可能冲突 | 命名空间隔离 | 完全隔离 |
Skill 文件结构
每个 Skill 是一个独立目录，包含 SKILL.md 文件：
skills/
├── fix-issue/
│ └── SKILL.md
├── review-feedback/
│ └── SKILL.md
├── pr-cycle/
│ └── SKILL.md
└── yunyoujun/
└── SKILL.mdSKILL.md 使用 YAML frontmatter 定义元数据，正文部分为 AI 的执行指令：
markdown
---
name: fix-issue
description: Fix a GitHub issue end-to-end.
disable-model-invocation: true
---
Fix a GitHub issue end-to-end.
## Instructions
1. Fetch the issue details using `gh issue view $ARGUMENTS`
2. Analyze the issue...
3. Create a new branch...Frontmatter 字段
| 字段 | 类型 | 说明 |
|---|---|---|
name | string | Skill 名称，即斜杠命令名（如 fix-issue → /fix-issue） |
description | string | 功能描述，帮助 AI 理解何时使用该 Skill |
argument-hint | string | 参数提示（如 "[issue-number-or-url]"） |
disable-model-invocation | boolean | 设为 true 则 AI 不会自动触发，仅限手动调用 |
allowed-tools | string | 限制 Skill 可使用的工具列表 |
metadata | object | 可选的额外信息（作者、版本等） |
$ARGUMENTS 参数传递
使用 $ARGUMENTS 占位符捕获用户在斜杠命令后输入的参数，实现动态交互。参数会被原样传入 Skill 正文。
markdown
Fix GitHub issue $ARGUMENTS end-to-end.用户调用 /fix-issue 42 时，$ARGUMENTS 被替换为 42。
编写 Skill 最佳实践
基础 Skill 模板
创建 skills/<skill-name>/SKILL.md：
markdown
---
name: my-skill
description: "What this skill does in one sentence."
argument-hint: "[required-argument]"
disable-model-invocation: true
allowed-tools: Bash(gh *), Bash(git *), Read, Grep, Glob, Edit, Write
---
Brief summary of the skill.
## Instructions
1. Step one — describe what the AI should do
2. Step two — use `$ARGUMENTS` to accept user input
3. Step three — include specific CLI commands
4. Final step — report results to the user
$ARGUMENTS should be <describe expected input>.编写要点
- 指令要具体明确，包含实际的 CLI 命令，减少 AI 的自由发挥空间
- 建议设置
disable-model-invocation: true，避免 AI 在不恰当的时机自动触发 - 使用
allowed-tools限制可用工具范围，提升安全性 - 用编号步骤组织指令，便于 AI 按顺序执行
- 在最后一步要求 AI 汇报结果
注意事项
$ARGUMENTS是用户在斜杠命令后输入的参数，会被原样传入- 将 skills 放在
~/.claude/skills/下即可在所有项目中全局使用
本仓库 Skills 一览
独立 Skills
/yunyoujun — 编码偏好与工具约定
md
---
name: yunyoujun
description: "YunYouJun's opinionated coding preferences and tooling conventions for JavaScript/TypeScript projects. Use when working on YunYouJun's projects, setting up new projects, or following YunYouJun's coding style."
metadata:
author: YunYouJun
version: 0.2.0
---
YunYouJun's coding preferences and tooling conventions.
## Coding Practices
### General
- Use English for code, comments, and commit messages
- Use Chinese (Simplified) for documentation and user-facing content
- Prefer functional and declarative programming patterns
- Keep files focused and single-responsibility
- Use `export default` sparingly; prefer named exports
### TypeScript
- Always use TypeScript for new projects
- Prefer `interface` over `type` for object shapes
- Use explicit return types for public APIs
- Avoid `enum`; prefer `as const` objects or union types
- Use `type` imports: `import type { Foo } from './foo'`
### Vue
- Use Vue 3 Composition API with `<script setup lang="ts">`
- Use `defineProps`, `defineEmits`, `defineModel` macros
- Prefer single-file components (`.vue`)
- Use VueUse composables when appropriate
### Naming
- Files: `kebab-case` for all files
- Components: `PascalCase` for Vue components
- Variables/functions: `camelCase`
- Constants: `SCREAMING_SNAKE_CASE` for true constants
- Types/Interfaces: `PascalCase`
### Git Commits
- Follow [Conventional Commits](https://www.conventionalcommits.org/)
- Format: `type(scope): description`
- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `chore`, `ci`
## Code Documentation
### Comment Guidelines
- Write comments in **English**; keep them concise and purposeful
- Use comments to explain **why**, not **what** — code should be self-explanatory
- Avoid redundant comments that merely restate the code
- Place comments on the line above the code they describe, not inline (except for brief clarifications)
```ts
// Good — explains intent
// Retry up to 3 times to handle transient network failures
await retry(fetchData, { attempts: 3 })
// Bad — restates the code
// Set count to 0
const count = 0
```
### JSDoc / TSDoc Standards
All **public** functions, classes, interfaces, and type exports must include JSDoc:
````ts
/**
* Resolve a module path relative to the project root.
*
* @param name - The module specifier (e.g. `@yunyoujun/utils`)
* @param options - Resolution options
* @returns The absolute file path of the resolved module
* @throws {ModuleNotFoundError} If the module cannot be located
*
* @example
* ```ts
* const path = resolveModule('@yunyoujun/utils', { root: '/app' })
* ```
*/
export function resolveModule(name: string, options: ResolveOptions): string {
// ...
}
````
Key rules:
- **`@param`** — describe every parameter with its purpose
- **`@returns`** — describe the return value and type
- **`@throws`** — document error conditions
- **`@example`** — provide a usage example for non-trivial APIs
- **`@see`** — link to related documentation, functions, or external references
- **`@deprecated`** — mark deprecated APIs with migration guidance
- Internal / private helpers do **not** require JSDoc (a short `//` comment suffices)
### Vue Component Documentation
Document component props, emits, and slots using TypeScript types and comments:
````vue
<script setup lang="ts">
/**
* A reusable card component with configurable header and content.
*
* @example
* ```vue
* <BaseCard title="Hello" :closable="true" @close="onClose">
* <p>Content goes here</p>
* </BaseCard>
* ```
*/
interface Props {
/** Card title displayed in the header */
title: string
/** Whether to show the close button */
closable?: boolean
}
const props = withDefaults(defineProps<Props>(), {
closable: false,
})
const emit = defineEmits<{
/** Emitted when the close button is clicked */
close: []
}>()
</script>
````
## Module Organization
### File & Directory Structure
- **One concept per file** — each file should have a clear, single responsibility
- **Group by feature**, not by type (prefer `features/auth/` over `components/`, `services/`)
- **Index files** (`index.ts`) should only re-export; avoid putting logic in barrel files
- Use **flat structure** within a module; nest directories only when >5 related files exist
```
# Good — feature-based grouping
src/
features/
auth/
composables/
use-auth.ts
components/
LoginForm.vue
types.ts
index.ts # re-exports only
dashboard/
...
# Avoid — type-based grouping at scale
src/
components/
LoginForm.vue
DashboardCard.vue
composables/
use-auth.ts
use-dashboard.ts
```
## Tooling
### Package Manager
- Use **pnpm** as the package manager
- Use `pnpm` commands directly (not ni/nr)
- Use pnpm workspace for monorepos
- Use pnpm catalogs for shared dependency versions
### ESLint
- Use `@antfu/eslint-config` — no Prettier needed
- Run `pnpm lint --fix` after making changes
### TypeScript Config
Prefer the following base `tsconfig.json`:
```json
{
"compilerOptions": {
"target": "ESNext",
"module": "ESNext",
"moduleResolution": "bundler",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"noEmit": true
}
}
```
### Build & Dev
- Use **Vite** for web projects
- Use **VitePress** for documentation sites
- Use **UnoCSS** (or Tailwind CSS) for styling
- Use **Vitest** for testing
### CI/CD
- Use **GitHub Actions** for CI
- Use `gh` CLI for GitHub operations
## References
| Topic | Command |
| -------------------- | ----------------------------------- |
| Fix issues | `/ai-coding:fix-issue` |
| PR automation | `/ai-coding:pr-cycle` |
| Review feedback | `/ai-coding:review-feedback` |
| Copilot review reply | `/ai-coding:address-copilot-review` |
| Copilot review loop | `/ai-coding:copilot-review-loop` |ai-coding 插件 Skills
以下 Skills 打包在 ai-coding 插件中，通过插件加载后命令带 ai-coding: 前缀。
/ai-coding:fix-issue — 一键修复 Issue 并创建 PR
md
---
name: fix-issue
description: Fix a GitHub issue end-to-end - create branch, implement fix, run checks, and create PR.
argument-hint: "[issue-number-or-url]"
disable-model-invocation: true
allowed-tools: Bash(gh *), Bash(git *), Bash(pnpm *), Read, Grep, Glob, Edit, Write
---
Fix GitHub issue $ARGUMENTS end-to-end.
## Instructions
1. Fetch the issue details using `gh issue view $ARGUMENTS --json title,body,labels,comments`
2. Analyze the issue and understand what needs to be fixed
3. Create a new branch: `git checkout -b fix/issue-<number>` (extract number from $ARGUMENTS)
4. Implement the fix with proper code changes
5. Write or update tests to cover the fix
6. Run lint/typecheck if available (`pnpm lint`, `pnpm typecheck`)
7. Commit with a conventional commit message referencing the issue: `fix: <description> (closes #<number>)`
8. Push the branch: `git push -u origin HEAD`
9. Create a PR: `gh pr create --title "fix: <description>" --body "Closes #<number>" --fill`
10. Report the PR URL and summary of changes/ai-coding:review-feedback — 拉取 Review 意见并自动修改
md
---
name: review-feedback
description: Fetch and address PR review feedback from Copilot or human reviewers - analyze, fix, push, and report.
disable-model-invocation: true
---
Fetch and address PR review feedback (from Copilot or human reviewers).
## Instructions
1. Get the current PR number. If $ARGUMENTS is provided, use it as the PR number. Otherwise, detect from the current branch: `gh pr view --json number -q .number`
2. Fetch all review comments: `gh pr view <number> --json reviews,comments,reviewRequests`
3. Also fetch inline review comments: `gh api repos/{owner}/{repo}/pulls/<number>/comments --jq '.[] | {path, line: .original_line, body, diff_hunk}'`
4. Analyze each review comment and categorize:
- **Must fix**: bugs, security issues, correctness problems
- **Should fix**: style, readability, best practices
- **Optional**: nitpicks, suggestions
5. For each "must fix" and "should fix" item, implement the changes
6. Run lint/typecheck after changes
7. Commit with message: `fix: address review feedback`
8. Push the changes: `git push`
9. Reply to each addressed comment on the PR: `gh pr comment <number> --body "Addressed review feedback: <summary>"`
10. Report what was changed and what was intentionally skipped (with reasoning)/ai-coding:pr-cycle — 完整 PR 生命周期
md
---
name: pr-cycle
description: "Full PR lifecycle automation: fix issue → create PR → wait for review → address feedback. All in one command."
disable-model-invocation: true
---
Full PR lifecycle: fix issue → create PR → wait for review → address feedback.
## Instructions
This is the full automated cycle. Run the following steps:
### Step 1: Fix the issue
1. Fetch issue details: `gh issue view $ARGUMENTS --json title,body,labels,comments`
2. Create branch, implement fix, run checks, commit, push
3. Create PR: `gh pr create --fill`
### Step 2: Check for existing reviews
1. Wait a moment, then check: `gh pr view --json reviews,comments`
2. Fetch inline comments: `gh api repos/{owner}/{repo}/pulls/<number>/comments`
### Step 3: Address feedback (if any)
1. If there are review comments, analyze and fix them
2. Commit and push fixes
3. Comment on PR with summary
### Step 4: Final status report
Report:
- PR URL
- Changes made for the original issue
- Review comments addressed (if any)
- Any remaining items that need human decision
$ARGUMENTS should be the issue number, e.g. `42`/ai-coding:address-copilot-review — 处理 Copilot Review 意见
md
---
name: address-copilot-review
description: "Fetch Copilot review comments on a PR, triage, fix valid issues, and reply to each comment. Single-pass."
argument-hint: "[pr-number-or-url]"
disable-model-invocation: true
allowed-tools: Bash(gh *), Bash(git *), Bash(pnpm *), Read, Grep, Glob, Edit, Write
---
Fetch and address GitHub Copilot review comments on a PR in a single pass: triage, fix, reply.
## Instructions
### Step 1: Identify the PR
1. If `$ARGUMENTS` is provided, use it as the PR number or URL.
2. Otherwise, detect from the current branch: `gh pr view --json number,url -q '.number'`
3. Get repo info: `gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'`
4. Print the PR number and URL for confirmation.
### Step 2: Fetch Copilot review comments
Fetch **all** review comments and filter for Copilot:
```bash
# Inline review comments (line-level)
gh api "repos/{owner}/{repo}/pulls/<number>/comments" \
--jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]" or .user.login == "copilot[bot]" or (.user.type == "Bot" and (.user.login | test("copilot"; "i")))) | {id, path, line: .original_line, body, diff_hunk, in_reply_to_id, created_at}'
# PR-level review comments
gh api "repos/{owner}/{repo}/pulls/<number>/reviews" \
--jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]" or .user.login == "copilot[bot]" or (.user.type == "Bot" and (.user.login | test("copilot"; "i")))) | {id, state, body, submitted_at}'
# Issue-style comments
gh api "repos/{owner}/{repo}/issues/<number>/comments" \
--jq '.[] | select(.user.login == "copilot-pull-request-reviewer[bot]" or .user.login == "copilot[bot]" or (.user.type == "Bot" and (.user.login | test("copilot"; "i")))) | {id, body, created_at}'
```
If no Copilot comments found, report "No Copilot review comments found on this PR." and stop.
### Step 3: Triage each comment
For each Copilot comment, read the referenced file and code context, then categorize:
| Category | Criteria | Action |
| -------------- | ----------------------------------------------- | ------------- |
| **MUST_FIX** | Bugs, security issues, correctness problems | Fix and reply |
| **SHOULD_FIX** | Style, best practices, readability improvements | Fix and reply |
| **SKIP** | False positives, not applicable, or nitpicks | Reply only |
**Triage guidelines:**
- Unused imports → usually valid, remove them
- Security warnings → take seriously, verify if real
- Performance suggestions → evaluate actual impact
- Refactoring suggestions → apply KISS/YAGNI; skip if over-engineering
- Type safety → usually valid for TypeScript projects
### Step 4: Fix valid issues
For each `MUST_FIX` (first) and `SHOULD_FIX` (second) comment:
1. Read the file and understand the surrounding code
2. Implement the fix following existing code patterns
3. Keep changes minimal and focused — one fix per comment
**Do NOT:**
- Bundle all fixes into one giant change
- Refactor unrelated code
- Change code formatting beyond what the comment requests
### Step 5: Verify changes
After all fixes:
1. `pnpm lint --fix` (if available)
2. `pnpm typecheck` (if available)
3. `pnpm test` (if available)
If any check fails, fix the issue before proceeding.
### Step 6: Commit and push
1. Stage changes: `git add -A`
2. Commit with descriptive message: `fix: address copilot review feedback`
- If multiple distinct fixes, prefer separate commits per fix
3. Push: `git push`
### Step 7: Reply to each comment on the PR
Reply to **every** Copilot comment, not just the ones you fixed:
**For inline review comments** (line-level), reply directly on the review thread:
```bash
gh api "repos/{owner}/{repo}/pulls/<number>/comments/<comment_id>/replies" \
-X POST -f body="<reply>"
```
**For PR-level or issue comments**, post a summary comment:
```bash
gh pr comment <number> --body "<summary>"
```
**Reply format:**
- Fixed: `"Fixed ✅ — <brief description of what was changed>"`
- Skipped: `"Skipped — <brief reason why this is not applicable>"`
- Partially addressed: `"Partially addressed — <what was done and what was deferred>"`
### Step 8: Summary report
Print a final summary table:
```
## Copilot Review — Summary
PR: #<number> (<url>)
| # | File:Line | Issue | Category | Action | Reply |
|---|-----------|-------|----------|--------|-------|
| 1 | src/foo.ts:42 | Unused import | SHOULD_FIX | Fixed | ✅ |
| 2 | src/bar.ts:10 | Null check | MUST_FIX | Fixed | ✅ |
| 3 | src/baz.ts:99 | Refactor suggestion | SKIP | Skipped | YAGNI |
Commits: <list of commit hashes and messages>
```/ai-coding:copilot-review-loop — Copilot Review 迭代循环
md
---
name: copilot-review-loop
description: "Iterative Copilot review loop: trigger review → delegate to address-copilot-review → re-trigger. Max 2 cycles until clean."
argument-hint: "[pr-number-or-url]"
disable-model-invocation: true
allowed-tools: Bash(gh *), Bash(git *), Bash(pnpm *), Read, Grep, Glob, Edit, Write
---
Iterative Copilot review loop. Triggers Copilot review, delegates comment handling to `/address-copilot-review`, then re-triggers until clean. Max 2 cycles.
## Prerequisites
- `gh` CLI installed and authenticated
- Optional: `gh-copilot-review` extension (`gh extension install ChrisCarini/gh-copilot-review`)
## Instructions
### Step 1: Preflight checks
1. Verify `gh` CLI: `gh auth status`
2. Check `gh-copilot-review` extension: `gh extension list | grep copilot-review`
- If not installed, will use fallback `gh pr review --request copilot`.
3. If `$ARGUMENTS` is provided, use it as the PR number or URL.
4. Otherwise, detect from current branch: `gh pr view --json number,url -q '.number'`
5. Get repo info: `gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"'`
6. Print the PR number and URL for confirmation.
7. Scan for project conventions (`CLAUDE.md`, `AGENTS.md`, `Makefile`, `.github/workflows/`) to understand available safety checks.
### Step 2: Safety checks (before any changes)
Run all available checks to ensure the branch is green:
1. `pnpm lint` (if available)
2. `pnpm typecheck` (if available)
3. `pnpm test` (if available)
**If any check fails, stop immediately and report.** Do not start the loop on a broken branch.
### Step 3: Review loop (max 2 cycles)
Set `cycle = 1`. Repeat until stop conditions are met or `cycle > 2`:
---
#### 3a. Record baseline
Count current unresolved Copilot comments for later comparison:
```bash
gh api "repos/{owner}/{repo}/pulls/<number>/comments" \
--jq '[.[] | select(.user.login == "copilot-pull-request-reviewer[bot]" or .user.login == "copilot[bot]" or (.user.type == "Bot" and (.user.login | test("copilot"; "i"))))] | length'
```
#### 3b. Trigger Copilot review
```bash
# Prefer extension if available:
gh copilot-review <number>
# Fallback:
gh pr review <number> --request copilot
```
#### 3c. Wait for Copilot to finish
Poll every 30 seconds. Compare comment count against baseline.
- New comments appear → proceed to 3d.
- No new comments after **5 minutes** → timeout, skip to Step 4.
#### 3d. Delegate to `/address-copilot-review`
Run the `/address-copilot-review <number>` skill to:
1. Fetch all Copilot comments
2. Triage (MUST_FIX / SHOULD_FIX / SKIP)
3. Fix valid issues
4. Verify (lint/typecheck/test)
5. Commit and push
6. Reply to each comment
Collect the results (how many MUST_FIX / SHOULD_FIX / SKIP).
#### 3e. Check stop conditions
- **Stop** if no `MUST_FIX` comments were found in this cycle.
- **Stop** if all comments were `SKIP`.
- **Stop** if `cycle >= 2` (max cycles reached).
- Otherwise, increment `cycle` and go back to **3a**.
---
### Step 4: Final summary
Post a summary comment on the PR and print to console:
```
## Copilot Review Loop — Summary
PR: #<number> (<url>)
Cycles completed: <N>
| # | File:Line | Issue | Category | Action | Reply | Cycle |
|---|-----------|-------|----------|--------|-------|-------|
| 1 | src/foo.ts:42 | Unused import | SHOULD_FIX | Fixed | ✅ | 1 |
| 2 | src/bar.ts:10 | Null check | MUST_FIX | Fixed | ✅ | 1 |
| 3 | src/baz.ts:99 | Refactor suggestion | SKIP | Skipped | YAGNI | 1 |
| 4 | src/qux.ts:5 | Missing error handling | MUST_FIX | Fixed | ✅ | 2 |
Commits:
- abc1234 fix: address copilot review feedback (cycle 1)
- def5678 fix: address copilot review feedback (cycle 2)
Remaining items needing human review: <list or "None">
```
Post to PR:
```bash
gh pr comment <number> --body "<summary above>"
```安装与使用
方式一：Skills CLI
通过 vercel-labs/skills CLI 安装：
bash
# 安装全部 skills
pnpx skills add yunyoujun/ai --skill='*'
# 安装单个 skill
pnpx skills add yunyoujun/ai --skill=fix-issue安装后直接用斜杠命令调用：
bash
/fix-issue 42
/review-feedback
/pr-cycle 42全局共享
将 skills 放在 ~/.claude/skills/ 下即可在所有项目中使用。
方式二：Plugin 加载
本仓库的 ai-coding 插件打包了编码工作流 Skills，加载后命令带 ai-coding: 命名空间前缀：
bash
claude --plugin-dir /path/to/ai/plugins/ai-codingbash
/ai-coding:fix-issue 42
/ai-coding:review-feedback
/ai-coding:pr-cycle 42
/ai-coding:address-copilot-review
/ai-coding:copilot-review-loop方式三：Marketplace 安装
从官方或团队市场浏览和安装：
bash
# 浏览官方市场
/plugin
# → 切换到「发现」选项卡浏览
# 直接安装
/plugin install commit-commands@claude-plugins-official参考链接
- Plugins 开发 — Plugin 创建、结构与迁移
- Marketplace 市场 — 发现、安装、创建与分发市场
- 创建插件 — Claude Code 官方文档
- 发现和安装插件 — Claude Code 官方文档
- Claude Code Skills 官方文档
- vercel-labs/skills — Skills CLI 安装工具
- PR 自动化实践 — Skills 在 PR 工作流中的实际应用
- Claude Code 最佳实践 — 斜杠命令与工具配合技巧
- MCP（Model Context Protocol） — MCP Server 集成说明