fdd

FDD 主流程 step 1（规划与拆解）。覆盖两段——plan（与用户弄清需求、经 investigator 调查代码库、定出 milestone、写出 plan.md 并呈现）与 features（把 milestone 拆成 features.json 并过 coverage 闸）。中间的 contract…

在全局层面定义 frontend 工程约定与质量标准。在启动新 frontend 项目、frontend-spec.md 缺失或过时、或需要确立组件模式、accessibility 标准或 performance budget 时使用。产出 docs/frontend-spec.md，作为 frontend…

FDD 主流程 step 2——执行循环。串行驱动 feature 构建：next-feature → 派 implementer → handoff 决策树 → complete。每个 feature 由交接决策树把关（核验 implementer 自验留下的证据）。静态验证 → 代码审查 → user-test…

为一个 plan 撰写 validation contract——把 definition of done 落成一组可测试、用户可观测的 assertion（VAL-<AREA>-NNN），带 persona 与声明的 Evidence。它是 fdd step 1（规划）里的 contract 阶段。契约通过逐…

FDD 的验证流水线——里程碑 / 最终批量闸。一条线性、成本递增的三级 gate：静态验证（scrutiny-validator 硬门禁 test/lint/type-check + 逐 feature scrutiny）→ 代码审查（code-reviewer，逐 feature）→…

在全局层面定义系统 architecture。在启动新项目、architecture.md 缺失或过时、或系统结构发生重大变化时使用。产出 docs/architecture.md，作为系统的结构地图。

为某个具体实现决策撰写一份 design doc（docs/design-docs/）。独立、由人触发——不属于主 build 流程。当一个解法足够含糊、技术路线应在动工前先论证清楚时使用；涵盖 feature design、技术性重构、架构决策与迁移。

构建并打磨项目的领域模型：在设计讨论中澄清术语、压测概念边界，并记录当场确定的定义和决策。

维护项目长期知识。用于已确认的行为、架构边界、术语、决策或操作方式发生变化，或把已验证的调查结论整理为可复用知识。

在 harness-stack 仓库里新增、拆分或调整 skill 时使用——决定调用方式、落位与注册、按约定写作、并实测插件能加载它。只管 harness-stack 自身约定，不教通用的 skill 写作方法。

为并行开发初始化每个 worktree 独立隔离的 runtime 环境。在创建新 worktree、dev server 因 port 或 database 冲突、或首次为某个项目搭建多 worktree 并行开发时使用。

在项目层面定义 API spec。在启动带 API 的项目、api-spec.md 缺失或过时、或跨服务出现 API 不一致时使用。产出 docs/api-spec.md，作为权威的 API contract。