完整示例

示例 1：PR 描述生成器

自动生成规范的 Pull Request 描述。

---
name: pr-description
description: |
  Generate a structured PR description from git diff and commits.
  Triggers on "generate PR description", "write PR summary".
metadata:
  type: workflow
  version: "1.0.0"
triggers:
  - "generate PR description"
  - "write PR summary"
  - "create pull request description"
allowed-tools:
  - Bash
  - Read
---

# PR Description Generator

## When to Use
- Creating a pull request and need a structured description
- User mentions "PR description", "pull request summary"

## When NOT to Use
- Creating the PR itself (use gh CLI)
- Commit message generation (that's a separate task)

## Workflow
1. Run `git log` to get commits on this branch vs. base
2. Run `git diff` to get the full changeset
3. Analyze: categorize changes (feature, fix, refactor, etc.)
4. Generate PR description in the format below

## Output Format

Summary

• 1-3 bullet points summarizing the key changes

Changes

• Feature: ...
• Fix: ...
• Refactor: ...

Test Plan

• [ ] Manual test: ...
• [ ] Unit test: ...

Screenshots

(if UI changes)

## Notes
- Keep the title under 70 characters
- Focus on WHY, not just WHAT
- If the diff is very large, suggest splitting the PR

示例 2：API 端点生成器

从数据库模型生成 RESTful API 端点。

---
name: api-generator
description: |
  Generate RESTful API endpoints from database models.
  Triggers on "generate API", "create endpoints for".
metadata:
  type: tool
  version: "1.0.0"
triggers:
  - "generate API"
  - "create endpoints"
  - "scaffold API routes"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
---

# API Generator

## When to Use
- User has a database model and wants CRUD endpoints
- User says "generate API for [model]"

## When NOT to Use
- GraphQL APIs (different patterns)
- Streaming or WebSocket endpoints

## Workflow
1. Read the model file to understand fields and types
2. Ask user: which CRUD operations are needed?
3. Ask user: what validation rules apply?
4. Generate:
   - Route file with CRUD handlers
   - Validation schemas
   - Service layer
   - Basic tests

## Output Structure

src/ ├── routes/ │ └── [resource].ts # Route definitions ├── services/ │ └── [resource].ts # Business logic ├── validators/ │ └── [resource].ts # Request validation └── tests/ └── [resource].test.ts # Integration tests

## Conventions
- Routes: thin, only request/response handling
- Services: all business logic
- Use async/await, no callbacks
- Return proper HTTP status codes
- Validate all inputs

## Notes
- Generate only what's requested — don't over-engineer
- Use the project's existing patterns and libraries
- Always include error handling for DB failures

示例 3：周报生成器

从 Git 活动生成团队周报。

---
name: weekly-report
description: |
  Generate a weekly report from git activity.
  Triggers on "weekly report", "team update", "write weekly summary".
metadata:
  type: workflow
  version: "1.0.0"
triggers:
  - "weekly report"
  - "team update"
  - "week in review"
allowed-tools:
  - Bash
---

# Weekly Report Generator

## When to Use
- End of week team status update
- User mentions "weekly report" or "team update"

## When NOT to Use
- Daily standup (different format)
- Sprint retrospective (different focus)

## Workflow
1. Run `git log --since="last Monday" --until="today" --author="<user>"` to get commits
2. Categorize commits into: Features, Fixes, Refactors, Chores
3. Ask user for non-code accomplishments (meetings, design, reviews)
4. Generate report in the format below

## Output Format

Weekly Report — [Date Range]

Accomplishments

• [Feature] ...
• [Fix] ...
• [Other] ...

Next Week

• Priority 1: ...
• Priority 2: ...

Blockers

• ...

## Notes
- Group related commits, don't list every commit
- Highlight business impact, not just technical changes
- Ask about blockers — they're important context

下一步

• 场景选择指南 — 如何选择正确的 Skill
• 常见误区 — 避免常见陷阱