用途
该技能是面向开发流程的前置设计工作流，位于 JetBrains thinkrail 项目中。它适用的时机是：在实现一个功能、一次行为变更或一个缺陷修复之前，无论改动多小，都应先经过这一流程。它不适用于提问、检查或不改变行为的编辑（例如修正错别字）。
其核心目标是：先得到一个用户理解并已接受的设计，将其记录在 spec-graph 的 task-spec 中，再据此构建，最后把结果反映到持久规格里，而不是直接做推测式实现。
工作流
- 定位（Orient）：使用 spec-graph 技能找到管控该区域的规格，其次阅读代码确认实现细节，不阅读无关规格；记下改动涉及、但未记录原因的非显然决策，作为后续提问项。
- 范围检查（Scope check）：若请求混合了独立的产品决策或子系统，应拆分处理，而不是把无关决策混进同一个 task-spec。
- 创建任务规格（Open a task-spec）：在
.thinkrail/context/TASK-<slug>.md创建状态为 draft 的 task-spec（含 id、title、parent 指向最近的模块），该文件被 gitignore，是唯一的临时设计产物，随答案落地持续更新。 - 缺陷分支（Bug?）：若请求报告的是错误行为，按 fixing-a-bug.md 执行，之后在第 5 步（实为功能）或第 8 步回到主流程。
- 产品阶段（Product phase）：先访谈“为什么做”再问“怎么做”——为什么需要、面向谁、用户会看到和做什么（含空态、错误态、边界态）、如何判断完成。按 asking-user-questions 概念技能分轮提问，直到无假设遗留；能用查证的事实就不问。答案记入 task-spec 的 Product 部分，并在做任何技术选择前用一个推断确认问题确认理解。仅当请求本身已提供全部信息时可跳过。
- 技术阶段（Technical phase）：访谈产品答案遗留的技术决策：约束、兼容性、如何验证，以及第 1 步记录决策的原因。若能说出被否决的替代方案（尤其涉及代码位置在服务端还是浏览器、契约还是展示），应连同权衡一并展示，而不是默默决定；将选定方案及原因、重要权衡、明确推迟项记入 Design 部分。
- 自审查后一次性评审：清除占位符、矛盾、意外扩大范围和歧义需求，然后呈现一份与改动规模相称的完整设计。仅在请求尚未批准时请求批准；用户调整则修订 task-spec。
- 构建（Build）：按已接受的设计实现。交付前自审查任务 diff：不得有静默的 lint/type 抑制、重复的非平凡推导、以代码注释承载的理由，或旧模式残留。
- 修订规格（Amend specs）：按 amending-specs.md 执行，将持久内容从临时 task-spec 移入归属规格。
若跳过提问或宿主没有提问 UI，不视为阻塞：把最佳假设记为未确认并继续。
良好 task-spec 的特征
- 限定为一项工作，规模匹配——小改动只需几行。
- 含 Request、Product（缺陷分支为 Bug）、Design、未确认假设和明确推迟项。
- 是临时的：持久内容在第 9 步移入归属规格，而不是复制。
警示信号
- 设计被接受前就编辑源码。
- 以“改动很小”或“请求已说明怎么做”为由跳过流程——工作流会缩放但不会关闭。
- 产品阶段未定就抛出技术选项。
- task-spec 中有用户未看过的 Design 部分。
- 未做第 9 步就交付——规格会随每一次被跳过的改动逐渐偏离代码。
结束
amending-specs.md 结束该工作流；若被请求，PR 生命周期工作随后单独进入 shipping-a-pr。
限制
资料未提供该技能的收费、价格、平台支持范围或量化效果信息，暂未提供。