القائمة
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/。