com um clique
changelog
创建并维护 CHANGELOG.md。在初始化变更日志、从 git 历史中提取未发布变更、或准备发布某个版本时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
创建并维护 CHANGELOG.md。在初始化变更日志、从 git 历史中提取未发布变更、或准备发布某个版本时使用。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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 框架的引导纲要(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/构建、或纯文档改动。