Token导航 LogoToken导航

Agent Skill · 研究检索

devdocs-requirements(开发文档要求)

用于辅助测试设计、自动化测试、用例整理和回归验证。它适合让 Agent 编写单元测试、端到端测试、测试计划或根据失败日志定位问题。使用时需要确认项目测试框架、运行命令和夹具数据,避免为了通过测试而改坏真实逻辑;涉及浏览器或外部服务时,应区分本地模拟、测试环境和生产环境。

devdocs-requirements 是研究检索类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为权限未标注;许可证为 MIT,暂无第三方扫描结果,按安装量在研究检索类的 73,675 个 Skill 里排第 61,129。

总安装 356周安装 15GitHub Stars 公开资料未说明下载 125核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:devdocs-requirements(开发文档要求)
来源仓库:https://github.com/chudiren/ai-agent-testing-platform
仓库路径:skills/devdocs-requirements
安装命令:
npx skills add chudiren/ai-agent-testing-platform --skill "devdocs-requirements"
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

AgentSkills.tonpx skills
npx skills add chudiren/ai-agent-testing-platform --skill "devdocs-requirements"

这个 Skill 是做什么的

研究检索类 Skill 主要解决「找资料、核对事实、把来源整理清楚」的问题,通常会让助手先检索再总结。

用于辅助开发需求文档的撰写与梳理。devdocs-requirements 属于研究检索类 Skill,可作为该场景下的辅助能力补充。适合提取功能点、验收标准和优先级建议。使用时需结合产品目标和现有代码库状态分析。避免将假设写成确定结论,所有需求应有来源或标记待确认。输出宜结构化,便于后续拆分为用户故事或任务卡。

来源仓库内路径:skills/devdocs-requirements

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add chudiren/ai-agent-testing-platform --skill "devdocs-requirements";命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    权限没有明确标注,第一次使用时只给一个无关紧要的任务,观察它到底读了哪些文件和网络。

常见问题

6 条

devdocs-requirements 怎么安装?

在终端执行 npx skills add chudiren/ai-agent-testing-platform --skill "devdocs-requirements"。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

devdocs-requirements 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

devdocs-requirements 需要什么权限?

权限级别没有明确标注。第一次使用时建议只给无关紧要的任务,观察它实际读写了哪些内容。

devdocs-requirements 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

devdocs-requirements 用的人多吗?

公开数据是累计安装 356 次,近一周安装 15 次,下载 125 次。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

devdocs-requirements 安全吗?

没有查到第三方扫描结果,安全性无法从公开资料判断,安装前请自行审查源码、依赖和命令行为。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 许可证明确为 MIT,商用和分发边界好判断。

先想清楚的地方

  • 没有第三方扫描结果,安全性只能靠自己读源码判断。
  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理研究检索类任务、又不想每次都手写提示词的人。

不太适合

  • 要求有安全扫描结论才肯安装的团队。
  • 需要厂商级技术支持和 SLA 的生产系统。

研究检索类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
find-skills

寻找技能 · Codex、Claude

31,199,81316,486操作浏览器MIT有提醒
self-improving-agent

自我改进 Agent · OpenClaw

16,464,0023,396接触敏感数据MIT-0通过
soultrace

灵魂追踪 · Codex、Claude

7,588,94412需要联网未明确有提醒
self-improving

自我完善 · OpenClaw

6,829,2841,046需要联网MIT-0通过
microsoft-foundry

微软代工厂 · Codex、Claude

6,614,144764调用外部服务未明确有提醒
devdocs-requirements

开发文档要求 · 本页

356—权限未标注MIT未收录

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

name
devdocs-requirements
description
DevDocs 需求扩写专家。将用户简短需求扩展为结构化的需求文档,建立功能点、用户故事、验收标准的关联体系。支持中英文需求分析,生成符合 DevDocs 规范的需求文档。
allowed-tools
Read, Write, Glob, Grep, AskUserQuestion

需求扩写

将用户简短需求扩展为结构化的需求文档,建立功能点、用户故事、验收标准的关联体系。

语言规则

  • 支持中英文提问
  • 统一中文回复
  • 使用中文生成文档

触发条件

  • 用户提供功能需求或想法
  • 用户要求创建/编写 PRD
  • 用户想要澄清或记录需求

工作流程

1. 理解需求
   │
   ▼
2. 探索代码库(如适用)
   │
   ▼
3. 识别功能点 (F-XXX)
   │
   ▼
4. 编写用户故事 (US-XXX)
   │
   ▼
5. 定义验收标准 (AC-XXX)
   │
   ▼
6. 生成追溯矩阵
   │
   ▼
7. 用户确认

编号规范

类型前缀格式示例
功能点FF-XXXF-001, F-002
用户故事USUS-XXXUS-001, US-002
验收标准ACAC-XXXAC-001, AC-002

编号规则:

  • 全局顺序编号,不嵌套
  • 通过追溯矩阵表达关联关系
  • 编号一旦分配不可复用

输出文件

主文件:docs/devdocs/01-requirements.md

如文档超过 300 行,可拆分为:

  • 01-requirements.md - 概览和功能点
  • 01-requirements-stories.md - 用户故事详情
  • 01-requirements-nfr.md - 非功能性需求

详细模板参见 templates/requirements-template.md

文档结构

# 需求文档:<功能名称>

## 1. 背景与目标
## 2. 功能点清单
## 3. 用户故事
## 4. 验收标准
## 5. 追溯矩阵
## 6. 非功能性需求
## 7. 范围边界
## 8. 风险与假设

核心概念

功能点 (Feature)

功能点是用户可感知的独立功能单元。

识别方法:

  • 可以独立交付和验证
  • 对用户有明确价值
  • 粒度适中(不过大也不过小)

示例:

| 编号 | 功能点 | 描述 | 优先级 |
|------|--------|------|--------|
| F-001 | 用户注册 | 新用户通过邮箱注册账号 | P0 |
| F-002 | 用户登录 | 已注册用户登录系统 | P0 |
| F-003 | 密码找回 | 用户通过邮箱重置密码 | P1 |

用户故事 (User Story)

用户故事描述用户如何使用功能点完成目标。

格式:作为 <角色>,我希望 <功能>,以便 <价值>

示例:

| 编号 | 功能点 | 角色 | 期望 | 目的 |
|------|--------|------|------|------|
| US-001 | F-001 | 新用户 | 使用邮箱注册 | 获得系统访问权限 |
| US-002 | F-001 | 新用户 | 设置安全密码 | 保护账号安全 |
| US-003 | F-002 | 已注册用户 | 使用邮箱密码登录 | 进入系统 |

验收标准 (Acceptance Criteria)

验收标准定义用户故事的完成条件,是测试用例设计的依据。

原则:

  • 可量化、可验证
  • 描述预期行为,不描述实现
  • 每个用户故事至少 2-3 条验收标准

示例:

### US-001: 使用邮箱注册

| 编号 | 标准描述 | 验证方式 |
|------|----------|----------|
| AC-001 | 有效邮箱格式可以提交注册 | 输入  [email protected] ,提交成功 |
| AC-002 | 已存在邮箱显示错误提示 | 输入已注册邮箱,显示"邮箱已存在" |
| AC-003 | 注册成功后发送验证邮件 | 收到包含验证链接的邮件 |

追溯矩阵

追溯矩阵展示功能点、用户故事、验收标准的关联关系。

示例:

| 功能点 | 用户故事 | 验收标准 |
|--------|----------|----------|
| F-001 | US-001 | AC-001, AC-002, AC-003 |
| F-001 | US-002 | AC-004, AC-005 |
| F-002 | US-003 | AC-006, AC-007, AC-008 |

约束

功能点约束

  • [ ] 每个功能点必须有唯一编号 (F-XXX)
  • [ ] 功能点必须标注优先级 (P0/P1/P2)
  • [ ] 功能点描述应简洁明确

用户故事约束

  • [ ] 每个用户故事必须关联到功能点
  • [ ] 必须遵循"作为...我希望...以便..."格式
  • [ ] 每个功能点至少有 1 个用户故事

验收标准约束

  • [ ] 每个验收标准必须有唯一编号 (AC-XXX)
  • [ ] 每个用户故事至少有 2 条验收标准
  • [ ] 验收标准必须可量化、可验证
  • [ ] 必须描述验证方式

追溯约束

  • [ ] 必须提供追溯矩阵
  • [ ] 所有功能点必须有对应的用户故事
  • [ ] 所有用户故事必须有对应的验收标准

确认约束

  • [ ] 必须与用户确认功能点是否完整
  • [ ] 不得添加用户未提及且未确认的功能

下一步

完成后建议运行 /devdocs-system-design 进行系统设计。

平台分布

windsurf

25.7%
按下载量换算32

OpenCode

25.46%
按下载量换算32

Cursor

18.89%
按下载量换算24

Codex

13.55%
按下载量换算17

Claude Code

7.4%
按下载量换算9

Antigravity

3.29%
按下载量换算4

安全审计

暂无安全审计结果可展示。

权限和风险

权限未标注

当前来源未能明确判断权限范围,默认进入异常复核队列。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。目前只有一个公开来源,建议同时核对源仓库。

继续浏览同类 Skills