安装命令
npx skills add https://github.com/davidk-cmyk/dk-replit-powerhouse --skill spec🇨🇳中文介绍
Spec Skill
编写清晰、完整、与技术栈无关的软件规范，以便任何工程师（或 AI 代理）都能一次性正确实现。
一份好的规范应包含的内容
一份规范应回答：要构建什么、为什么构建、谁使用它，以及如何衡量成功。除非是约束条件，否则它不应规定实现细节。
规范模板
# 规范：[功能 / 系统名称]
## 状态
草案 | 评审中 | 已批准
## 问题陈述
一段话。这解决了什么用户痛点或业务需求？
为什么现在需要解决？
## 目标
- [ ] 目标 1（可衡量的结果）
- [ ] 目标 2
## 非目标（范围外）
- 明确列出此规范不涵盖的内容，以防止范围蔓延。
## 用户与角色
谁使用这个？用通俗的语言描述主要用户。
包括任何次要用户或系统参与者（例如，定时任务、外部服务）。
## 用户故事
作为一个[角色]，我想要[执行某个操作]，以便[达成某个结果]。
每个故事的格式如下：
**US-001**：作为一个[用户]，我想要[某个能力]，以便[获得某个收益]。
- 验收标准：
- [ ] 给定[上下文]，当[执行某个操作]时，那么[出现某个结果]
- [ ] ...
## 功能需求
列出系统必须做什么。为便于追溯，请为其编号。
FR-001：系统应...
FR-002：系统应...
## 非功能需求
- **性能**：例如，"95% 分位的响应时间 < 200ms"
- **安全性**：例如，"所有传输中的数据必须加密"
- **可靠性**：例如，"99.9% 正常运行时间 SLA"
- **可扩展性**：例如，"必须支持 10,000 个并发用户"
- **可访问性**：例如，"符合 WCAG 2.1 AA 标准"
## 约束与假设
- 约束：硬性限制（预算、截止日期、需要集成的现有系统）
- 假设：被认为是真实但需要验证的事情
## 数据模型（如适用）
用通俗的语言或简单的图表描述关键数据实体及其关系。
除非是硬性约束，否则避免指定数据库技术。
## 关键流程 / 场景
逐步演练 2-3 个最重要的用户旅程。
使用编号步骤。为每个流程包含错误/边界情况。
**理想路径：[流程名称]**
1. 用户执行 X
2. 系统响应 Y
3. ...
**错误情况：[场景]**
1. 用户执行 X
2. 系统检测到 Y 条件
3. 系统响应 Z
## 待解决问题
- [ ] Q1：[问题] — 负责人：[姓名] — 截止日期：[日期]
- [ ] Q2：...
## 成功指标
上线后我们如何知道这个功能成功了？
- 指标 1：例如，"注册转化率提高 10%"
- 指标 2：例如，"关于 X 的支持工单减少 50%"
## 依赖项
- 上游：在开始此工作之前必须完成什么？
- 下游：什么工作会因此项未完成而受阻？
## 参考资料
- 链接到设计稿、现有方案、相关工单、研究文档
如何写好每个部分
🇺🇸English
Spec Skill
Write clear, complete, technology-agnostic software specifications that can be handed to any engineer (or AI agent) to implement correctly the first time.
What a Good Spec Contains
A spec answers: What should be built, Why , Who uses it, and How success is measured. It does NOT prescribe implementation details unless they are constraints.
Spec Template
# Spec: [Feature / System Name]
## Status
Draft | In Review | Approved
## Problem Statement
One paragraph. What user pain or business need does this solve?
Why does it need to be solved now?
## Goals
- [ ] Goal 1 (measurable outcome)
- [ ] Goal 2
## Non-Goals (Out of Scope)
- Explicitly list what this does NOT cover to prevent scope creep.
## Users & Personas
Who uses this? Describe the primary user(s) in plain language.
Include any secondary users or system actors (e.g., cron jobs, external services).
## User Stories
As a [persona], I want to [action], so that [outcome].
Format each story as:
**US-001**: As a [user], I want [capability] so that [benefit].
- Acceptance Criteria:
- [ ] Given [context], when [action], then [outcome]
- [ ] ...
## Functional Requirements
List what the system MUST do. Number them for traceability.
FR-001: The system shall...
FR-002: The system shall...
## Non-Functional Requirements
- **Performance**: e.g., "Response time < 200ms for 95th percentile"
- **Security**: e.g., "All data in transit must be encrypted"
- **Reliability**: e.g., "99.9% uptime SLA"
- **Scalability**: e.g., "Must support 10,000 concurrent users"
- **Accessibility**: e.g., "WCAG 2.1 AA compliant"
## Constraints & Assumptions
- Constraints: Hard limits (budget, deadline, existing systems to integrate with)
- Assumptions: Things believed to be true that should be validated
## Data Model (if applicable)
Describe the key data entities and their relationships in plain language or simple diagrams.
Avoid specifying database technology unless it is a hard constraint.
## Key Flows / Scenarios
Walk through the 2–3 most important user journeys step by step.
Use numbered steps. Include error/edge cases for each flow.
**Happy Path: [Flow Name]**
1. User does X
2. System responds with Y
3. ...
**Error Case: [Scenario]**
1. User does X
2. System detects Y condition
3. System responds with Z
## Open Questions
- [ ] Q1: [Question] — Owner: [Name] — Due: [Date]
- [ ] Q2: ...
## Success Metrics
How will we know this feature succeeded after launch?
- Metric 1: e.g., "Sign-up conversion rate increases by 10%"
- Metric 2: e.g., "Support tickets about X decrease by 50%"
## Dependencies
- Upstream: What must be done before this can start?
- Downstream: What is blocked until this is done?
## References
- Link to designs, prior art, related tickets, research docs
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者，精准高效
