idea-md

Idea.md

概述

当用户只有初步构想、尚未形成完整 PRD 时，创建一份有力的 Idea.md。将它视为原始头脑风暴与正式产品需求之间的桥梁。

Idea.md 并非通用格式。如果仓库已有本地约定，请遵循该约定。如果没有，请默认采用 references/what-is-idea-md.md 中的规范：一份简洁、结构清晰的概念简介，涵盖问题、用户、解决方案、与仓库的契合度、风险和后续验证步骤。

开始时声明：I'm using the idea-md skill to create or refine the idea file.

收集输入

按以下顺序，从信息最丰富的来源中提取内容：

1. 现有的 Idea.md / IDEA.md / 相关草稿
2. 当前仓库上下文：README、规范、路线图文档、议题、包结构、重要约束
3. 对话历史和用户提供的笔记
4. 相邻资料，例如 PRD、设计文档或研究笔记

如果存在仓库，请先检查再写作。不要臆造本可从代码库或文档中获知的技术背景。

工作流程

1. 确定模式

选择一种：

• 新建构想文件：没有现有构想文档，用户希望创建一份
• 扩展：用户有一份粗略草稿，希望扩充内容
• 改写：用户希望让现有构想文件更清晰、结构更合理

2. 推断合适的格式

• 如果仓库已有 Idea.md 约定，请保留该格式。
• 如果工作流将 Idea.md 作为前期规划资料，请保持结构清晰、内容精简。
• 如果请求仅是记录构想，格式可以更轻量，但仍需让原作者之外的人也能看懂。

如果没有本地模板，请使用 references/idea-template.md。

3. 综合整理，而非照录

将零散笔记整理为连贯的叙述：

• 提炼核心论点
• 删除重复内容
• 明示隐含假设
• 区分已知信息与推测
• 保留用户独特的措辞或见解

4. 以实际情况为依据

如果有仓库，请纳入与仓库相关的具体背景：

• 该构想基于哪些现有界面、包或系统
• 影响该构想的约束
• 相关集成点或架构优势

如果没有仓库，请明确说明假设，不要将假设伪装成事实。

5. 把握适当的范围

Idea.md 应当：

• 比随手记更有条理
• 比 PRD 更简洁
• 有足够说服力，能说明该构想为何重要
• 足够具体，能指导验证或后续规划

不要将其写成逐项任务的实现计划，除非本地工作流明确要求这样做。

默认输出结构

如果没有针对仓库的特定格式，请采用以下结构：

1. 标题
2. 一段概述
3. 问题
4. 目标用户
5. 建议的解决方案
6. 可行性依据 / 差异化优势
7. 与仓库或技术的契合度
8. MVP
9. 风险与待解问题
10. 验证或后续步骤

如果仓库已有既定术语，请相应调整章节名称。

质量标准

• 开门见山，先讲核心洞见
• 使用具体的名词和动词；避免夸大宣传
• 优先说明具体取舍，而非泛泛表达乐观预期
• 清楚呈现未知事项
• 如果构想源自零散对话，解决其中的矛盾，或明确指出矛盾
• 如果是在扩充现有草稿，在保留原意的同时提升清晰度和实用性

何时提问

只有当缺失的信息会实质性改变文档时才提问：

• 目标用户不明确
• 核心问题含糊不清
• 存在多个相互冲突的产品方向

否则，请谨慎推断并标注假设。

随附参考资料

• references/what-is-idea-md.md：经过研究的定义和常见模式
• references/idea-template.md：没有本地约定时使用的默认规范模板