菜单
harness-stack 框架的引导纲要（bootstrap doctrine）。在会话开始时自动加载，用以介绍 lifecycle map、golden rules，以及如何挑选正确的 harness-stack:* skill。在一次会话中首次调用任何 harness-stack:* skill 之前，先读它。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
FDD 主流程 step 1（规划与拆解）。覆盖两段——plan（与用户弄清需求、经 investigator 调查代码库、定出 milestone、写出 plan.md 并呈现）与 features（把 milestone 拆成 features.json 并过 coverage 闸）。中间的 contract 段交给 harness-stack:fdd-validation-contract。由 harness-stack:fdd 调用。
构建新特性的主流程编排器。契约优先的多 agent 架构——捕获一个 plan，定义可测试的断言，拆解为多个 feature，再用全新上下文的 implementer/reviewer/validator subagent 驱动一个里程碑设闸的执行循环。当一处改动触及多个文件、有多条验收标准、或跨越多个 feature 时使用。主流程分三步，分发给 fdd-planning（含 fdd-validation-contract）/ fdd-execution / fdd-validate。
为一个 plan 撰写 validation contract——把 definition of done 落成一组可测试、用户可观测的 assertion（VAL-<AREA>-NNN），带 persona 与声明的 Evidence。它是 fdd step 1（规划）里的 contract 阶段。契约通过逐 area 的 investigation subagent 与若干轮 adversarial review 构建，而非一人独写。产出 .harness-runtime/plans/<slug>/validation-contract.md，并经由 fdd init-state 播种 validation-state.json。在项目内首次使用时，还会 bootstrap 项目级约定文档 docs/user-test-patterns.md。
规范 git 工作流实践。任何代码改动都适用。在提交、开分支、解决冲突，或需要把多条并行工作线组织起来时使用。
复盘一次 harness-stack 使用，把值得上报的摩擦、缺陷或建议提成 GitHub Issue 反馈给上游。在完成一项任务、用完某个 skill 后有意见或改进想法，或想为框架本身留下改进线索时使用。
FDD 主流程 step 2——执行循环。串行驱动 feature 构建：next-feature → 派 implementer → handoff 决策树 → complete。每个 feature 由交接决策树把关（核验 implementer 自验留下的证据）。静态验证 → 代码审查 → user-test 这条验证流水线在里程碑收口（fdd-validate scope=milestone）与循环跑空（scope=final）批量跑。由 harness-stack:fdd 在 features.json 通过 coverage 后调用。
| name | using-harness-stack |
| description | harness-stack 框架的引导纲要（bootstrap doctrine）。在会话开始时自动加载，用以介绍 lifecycle map、golden rules，以及如何挑选正确的 harness-stack:* skill。在一次会话中首次调用任何 harness-stack:* skill 之前，先读它。 |
harness-stack 是一个 agent-first 的开发框架。人类给出方向；agent 通过一份固定的 harness-stack:* skill 目录来执行，每个 skill 各自负责软件 lifecycle 的一个阶段。本文档是入口——它告诉你该取用哪个 skill，而不是每个 skill 内部如何运作。
一项 non-trivial 改动会经过这些阶段。挑选与当前阶段相符的 skill，而不是下一个阶段的。
| Phase | Trigger | Skill |
|---|---|---|
| Define | what/why 尚不清晰 | harness-stack:define-product、harness-stack:define-architecture、harness-stack:define-api-spec、harness-stack:define-frontend-spec、harness-stack:define-ui-spec（一次性、项目级） |
| Design（可选） | 方案含糊；技术路线应当先论证 | harness-stack:design —— 一份独立的技术文档 → docs/design-docs/。不是 main flow 的一步；FDD 在其存在时会读它。 |
| Build（main flow） | 任何 non-trivial 改动 | harness-stack:fdd —— 编排器，你只直接调它。它把主流程分成三步：harness-stack:fdd-planning（plan + contract + features，其中 contract 段交给 harness-stack:fdd-validation-contract）、harness-stack:fdd-execution（执行循环）、harness-stack:fdd-validate（milestone / 最终 gate）。implementer 的任务内用 harness-stack:tdd（test-first）。 |
| Verify | 有东西坏了或未经验证 | harness-stack:debug（root cause）、harness-stack:fdd-validate（验证流水线：静态 → 审查 → user-test；对照 contract 断言探测运行中的系统、写入 validation-state.json） |
| Review | 改动已就绪、可供审视 | harness-stack:review-request（派发）、harness-stack:review-receive（处理发现）、harness-stack:security（安全审计） |
| Deliberate | 问题有争议或高风险 | harness-stack:debate（多轮）、harness-stack:decide（一次性并行） |
| Ship | 代码已获批 | harness-stack:commit → harness-stack:pr（开 PR 并推进到合并）→ harness-stack:changelog → harness-stack:ship |
| Meta | 管理框架本身 | harness-stack:docs-init、harness-stack:env-init、harness-stack:skill-create |
Trivial 的工作（一行修复、错别字、显而易见的重命名）跳过 lifecycle。请用判断力：这些 skill 的存在是为了防止跳过它们所带来的失败模式，而不是走形式。
这些规则在每个 skill 中都成立。完整文本见 references/golden-rules.md。
packages/ 下，通过 pnpm workspaces 管理。@hs/llm（packages/hs-llm/）是无状态的 LLM provider 抽象（api / cli / sdk / mock）。调用模型的 skill 都经由它。@hs/fdd（packages/fdd/）是 feature-driven development 的确定性记账 CLI。FDD skill 把所有 per-plan 的状态转移都委托给它。它以预构建单文件 bundle（packages/fdd/bin/fdd.mjs，依赖已内联）随插件分发——不装进系统、不现场编译，经 node <plugin-root>/packages/fdd/bin/fdd.mjs 调用；skills 里的 fdd <subcommand> 都是它的简写。定位与使用见 <plugin-root>/references/fdd-cli.md。harness-stack: 这个 plugin 命名空间寻址（例如 harness-stack:fdd、harness-stack:code-reviewer）；plugin 名提供了冲突隔离，因此单个 skill 与 agent 不再带额外前缀。docs/ 是项目的 Library：长期约定 + 记忆（architecture、design-docs、references、golden-rules、测试约定）。具体需求与实现以 Code is the source of truth 为准。.harness-runtime/plans/<slug>/ 下——gitignored，绝不放进 docs/。