关于 to-prd
将现有对话和项目上下文整理为提交到问题跟踪器的结构化 PRD。适用于拆分任务前正式梳理需求的团队，并涵盖模块设计与质量检查。
主要功能
- 01综合现有项目上下文
- 02识别模块与接口
- 03按 PRD 结构整理需求
- 04添加 needs-triage 标签发布
- 05检查 PRD 质量
适用场景
- 01正式记录讨论中的需求
- 02拆分问题前编写功能规格
- 03结合用户故事记录架构决策
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/to-prd确认已加载。
详细介绍
转换为 PRD
将当前对话上下文转换为结构化 PRD，以便发布到项目问题跟踪器。
适用场景
- 根据现有讨论记录需求
- 将工作拆分为问题前编写正式规范
- 将架构决策与用户故事一并记录
不适用场景
- 将工作拆分为工单 → 使用
to-issues - 编写内部技术文档 → 使用
technical-writing - 记录快速任务笔记 → 使用
task-planning
流程
1. 探索并理解
使用项目的领域词汇（CONTEXT.md）和相关 ADR 查看代码库。不要采访用户——根据现有上下文进行归纳。
2. 设计模块
识别需要构建或修改的主要组件。强调深层模块：接口简单、易于测试且契约稳定。与用户确认假设，并确认哪些模块需要测试覆盖。
3. 编写文档并发布
完成 PRD 模板，并添加 needs-triage 标签后提交到问题跟踪器。
PRD 模板
# [Feature/Change Name]
## Problem Statement
[User-facing description of the issue or opportunity. What pain does this solve?]
## Solution
[User-facing description of the resolution approach.]
## User Stories
1. As a [actor], I want [feature], so that [benefit].
2. As a [actor], I want [feature], so that [benefit].
[... comprehensive list covering all use cases]
## Implementation Decisions
### Modules
[Major components to build/modify with interface descriptions]
### Technical Choices
[Architecture decisions, schema design, API contracts — avoid file paths and code snippets]
### ADR References
[Links to relevant Architecture Decision Records]
## Testing Decisions
[Testing philosophy for this feature, which modules need coverage, relevant test precedents]
## Out of Scope
- [Explicitly excluded item]
- [Explicitly excluded item]
## Further Notes
[Additional context, open questions, or dependencies]
质量检查清单
- 问题描述面向用户（而非技术层面）
- 用户故事涵盖所有参与者和用例
- 实现决策引用现有领域词汇
- “范围之外”部分可防止范围蔓延
- PRD 中不包含文件路径或代码（这些内容应放在问题中）
说明
- 确认任务触发条件和预期输出。
- 按顺序从头到尾遵循此技能中的工作流步骤。
- 在进入下一步前验证输出。
- 如果任何步骤失败，记录阻塞因素和备用方案。
示例
- 示例：先将此技能用于小范围任务，通过验证后再扩展到完整范围。
最佳实践
- 确保输出具有确定性且可审计。
- 优先采用小型、可逆的更改，避免大范围、高风险的修改。
- 明确记录假设。
参考资料
- 项目标准：
.agent-skills/skill-standardization/SKILL.md - 验证器脚本：
.agent-skills/skill-standardization/scripts/validate_skill.sh
评论
支持 Markdown