用途
该技能旨在为设计“软件工厂”（software factory）提供一套共享语言和设计方法。软件工厂是一个由智能体组成的系统，能够将工单、PR 和定时计划转化为合并的代码，并部署在用户选择的远程基础设施上。该技能本身不是可执行代码，而是用于讨论、白板设计或与用户沟通时的术语规范与设计检查清单。
主要能力
- 统一术语：定义并区分任务（Task）、触发器（Trigger）、运行（Run）、运行器（Runner）等核心概念，并给出应避免使用的同义词，确保讨论时用词一致。
- 服务槽位模型：将软件工厂拆分为若干服务槽位，包括工单跟踪器（Ticket tracker）、工单来源（Ticket source）、Git 托管（Git host）、编排器（Orchestrator）和可观测性平台（Observability platform），并说明每个槽位的职责。
- 设计方法指导：强调从用户实际问题出发，而非从工厂本身出发；建议逐步增加自动化触发器，并配合三种刹车机制（自动化检查、自动化评审、人工评审）来控制风险。
- 提供示例设计：给出三种并排的设计示例（全在 GitHub、使用 Linear 工单、自建跟踪器），展示不同产品组合如何填充槽位。
- 任务与来源审查清单：对每个任务提出五个关键问题（触发器、行为与读写服务、后续触发器、人工介入点、防止重复工作的机制），对每个工单来源追问防止重复提交的机制。
使用方式
- 在设计或讨论软件工厂时，使用该技能提供的术语，避免使用被标记为“Avoid”的词汇。
- 当用户遇到具体问题（如未分类工单、等待自动评审的 PR、需要迁移的更严格自动检查、无人阅读的 bug 报告）时，可参考 EXAMPLE-TASKS.md 中解决常见问题的任务。
- 当用户为某个槽位选择产品时，先阅读对应的调研文档（TICKET-TRACKERS.md、GIT-HOSTS.md、RUNNERS.md、OBSERVABILITY-PLATFORMS.md）以了解选项分类和决策问题，然后自行研究当前可选产品。
- 设计完成的标准是：每个槽位都指定了产品（可观测性平台可明确为“无”），并且每个任务和工单来源都对所有关键问题有答案。
适用场景
- 团队或个人希望构建由智能体驱动的自动化软件开发流水线。
- 需要与其他人或智能体讨论软件工厂架构，并要求术语统一。
- 正在为工单跟踪、Git 托管、运行器、编排器等组件选型。
- 希望以渐进、可控的方式引入自动化，避免“加速器没有刹车”导致低质量产出泛滥。
限制
- 该技能是设计语言和指导，不包含可直接运行的代码或安装命令。
- 不提供具体产品的价格、功能对比或性能数据；选型需用户自行研究当前选项。
- 示例设计仅作参考，实际产品可用性和集成方式可能随时间变化。
- 技能中提到的调研文档（如 TICKET-TRACKERS.md）和示例任务文档（EXAMPLE-TASKS.md）的具体内容未在资料中提供，需另行获取。