mcpField
W
workflow-project-intake

workflow-project-intake

github.com/heyvhuangAgent 工作流33849 次安装30 周前更新
代码仓库

关于 workflow-project-intake

用于项目入口梳理与需求澄清的技能，面向想法尚不明确或需要为已有项目选择执行路径的团队。它将对话收敛为文件化、可追踪的执行输入，再移交给相应工作流。

主要功能

  1. 01澄清目标与验收标准
  2. 02逐次提出一个问题
  3. 03将状态和产物写入文件
  4. 04写操作前设置审批检查点
  5. 05按项目需求选择后续工作流

适用场景

  1. 01把初步想法整理成可执行需求
  2. 02为现有代码库明确项目范围和路线
  3. 03在执行外部写操作前收集确认

安装

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

$npx skills add https://github.com/heyvhuang/ship-faster --skill workflow-project-intake

安装后在 Claude Code 中输入/workflow-project-intake确认已加载。

详细介绍

项目接入（头脑风暴 + 澄清 + 路由）

将技能视为“无状态执行单元”，把所有状态外置到文件系统。

此技能定位为**“项目入口 / 需求澄清”**：

  • 当用户只有模糊想法时：帮助他们澄清需求（最小信息集），然后再进入执行链
  • 当用户提供代码仓库 / 明确目标时：快速确认理解，然后进入正确的工作流 / 步骤

此技能不负责实际的大规模实现（这是 workflow-ship-faster / workflow-feature-shipper 等执行技能的工作）。它负责将“对话”收敛为“可执行输入”，然后移交控制权。

核心原则（必须遵循）

  1. 只传路径，不传内容：智能体 / 子智能体只传递 ..._path，让执行者自行读取文件。
  2. 文件是头等公民：每个步骤都必须持久化产物；失败后可以重试；可以重放；可以追踪。
  3. 写操作必须设有检查点：任何带有外部副作用的操作（删除 / 修改云资源 / 数据库写入 / 退款 / 取消订阅）都必须先写入计划，并等待用户明确确认。
  4. 一次只问一个问题：如果信息缺失，可以追问，但每条消息只问 1 个问题（优先选择题）；复杂主题分多轮询问。
  5. Hooks doctor（必需检查；非阻塞）：如果在 Claude Code 下运行且希望启用演进循环，请尽早运行一次 tool-hooks-doctor；如果缺少 hooks，则提出安装项目级 hooks（无论如何都继续）。

0）头脑风暴模块（取代旧方法）

当用户输入仍是“想法 / 方向 / 模糊需求”时，先使用 workflow-brainstorm 模块将其完善为可执行设计，然后进入接入检查清单。

workflow-brainstorm 模块要求：

  • 如果存在代码仓库，先检查项目上下文
  • 一次只问 1 个问题（优先选择题）
  • 提供 2-3 个选项，并说明各自的权衡
  • 分段输出设计（每段约 200-300 字），每段末尾询问“这样看起来可以吗？”

需要整理出的最小信息集（接入检查清单）

将用户输入收敛为以下信息（询问缺失的部分；如果用户已经提供，则不要重复询问）。

提问流程（必需）：

  • 每条消息只问 1 个问题
  • 优先使用选择题；仅在必要时使用开放式问题
  • 先问决定方向的问题（成功标准 / 非目标 / 约束），再问实现细节
A）入口类型
  • entry_type：idea | prototype
  • 如果是 prototype：repo_root（本地路径或代码仓库链接）
B）成功标准（必需）
  • 用户希望首先实现的“一个核心循环”（一句话）
  • 验收标准（3-5 项）
  • 明确的非目标（1-3 项）
C）Ship Faster 关键开关（必须澄清）
  • need_database：是否需要数据库（默认 Supabase）
  • need_billing：是否需要计费 / 支付（默认 Stripe）
  • need_auth：是否需要身份验证（默认：false）
  • need_deploy：是否需要部署到生产环境（默认 GitHub + Vercel）
  • need_seo：是否需要 SEO（sitemap/robots/llms.txt 等）
D）约束（可选，但建议提供）
  • 上线时间表（如有）
  • 风险偏好（激进 / 保守）
  • 现有设计约束（品牌颜色 / 字体 / 现有组件库）

运行目录规范

默认（推荐）：在目标项目根目录下创建：runs/<workflow>/active/<run_id>/

OpenSpec 兼容模式（存在 openspec/project.md，或用户通过 context.json 强制启用时）：

  • 活跃目录：openspec/changes/<change-id>/
  • 归档目录：openspec/changes/archive/YYYY-MM-DD-<change-id>/

后端选择规则（确定性）：

  1. 如果 context.json 包含 "artifact_store": "runs" 或 "openspec"，则遵循该设置。
  2. 否则，如果 repo_root 中存在 openspec/project.md，则使用 OpenSpec 模式。
  3. 否则，使用 runs/。

推荐结构（OpenSpec 风格，流程精简）：

  • proposal.md：用户目标（原始问题 + 预期输出 + 约束条件 + 验收标准 + 非目标）
  • tasks.md：可执行检查清单（- [ ] → - [x]）+ 审批关卡
  • context.json：关键信息（repo_root、need_* 开关、风险偏好、已知 ID）
  • evidence/（可选）：各分析器提供的证据/分析（大型输出不要放在聊天中）
  • logs/（可选）：
    • events.jsonl：结构化事件日志（每个步骤追加一行）
    • state.json：可选的机器可读状态（下一步是什么／哪些事项已完成）

归档约定（完成后）：将 active/<run_id>/ 移至 archive/YYYY-MM-DD-<run_id>/

事件日志格式（推荐）

每行一个 JSON：

{"ts":"2026-01-11T12:00:00Z","step":"evidence","action":"cloudflare.query_worker_observability","status":"ok","artifacts":["evidence/observability.md"],"note":"p95 latency spike"}

不要记录敏感内容（token/email/phone/secret）。必要时写入脱敏版本。

检查点协议（写入操作必需）

执行写入操作前：

  1. 在 tasks.md 的 Approvals 部分写入审批计划（对象 ID、影响范围、验证方法）
  2. 在对话中展示相同摘要，并等待用户明确回复“confirm/yes/proceed”
  3. 仅在用户确认后执行，并将结果写入 evidence/（以及可选的 logs/events.jsonl）

产物（此 Skill 必须持久化）

在路由／执行前，将澄清结果写入：

  • proposal.md：目标、范围、验收标准、非目标、时间线
  • context.json：repo_root、entry_type、need_* 开关、风险偏好等

如果本次 Intake 包含“设计规范”阶段（来自 workflow-brainstorm 模块），还要持久化：

  • evidence/YYYY-MM-DD-<topic>-design.md：已确认的设计和关键决策，供下游规划／实施参考

注意：

  • 如果文件已存在：仅补充缺失字段／追加信息，不要盲目覆盖（避免与下游工作流重复写入）
  • 目标是让下游工作流无需再进行一轮澄清即可“直接开始运行”

context.json（推荐的最简结构）：

{
  "entry_type": "idea",
  "repo_root": "",
  "scope": "full",
  "artifact_store": "auto",
  "need_database": false,
  "need_billing": false,
  "need_auth": false,
  "need_deploy": false,
  "need_seo": false
}

路由：选择哪个工作流／Skill（默认优先快速交付）

优先建议：

  1. 从创意／小型原型到上线（默认）：使用 workflow-ship-faster
  • workflow-ship-faster 默认会将产物持久化到 runs/ship-faster/active/<run_id>/（或在选择 OpenSpec 模式时写入 openspec/changes/<change-id>/），并根据 context.json 开关决定是否执行 DB／支付／部署／SEO 等可选步骤
  • 仅需样式／设计系统：使用 tool-design-style-selector
  • 仅需迭代一个功能（拆分并交付）：使用 workflow-feature-shipper
  • 仅需审查 React/Next.js 性能（瀑布流／包体积／重复渲染）：使用 review-react-best-practices
  • 仅需执行 DB 侧操作（SQL／迁移／日志／类型生成）：使用 supabase skill
  • 仅需执行 Stripe 侧操作（产品／价格／支付链接／退款等）：使用 stripe skill

如果不确定：先完成 Intake 清单 → 写入 proposal.md/context.json → 然后再路由（不要一开始就执行大型操作）。

结束时的对话收敛（必需）

在将控制权交给下游技能之前，以 3 段内容结束此技能：

  1. 重述理解（目标 + 验收标准 + 非目标）
  2. 说明要采取的路径（默认使用 workflow-ship-faster，并解释原因）
  3. 询问用户是否要现在开始执行：
    • “准备好开始 workflow-ship-faster 了吗？（默认会将产物写入项目中的 runs/ship-faster/active/<run_id>/，并且在执行关键写入操作前需要确认）”

并行执行（子 Agent）

出现以下任一情况时，将工作拆分为并行子任务：

  • 需要按目录/模块扫描
  • 需要按维度审查（命名/函数/重复项/……）
  • 需要生成多个备选方案（方案 A/B/C）

并行子任务约定：

  • 输入：仅接收路径（proposal_path、context_path、output_dir）
  • 输出：将产物写入 evidence/parallel/<task-name>/，并返回产物路径列表

从检查点恢复

再次运行时：

  • 首先读取 tasks.md；仅在存在 logs/state.json 且需要机器状态时才读取它
  • 不要重复已完成的步骤；只补齐缺失的产物，或从失败处继续

交付物（最低要求）

  • tasks.md：清单应反映实际情况，并包含执行摘要 + 后续步骤
  • 可选：用于追踪的 logs/events.jsonl

完成后，执行一次 skill-evolution Evolution checkpoint（3 个问题）；如果用户选择“想要优化”，则调用 skill-improver 审查本次运行并提出最小补丁建议。

评论

支持 Markdown