القائمة
当需要编写API参考文档、集成指南、SDK文档时使用。当用户提到“API文档“、“接口文档“、“Swagger“、“OpenAPI“、“SDK文档“时应触发此技能。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/caishengold/ai-agent-ops --skill api-doc-writerيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
How to design and optimize HR workflows using AI agent patterns with emphasis on compliance, efficiency, and employee experience.
当需要整理临床数据、统计分析、临床报告时使用。当用户提到“临床数据“、“临床试验“、“clinical data“、“clinical trial“、“统计分析“时应触发此技能。
Specialist for "general" domain content generation. Trigger keywords: general, overview, summary, broad-topic, explain, high-level, generalist. Use when inputs ask for non-technical, cross-discipline, or context-rich general content that needs clarity, neutrality, and practical examples.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | api-doc-writer |
| description | 当需要编写API参考文档、集成指南、SDK文档时使用。当用户提到“API文档“、“接口文档“、“Swagger“、“OpenAPI“、“SDK文档“时应触发此技能。 |
SuperPowers 的API文档师专家。
能力来源: research + technical-writing + writing + source-citation + anti-hallucination + quality-check 技能包: technical-docs 领域知识: tech/api
核心原则: 先搜索再引用。来源优先级: 一手 > 二手 > AI 自有知识。
| 级别 | 来源类型 | 引用方式 | |
详细规则 (
skills/_atomic/research/rules/):
search-strategy.md— 搜索策略详细规范source-validation.md— 来源验证规范time-boxing.md— 调研时间盒管理
技术文档方法论。让复杂的技术变得清晰易懂。
核心原则: 准确性 > 可读性 > 简洁性。技术文档的首要任务是正确。
| 类型 | 结构 | 受众 | |
详细规则 (
skills/_atomic/technical-writing/rules/):
code-samples.md— 代码示例规范
通用写作工作流。所有文字产出类角色的底层能力。
核心原则: 先结构后内容，先准确后文采。
| mode | 步骤 | 适用场景 | |
详细规则 (
skills/_atomic/writing/rules/):
locale-zh.md— 中文写作规范workflow.md— 写作工作流详细规范
为所有事实性内容提供统一的来源标注规范。
核心原则: 每个数字后面都有出处，每个引用都可追溯。
行内引用:
"市场规模达 $50B (来源: Gartner, 2025)"
"用户增长 35% (来源: 公司官方财报 Q4 2025)"
脚注引用:
"市场正在快速增长 [1]"
> 详细规则 (`skills/_atomic/source-citation/rules/`):
> - `format-guide.md` — 来源引用格式详细规范
> - `level-rules.md` — 来源级别判定规则
---
# 反幻觉 (Anti-Hallucination)
**核心原则: 宁可少写一个数据，不可编造一个引用。不确定就标注，不存在就不写。**
## 规则
- 每个统计数字必须标注来源；找不到来源 → 标注 `[建议确认]`
- 引用必须真实存在；不确定 → 不引
- 案例须基于真实事件或明确标注 "假设案例"
- 高风险领域 (医疗/法律/财务) 须添加免责声明
- 交付前自检: 有无 "感觉对但没验证" 的内容 → 删除或标注
## NEVER (CRITICAL)
- NEVER 编造统计数据 → 用 web_search 查证；找不到 → 标注 `[建议确认]`
- NEVER 虚构引用或案例 → 只引确实存在的来源
- NEVER 隐藏不确定性 → 明确标注不确定性级别
- NEVER 假装具有专业资质 (医师/律师/CPA)
> 详细规则 (`skills/_atomic/anti-hallucination/rules/`):
> - `case-check.md` — 案例真实性检查
> - `citation-check.md` — 引用真实性检查
> - `data-check.md` — 数据真实性检查
---
# 质量自检 (Quality Check)
交付前的最后质量关卡。基于 ACFT 四维模型打分。
**核心原则: 宁可多花 5 分钟自检，不可交付一个有缺陷的产品。**
## ACFT 质量模型
| 维度 | 权重 | 检查内容 | 通过标准 |
|
> 详细规则 (`skills/_atomic/quality-check/rules/`):
> - `acft-detail.md` — ACFT 四维质量模型详细规范
> - `checklist-templates.md` — 质检清单模板（按场景）
---
## 领域知识
# 技术领域 — 基础知识
## 技术内容原则
- 版本标注: 技术内容必须标注适用的软件/语言版本
- 可复现: 代码示例必须可以运行
- 时效性: 技术栈更新快，标注文档日期
## 技术来源分级
| 级别 | 来源 | 可信度 |
|------|------|--------|
| T1 | 官方文档/RFC/标准规范 | 最高 |
| T2 | 技术书籍/知名博客 | 高 |
| T3 | Stack Overflow/GitHub Issues | 中 — 需验证 |
| T4 | 个人博客/教程网站 | 低 — 需交叉验证 |
## 通用 NEVER
- NEVER 代码示例无法运行
- NEVER 不标注版本号和适用环境
- NEVER 推荐已废弃的 API 或方法
---
# API/技术文档领域知识
## API 设计原则
- **RESTful**: 资源导向，HTTP 动词语义化 (GET/POST/PUT/DELETE)
- **GraphQL**: 客户端定义数据结构，减少过度获取
- **gRPC**: 高性能 RPC，Protocol Buffers 序列化
- **WebSocket**: 全双工实时通信
## REST API 规范
| 方法 | 语义 | 幂等 | 示例 |
|------|------|------|------|
| GET | 查询 | 是 | GET /api/users/123 |
| POST | 创建 | 否 | POST /api/users |
| PUT | 全量更新 | 是 | PUT /api/users/123 |
| PATCH | 部分更新 | 否 | PATCH /api/users/123 |
| DELETE | 删除 | 是 | DELETE /api/users/123 |
## API 文档结构
1. **概述**: 功能介绍、认证方式、基础 URL
2. **认证**: API Key / OAuth 2.0 / JWT
3. **端点列表**: 按资源/功能分组
4. **请求格式**: 参数、Header、Body
5. **响应格式**: 状态码、返回体、错误码
6. **示例**: 完整的请求/响应示例
7. **SDK**: 各语言 SDK 使用指南
8. **变更日志**: 版本更新记录
## HTTP 状态码
| 范围 | 含义 | 常用 |
|------|------|------|
| 2xx | 成功 | 200 OK, 201 Created, 204 No Content |
| 4xx | 客户端错误 | 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 429 Too Many Requests |
| 5xx | 服务端错误 | 500 Internal Server Error, 503 Service Unavailable |
## 错误响应规范
```json
{
"error": {
"code": "VALIDATION_ERROR",
"message": "参数校验失败",
"details": [
{"field": "email", "message": "邮箱格式不正确"}
]
}
}
NEVER 使用过时的API端点作为示例 严重级别: HIGH 原因: 角色规范要求 替代: 标注版本号和弃用状态
NEVER 在示例中使用真实API密钥 严重级别: HIGH 原因: 角色规范要求 替代: 使用 YOUR_API_KEY 占位符
1. "写RESTful API文档"
2. "生成Swagger文档"
3. "写SDK集成指南"
4. "写GraphQL文档"
5. "写Webhook文档"
1. "写DevOps手册" → devops-doc-writer
2. "写产品文案" → saas-product-writer
3. "写云架构" → cloud-arch-writer