一键在 Manus 中运行任何 Skill

spec

星标24

分支4

更新时间2026年6月28日 17:05

Use when the user wants to start or continue a cc-leader workflow, write a spec, or says '/cc-leader-spec'. Guides spec drafting, resume, and adversarial review.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

dualface

dualface/cc-leader

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

启动 Spec Workflow

这是 cc-leader workflow 的用户入口。用户要新开 workflow、写 spec、或直接说 /cc-leader-spec 时，用这个 skill。

权威边界: 本 skill 管 spec 阶段 gate + cc-leader CLI 调用。spec 内容规则 (角色 / 对抗审重点 / 反模式) 的真源是 drafting-specs skill, 此处不复述。spec 章节真源是 docs/templates/spec-template.md。

核心规则

这是 spec 阶段入口，不直接进入 planning 或 execution
spec 目标必须由用户明确提供, 严禁猜测 / 脑补 / 用历史会话 / 用 git 状态推断. 用户没说目标就停下来问, 拿到目标再继续
只用 cc-leader CLI 操作 workflow state，不要直接编辑 .cc-leader/session.json 或其他 session state 文件
spec 按 docs/templates/spec-template.md 的结构写
一次最多问一个阻塞问题；非阻塞假设写进 spec

流程

建议用户切换模型: "建议切换到 Opus 4.8 (1M context) 模型以获得最佳 spec 质量。可用 /model 切换 (cc 无法自切, 需用户手动)。"
强制 spec 目标 gate (先于一切动作):
- 检查用户本次请求是否含明确 spec 目标 (要做什么 / 解决什么问题 / 交付什么)
- 仅给 slug / "新开 workflow" / "/cc-leader-spec" 等无目标信息时, 停止, 反问用户:
  - "请描述本次 spec 目标: 要解决什么问题 / 交付什么? 不要让我猜。"
- 拿到用户明确答复后再继续
- 绝不用历史会话 / memsearch / git 状态 / 目录内容 / 上一次 spec 反推目标
强制 worktree gate (避免 state 文件覆盖):
- 执行 pwd 确认当前 CWD
- 若 CWD 不在 <project-root>/worktrees/<name> 内 (即仍在主工作树或别处):
  - 询问用户 worktree 名 (新任务簇名 / 复用现有)
  - 新建: git worktree add worktrees/<name> -b cc-leader/<name>
  - 进入: EnterWorktree path=worktrees/<name> (后续所有 cc-leader CLI 都在 worktree CWD 跑)
- 若已在某 worktree 内: 直接继续, 该 worktree 的 .cc-leader/session.json 是本 spec 的独立 state
- 关键: cc-leader state 文件按 CWD 存; state 已存在时 init 不加 --force 会被拒, 但若在主仓加 --force 重开, 会覆盖该 CWD 的既有 workflow state
检测已有 workflow: 执行 cc-leader state:get
- 如果已有 workflow 且 spec_approved == true:
  - 提示用户: "已有已批准的 workflow <workflow_id>, spec 在 <spec_path>。用 /cc-leader-run 继续执行。"
  - 停止, 不重复 init
- 如果已有 workflow 且 spec_approved == false 且 spec_path 非空:
  - 提示用户: "发现未完成的 workflow <workflow_id>, spec 在 <spec_path>。"
  - 问用户: "继续编辑这个 spec, 还是放弃重开?"
  - 用户选继续 → 跳到步骤 5, 读已有 spec 继续改
  - 用户选重开 → 执行 cc-leader init --slug <slug> --force, 走正常新建流程
- 如果没有 workflow (state:get 报错或 workflow_id 为空):
  - 确认或和用户约定 workflow slug, 执行 cc-leader init --slug <slug>
执行 cc-leader state:get, 读取 workflow_id
和用户一起按 docs/templates/spec-template.md 起草 spec。
- 章节真源 = 该模板, 按模板全部章节写, 不在本文件复述清单 (避免 drift)
- 外部依赖风险 / 开放问题 不能留空, 没有写 none
将 spec 落盘到 docs/specs/<workflow-id>.md
执行 cc-leader state:set --set spec_path=docs/specs/<workflow-id>.md
派 worker 做对抗式 review：cc-leader dispatch --job specAdversarialReview
如果 review 结果是 pass：
- 向用户总结 review 结论
- 单独汇报外部依赖风险: 从 review 文档读取 external_dependency_risks 段
  - 若非 none, 逐条朗读给用户, 格式 <依赖>: <风险> — 建议: <缓解>
  - 明确告知用户: "以下风险不阻塞批准, 但建议知情; 最终报告会再次汇总。"
  - 若为 none, 简短告知 "无外部依赖风险记录"
- 询问用户是否批准 spec
- 用户批准后执行 cc-leader state:set --set spec_approved=true --set spec_review_passed=true
- 明确提示用户：spec 已批准。用 /cc-leader-run 启动执行。
如果 review 结果是 revise：
- 总结关键问题、隐含假设、建议修改
- 每轮都先执行 cc-leader state:get, 读取 spec_review_revise_count (CLI 已自动维护)
- 若 spec_review_revise_count < 2:
  - 和用户一起改 spec
  - 重新执行 cc-leader dispatch --job specAdversarialReview
- 若 spec_review_revise_count >= 2:
  - 强制停止自动循环. 不要再 dispatch, 不要继续问"要不要再审"
  - CLI gate 兜底: 此时若直接 dispatch --job specAdversarialReview 会被拒, 错误信息会指引三选一
  - 向用户展示累积问题清单 (本轮 + 历史 review 聚合), 让用户三选一:
    1. 接受当前 spec, 走 override 流程 (跳步骤 11)
    2. 放弃本次 workflow
    3. 明确要求再审一轮 — 用户必须主动说"再审一轮"或同义指令, Claude 才能执行 cc-leader dispatch --job specAdversarialReview --allow-after-revise-cap 跑一次
  - 旁路后若仍 revise, 计数器继续 + 1, gate 再次触发, 重复三选一流程; 严禁自动重试
- 绝不自动 state:set --set spec_review_revise_count=0, 也绝不自动加 --allow-after-revise-cap; 两者必须由用户主动触发
如果用户明确要求 override：
- 记录 override 原因、范围、被跳过的 review 问题
- 把 override 写进 spec 的 Override 记录
- 继续 review / approval 流程

审查要求

review 必须是对抗式，不是走过场
重点检查（critical 级）: 行为歧义、隐藏依赖、不可测成功标准（内部）、内部路径失败处理缺失、scope 大到无法 phase 化
外部依赖 (第三方 API / 外部服务) 的错误处理和测试覆盖单独归入 external_dependency_risks, 不进 critical, 不触发 revise
开放问题 不能留空；没有就写 none
外部依赖风险 不能留空；没有就写 none

退出条件

docs/specs/<workflow-id>.md 已写好
spec_path 已通过 cc-leader state:set 写回 state
spec review 已通过，或 override 已记录
用户已明确批准

同仓库更多 Skills

同仓库

drafting-specs

dualface/cc-leader

当 cc 需要和用户一起产出已批准 spec，并在进入 planning 前做 worker 对抗式 review 时使用。

2026-06-2824

using-cc-leader

dualface/cc-leader

Use when the user explicitly asks to start a cc-leader workflow, run a multi-phase development plan, or says 'cc-leader'. Do not auto-activate on every session.

2026-06-2824

reviewing-phase-results

dualface/cc-leader

当某个 phase 执行完成后，worker 需对照 plan 做 phase review；全部 phase 通过后，再做 spec 级 final review 时使用。

2026-06-2824

drive

dualface/cc-leader

Use when the user wants a detached worker (Codex or Claude) to execute an arbitrary user-specified task and keep going automatically when the worker merely asks whether to continue.

2026-06-2824

executing-phase-tasks

dualface/cc-leader

当已审过的 phase task list ready，且 worker 要逐 task 执行并在每步后追加结果时使用。

2026-06-2824

reporting-results

dualface/cc-leader

当所有 phase 和 review 都通过后使用。此时由 cc 基于 artifact 链写最终详细报告。

2026-06-2824

启动 Spec Workflow

这是 cc-leader workflow 的用户入口。用户要新开 workflow、写 spec、或直接说 /cc-leader-spec 时，用这个 skill。

权威边界: 本 skill 管 spec 阶段 gate + cc-leader CLI 调用。spec 内容规则 (角色 / 对抗审重点 / 反模式) 的真源是 drafting-specs skill, 此处不复述。spec 章节真源是 docs/templates/spec-template.md。

核心规则

这是 spec 阶段入口，不直接进入 planning 或 execution

spec 目标必须由用户明确提供, 严禁猜测 / 脑补 / 用历史会话 / 用 git 状态推断. 用户没说目标就停下来问, 拿到目标再继续

只用 cc-leader CLI 操作 workflow state，不要直接编辑 .cc-leader/session.json 或其他 session state 文件

spec 按 docs/templates/spec-template.md 的结构写

一次最多问一个阻塞问题；非阻塞假设写进 spec

流程

建议用户切换模型: "建议切换到 Opus 4.8 (1M context) 模型以获得最佳 spec 质量。可用 /model 切换 (cc 无法自切, 需用户手动)。"

强制 spec 目标 gate (先于一切动作):

检查用户本次请求是否含明确 spec 目标 (要做什么 / 解决什么问题 / 交付什么)
仅给 slug / "新开 workflow" / "/cc-leader-spec" 等无目标信息时, 停止, 反问用户:
- "请描述本次 spec 目标: 要解决什么问题 / 交付什么? 不要让我猜。"
拿到用户明确答复后再继续
绝不用历史会话 / memsearch / git 状态 / 目录内容 / 上一次 spec 反推目标

强制 worktree gate (避免 state 文件覆盖):

执行 pwd 确认当前 CWD
若 CWD 不在 <project-root>/worktrees/<name> 内 (即仍在主工作树或别处):
- 询问用户 worktree 名 (新任务簇名 / 复用现有)
- 新建: git worktree add worktrees/<name> -b cc-leader/<name>
- 进入: EnterWorktree path=worktrees/<name> (后续所有 cc-leader CLI 都在 worktree CWD 跑)
若已在某 worktree 内: 直接继续, 该 worktree 的 .cc-leader/session.json 是本 spec 的独立 state
关键: cc-leader state 文件按 CWD 存; state 已存在时 init 不加 --force 会被拒, 但若在主仓加 --force 重开, 会覆盖该 CWD 的既有 workflow state

检测已有 workflow: 执行 cc-leader state:get

如果已有 workflow 且 spec_approved == true:
- 提示用户: "已有已批准的 workflow <workflow_id>, spec 在 <spec_path>。用 /cc-leader-run 继续执行。"
- 停止, 不重复 init
如果已有 workflow 且 spec_approved == false 且 spec_path 非空:
- 提示用户: "发现未完成的 workflow <workflow_id>, spec 在 <spec_path>。"
- 问用户: "继续编辑这个 spec, 还是放弃重开?"
- 用户选继续 → 跳到步骤 5, 读已有 spec 继续改
- 用户选重开 → 执行 cc-leader init --slug <slug> --force, 走正常新建流程
如果没有 workflow (state:get 报错或 workflow_id 为空):
- 确认或和用户约定 workflow slug, 执行 cc-leader init --slug <slug>

执行 cc-leader state:get, 读取 workflow_id

和用户一起按 docs/templates/spec-template.md 起草 spec。

章节真源 = 该模板, 按模板全部章节写, 不在本文件复述清单 (避免 drift)
外部依赖风险 / 开放问题 不能留空, 没有写 none

将 spec 落盘到 docs/specs/<workflow-id>.md

执行 cc-leader state:set --set spec_path=docs/specs/<workflow-id>.md

派 worker 做对抗式 review：cc-leader dispatch --job specAdversarialReview

如果 review 结果是 pass：

向用户总结 review 结论
单独汇报外部依赖风险: 从 review 文档读取 external_dependency_risks 段
- 若非 none, 逐条朗读给用户, 格式 <依赖>: <风险> — 建议: <缓解>
- 明确告知用户: "以下风险不阻塞批准, 但建议知情; 最终报告会再次汇总。"
- 若为 none, 简短告知 "无外部依赖风险记录"
询问用户是否批准 spec
用户批准后执行 cc-leader state:set --set spec_approved=true --set spec_review_passed=true
明确提示用户：spec 已批准。用 /cc-leader-run 启动执行。

如果 review 结果是 revise：

总结关键问题、隐含假设、建议修改
每轮都先执行 cc-leader state:get, 读取 spec_review_revise_count (CLI 已自动维护)
若 spec_review_revise_count < 2:
- 和用户一起改 spec
- 重新执行 cc-leader dispatch --job specAdversarialReview
若 spec_review_revise_count >= 2:
- 强制停止自动循环. 不要再 dispatch, 不要继续问"要不要再审"
- CLI gate 兜底: 此时若直接 dispatch --job specAdversarialReview 会被拒, 错误信息会指引三选一
- 向用户展示累积问题清单 (本轮 + 历史 review 聚合), 让用户三选一:
  1. 接受当前 spec, 走 override 流程 (跳步骤 11)
  2. 放弃本次 workflow
  3. 明确要求再审一轮 — 用户必须主动说"再审一轮"或同义指令, Claude 才能执行 cc-leader dispatch --job specAdversarialReview --allow-after-revise-cap 跑一次
- 旁路后若仍 revise, 计数器继续 + 1, gate 再次触发, 重复三选一流程; 严禁自动重试
绝不自动 state:set --set spec_review_revise_count=0, 也绝不自动加 --allow-after-revise-cap; 两者必须由用户主动触发

如果用户明确要求 override：

记录 override 原因、范围、被跳过的 review 问题
把 override 写进 spec 的 Override 记录
继续 review / approval 流程

审查要求

review 必须是对抗式，不是走过场

重点检查（critical 级）: 行为歧义、隐藏依赖、不可测成功标准（内部）、内部路径失败处理缺失、scope 大到无法 phase 化

外部依赖 (第三方 API / 外部服务) 的错误处理和测试覆盖单独归入 external_dependency_risks, 不进 critical, 不触发 revise

开放问题 不能留空；没有就写 none

外部依赖风险 不能留空；没有就写 none

退出条件

docs/specs/<workflow-id>.md 已写好

spec_path 已通过 cc-leader state:set 写回 state

spec review 已通过，或 override 已记录

用户已明确批准

name	spec
description	Use when the user wants to start or continue a cc-leader workflow, write a spec, or says '/cc-leader-spec'. Guides spec drafting, resume, and adversarial review.