用途
prd-writer 面向这样的场景：客户或产品经理提出新功能需求，或需求信息零散（Slack 消息、邮件、通话记录、Jira 工单），需要将其转化为开发人员可据以实施的需求文档。产出的 PRD 会被后续的 jira-tickets 和 impact-analysis 技能读取，因此要求足够具体，使未参与客户沟通的开发者也能据此开发。
主要能力
- 阅读现有资料：请求原文、仓库地图（../repo-map.md 或 docs/repo-map.md）以确定由哪些仓库和 Django 应用负责该区域，以及请求涉及的模型、接口和页面代码，避免为已存在的功能写规格。
- 一次性批量提问：只列出无法从代码或请求中得到答案的问题，合并为一条消息，最多约 6 个，每个附带最佳猜测供开发者确认。典型缺口包括角色与权限、存量数据的处理、尺寸/数量/频率限制、通知、客户眼中的“完成”标准，以及因截止日期而做的范围裁剪。开发者若不知道答案，则记入“待决问题”并继续，不阻塞流程。
- 按模板生成 PRD，保存到主仓库的 docs/prd/YYYY-MM-DD-<slug>.md（必要时创建目录）。模板包含：问题、目标、范围外内容、用户故事、验收标准、边界情况、受影响的仓库与应用（表格列出仓库、应用/区域、变更）、数据与 API 变更、上线方式、待决问题。不适用的章节可删减。
- 交付说明：给出文件路径，并指出 3 至 5 个最可能导致返工的事项（如验收标准不清晰、待决问题、跨仓库变更），然后建议下一步是拆分 Jira 工单，或在“受影响仓库”表不确定时先做影响分析。
使用方式
该技能以技能形式使用，具体安装命令和调用方式暂未提供。工作流程为四步：先读现有资料，再批量提问补齐缺口，然后按模板撰写 PRD 并保存，最后进行交付说明。
规则与限制
- 验收标准必须可测试，例如“列表接口在 1000 行数据下响应时间低于 300 毫秒”，而非“应该很快”。
- 使用项目自身的模型名、应用名等命名，而非客户措辞；两者不一致时注明对应关系。
- 不在此阶段设计实现方案，仅设计到足以列出受影响仓库和 API/数据变更的程度。
- 技能页面未提供收费、价格、平台等信息，暂未提供。