with one click
changelog
创建并维护 CHANGELOG.md。在初始化变更日志、从 git 历史中提取未发布变更、或准备发布某个版本时使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Menu
创建并维护 CHANGELOG.md。在初始化变更日志、从 git 历史中提取未发布变更、或准备发布某个版本时使用。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
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 框架的引导纲要(bootstrap doctrine)。在会话开始时自动加载,用以介绍 lifecycle map、golden rules,以及如何挑选正确的 harness-stack:* skill。在一次会话中首次调用任何 harness-stack:* skill 之前,先读它。
复盘一次 harness-stack 使用,把值得上报的摩擦、缺陷或建议提成 GitHub Issue 反馈给上游。在完成一项任务、用完某个 skill 后有意见或改进想法,或想为框架本身留下改进线索时使用。
| name | changelog |
| description | 创建并维护 CHANGELOG.md。在初始化变更日志、从 git 历史中提取未发布变更、或准备发布某个版本时使用。 |
按 Keep a Changelog 1.1.0 与语义化版本(Semantic Versioning)维护 CHANGELOG.md。
| 场景 | 子流程 |
|---|---|
项目里还没有 CHANGELOG.md | references/init-template.md |
把近期 git 改动收进 [Unreleased] | references/extract-changes.md |
发布——把 [Unreleased] 移到一个带日期的版本标题下 | references/new-version.md |
初始化完成后,按需再分流到 extract 或 new-version。每个子流程各自管自己的规则、草稿与校验;在用户确认草稿前,绝不写入文件。
不影响用户的内部重构、测试、CI/构建、或纯文档改动。