mcpField
F
feature-vision

feature-vision

github.com/steveclarke开发3677 次安装今天更新
代码仓库

关于 feature-vision

feature-vision 是一项引导功能愿景文档编写的技能，面向按既定功能开发流程工作的团队。它通过五个阶段逐步收集信息，并生成愿景、未来规划和讨论摘要文档。

主要功能

  1. 01五阶段逐步需求探索
  2. 02按既定结构编写愿景文档
  3. 03明确 v1 范围与未来内容
  4. 04生成三份功能文档
  5. 05记录技术讨论与关键决策

适用场景

  1. 01从头梳理新功能的问题与方案
  2. 02明确首版交付内容及排除项
  3. 03为后续需求和规格阶段保留讨论记录

安装

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

$npx skills add https://github.com/steveclarke/dotfiles --skill feature-vision

安装后在 Claude Code 中输入/feature-vision确认已加载。

详细介绍

愿景文档

概述

通过引导用户完成重点明确的发现阶段，并按照既定的功能开发流程逐步构建各个章节，创建愿景文档。

按照既定的功能开发流程创建愿景文档。首先，阅读功能开发指南 @~/.local/share/dotfiles/ai/guides/feature-development-process.md，了解愿景文档的结构和方法。

注意：如果项目在 @project/guides/feature-development-process.md 中有本地版指南，也可以参考该版本，以了解针对项目的修改。

重要：首先创建 TODO 列表，用于跟踪愿景文档创建的 5 个阶段。将第一个阶段标记为 "in_progress"，其余阶段标记为 "pending"。

愿景文档结构

我们的愿景文档简洁聚焦，通常为 100–150 行，绝不超过 200 行。内容由概括逐步展开到具体细节：

必需章节：

  • 清晰的愿景陈述（一句话）
  • 目录（包含指向所有主要章节的链接）
  • 问题（什么出了问题、影响哪些人、为何重要）
  • 解决方案（如何解决、核心理念、关键能力）
  • 用户需求（按角色用简明的项目符号列出他们需要完成的事项）
  • 未来展望（简要概述，并引用单独的 future.md）
  • 范围（明确列出 v1 要交付的内容和不包含的内容）

愿景文档中不应包含：

  • 详细的业务论证或 ROI 计算
  • 部署细节（在哪里或如何运行——这些属于规格说明）
  • 技术实现细节（API、架构模式、架构——这些属于规格说明）
  • 详细的用户故事或验收标准（这些属于需求文档）
  • 分步骤的工作流或流程（这些属于需求文档）
  • 重复陈述相同信息的章节

流程：按顺序完成以下 5 个阶段

阶段 1：问题发现

提出重点明确的问题，以了解：

  • 我们要解决什么具体问题？
  • 谁会遇到这个问题？他们会受到怎样的影响？
  • 当前痛苦或繁琐的流程是什么？
  • 不解决这个问题会有什么后果？

一次只问一个问题——等对方回答后再继续。 不要使用官话——语言要自然、直接。

阶段 2：探索解决方案

询问：

  • 我们设想如何从高层次解决这个问题？
  • 我们的核心理念或方法是什么？
  • 我们需要哪些 3–5 项关键能力？
  • 这个解决方案有何不同或优势？
阶段 3：用户需求分析

在愿景层面使用合并后的用户角色：

  • 最终用户（所有用户类型）
  • 管理人员（合并所有员工类型——员工、管理员、组织管理员）
  • 产品团队（如相关）

避免细分角色——详细的角色划分应放在需求文档中。

对于每个合并后的角色，只询问：

  • 他们需要使用此功能完成什么？

**到此为止。**不要询问“当前的痛点”或“成功后有何不同”——这会与“问题”章节重复，且应放在需求文档中。

阶段 4：未来展望与范围探索

询问：

  • 后续阶段可以考虑哪些锦上添花的功能？
  • 我们明确要在 v1 中纳入哪些范围？（获取具体细节）
  • 我们明确不在 v1 中纳入哪些范围？

关键：详细、具体地了解 v1 实际要交付的内容——这将成为衔接需求文档的桥梁。

阶段 5：文档生成

生成前，务必彻底删去冗余内容：

  • 本节是否重复了其他章节的信息？
  • 本节是否只是在论证问题本身已经显而易见的内容？
  • 这是否属于规格层面的细节（部署、技术架构）？
  • 这是否属于需求层面的细节（详细工作流、验收标准）？

然后生成三份文档：

1. vision.md - 精简、聚焦的愿景文档：

  • 创建一句清晰的愿景陈述
  • 生成包含所有主要章节链接的目录
  • 编写愿景文档，并包含具体的范围章节
  • 从一般内容（问题、解决方案）逐步深入到具体内容（详细范围）
  • 全文遵循“拒绝企业套话”的原则
  • 在简短的未来可能性章节中引用 future.md
  • 总长度控制在 150 行以内——务必精简

2. future.md - 详细的未来增强计划：

  • 创建单独的详细 future.md 文档，列出所有未来功能
  • 按阶段组织（阶段 2、阶段 3 等）
  • 包含战略性未来愿景（如适用）

3. discussion-summary.md - 持续更新的讨论摘要文档：

  • 创建一份统一的讨论摘要，汇总所有阶段的内容
  • 包含「愿景阶段」章节，记录所有与愿景相关的讨论
  • 为需求、规格和计划阶段设置占位章节
  • 在关键决策日志中记录架构决策及其原因
  • 记录技术可行性讨论和实现思路
  • 记下已发现的技术限制或挑战
  • 列出应在需求／规格阶段解决的待解决问题
  • 添加「技术背景」章节，记录引用的文件和相关功能
  • 设置清晰的章节和目录
  • 本文档用于在整个功能生命周期中保存项目知识

关键原则

从一般到具体： 从高层次的问题和解决方案入手，最后以具体的范围细节收尾，自然衔接到需求阶段。

范围章节至关重要： 这里应以具体的列表说明 v1 将交付的内容。可以列出功能、工具或特性。此部分将愿景与需求衔接起来。

但不要包含：

  • 部署方式（预发布环境还是生产环境）——这属于规格范畴
  • 技术架构细节——这属于规格范畴
  • 排除某些内容的理由——只需列出不包含的内容，无须解释

单独整理未来内容： 为所有未来功能创建详细的 future.md 文档。愿景文档中只需简要概述未来规划。

拒绝企业套话： 优先使用人们易懂的表达。语言清晰、简单，避免术语和不必要的复杂措辞。

合并用户角色： 在愿景层面合并用户角色。详细的角色划分应放在需求文档中。

消除冗余（至关重要）： 我们是一个重视文档精简易读的小团队。每个章节都必须提供新信息。添加章节前，先问自己：“这是否重复了已有内容？”如果是，就删除。

需要避免的常见冗余模式：

  • 只是用企业套话重述问题的“商业论证”
  • 重复问题章节中痛点的“后果”章节
  • 问题已明确说明影响对象时，另设“受影响人群”章节
  • 用多个章节以不同方式罗列收益或价值
  • 在用户需求中同时详细列出“当前痛点”和“成功后的变化”（问题章节已涵盖）

保持简短： 愿景文档最多应为 100–150 行。如果超过 200 行，说明内容重复，或包含了规格／需求层面的细节。

指南

  • 一次只问一个问题，并等待回复
  • 完成每个阶段后更新 TODO 列表
  • 提问时保持自然随和，避免官腔
  • 聚焦当下有用的信息，避免空话
  • 参考提供的任何现有笔记或上下文
  • 务实一些——我们是一个重视文档易读、可执行的小团队
  • 在需求探索过程中，讨论技术可行性和架构很正常——请记录所有这些内容
  • 最后始终创建三份文档：vision.md、future.md 和 discussion-summary.md

入门流程

  1. 立即创建 5 阶段 TODO 列表
  2. 询问用户：“你正在处理哪个功能目录？请提供完整路径（例如 project/features/FT033-feature-name）”
  3. 询问用户：“如果你有现有笔记，请使用 @notes.md 或 @[filename].md 标记，以便我查看”
  4. 验证目录是否存在，并确认将在此处创建 vision.md、future.md 和 discussion-summary.md
  5. 查看所有标记的笔记文件
  6. 使用第一个问题开始第 1 阶段的问题探索
  7. 提问时聚焦明确的问题，并等待用户回答后再继续下一个问题
  8. 在对话过程中，记录技术和架构讨论，即使它们不直接写入 vision.md

discussion-summary.md 中需要记录的内容

本文档应采用以下结构，逐步积累各个功能开发阶段的上下文。对于愿景阶段，请创建完整的文档结构：

文档结构：

# Feature Name: Discussion Summary

Living document capturing technical discussions, research, decisions, and
context from all phases of feature development.

## Table of Contents
- [Vision Phase](#vision-phase)
- [Requirements Phase](#requirements-phase)
- [Spec Phase](#spec-phase)
- [Plan Phase](#plan-phase)
- [Key Decisions Log](#key-decisions-log)
- [Technical Context](#technical-context)

## Vision Phase
[Vision phase content goes here]

## Requirements Phase
*To be added during requirements phase.*

## Spec Phase
*To be added during spec phase.*

## Plan Phase
*To be added during plan phase.*

## Key Decisions Log
| # | Decision | Rationale | Phase |
|---|----------|-----------|-------|
[Decisions from vision phase]

## Technical Context
### Files Referenced
[Backend and frontend files referenced]

### Related Features
[Related feature references]

愿景阶段需包含的内容：

  • 确认的核心问题及讨论过的所有细节
  • 解决方案及其在讨论过程中的演变
  • 技术可行性讨论
  • 已作出的架构决策及其依据
  • 探讨过的实现思路（包括未采用的方案）
  • 技术选型及其原因（SDK、框架、协议）
  • 确认的技术约束
  • 与现有系统的集成点
  • 需求或规格阶段的待解决问题

关键决策日志：

  • 决策从 1 开始编号
  • 包含决策内容、依据以及“Vision”阶段标记
  • 后续阶段继续编号

技术上下文：

  • 列出讨论中提到的文件（后端和前端路径）
  • 记录可能受到影响的相关功能

**目的：**本文档用于在整个功能生命周期中保留项目经验。每个阶段都会添加相应章节，关键决策日志和技术上下文则会在所有阶段持续积累。

评论

支持 Markdown