mcpField
I
idea-to-design-doc

idea-to-design-doc

github.com/akoliteza生产力27457 次安装25 周前更新
代码仓库

关于 idea-to-design-doc

Idea to Design Doc Workflow 是一项引导用户将初步产品构想整理为设计文档和关联笔记的技能。访谈先聚焦产品意图与体验，待概念清晰后再讨论技术方向。

主要功能

  1. 01逐次提问的引导式访谈
  2. 02轻量和完整记录模式
  3. 03维护构想索引及独立 Markdown 笔记
  4. 04先梳理产品再讨论技术
  5. 05为待构建构想提出技术默认项并记录问题

适用场景

  1. 01梳理早期应用构想
  2. 02准备可长期使用的产品设计文档
  3. 03将多个构想整理为关联笔记

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/akoliteza/hermes-agent-idea-workflow --skill idea-to-design-doc

安装后在 Claude Code 中输入/idea-to-design-doc确认已加载。

详细介绍

从创意到设计文档的工作流

当用户说出以下内容时，使用此技能：

  • “我有一个应用创意”
  • “帮我完善这个产品”
  • “把这个想法整理成设计文档”
  • “帮我列出一些创意，并把每个创意链接到一条笔记”

目标

将粗略的创意转化为结构化设计文档，其中包含：

  1. 一份创意总索引
  2. 每个创意对应一条 Markdown 笔记
  3. 一场引导式访谈，直到用户说 stop、that's enough 或 done 才停止
  4. 产品创意、理念、预期体验，以及理解该应用所需的实际技术形态

此工作流从产品思考开始，只有在概念和理念明确后才进入技术层面。设计文档应记录用户的期望，以及足以支持后续制定构建计划的技术方向。

重要约束

  • 不要过早深入后端、框架、数据库设计或代码架构。
  • 首先记录产品意图、行为、受众、布局、功能、用户体验和理念。
  • 然后，在起草设计文档时，纳入相关技术方面：平台假设、主要系统组件、数据需求、集成、约束，以及可能的架构问题。
  • 对于 Full 模式或准备进入构建阶段的创意，先推荐合理的技术默认方案，再让用户接受或修改。只有在产品方向明确后，才讨论数据库/存储、托管/部署、后端/运行时、前端/界面、身份验证、目标平台和其他技术组成部分。
  • 尽可能一次只问一个问题。
  • 如果用户回答简短，就针对回答提出更具体的问题。
  • 如果用户说要停止，立即根据现有信息起草笔记。

默认存储布局

先将文件保存在本地，而不是直接保存到 Obsidian 库中。

建议的本地文件夹结构：

  • ./ideas/Ideas Index.md
  • ./ideas/<idea-title>.md

如果用户之后想导出到 Obsidian，将其作为单独的导出步骤处理。

Lite 与 Full 模式

快速记录创意时使用 Lite 模式：只询问足以生成实用笔记的问题。用户想要一份可长期使用的设计文档，或最终需要交接实施时，使用 Full 模式。

用户可以使用精确短语 GREENLIGHT NEXT STAGE 强制进入下一阶段。如果用户使用了此短语，就停止提问，根据现有信息起草文档，并将缺失信息记录在 待解决问题下。

访谈流程

按以下顺序提问，并根据用户的回答灵活调整。要设计更有针对性的提示，请参考 idea-superpowers-suite/references/interview-question-bank.md：

  1. 暂定标题
    • “这个创意暂时叫什么？”
  2. 问题 / 目的
    • “它解决什么问题，或用于什么？”
  3. 受众
    • “它面向谁？”
  4. 核心行为
    • “用户使用时，它应该做什么？”
  5. 主要用户流程
    • “用户应该能够从头到尾完成的主要操作是什么？”
  6. 关键功能
    • “哪些功能是必需的？”
  7. 布局 / 组织方式
    • “主要部分应该如何排列或分组？”
  8. 数据位置 / 托管偏好
    • “数据应该保存在本地、由用户自行托管、放到 Cloudflare/AWS/其他云平台，还是尚未决定？”
  9. 目标平台
    • “它应该仅限 Web，还是也需要 Windows 应用、Mac 应用、跨平台桌面应用、移动应用或响应式移动网页？”
  10. 推荐的技术默认方案
  • “根据这个创意，我推荐以下技术默认方案：<简短技术栈摘要>。你愿意接受这些方案，还是想修改其中任何部分？”
  1. 偏好 / 感受
  • “它应该给人什么感觉？简单、活泼、严肃、快速、平静，还是其他？”
  1. 非目标
  • “它不应该做什么？”
  1. 成功标准
  • “你如何判断这个创意已经足够完善，可以继续推进？”

访谈风格

使用以下提示：

  • “详细说说这部分。”
  • “接下来会发生什么？”
  • “能举个例子吗？”
  • “这是必需项，还是锦上添花？”
  • “你希望它简单一些，还是功能更丰富一些？”

如果用户不确定，提供轻量的选项，而不是提出开放式问题给用户施加压力：

  • “你希望它更像列表应用、概览页面，还是专注于单一用途的工具？”
  • “用户应该一次看到所有内容，还是一次逐步查看一个部分？”

停止条件

如果用户说了以下任意内容，请停止访谈并立即起草：

  • stop
  • that's enough
  • enough for now
  • done
  • draft it
  • write it up
  • GREENLIGHT NEXT STAGE

输出格式

起草时，生成一份 Markdown 笔记，结构如下：

# <Idea Title>

## One-line summary

## Problem / purpose

## Product philosophy

## Target user

## Core concept

## Desired behavior

## Key features

## Layout / information architecture

## UX / product notes

## Technical shape

## Data / integrations / platform needs

## Hosting / data location

## Platform targets

## Recommended technical defaults

## Non-goals

## Open questions

## Next steps

主索引格式

将 Ideas Index.md 维护为简单的创意笔记项目符号列表：

# Ideas Index

- [[Idea Title]] — short one-line summary
- [[Another Idea]] — short one-line summary

如果索引文件已存在，按字母顺序或最新优先顺序追加新创意，但保持顺序一致。

建议的响应方式

访谈期间：

  • 保持对话自然、简洁。
  • 提出一个问题，然后等待用户回答。
  • 聚焦于产品与设计思考。

用户停止时：

  • 清晰概括创意。
  • 在 待解决问题 下记录尚未确定的事项。
  • 在本地保存笔记。
  • 添加或更新本地索引。
  • 告知用户本地笔记路径。

质量标准

好的结果应便于日后回顾，并让人立即了解：

  • 这是什么
  • 面向谁
  • 应该如何运作
  • 哪些方面最重要
  • 哪些内容是有意排除在范围之外的

评论

支持 Markdown