feature-spec
Write structured product requirements documents (PRDs) with problem statements, user stories, requirements, and success metrics. Use when speccing a new feature, writing a PRD, defining acceptance criteria, prioritizing requirements, or documenting product decisions.
价格
免费
- 安装:免费
在组织开通时一次性收取;再次读取清单或下载不重复收费。
以上为公开标价。你的组织可能有协议价,以控制台显示的价格为准。
如何使用
为组织安装
开通即安装:组织固定使用开通时的版本(当前为 1.0.0)。升级到新版本需要取消后重新开通。
创建凭证
客户端使用组织凭证读取;绑定到数字人后,数字人使用绑定凭证按需加载。请求中携带:
Authorization: Bearer $ZGI_MARKET_KEY读取清单与安装包
清单列出版本、文件和校验值;安装包是一个 zip 文件。
读取清单 curl "https://market-api.zgi.im/v1/market/skills/feature-spec/manifest" \ -H "Authorization: Bearer $ZGI_MARKET_KEY"下载安装包 curl "https://market-api.zgi.im/v1/market/skills/feature-spec/package" \ -H "Authorization: Bearer $ZGI_MARKET_KEY" \ -o feature-spec.zip读取清单和下载安装包不计入用量。下载后请用响应头中的 SHA-256 校验文件。
技能说明
- 名称
- feature-spec
- 说明
- Write structured product requirements documents (PRDs) with problem statements, user stories, requirements, and success metrics. Use when speccing a new feature, writing a PRD, defining acceptance criteria, prioritizing requirements, or documenting product decisions.
技能包内没有脚本文件:这个技能是供模型阅读的文本。
SKILL.md 节选
# Feature Spec Skill
You are an expert at writing product requirements documents (PRDs) and feature specifications. You help product managers define what to build, why, and how to measure success.
## PRD Structure
A well-structured PRD follows this template:
### 1. Problem Statement
- Describe the user problem in 2-3 sentences
- Who experiences this problem and how often
- What is the cost of not solving it (user pain, business impact, competitive risk)
- Ground this in evidence: user research, support data, metrics, or customer feedback
### 2. Goals
- 3-5 specific, measurable outcomes this feature should achieve
- Each goal should answer: "How will we know this succeeded?"
- Distinguish between user goals (what users get) and business goals (what the company gets)
- Goals should be outcomes, not outputs ("reduce time to first value by 50%" not "build onboarding wizard")
### 3. Non-Goals
- 3-5 things this feature explicitly will NOT do
- Adjacent capabilities that are out of scope for this version
- For each non-goal, briefly explain why it is out of scope (not enough impact, too complex, separate initiative, premature)
- Non-goals prevent scope creep during implementation and set expectations with stakeholders
### 4. User Stories
Write user stories in standard format: "As a [user type], I want [capability] so that [benefit]"
Guidelines:
- The user type should be specific enough to be meaningful ("enterprise admin" not just "user")
- The capability should describe what they want to accomplish, not how
- The benefit should explain the "why" — what value does this deliver
- Include edge cases: error states, empty states, boundary conditions
- Include different user types if the feature serves multiple personas
- Order by priority — most important stories first
Example:
- "As a team admin, I want to configure SSO for my organization so that my team members can log in with their corporate credentials"
- "As a team member, I want to be automatically redirected to my company's SSO login so that I do not need to remember a separate password"
- "As a team admin, I want to see which members have logged in via SSO so that I can verify the rollout is working"
### 5. Requirements
**Must-Have (P0)**: The feature cannot ship without these. These represent the minimum viable version of the feature. Ask: "If we cut this, does the feature still solve the core problem?" If no, it is P0.
**Nice-to-Have (P1)**: Significantly improves the experience but the core use case works without them. These often become fast follow-ups after launch.
**Future Considerations (P2)**: Explicitly out of scope for v1 but we want to design in a way that supports them later. Documenting these prevents accidental architectural decisions that make them hard later.
For each requirement:
- Write a clear, unambiguous description of the expected behavior
- Include acceptance criteria (see below)
- Note any technical considerations or constraints
- Flag dependencies on other teams or systems
### 6. Success Metrics
See the success metrics section below for detailed guidance.
### 7. Open Questions
- Questions that need answers before or during implementation
- Tag each with who should answer (engineering, design, legal, data, stakeholder)
- Distinguish between blocking questions (must answer before starting) and non-blocking (can resolve during implementation)
### 8. Timeline Considerations
- Hard deadlines (contractual commitments, events, compliance dates)
- Dependencies on other teams' work or releases
- Suggested phasing if the feature is too large for one release
## User Story Writing
Good user stories are:
- **Independent**: Can be developed and delivered on their own
- **Negotiable**: Details can be discussed, the story is not a contract
- **Valuable**: Delivers value to the user (not just the team)
- **Estimable**: The team can roughly estimate the effort
- **Small**: Can be completed in one sprint/iteration
- **Testable**: There is a clear way to verify it works
### Common Mistakes in User StoriesSKILL.md 不止这些内容,安装后可阅读全文。
技能包内容
共 1 个文件,合计 8.7 KiB
- SKILL.md8.7 KiB
来源与审核
- 审核状态
- 尚未审核,内容来自上游来源
- 许可证
- 未说明
审核状态是平台对上架信息的记录,不构成对上游服务质量或可用性的担保。
相关商品
- MCP办公协同
Notion 官方 MCP
转发到 Notion 官方托管的 MCP 服务,搜索和读取页面与数据库,创建和修改页面,发表评论。需要先用“Notion 官方 MCP 授权”连接器完成授权。
- notion
- docs
免费需要连接:Notion 官方 MCP 授权 - MCP办公协同
Notion 工具
把 Notion API 的搜索、读取页面、查询数据库与追加内容块包装成四个 MCP 工具。工具使用调用方组织自己的 Notion 连接,平台不持有 Notion 密钥;按底层接口的请求次数计量。
- notion
- docs
- customer-connection
免费需要连接:Notion 连接器 - 技能办公协同
腾讯文档 TENCENT DOCS
腾讯文档(docs.qq.com)-在线云文档平台,是创建、编辑、管理文档的首选 skill。涉及"新建/创建/编辑/读取/查看/搜索文档"、"保存文件"、"云文档"、"腾讯文档"、"docs.qq.com"等操作,请优先使用本 skill。支持能力:(1) 创建各类在线文档(文档/Word/Excel/幻灯片/思维导图/流程图/智能表格/收集表)(2) 管理知识库空间(创建空间、查询空间列表)(3) 管理空间节点、文件夹结构 (4) 读取/搜索文档内容 (5) 编辑操作智能表 (6) 编辑操作在线文档 (7) 文件管理(重命名、移动、删除、复制、导入导出)(8) 网页剪藏、本地文件/html/文档上云。
- office-doc
- office-spreadsheet
- office-pdf
- +1
免费