关于 cli-forge
cli-forge 是 cli-forge 工作流的路由技能，面向需要管理 CLI 项目阶段的用户。它检查仓库状态、整理交接信息并选择后续阶段，本身不负责实现。
主要功能
- 01将请求归入七个工作阶段
- 02检查项目文件与流程状态
- 03生成 handoff.yml 交接契约
- 04从现有状态恢复中断流程
适用场景
- 01将新 CLI 项目请求转交设计阶段
- 02依据仓库状态恢复工作流
- 03将功能或验证请求交给对应阶段
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/cli-forge确认已加载。
附带文件contracts/handoff.yml.tplplanning-brief.md
详细介绍
cli-forge 路由器
将此父级技能作为完整 cli-forge
工作流的稳定入口。
此技能本身不执行任何设计、规划或实现工作。它的任务是识别当前阶段，根据仓库状态找出最早的未完成阶段，整理所需输入，并将工作路由到正确的子技能。
用途
充当接入层和流量控制器。
- 将请求归类到七个下游阶段之一：Design、Takeover、 Plan、Scaffold、Extend、Validate 或 Publish。
- 检查当前文件系统状态（目录、基础文件和验证报告是否存在）。
- 整理输入并生成
handoff.yml契约。 - 用户提供部分上下文时，恢复中断的工作流。
规范参考
入口检查
| # | 检查 | 来源 |
|---|---|---|
| 1 | 用户请求存在 | 用户 |
必需输入
- 用户请求（明确或含糊）
- 目标目录路径。重要：如果用户未提供项目路径，你必须主动搜索工作区中的
.cli-forge/目录，以定位当前项目。如果请求似乎针对一个尚未采用cli-forge的现有 Rust CLI 项目，则搜索可能的项目根目录，例如包含Cargo.toml和src/main.rs的目录，或明确询问用户路径。不要假定根目录就是目标项目。
工作流
- 阅读用户请求并判断预期结果。
- 检查文件系统以确定所处阶段：
- 目标目录不存在 + 新请求 -> 设计
- 存在
design-contract.yml，但不存在cli-plan.yml-> 规划 - 已有项目且源文件已存在 + 缺少
.cli-forge/design-contract.yml-> 接管 - 已有项目且源文件已存在 + 同时缺少
.cli-forge/design-contract.yml和.cli-forge/cli-plan.yml-> 接管 - 存在
cli-plan.yml，但没有源文件 -> 搭建 - 已有项目 + 功能请求（
stream或repl）+ 基线兼容搭建 -> 扩展 - 已有项目 + 守护进程能力请求 -> 规划
- 已有项目 + 审计请求（或编辑后验证）-> 验证
- 验证通过 + 发布请求（包括 npm 发布）-> 发布
- 确认所选路径所需的输入：
- 搭建：
skill_name - 接管：
project_path、post_adoption_objective和takeover_mode - 扩展：
project_path和feature（stream或repl） - 规划：守护进程能力请求、守护进程契约变更或守护进程范围更新
- 验证：
project_path - 发布：
publish_mode
- 搭建：
- 在写入任何路由产物前，确保目标项目的
.cli-forge/目录存在。这一首次写入屏障也适用于尚无任何流水线文件的首次接管仓库。 - 使用
contracts/handoff.yml.tpl模板，在目标项目目录中生成.cli-forge/handoff.yml。此文件会明确记录分类和供下游使用的输入。 - 提供清晰的交接回复，指出接下来应调用哪个子技能。当有 2 或 3 个合法的下一阶段选项时，如果运行时提供基于对话框的选择器（例如
AskUserQuestion），则调用该选择器并列出这些选项（推荐路径优先）。如果没有可用的基于对话框的选择器，或只剩一个合法的下一阶段，则提供带编号的文本菜单，列出 1 到 3 个明确的下一阶段选项，且只能从当前文件系统状态下仍有效的阶段中选择。使用最小的有效选项集；若只剩一个合法的下一阶段，则仅显示该阶段的1.选项。将推荐路径放在首位，并添加Other: explain a routing concern作为其他选择。只接受与实际显示的编号选项对应的确切数字，或Other: ...。不得将普通语言回复自动对应到编号选项。如果数字回复中包含其他文字，或者Other:回复要求的阶段与流水线防护规则冲突，则请求澄清，并将交接限定在有效阶段范围内。不得要求用户输入完全一致的短语或技能名称。
输出
.cli-forge/handoff.yml— 明确的路由契约
退出检查
| # | 检查项 |
|---|---|
| 1 | 已成功判断请求意图 |
| 2 | 已整理下游阶段所需的输入 |
| 3 | 已生成 handoff.yml |
| 4 | 已明确交接至正确的子阶段 |
护栏
- 给助手的关键指令：在此阶段，绝不能绕过分阶段流水线。不要自行编写、生成或搭建代码。
- 给助手的关键指令：生成
handoff.yml并说明后续步骤后，必须停止并交由用户决定。不得自行调用下一阶段。如果运行时提供基于对话框的选择器（例如AskUserQuestion），且有 2 或 3 个合法的下一阶段选项，则在交接时使用该选择器。如果没有可用的基于对话框的选择器，或者只剩一个合法的下一阶段，则使用标准编号文本回退方案，并提供Other: explain a routing concern选项。绝不要要求用户明确输入下一项技能的名称，也绝不要让回退输入绕过根据仓库状态计算出的有效阶段集合。 - 路由器必须保持精简。不要在此处执行模板、运行编译步骤或定义 CLI 约定。
- 如果较早阶段尚未完成，绝不要强行推进工作流。例如，如果用户要求“验证”，但项目是一个没有可用约定基线的既有仓库，则先路由到 Takeover，再到 Validate。如果
design-contract.yml已存在，但cli-plan.yml不存在，则恢复 Plan，而不是根据实现重建约定。如果用户已批准cli-plan.yml，但尚无生成的源代码树，则路由到 Scaffold。 - 如果用户要求发布，但验证缺失或已过期，则先路由到 Validate。
- 如果用户要求为现有项目添加守护进程支持，则先路由到 Plan，以便明确更新守护进程能力约定。守护进程实现支持尚未在 Extend 中具备之前，不要将守护进程请求发送到 Extend。
- 如果现有 Rust CLI 项目已有源文件，但缺少可用的约定基线，则不要直接将其发送到 Design、Scaffold、Extend 或 Validate。仅当仓库缺少
.cli-forge/design-contract.yml、用户明确要求刷新已采纳的约定，或下游阶段需要建立 Takeover 基线（因为约定已存在但没有可用的基线回执）时，才将其路由到 Takeover。如果design-contract.yml已获批准，应保留 Design -> Plan 的恢复路径，除非用户明确要求刷新 Takeover 或建立基线，否则不要重新路由到 Takeover。 - 不要将任意由 Takeover 采纳的项目路由到 Extend。只有当当前项目布局已符合脚手架兼容文件要求，且功能模板可直接修改这些文件时，Extend 才有效。
- 不要将新工作路由到
cli-forge-distribute。npm 发布属于 Publish；cli-forge-distribute模块已在守护进程实现提交中归档，不再存在。 - 如果目标项目目录未知，必须询问用户或搜索
.cli-forge/文件夹。如果很可能需要 Takeover，还要搜索可能的 Rust CLI 项目根目录。不要假定当前工作目录就是目标目录。
下一步
路由到以下其中一项：
评论
支持 Markdown