Delivery Harness Framework / Skill Inventory

DHF 每一步由哪些 Skill 接管。

本页把当前 DHF 工作流程拆成逐步矩阵:每一步使用哪些 Skill、这些 Skill 具体做什么,并附上对应的 GitHub 源码链接。

How to read this

DHF 先路由,再委托给专用 Skill。

生命周期路由器负责恢复持久状态、判断阶段和 execution lane、选择专用工作流。Helper scripts 负责验证 requirements、agent plan、evidence 和 checkpoint;本页聚焦 Skill,因为它们定义每个阶段中 agent 应该怎样行动。

Step 01

恢复与路由

从 repo 持久状态启动或恢复复杂任务,然后选择下一步工作流。

delivery-harness-framework

读取 repo 指南、恢复当前阶段、分类生命周期、选择下一步 skill/helper,并明确验证证据门槛。

GitHub 源码
shipq-lifecycle-harness

repo-specific lifecycle adapter 示例。已知项目需要业务路径、本地命令、fixtures 或部署边界时,由它接管。

GitHub 源码
Step 02

需求澄清

把模糊目标变成成功标准、范围、约束和可作为 source of truth 的材料。

planner

分析复杂需求、架构上下文、任务拆解与风险,在改代码前把问题边界理清。

GitHub 源码
req-to-dev

把需求或原则文档转成可执行开发包,包括计划、安全网、契约、验收测试和 owner 分工。

GitHub 源码
vendored gstack spec

把模糊实现意图转成 backlog-ready issue、ticket 或 executable spec,同时保留 DHF 的 source-of-truth、lane 和验证边界。

GitHub 源码
Step 03

计划锁定

在进入实现前锁定产品、工程、设计和执行顺序。

delivery-harness-framework

当 durable sources 冲突时,DHF 拥有 architecture alignment checkpoint:先比较产品、流程、组件、数据归属、lane、安全、切片和 handoff state,再进入编辑。

GitHub 源码
gstack-plan-eng-review

审查架构、数据流、边界情况、测试覆盖、性能和运维风险;gbrain 已配置时可读取结构化规划上下文。

GitHub 源码
gstack-plan-ceo-review

从产品与创始人视角压力测试定位、范围、用户价值和战略取舍。

GitHub 源码
gstack-office-hours

以 founder 或 builder office hours 方式暴露需求真实性、最窄切入点和产品想法是否值得继续;可使用 gbrain preflight。

GitHub 源码
gstack-plan-design-review

在 UI 实现前审查 UX 结构、视觉方向、响应式行为和设计验收标准;gbrain 只作为专用规划上下文,不替代 repo state。

GitHub 源码
task-flow-orchestrator

为复杂任务安排执行顺序,把 Karpathy 思考、规划、TDD 和验证组合成可执行流程。

GitHub 源码
planner / prototype route

throwaway prototype 只用于回答一个明确的数据模型、状态机、模块接口或 UI 问题;结束后删除原型或把结论写入 durable decision。

GitHub 源码
Step 04

开发实现

在文件/模块范围明确后,按风险选择测试优先或验收优先的实现路径。

tdd-guide

对功能、bug 修复、重构和核心业务逻辑执行 RED -> GREEN -> REFACTOR。

GitHub 源码
atdd-guide

从业务可读的验收场景开始,用可执行规格驱动实现和生产级验证。

GitHub 源码
gstack-investigate

遇到 bug、错误输出、断裂 UI flow 或 root cause 不明时,先建立可运行 feedback loop,再基于证据修复。

GitHub 源码
Step 05

验证证据

用 fresh command evidence 证明代码、文档或配置修改真的可用。

verification-loop

交付前执行构建、静态检查、测试、覆盖率和安全扫描等全量验证流程。

GitHub 源码
delivery-harness-framework

完成结论必须带 command、exit code、key output、timestamp、匹配 task demand 的验证门、effective feedback check,以及本地 evidence 存在时的 conversion health。

GitHub 源码
Step 06

Review 与 QA

在发布前发现回归、可见故障、安全风险和缺失测试。

gstack-review

做 pre-landing diff review,检查结构性风险、信任边界、副作用分支和合并准备度。

GitHub 源码
code-reviewer

审查 staged、unstaged 或 PR 变更,聚焦正确性、安全性、可维护性和项目规范。

GitHub 源码
review-swarm

并行运行只读 review agents,覆盖行为、安全、性能、可靠性和测试覆盖风险。

GitHub 源码
gstack-cso

做 infrastructure-first 安全与隐私审查,覆盖 auth、tokens、secrets、PII、审批、审计和公私边界。

GitHub 源码
security-reviewer

检查输入校验、认证授权、密钥泄漏、注入和错误信息泄露风险。

GitHub 源码
gstack-qa

系统化浏览器 QA,包含截图、console/network 检查、响应式检查和 bug 回归验证。

GitHub 源码
gstack-qa-only

当用户只要报告而不要自动修复时,执行只读浏览器 QA、截图、风险记录和 findings 汇总。

GitHub 源码
committee-review-loop

只有明确要求 committee、expert panel、reviewer/worker、rating loop 或目标评分时才路由到这里;普通 review 保持专用 route。

GitHub 源码
Step 07

委员会评分循环

仅在用户明确要求 committee/subagent review 和目标评分时使用。

committee-review-loop

组织三领域专家委员会评分并给出 findings,把 revision brief 交给 worker 修改,循环到目标分或遇到 blocker。

GitHub 源码
Step 08

发布与部署

用户明确要求发布时,才进入 commit、PR、merge、deploy 和生产监控。

gstack-ship

执行 opinionated ship workflow:识别 base branch、测试、review diff、更新 release metadata、commit、push、准备 PR。

GitHub 源码
gstack-land-and-deploy

在 ship 后合并与部署,等待 CI/deploy 完成,并验证生产健康状态。

GitHub 源码
gstack-canary

部署后监控 console errors、性能回退、页面失败和截图差异。

GitHub 源码
Step 09

交接与学习

跨 session 工作需要留下可恢复状态,并沉淀可复用经验。

gstack-retro

基于提交历史、工作模式和质量指标生成工程 retrospective。

GitHub 源码
gstack-learn

检索、整理、修剪和导出项目 learnings,让后续 session 复用已有经验。

GitHub 源码
gstack-plan-tune

调整重复规划问题、developer profile 和提问偏好;这是操作者偏好状态,不是 repo lifecycle state。

GitHub 源码
Step 10

文档发布

让 public docs、README、路由规范和 release notes 与已交付行为一致。

gstack-document-release

发布后同步 README、架构文档、CHANGELOG、TODOS 和 VERSION 等文档表面。

GitHub 源码
doc-updater

在功能、API 或架构变更后更新 docs、codemaps、README、指南、路径和示例。

GitHub 源码
skill-evaluator

评估一个 skill 是否应该存在、如何路由、需要哪些 eval,以及是否相对 baseline 有真实提升。

GitHub 源码
visual-explainer

生成自包含 HTML 图、流程图、架构视图和技术概念可视化说明。

GitHub 源码