hao/skills
1
0
派生 0
代码 工单 合并请求 工作流 软件包 项目 发布 百科 活动

Add cc-switch-dev-workflow skill

浏览代码
这个提交包含在：
X
2026-03-26 00:27:17 -07:00
父节点 fc8ad7c145
当前提交 dcb2a10ad8
共修改 46 个文件，包含 3393 行新增和 0 行删除
下载 Patch 文件 下载 Diff 文件 展开所有文件 折叠所有文件

65
cc-switch-dev-workflow/references/knowledge-base/sources/2026-02-02-ralphy-task-list-flow.md 普通文件
查看文件

@@ -0,0 +1,65 @@
# Source Digest: 2026-02-02 Ralphy Task List Flow
## Purpose
提炼 `20260202-ralphy任务清单开发流程(3).md` 中关于设计先行、Ralphy 配置和任务标题质量的最小执行规则。
## When to Use
- 需要快速解释为什么先写设计文档再让 AI 执行循环时
- 需要生成 `tasks.md` 或 `TODO.yaml` 的命名与约束时
- 需要初始化 `.ralphy/config.yaml` 时
## Inputs
- `20260202-ralphy任务清单开发流程(3).md`
## Outputs
- Ralphy 最小可执行规则
- 配置基线
- 任务文案要求
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- `ralphy-initializing`
- `spec-tasking`
## Steps
1. 提取最小流程和配置要求。
2. 将 `tasks.md` 规则折叠进 `TODO.yaml` 模板。
3. 保留必要配置项，去掉一次性案例细节。
## Exit Criteria
- Ralphy 初始化与任务标题规则都已有固定模板
## Failure Recovery
- 如果项目已不使用 Ralphy CLI，本页仍保留任务标题的自包含规则，不依赖具体工具
## Related Templates
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
- [`../templates/claude-md-template.md`](../templates/claude-md-template.md)
## Core Conclusions
- 先写设计哲学与规范，再让 AI 进入执行循环，杠杆最大。
- 用法文档和设计文档属于低成本试错层，必须在代码前反复打磨。
- Ralphy 的规则配置要写死到项目配置里，而不是靠口头提醒。
- 默认 `TypeScript strict mode`、`KISS`、`DRY`、`YAGNI`、最大化复用。
## Reusable Rules
- `.ralphy/config.yaml` 至少要固定 `test/lint/build` 命令和项目规则。
- AI 执行前先读 `.references/`，如果有参考至少对照两个。
- 任务列表要能独立被执行，不能依赖任务正文的隐含语境。
## Background Only
- “几十轮打磨用法文档”的经验性描述
- 示例里的具体组件库和项目名
## Conflict Notes
- 本文使用 `tasks.md` 作为示例文件名；知识库统一使用 `TODO.yaml`，以 `workflow.zip` 和 `skills.zip` 为准。
## Traceability Targets
- `workflows/stage-0-setup.md`
- `workflows/stage-3-code.md`
- `templates/todo-yaml-template.md`

75
cc-switch-dev-workflow/references/knowledge-base/sources/2026-03-04-ai-pipeline-reliability.md 普通文件
查看文件

@@ -0,0 +1,75 @@
# Source Digest: 2026-03-04 AI Pipeline Reliability
## Purpose
提炼 `20260304-AI自动化开发流水线与可靠性工程(1).md` 中关于可靠性工程、偏差放大、Gap 对齐、代码简化和阶段性重构的规则。
## When to Use
- 需要定义为什么不能让模型从需求直接写代码时
- 需要设计 `Alignment`、`Refinement` 和质量检查点时
- 需要解释 80% 单步可靠性为何会导致整体失控时
## Inputs
- `20260304-AI自动化开发流水线与可靠性工程(1).md`
## Outputs
- 可靠性收敛规则
- Gap 分类与质量机制
- 与其他来源的冲突说明
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- `spec-gap-tasking`
- `code-simplifying`
- `code-refactoring`
- `architecture-audit`
## Steps
1. 提炼可靠性数学和偏差来源。
2. 提炼“遗漏”和“过度添加”两类核心失真。
3. 映射到 Alignment、Refinement 和 Acceptance 页。
4. 把策略性选项与执行规则分开。
## Exit Criteria
- 可靠性收敛逻辑已经转化为阶段化执行规则
- 缺口分类、检查点、验收路径全部有落点
## Failure Recovery
- 若与更具体的技能规则冲突，以技能规则定义的任务结构和检查点为准
## Related Templates
- [`../templates/tdd-plan-template.md`](../templates/tdd-plan-template.md)
- [`../templates/acceptance-checklist-template.md`](../templates/acceptance-checklist-template.md)
## Core Conclusions
- 从需求到代码的每一层都会放大偏差，不能把“总体看起来差不多”当作可靠。
- 减少层级和提升单步质量，是提高整体可靠性的两个杠杆。
- AI 实施最主要的两类问题是 `遗漏` 和 `过度添加`，分别需要 `Gap 对齐` 和 `代码简化` 去收敛。
- 简化、重构、对齐不能作为末尾补丁，而要嵌入主流程。
- `Spec` 的质量决定最终收敛上限，低质量 Spec 只会让系统更快地收敛到低质量结果。
## Reusable Rules
- 用 `Alignment` 补齐 `Missing / Partial / Divergent / Untested / Integration` 五类缺口。
- 每 4 个类别插入一次质量检查点，防止技术债堆积。
- `Refinement` 不是一次“美化”，而是全库级的清晰度、结构和架构收敛。
- `Acceptance` 必须由人主导，不能被自动化审查替代。
## Background Only
- 各组用量对比
- 外部项目 OpenClaw 的星数与账号投入
- 市场竞争与六月产品上线时间点
## Conflict Notes
- 本文对 95% 单步可靠性给出目标值，但没有提供模板和目录组织；执行骨架依旧以 `workflow.zip` 和 `skills.zip` 为准。
- 文中部分质量检查点是理念层描述，正式任务对的生成方式以 `spec-gap-tasking` 为准。
## Traceability Targets
- `foundations/reliability-and-convergence.md`
- `foundations/refactoring-and-gap-closure.md`
- `workflows/stage-4-alignment.md`
- `workflows/stage-5-refinement.md`
- `workflows/stage-6-acceptance.md`

77
cc-switch-dev-workflow/references/knowledge-base/sources/2026-03-06-spec-driven-workflow.md 普通文件
查看文件

@@ -0,0 +1,77 @@
# Source Digest: 2026-03-06 Spec-Driven Workflow
## Purpose
提炼 `20260306-基于规范编程的开发模式与工作流.md` 中关于 Spec 驱动开发、技能体系、`CLAUDE.md`、调研与任务拆分的长期规则。
## When to Use
- 需要定义项目级设计哲学和 `CLAUDE.md` 时
- 需要解释为什么 Spec 是代码之前的单一真相源时
- 需要确定会议、调研、Spec、Code 的标准链路时
## Inputs
- `20260306-基于规范编程的开发模式与工作流.md`
## Outputs
- 可复用规则集
- 背景性信息分层
- 与其他来源的冲突说明
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- `spec-tasking`
- `spec-reviewing`
- `ralphy-initializing`
## Steps
1. 提取文档中的不变原则。
2. 区分“流程规则”和“历史背景”。
3. 将能执行的规则映射到 workflow、playbook 和模板。
4. 将策略性、可变化内容转移到 ADR。
## Exit Criteria
- 本文档中的规则已被至少一个正式页面复用
- 背景故事没有混入 SOP 主文
## Failure Recovery
- 如果某条说法与技能规则冲突，以技能规则为准并记录到 ADR
## Related Templates
- [`../templates/claude-md-template.md`](../templates/claude-md-template.md)
- [`../templates/spec-template.md`](../templates/spec-template.md)
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
## Core Conclusions
- `Spec` 是代码之前的单一真相源，需求变化时先改 Spec，再改代码。
- `CLAUDE.md` 是项目执行说明的核心文件，必须承载设计哲学、技能索引、边界和质量标准。
- 会议纪要不能原样喂给模型，必须先清洗，只保留当前项目相关决策。
- 参考仓库要经过筛选，前端优先 `TypeScript` 实现，且要有近年更新与足够社区信号。
- 调研、Spec 审查和人工判断占大头，代码实施只占整体时间的一部分。
- 任务标题必须自包含，至少说明 `Action + Where + Reference`，否则 Ralphy 循环会偏航。
- 技能不是“提示词收藏夹”，而是团队最佳实践的标准化封装，能显著提升稳定性。
## Reusable Rules
- 新项目先建 `.meetings/`、`.references/`、`CLAUDE.md`、`SPECS/`，再谈实施。
- 每个项目都要有明确的设计哲学，不接受“让模型随机发挥”。
- 调研报告和 Spec 要模块化拆分，便于独立生成、独立审查、独立对齐。
- `SPECS/` 使用编号和分域组织，不按写作顺序组织。
- 每实现 4 个小任务做一次重构，结束后再做一次更大的收敛。
## Background Only
- 对大型团队培训 TDD/敏捷的背景讨论
- 对未来客户端形态、自我学习能力的愿景描述
- 对不同语言 skill 包数量的示例性说明
## Conflict Notes
- 本文强调 `CLAUDE.md` 和技能驱动，但没有提供统一的 7 阶段骨架；骨架以 `workflow.zip` 为准。
- 本文提到的某些 skill 名称与 `skills.zip` 中实际命名略有差异；正式文档统一以 `skills.zip` 为准。
## Traceability Targets
- `foundations/spec-driven-development.md`
- `foundations/human-agent-boundaries.md`
- `workflows/stage-0-setup.md`
- `playbooks/new-project-from-scaffold.md`

75
cc-switch-dev-workflow/references/knowledge-base/sources/README.md 普通文件
查看文件

@@ -0,0 +1,75 @@
# Sources Index And Traceability
## Purpose
建立知识库的来源索引、追溯矩阵和冲突处理规则，确保所有核心规则可回溯。
## When to Use
- 新增或修改知识库规则前
- 发现两份来源说法不一致时
- 需要证明某条 SOP 来自哪里时
## Inputs
- `20260306-基于规范编程的开发模式与工作流.md`
- `20260304-AI自动化开发流水线与可靠性工程(1).md`
- `20260202-ralphy任务清单开发流程(3).md`
- `workflow.zip`
- `skills.zip`
## Outputs
- 源资产摘要索引
- 规则追溯矩阵
- 冲突处理顺序
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- 无强制 skill；必要时参考 `spec-reviewing` 的一致性思路
## Steps
1. 先看每个源资产对应的 digest 页面。
2. 判断这条规则是阶段骨架、质量原则、技能约束还是执行经验。
3. 若多个来源重叠，按“更具体、更晚、更新、更可执行”的顺序裁决。
4. 若裁决影响主流程或白名单，写 ADR 后再更新知识库正文。
## Exit Criteria
- 每条核心规则都能指向至少一个源资产
- 冲突规则已记录取舍和去向
- 不需要回看原始大段会议文本即可找到规则入口
## Failure Recovery
- 如果某条规则找不到来源，先降级为“待确认”，不要写入正式 SOP
- 如果来源冲突无法消解，写 ADR 并保留冲突说明
## Related Templates
- [`../templates/analysis-template.md`](../templates/analysis-template.md)
- [`../templates/agent-handoff-template.md`](../templates/agent-handoff-template.md)
## Source Digest 列表
| 源资产 | Digest |
|---|---|
| `20260306-基于规范编程的开发模式与工作流.md` | [`2026-03-06-spec-driven-workflow.md`](./2026-03-06-spec-driven-workflow.md) |
| `20260304-AI自动化开发流水线与可靠性工程(1).md` | [`2026-03-04-ai-pipeline-reliability.md`](./2026-03-04-ai-pipeline-reliability.md) |
| `20260202-ralphy任务清单开发流程(3).md` | [`2026-02-02-ralphy-task-list-flow.md`](./2026-02-02-ralphy-task-list-flow.md) |
| `workflow.zip` | [`workflow-zip-digest.md`](./workflow-zip-digest.md) |
| `skills.zip` | [`skills-zip-digest.md`](./skills-zip-digest.md) |
## 追溯矩阵
| 主题 | 主要来源 | 落点 |
|---|---|---|
| Spec 驱动、`CLAUDE.md`、调研到实施的链路 | `20260306...md` | `foundations/spec-driven-development.md`, `workflows/stage-0-setup.md`, `playbooks/new-project-from-scaffold.md` |
| 可靠性数学、Gap、简化与重构收敛 | `20260304...md` | `foundations/reliability-and-convergence.md`, `foundations/refactoring-and-gap-closure.md`, `workflows/stage-4-alignment.md`, `workflows/stage-5-refinement.md` |
| Ralphy 自包含任务标题与配置规则 | `20260202...md`, `skills.zip` | `templates/todo-yaml-template.md`, `workflows/stage-3-code.md` |
| 7 阶段流程骨架 | `workflow.zip` | `workflows/README.md` 与全部阶段页 |
| 技能到阶段的映射 | `skills.zip` | `workflows/`, `templates/`, `orchestration/` |
## 冲突处理顺序
1. `skills.zip` 中技能规则优先于泛化的阶段口述，前提是它更具体。
2. 两份会议整理冲突时，优先更晚的文档。
3. `workflow.zip` 提供流程骨架，不覆盖后续更具体的技能行为约束。
4. 一切正式取舍写入 [`../decisions/ADR-2026-03-21-source-precedence-and-conflict-resolution.md`](../decisions/ADR-2026-03-21-source-precedence-and-conflict-resolution.md)。

78
cc-switch-dev-workflow/references/knowledge-base/sources/skills-zip-digest.md 普通文件
查看文件

@@ -0,0 +1,78 @@
# Source Digest: skills.zip
## Purpose
提炼 `skills.zip` 中与知识库直接相关的 skill 行为约束，尤其是任务结构、审查门禁、检查点和计划模板。
## When to Use
- 需要把阶段流程落到可执行技能时
- 需要定义 `TODO.yaml`、Plan/Impl 对、审查门禁和重构检查点时
- 需要确认“流程说法”和“技能行为”哪个更具体时
## Inputs
- `skills.zip`
## Outputs
- 技能级执行约束摘要
- 阶段到 skill 的映射
- 审查与计划模板约束
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- `spec-tasking`
- `spec-gap-tasking`
- `spec-reviewing`
- `ralphy-initializing`
- `tdd-planning`
- `tdd-implementing`
- `code-simplifying`
- `code-refactoring`
- `architecture-audit`
## Steps
1. 找出直接约束阶段流程的 skill。
2. 把技能规则转成知识库里的固定结构。
3. 将可变化的策略和命名差异转移到 ADR。
## Exit Criteria
- 阶段和模板里的行为约束与 skill 真实定义一致
## Failure Recovery
- 如果阶段文档与 skill 描述冲突，以 skill 描述定义的任务结构、检查点和门禁为准
## Related Templates
- [`../templates/tdd-plan-template.md`](../templates/tdd-plan-template.md)
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
- [`../templates/spec-template.md`](../templates/spec-template.md)
## Core Conclusions
- `spec-tasking` 先审计 `ANALYSIS.md`，再生成 `TODO.yaml`，避免为已存在内容重复派工。
- `spec-gap-tasking` 必须先对照真实实现再生成 Plan/Impl 对，并按批次插入质量检查点。
- `spec-reviewing` 是 Spec 进入实施前的硬门禁，重点看结构、语义、可实施性和过度设计。
- `code-simplifying` 关注刚改过的代码，优先删除“伪代码化文档”和不必要抽象。
- `code-refactoring` 从最近变更出发，但会跨代码库追查重复、职责错位和依赖反转问题。
- `architecture-audit` 是系统级全库健康检查，不等同于最近修改的重构。
## Reusable Rules
- `TODO.yaml` 的标题必须是一行内可执行说明。
- 对 Gap 和实现类任务，默认是 `Plan -> Implement -> Simplify -> Checkpoint Refactor`。
- 审查和重构任务都要以现有代码和现有文档为前提，不允许忽略现状直接重写。
## Background Only
- skill 内部的示例路径、年份占位和具体范例文本
- 与当前知识库无关的语言特定参考文件细节
## Conflict Notes
- 部分 skill 的文案更偏代码项目；知识库已经把这些规则重写为 `CC Switch` 可执行版，但不会改变核心任务结构。
## Traceability Targets
- `workflows/stage-2-spec.md`
- `workflows/stage-3-code.md`
- `workflows/stage-4-alignment.md`
- `workflows/stage-5-refinement.md`
- `templates/todo-yaml-template.md`
- `templates/tdd-plan-template.md`

66
cc-switch-dev-workflow/references/knowledge-base/sources/workflow-zip-digest.md 普通文件
查看文件

@@ -0,0 +1,66 @@
# Source Digest: workflow.zip
## Purpose
提炼 `workflow.zip` 中的 7 阶段骨架、阶段输入输出和阶段间流转关系，作为知识库流程层的主骨架。
## When to Use
- 需要快速定位当前项目所在阶段时
- 需要把会议经验落到统一阶段模型时
- 需要知道每个阶段的标准产物时
## Inputs
- `workflow.zip`
## Outputs
- 7 阶段骨架
- 阶段产物清单
- 与技能和会议经验的拼接点
## Primary Agent/Model
`GPT-5.4 Pro xhigh`
## Secondary Agent/Model
`Claude Opus 4.6`
## Required Skills
- 阶段自身列出的全部 skill
## Steps
1. 读取 `README.md` 和 `QUICK-REFERENCE.md` 得到总骨架。
2. 逐个读取 `0-setup.md` 到 `6-acceptance.md`。
3. 将阶段骨架改写为 `CC Switch` 适配版。
4. 用技能规则和会议规则修补“谁来做、何时 reset、何时人工接管”。
## Exit Criteria
- 7 阶段均有明确输入、输出、主模型、辅模型、技能和退出条件
## Failure Recovery
- 如果 `workflow.zip` 的流程描述与技能模板不一致，保留其阶段骨架，但用技能规则修正阶段内部行为
## Related Templates
- [`../templates/analysis-template.md`](../templates/analysis-template.md)
- [`../templates/todo-yaml-template.md`](../templates/todo-yaml-template.md)
- [`../templates/acceptance-checklist-template.md`](../templates/acceptance-checklist-template.md)
## Core Conclusions
- 流程统一分为 `Setup / Research / Spec / Code / Alignment / Refinement / Acceptance` 七个阶段。
- 每个阶段都要有输入、输出、关键活动、工作流图和下一步衔接。
- `workflow.zip` 已经提供了适合新人理解的阶段职责划分，是知识库的流程骨架来源。
## Reusable Rules
- 阶段输出要标准化，尤其是 `ANALYSIS.md`、`TODO.yaml`、`SPECS/*.md`、`.plans/*.md`。
- `Acceptance` 明确是人工主导，不是自动化阶段。
- `Refinement` 默认包含全局简化和增量重构，可选再做模块化与结构重组。
## Background Only
- 示例项目中的具体组件、包名和年份占位
- 流程图里的示意性文件路径
## Conflict Notes
- `workflow.zip` 对多 agent 分工没有建模；该部分由 `orchestration/` 补齐。
- `workflow.zip` 某些技能名是抽象名，具体名称以 `skills.zip` 为准。
## Traceability Targets
- `workflows/README.md`
- `workflows/stage-0-setup.md` 到 `workflows/stage-6-acceptance.md`
- `playbooks/*.md`