feat: add idea-to-product skill

.gitignore

@@ -0,0 +1 @@
+.pydeps/

idea-to-product/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: idea-to-product
+description: 将已经通过的软件点子依次推进为固化需求、实施方案、项目骨架、纵向功能、功能验收和发布候选版本。适用于用户提出应用、网站、服务、工具或其他软件项目，并希望 Agent 不进行市场、竞品或价值分析而直接落地的场景；也适用于继续执行已经由本流程管理的项目。开始开发前的每个阶段都必须获得明确的人工确认。
+---
+
+# 从点子到产品
+
+通过一套由项目文件持续记录的流程，将已经通过的软件点子落地为可验收产品。默认点子已经立项，只关注交付。
+
+## 不可违反的规则
+
+- 不进行市场、竞品、需求价值或商业价值分析。
+- 对不影响方向的歧义采用合理默认值。
+- 只有当选择会改变产品方向、产生明显成本差异、涉及敏感数据、缺少必要权限或造成需求冲突时才询问用户。
+- 当前版本保持精简，但核心流程必须端到端可用。
+- 把决策和进度写入项目文件，不依赖聊天记录。
+- 三个开发前阶段未全部获得明确人工确认时，绝不进入纵向功能开发。
+- 不得把沉默、话题切换或要求解释理解为确认。
+- 不得代替用户批准阶段门。
+
+## 项目控制文件
+
+新项目应从 `assets/` 复制模板，结合项目内容生成以下文件：
+
+```text
+AGENTS.md
+.ai-project/state.yaml
+docs/REQUIREMENTS.md
+docs/IMPLEMENTATION.md
+docs/FEATURES.md
+docs/ACCEPTANCE.md
+```
+
+如果已有 `AGENTS.md`，保留原有内容，只合并本项目需要的流程规则，不得删除用户指令。
+
+继续已有项目时，先读取 `AGENTS.md`、`.ai-project/state.yaml`、相关 `docs/` 文件、仓库状态和已有实现，再从记录的阶段继续。如果状态文件与实际产物不一致，停止执行并报告差异，不得自行猜测。
+
+开始或继续流程前，读取 [references/stage-gates.md](references/stage-gates.md)。
+
+## 状态流转
+
+在 `.ai-project/state.yaml` 中使用以下阶段值：
+
+```text
+需求起草
+需求待确认
+实施方案起草
+实施方案待确认
+骨架构建中
+骨架待确认
+纵向功能开发
+功能验收中
+验收待确认
+发布候选
+```
+
+阶段开始、产物变化、阶段门确认或出现阻塞时，都要更新状态文件。
+
+## 执行流程
+
+### 1. 记录点子
+
+把用户的点子整理成简短的项目身份信息：暂定名称、一句话说明、目标用户、核心流程、交付形态和采用的默认值。不要评估这个点子是否值得做。
+
+除非存在会改变产品方向的歧义，否则立即基于这份理解起草需求。
+
+### 2. 固化需求——人工确认门 1
+
+根据 `assets/REQUIREMENTS.md.template` 创建或更新 `docs/REQUIREMENTS.md`。
+
+让每条规则都能被开发和测试。包含用户角色、用户流程、页面或接口、功能、业务规则、数据、权限、正常和异常流程、非目标以及验收标准。
+
+把阶段设为“需求待确认”，展示精简的范围摘要和变更文件，然后停止。请用户确认或提出修改。
+
+只有用户明确说出“需求确认”“通过，进入下一阶段”或同等明确的话语后才能继续。把确认记录到需求文档和状态文件中，并冻结当前版本范围。
+
+### 3. 生成实施方案——人工确认门 2
+
+根据 `assets/IMPLEMENTATION.md.template` 创建或更新 `docs/IMPLEMENTATION.md`。
+
+只依据已经冻结的需求和仓库约束制定方案。明确架构、技术栈、目录结构、路由、数据模型、接口、身份认证、存储、外部服务、状态流转、失败处理、安全、可观测性、环境、测试、验证命令、部署形态和有序的纵向功能切片。
+
+把阶段设为“实施方案待确认”，展示关键技术决策和变更文件，然后停止。不得创建项目骨架或编写产品代码。
+
+只有用户明确确认实施方案后才能继续。记录确认人和确认时间。
+
+### 4. 生成并验证项目骨架——人工确认门 3
+
+把阶段设为“骨架构建中”。只构建已确认方案中定义的基础工程：项目初始化、目录、依赖、配置示例、质量工具、必要的数据库与迁移机制、基础布局、健康检查、错误与日志基础以及最小冒烟测试。
+
+不得提前实现计划中的产品功能。实际运行文档中规定的安装、格式或静态检查、类型检查、测试和生产构建命令，并把准确命令和结果记录到 `docs/IMPLEMENTATION.md`。
+
+把阶段设为“骨架待确认”，总结项目结构、验证结果、尚未配置的外部服务和建议的第一个纵向功能，然后停止。
+
+只有用户明确确认项目骨架后才能开始产品功能开发。确认后记录结果，并把阶段设为“纵向功能开发”。
+
+### 5. 按纵向功能开发
+
+根据 `assets/FEATURES.md.template` 创建或更新 `docs/FEATURES.md`，从已确认的实施方案生成有序的功能切片清单。
+
+每次只完成一个切片。每个切片必须覆盖所有适用的界面、服务或接口、数据持久化、身份与权限、输入校验、加载/空白/成功/失败状态、重试与幂等、日志、自动化测试和人工验证步骤。
+
+每个切片按以下步骤执行：
+
+1. 标记为“进行中”。
+2. 修改前先检查现有代码。
+3. 只实现当前切片及其直接前置条件。
+4. 运行相关检查，并在风险相称时运行完整检查套件。
+5. 工具允许时，人工操作验证核心流程。
+6. 记录证据并标记为“已完成”，不得标记为已经获得人工验收。
+
+除非遇到阻塞或用户要求暂停，否则持续完成已确认的切片清单。新功能想法只记录到后续版本，不得加入当前版本。
+
+### 6. 执行功能验收——人工确认门 4
+
+把阶段设为“功能验收中”。根据 `assets/ACCEPTANCE.md.template` 创建或更新 `docs/ACCEPTANCE.md`。
+
+把每条冻结需求和验收标准映射到具体实现与验证证据。运行全部必要的静态检查、测试、生产构建、迁移验证、权限与数据隔离检查、密钥检查、失败恢复检查和可执行的端到端流程。
+
+修复冻结范围内能够明确判断的实现缺陷，增加回归测试，并重新运行受影响的检查。把结果分为已通过、未通过、仅能人工验证、已知限制、发布阻塞项和非阻塞项。
+
+自动验收不存在发布阻塞项后，把阶段设为“验收待确认”，提供准确的人工测试步骤，然后停止。必须由用户明确报告验收通过，不能只凭 AI 的验证结果标记为通过。
+
+用户明确验收通过后，记录结果并把阶段设为“发布候选”。除非用户另外要求部署，否则不得自行部署。
+
+## 阶段门回复格式
+
+每个人工确认门都只使用以下栏目回复：
+
+```text
+阶段结果
+关键内容
+验证证据
+需要你确认
+确认后下一步
+```
+
+保持回复简洁，并链接相关项目文件。明确说明尚未开始下一阶段。

idea-to-product/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "点子落地"
+  short_description: "将软件点子按四个人工确认阶段推进到功能验收与发布候选版本"
+  default_prompt: "使用 $idea-to-product 将这个已通过的软件点子推进到功能验收，并在每个开发前阶段等待我的明确确认。"

idea-to-product/assets/ACCEPTANCE.md.template

@@ -0,0 +1,34 @@
+# 功能验收
+
+状态：草稿
+版本：0.1.0
+验收人：
+验收时间：
+
+## 需求追踪
+
+| 验收标准 | 具体实现 | 自动验证证据 | 人工验证证据 | 结果 |
+|---|---|---|---|---|
+
+## 自动化检查
+
+## 端到端流程
+
+## 安全与数据隔离检查
+
+## 迁移与生产构建检查
+
+## 已通过
+
+## 未通过
+
+## 仅能人工验证
+
+## 已知限制
+
+## 发布阻塞项
+
+## 非阻塞项
+
+## 人工验收步骤
+

idea-to-product/assets/AGENTS.md.template

@@ -0,0 +1,31 @@
+# 从点子到产品工作流
+
+## 唯一事实来源
+
+- `docs/REQUIREMENTS.md` 是当前版本产品范围的唯一来源。
+- `docs/IMPLEMENTATION.md` 保存已经确认的技术实施方案。
+- `.ai-project/state.yaml` 记录当前阶段和人工确认结果。
+- `docs/FEATURES.md` 记录纵向功能切片进度。
+- `docs/ACCEPTANCE.md` 记录验收证据。
+
+## 人工确认门
+
+- 完成需求草案后停止，等待明确人工确认。
+- 完成实施方案后停止，等待明确人工确认。
+- 生成并验证项目骨架后停止，等待明确人工确认。
+- 三个阶段门全部通过前，不得开始纵向功能开发。
+- 完成功能验收后停止，等待明确人工确认。
+
+## 开发规则
+
+- 默认项目已经立项，不进行市场、竞品、需求价值或商业价值分析。
+- 不得扩大已经冻结的当前版本范围。
+- 新想法记录到后续版本。
+- 每次只开发一个完整的纵向功能切片。
+- 每个切片覆盖所有适用的界面、接口或服务、数据持久化、权限、校验、异常状态、日志和测试。
+- 修改前先检查现有代码。
+- 实际运行项目规定的格式或静态检查、类型检查、测试和生产构建。
+- 不得通过删除或跳过测试获得通过结果。
+- 绝不提交真实密钥。
+- 保留与当前任务无关的用户修改。
+

idea-to-product/assets/FEATURES.md.template

@@ -0,0 +1,23 @@
+# 纵向功能
+
+需求版本：0.1.0
+
+允许的状态：“待开始”“进行中”“已完成”“已阻塞”。
+
+## 当前版本功能切片
+
+### F-001——功能名称
+
+- 状态：待开始
+- 用户可见结果：
+- 页面与交互：
+- 服务或接口：
+- 数据持久化：
+- 权限与校验：
+- 异常状态：
+- 自动化测试：
+- 验证命令与结果：
+- 人工验证步骤：
+- 已知限制：
+
+## 后续版本想法

idea-to-product/assets/IMPLEMENTATION.md.template

@@ -0,0 +1,41 @@
+# 实施方案
+
+状态：草稿
+需求版本：0.1.0
+确认人：
+确认时间：
+
+## 约束与默认值
+
+## 技术栈
+
+## 系统架构
+
+## 目录结构
+
+## 路由与接口
+
+## 数据模型与迁移
+
+## 身份认证与权限
+
+## 外部服务与存储
+
+## 状态流转
+
+## 校验、失败、重试与幂等
+
+## 安全、日志、监控与密钥
+
+## 本地、测试与生产环境
+
+## 自动化测试方案
+
+## 验证命令
+
+## 有序的纵向功能切片
+
+## 项目骨架验证证据
+
+记录命令、日期、退出状态和简要结果。
+

idea-to-product/assets/REQUIREMENTS.md.template

@@ -0,0 +1,39 @@
+# 产品需求
+
+状态：草稿
+版本：0.1.0
+确认人：
+确认时间：
+
+## 项目身份
+
+- 项目名称：
+- 一句话说明：
+- 目标用户：
+- 交付形态：
+- 采用的默认值：
+
+## 当前版本范围
+
+## 用户角色与权限
+
+## 核心用户流程
+
+## 页面或接口
+
+## 功能需求
+
+## 业务规则
+
+## 数据与状态
+
+## 正常、异常和边界流程
+
+## 本版本不做
+
+## 验收标准
+
+每条标准使用 `AC-001` 这样的稳定编号。
+
+## 后续版本想法
+

idea-to-product/assets/state.yaml.template

@@ -0,0 +1,26 @@
+工作流: "idea-to-product"
+项目: ""
+版本: "0.1.0"
+当前阶段: "需求起草"
+更新时间: ""
+阻塞: null
+
+阶段门:
+  需求:
+    状态: "草稿"
+    确认人: null
+    确认时间: null
+  实施方案:
+    状态: "未开始"
+    确认人: null
+    确认时间: null
+  项目骨架:
+    状态: "未开始"
+    确认人: null
+    确认时间: null
+  功能验收:
+    状态: "未开始"
+    确认人: null
+    确认时间: null
+
+功能: []

idea-to-product/references/stage-gates.md

@@ -0,0 +1,65 @@
+# 阶段门
+
+使用以下检查表判断某个阶段是否已经具备提交人工确认的条件。“可以提交确认”不等于“已经获得确认”。
+
+## 1. 需求阶段门
+
+- 项目点子已经被完整表达，没有市场或价值分析。
+- 当前版本范围和明确不做的内容清晰。
+- 用户角色、核心流程、页面或接口、数据、权限和业务规则具体。
+- 正常、异常、边界和未授权流程已经覆盖。
+- 验收标准可观察、可测试。
+- 会改变产品方向的未决问题已经列出。
+- `docs/REQUIREMENTS.md` 标记为“待确认”。
+
+获得明确确认后，先标记为“已确认”和“已冻结”，然后才能制定实施方案。
+
+## 2. 实施方案阶段门
+
+- 每条冻结需求都有明确的实现位置。
+- 技术选择和关键默认值清晰。
+- 架构和目录结构符合小工作室的规模。
+- 数据模型、接口、身份认证、权限、外部服务和失败处理已经定义。
+- 验证命令和部署假设已经列出。
+- 纵向功能切片有明确顺序，每个切片都会产生用户可见结果。
+- 本阶段没有创建产品代码或项目骨架。
+- `docs/IMPLEMENTATION.md` 标记为“待确认”。
+
+获得明确确认后，先标记为“已确认”，然后才能生成项目骨架。
+
+## 3. 项目骨架阶段门
+
+- 项目能在文档规定的开发环境中启动。
+- 已配置必要的质量、类型、测试和构建命令。
+- 文档规定的验证命令都已经实际运行。
+- 环境变量已经记录，但没有写入真实密钥。
+- 必要时已经建立数据库迁移、日志与错误处理基础和健康检查。
+- 没有提前实现计划中的产品功能。
+- 准确命令和结果已经记录。
+- 已明确第一个纵向功能切片。
+
+获得明确确认后才能进入“纵向功能开发”，不得提前进入。
+
+## 4. 功能验收阶段门
+
+- 每条冻结验收标准都映射到代码和证据。
+- 全部必要的自动化检查和生产构建通过。
+- 已检查权限和数据隔离。
+- 适用时，失败、超时、重试和重复提交场景都有证据。
+- 适用时，数据库迁移安全且可复现。
+- 没有密钥被提交或暴露给客户端。
+- 发布阻塞项为空。
+- 仅能人工执行的步骤准确且可复现。
+
+只有用户可以确认功能验收通过。
+
+## 确认处理规则
+
+有效确认必须明确指向当前等待确认的阶段，并授权进入下一阶段。例如：
+
+- “需求确认，进入实施方案。”
+- “实施方案通过。”
+- “骨架确认，可以开始开发。”
+- “功能验收通过。”
+
+要求解释、部分认可、保持沉默或只批准其中一小部分，都不能视为阶段确认。如果用户要求修改，保持阶段门为等待确认状态；修改完成后重新提交确认。