تشغيل أي مهارة في Manus بنقرة واحدة

spec

النجوم٢٤

التفرعات٤

آخر تحديث٢٨ يونيو ٢٠٢٦ في ١٧:٠٥

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

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

المهن الحاسوبية الأخرىمهن الحاسوب والرياضيات·SOC 15-1299

SKILL.md

readonly

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.

启动 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 已记录
用户已明确批准

المزيد من هذا المستودع

نفس المستودع

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 已记录

用户已明确批准