Is requirements-srs safe to install?

SaferSkills independently audited requirements-srs (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

pm-03-design/skills/requirements-srs/SKILL.md · 1 file

pm-03-design/skills/requirements-srs/SKILL.md11.3 KB · Markdown

name: requirements-srs

description: 当需要将PRD转化为面向研发团队的技术需求规格时使用。需求规格说明书（SRS）自动生成，补充非功能需求、接口约束、数据约束和边界条件，输出结构化Markdown文档。关键词：需求规格说明书、SRS、技术需求、软件需求规格、非功能需求、需求规格。

metadata:

module: "产品构思与设计"

sub-module: "需求管理"

type: "pipeline"

version: "2.0"

interaction_mode: "ai_suggest_human_approve"

需求规格说明书（SRS）自动生成

核心原则

PRD说做什么，SRS说怎么做——SRS是PRD的技术化翻译，面向研发而非业务
可验证性优先——每条需求必须是可测试的，模糊描述是SRS的最大敌人
完整性覆盖——功能需求+非功能需求+约束条件缺一不可
变更可追溯——每条需求有唯一编号，变更可追踪

交互模式

🤖→👤 AI建议人类审批

输入

输入项	类型	必填	来源	说明
PRD文档	Markdown	是	output/pm-design/design-prd/PRD-{产品名}.md	产品需求文档
API契约	JSON	○	output/pm-development/api-contract/openapi.yaml	接口定义
数据模型	JSON	○	output/pm-development/data-model/er_model.json	数据实体和关系
IA信息架构	JSON	○	output/pm-design/design-ia/ia.json	页面路由和导航结构
用户流程	JSON	○	output/pm-design/design-userflow/userflow.json	用户操作流程
技术约束	string	○	用户提供	技术栈、部署环境、性能基线等

执行步骤

Step 1: PRD解析与功能需求提取

从PRD中提取所有功能需求，转化为SRS格式：

需求编号规则：

FR-{模块}-{序号}    功能需求
NFR-{类别}-{序号}   非功能需求
CON-{类别}-{序号}   约束条件

每条功能需求包含：

字段	说明	示例
需求编号	唯一标识	FR-AUTH-001
需求名称	简洁描述	用户手机号注册
优先级	MoSCoW	Must/Should/Could/Won't
描述	完整需求描述	用户可通过手机号+验证码完成注册
前置条件	执行前必须满足的条件	用户未注册过该手机号
正常流程	主流程步骤	1.输入手机号 2.发送验证码 3.输入验证码 4.注册成功
异常流程	异常场景处理	验证码错误→提示重试（最多3次）
业务规则	约束和计算逻辑	验证码6位数字，有效期5分钟
验收标准	可测试的通过条件	注册成功率>99%，响应时间<2s
关联需求	依赖的其他需求	FR-AUTH-002(登录)

Step 2: 非功能需求补充

PRD通常缺少非功能需求，SRS必须补充：

性能需求：

指标	要求	测量方法
响应时间	页面首屏<2s，API<500ms	性能测试
并发量	支持1000 QPS	压力测试
吞吐量	日活10万级	监控统计

可用性需求：

指标	要求	测量方法
可用率	99.9%	监控统计
RTO	<1小时	故障演练
RPO	<5分钟	备份验证

安全需求：

类别	要求
认证	JWT Token，有效期2小时
授权	RBAC角色权限模型
传输加密	HTTPS/TLS 1.2+
数据加密	敏感字段AES-256加密存储
审计	关键操作日志留存180天

兼容性需求：

维度	要求
浏览器	Chrome 90+、Safari 15+、Firefox 90+、Edge 90+
移动端	iOS 14+、Android 10+
分辨率	375px-2560px响应式
网络	弱网(3G)可降级使用

可维护性需求：

指标	要求
代码覆盖率	单元测试>80%
文档完整性	API文档自动生成
部署方式	CI/CD自动化部署

Step 3: 接口需求定义

基于API契约和PRD，定义接口需求（从PM视角）：

接口需求 vs API契约的区别：

接口需求：PM定义"需要什么接口、接口的业务规则"
API契约：后端定义"接口的具体实现规范"

接口需求清单：

接口	业务场景	业务规则	优先级	关联功能需求
POST /auth/register	用户注册	手机号唯一、验证码校验	Must	FR-AUTH-001
POST /auth/login	用户登录	支持手机号/邮箱	Must	FR-AUTH-002

Step 4: 数据需求定义

基于数据模型和PRD，定义数据需求：

数据实体需求：

实体	核心字段	数据量预估	保留策略	关联需求
User	phone, email, status	100万	永久	FR-AUTH
Order	order_no, amount, status	1000万/年	5年	FR-ORDER

数据约束：

唯一性约束
引用完整性约束
数据格式约束
数据生命周期约束

Step 5: 约束条件汇总

汇总所有约束条件：

约束类别	约束内容	来源
技术约束	技术栈、框架版本	用户提供
环境约束	部署环境、网络限制	用户提供
法规约束	合规要求、数据保护	隐私合规评估
资源约束	团队规模、时间限制	用户提供
集成约束	第三方系统对接	用户提供

Step 6: 文档组装

SRS文档结构：

# {产品名}需求规格说明书（SRS）

## 文档信息
- 版本：v1.0
- 基于PRD：PRD-{产品名}.md v{版本}
- 编写日期：{日期}

## 1. 引言
### 1.1 目的
### 1.2 范围
### 1.3 定义与缩写
### 1.4 参考文献

## 2. 总体描述
### 2.1 产品视角（系统上下文）
### 2.2 用户特征
### 2.3 运行环境
### 2.4 设计与实现约束

## 3. 功能需求
### 3.1 {模块A}
#### 3.1.1 FR-{A}-001: {需求名称}
#### 3.1.2 FR-{A}-002: {需求名称}
### 3.2 {模块B}
- ...

## 4. 非功能需求
### 4.1 性能需求（NFR-PERF）
### 4.2 可用性需求（NFR-AVAIL）
### 4.3 安全需求（NFR-SEC）
### 4.4 兼容性需求（NFR-COMPAT）
### 4.5 可维护性需求（NFR-MAINT）

## 5. 接口需求
### 5.1 接口需求清单
### 5.2 外部系统接口

## 6. 数据需求
### 6.1 数据实体
### 6.2 数据约束
### 6.3 数据量与保留策略

## 7. 约束条件

## 附录
- 需求追踪矩阵（FR→PRD章节映射）
- 术语表

输出

存储路径：output/pm-design/requirements-srs/

输出文件：

文件	格式	说明
SRS-{产品名}.md	Markdown	完整需求规格说明书
requirements-srs.json	JSON	结构化数据（供下游Skill引用）

requirements-srs.json 结构：

{
  "document_info": {
    "product": "产品名",
    "version": "1.0",
    "prd_reference": "",
    "generated_at": "时间戳"
  },
  "functional_requirements": [
    {
      "id": "FR-AUTH-001",
      "name": "需求名称",
      "priority": "Must/Should/Could/Won't",
      "description": "",
      "preconditions": [],
      "normal_flow": [],
      "exception_flows": [],
      "business_rules": [],
      "acceptance_criteria": [],
      "related_requirements": []
    }
  ],
  "non_functional_requirements": {
    "performance": [],
    "availability": [],
    "security": [],
    "compatibility": [],
    "maintainability": []
  },
  "interface_requirements": [],
  "data_requirements": [],
  "constraints": []
}

决策规则

条件	决策
PRD缺失	无法生成SRS，要求用户提供PRD
API契约缺失	接口需求基于PRD推导，标注"建议补充API契约"
数据模型缺失	数据需求基于PRD推导，标注"建议补充数据模型"
技术约束未提供	非功能需求使用行业通用标准，标注"建议确认技术约束"
功能需求>50条	按模块分批输出，每批不超过20条

质量检查

[ ] 每条功能需求有唯一编号
[ ] 每条需求可测试（有验收标准）
[ ] 非功能需求覆盖5个维度
[ ] 接口需求从PM视角定义
[ ] 数据需求含数据量预估
[ ] 需求追踪矩阵完整（FR→PRD映射）
[ ] 无模糊描述（"快速""友好"等已量化）

降级策略

缺失的上游输入	降级方案	输出影响
PRD缺失	无法生成，要求用户提供	—
API契约缺失	接口需求基于PRD推导	接口业务规则可能不够精确
数据模型缺失	数据实体基于PRD推导	数据约束可能不够完整
IA/用户流程缺失	功能需求基于PRD文本推导	流程描述可能不够细致
技术约束缺失	非功能需求使用通用标准	需确认是否符合实际环境

输出校验规则

字段路径	类型	必填	说明
document_info	object	是	文档信息
document_info.product	string	是	产品名称
document_info.version	string	是	文档版本号
document_info.prd_reference	string	是	关联PRD引用
functional_requirements	array	是	功能需求列表
functional_requirements[].id	string	是	需求编号（FR-XXX-NNN）
functional_requirements[].name	string	是	需求名称
functional_requirements[].priority	string	是	优先级（Must/Should/Could/Won't）
functional_requirements[].description	string	是	需求描述
functional_requirements[].acceptance_criteria	array	是	验收标准
non_functional_requirements	object	是	非功能需求
non_functional_requirements.performance	array	是	性能需求
non_functional_requirements.availability	array	是	可用性需求
non_functional_requirements.security	array	是	安全需求
non_functional_requirements.compatibility	array	是	兼容性需求
non_functional_requirements.maintainability	array	是	可维护性需求
interface_requirements	array	是	接口需求
data_requirements	array	是	数据需求
constraints	array	是	约束条件

上游变更响应

上游变更影响

上游变更	影响范围	响应策略
PRD功能需求增删	功能需求列表、接口需求	标注受影响的功能需求，建议人类确认是否更新SRS
PRD优先级调整	功能需求优先级	标注优先级变更，建议人类确认是否调整MoSCoW标注
API契约变更	接口需求定义	标注受影响的接口，建议人类确认是否更新接口需求
数据模型变更	数据需求定义	标注受影响的数据实体，建议人类确认是否更新数据需求
技术约束变更	非功能需求	标注受影响的非功能需求，建议人类确认是否调整指标

下游通知机制

SRS变更类型	通知范围	通知方式
功能需求增删	开发团队、测试团队	标记需求变更，触发开发任务和测试用例更新
非功能需求指标变更	开发团队、运维团队	标记指标变更，触发性能测试和监控配置更新
接口需求变更	后端开发	标记接口变更，触发API契约更新
约束条件变更	开发团队	标记约束变更，触发技术方案评估更新

requirements-srs— agent skill

Is requirements-srs safe to install?

需求规格说明书（SRS）自动生成

核心原则

交互模式

输入

执行步骤

Step 1: PRD解析与功能需求提取

Step 2: 非功能需求补充

Step 3: 接口需求定义

Step 4: 数据需求定义

Step 5: 约束条件汇总

Step 6: 文档组装

输出

决策规则

质量检查

降级策略

输出校验规则

上游变更响应

上游变更影响

下游通知机制

Audit the pieces. Scan the whole. Decide.