使用代理技能

Agent Skills 是一组按开发阶段组织的工程工作流技能集合。这个元技能（meta-skill）帮助你发现并应用合适的技能。

技能发现

当任务到来时，识别其所处的开发阶段，并应用对应的技能：

Task arrives
    │
    ├── Don't know what you want yet? ──────→ interview-me
    ├── Have a rough concept, need variants? → idea-refine
    ├── New project/feature/change? ──→ spec-driven-development
    ├── Have a spec, need tasks? ──────→ planning-and-task-breakdown
    ├── Implementing code? ────────────→ incremental-implementation
    │   ├── UI work? ─────────────────→ frontend-ui-engineering
    │   ├── API work? ────────────────→ api-and-interface-design
    │   ├── Need better context? ─────→ context-engineering
    │   ├── Need doc-verified code? ───→ source-driven-development
    │   └── Stakes high / unfamiliar? ──→ doubt-driven-development
    ├── Writing/running tests? ────────→ test-driven-development
    │   └── Browser-based? ───────────→ browser-testing-with-devtools
    ├── Something broke? ──────────────→ debugging-and-error-recovery
    ├── Reviewing code? ───────────────→ code-review-and-quality
    │   ├── Too complex? ─────────────→ code-simplification
    │   ├── Security concerns? ───────→ security-and-hardening
    │   └── Performance concerns? ────→ performance-optimization
    ├── Committing/branching? ─────────→ git-workflow-and-versioning
    ├── CI/CD pipeline work? ──────────→ ci-cd-and-automation
    ├── Deprecating/migrating? ────────→ deprecation-and-migration
    ├── Writing docs/ADRs? ───────────→ documentation-and-adrs
    ├── Adding logs/metrics/alerts? ───→ observability-and-instrumentation
    └── Deploying/launching? ─────────→ shipping-and-launch

核心运作行为

1. 显式说明假设

在实现任何非琐碎的内容之前，明确陈述你的假设：

ASSUMPTIONS I'M MAKING:
1. [assumption about requirements]
2. [assumption about architecture]
3. [assumption about scope]
→ Correct me now or I'll proceed with these.

2. 主动管理困惑

当你遇到不一致之处时：

1. 停下来。 不要带着猜测继续。
2. 指出具体的困惑所在。
3. 提出取舍方案，或提出澄清性的问题。
4. 在问题解决之前不要继续。

3. 在有理有据时提出异议

你不是一台只会点头的机器。当某个方案存在明显问题时：

• 直接指出问题
• 解释具体的负面影响
• 提出替代方案
• 如果人类否决了你的意见，则接受其决定

4. 强制保持简单

在完成任何实现之前，先问：

• 这能用更少的代码完成吗？
• 这些抽象配得上它们带来的复杂度吗？
• 一位资深工程师看到这段代码，会不会说“你为什么不直接……”？

5. 保持范围纪律

只改动你被要求改动的部分。不要：

• “整理”与任务无关的代码
• 作为副作用去重构相邻的系统
• 添加规范中没有的功能

6. 验证，而非假设

每个技能都包含一个验证步骤。任务在验证通过之前都不算完成。

生命周期序列

对于一个完整的功能：

1.  interview-me                → Extract what the user actually wants
2.  idea-refine                 → Refine vague ideas
3.  spec-driven-development     → Define what we're building
4.  planning-and-task-breakdown → Break into verifiable chunks
5.  context-engineering         → Load the right context
6.  source-driven-development   → Verify against official docs
7.  incremental-implementation  → Build slice by slice
8.  test-driven-development     → Prove each slice works
9.  code-review-and-quality     → Review before merge
10. code-simplification         → Reduce unnecessary complexity
11. git-workflow-and-versioning → Clean commit history
12. documentation-and-adrs      → Document decisions
13. deprecation-and-migration   → Retire old systems when needed
14. shipping-and-launch         → Deploy safely

速查表

阶段	技能	概要
定义	interview-me	挖掘用户真正想要的东西
定义	idea-refine	通过发散/收敛思维打磨想法
定义	spec-driven-development	先有需求，再写代码
规划	planning-and-task-breakdown	拆解为可验证的任务
构建	incremental-implementation	纵向薄切片
构建	source-driven-development	对照官方文档进行验证
构建	doubt-driven-development	对非琐碎决策进行对抗式审查
构建	context-engineering	在正确的时机提供正确的上下文
构建	frontend-ui-engineering	生产级质量的 UI
构建	api-and-interface-design	契约清晰、稳定的接口
验证	test-driven-development	先写会失败的测试，再让它通过
验证	browser-testing-with-devtools	运行时验证
验证	debugging-and-error-recovery	复现 → 定位 → 修复 → 加固
审查	code-review-and-quality	五维度审查
审查	code-simplification	在保持行为不变的前提下降低复杂度
审查	security-and-hardening	OWASP 防护、最小权限
审查	performance-optimization	先测量，只优化真正重要的部分
发布	git-workflow-and-versioning	原子化提交、整洁的历史
发布	ci-cd-and-automation	自动化质量门禁
发布	deprecation-and-migration	安全地移除旧系统
发布	documentation-and-adrs	记录“为什么”
发布	observability-and-instrumentation	日志、指标、链路追踪
发布	shipping-and-launch	上线前检查清单、回滚