用途
本仓库工作流约定用于解决 Git 仓库中的文件归属混乱问题，明确哪些文件应该被团队共享、哪些应当保持个人私有，临时产物应当放在哪里，以及分支和提交应当如何组织。这些约定与具体技术栈无关，适用于任意 Git 仓库。
主要能力
共享规则与个人便签的分层
同一约定目录中可以同时存在两层文件：
- 共享层：普通 *.md 文件，纳入 Git 跟踪，适用于整个团队。
- 本地层：*.local.md 文件，被 gitignore 忽略，仅属于某位开发者。
命名规则：如果个人便签有对应的共享文件，则采用相同路径，并在扩展名前加 .local.md（例如 rules/commits.md 对应 rules/commits.local.md）；如果没有对应文件，则直接使用基于主题的名称。
关于自动加载：*.local.md 默认不会被自动加载。团队级的自动加载机制（如 @import 风格指令）只接受被跟踪的共享路径，因为每个开发者的本地副本各不相同。在相关时应显式读取 *.local.md 文件，而不是期望它被预加载。根级 *.local.md 覆盖文件通常是例外，它依靠文件名约定被识别，并且可以为该开发者自身选择将某些个人便签纳入自动加载，而不影响团队级配置。
歧义处理：如果无法确定某条事实属于共享规则还是个人便签，应先询问再做决定，因为除了明确说“为团队记住这个”或“只给我自己”之外，没有固定的自动判断信号。
子代理不使用本地便签：不要将 *.local.md 的内容作为项目约定传入实现或审查子代理的提示中，子代理代表整个团队或仓库行事。只有在用户明确要求该便签适用于当前任务时才应包含。
临时工作产物的归档
使用多步骤工作流时，按类型将服务文件放入对应位置，而不是随意放置：
- 规划与规格文档放在项目根目录，而不是 tmp/：命名为 YYYY-MM-DD-<功能名>.md（计划）或 YYYY-MM-DD-<主题>-design.md（设计规格/头脑风暴输出）。这是唯一应当放在根目录的例外，因为它们是规划阶段的持久产物，而非草稿输出。
- 其他所有内容——报告、审查包、构建/调试日志——放入按类型划分的 tmp/ 子目录（tmp/reports/、tmp/reviews/、tmp/logs/ 或适合工作流的分类），绝不放入 .git/、仓库根目录或外部临时目录。
清理：一旦计划完全实现、验证完毕且不再需要审查，就删除 tmp/ 中的产物以及计划/规格文件本身，除非用户明确要求保留。功能发布后仍留在根目录的过时计划文件是杂乱，而不是文档。
Git 分支
绝不直接提交到 main（或主干分支），始终先创建并切换到功能/修复分支，即使只是一行修复。如果误提交到主干，应从该提交分出分支，并将主干重置回其远程跟踪引用（只要尚未推送就是安全的）。
发布分支命名：r<YY>.<Q>.<NN>（YY 为年份后两位，Q 为季度 1–4，NN 为从 01 开始的两位序号）。示例：r26.1.01。发布标签（发布分支中第一个最终提交）：<release-number>t，例如 r26.1.01t。热修复分支：<release-number>-hf<NNN>（NNN 为从 01 开始的两位序号），例如 r26.1.01-hf01。
Git 提交
绝不自动提交。git commit 仅在用户明确要求时运行——不在任务后、不在整个计划后、不作为工作流技能的默认行为。计划文档不应将提交步骤作为任务的一部分。
每个功能一个提交。计划中单个任务完成后不做中间提交——在整个功能结束时用一个提交打包全部变更。
实现子代理绝不提交。在实现子代理的提示中明确禁止 git commit；它将变更保持未提交状态，由编排代理或用户处理。
提交信息格式：过去时、单行、无正文/项目符号、无 Co-Authored-By 尾注。说明做了什么（“Added…”“Fixed…”），而不是命令式（“Add…”“Fix…”）。
带工单前缀的格式（项目跟踪工单时）：[<PREFIX>-NNN] type(scope): 过去时、首字母大写——例如 [SCB-123] feat(bot-gateway): Added....。前缀来自 .claude/dev-conventions.json 的 ticketPrefix（由 project-orchestrator 读取并传递）——绝不自行猜测或编造工单号；如果配置缺失且项目明显使用工单前缀，应询问用户而不是编造。发布/热修复分支有时使用 [branch-name] … 代替 type(scope)。没有工单跟踪器的项目直接跳过前缀。
文档语言
内部规则/文档文件（约定目录下的任何文件，或根指令文件中的 workflow-overrides 部分）使用英文编写——与用户实际交流所用的语言无关。例外——触发短语：当规则定义了必须在用户实际输入中识别的短语（技能激活触发器、remember-this 关键词）时，保留该短语的原始语言，并在旁边添加英文副本——绝不翻译掉字面短语，因为这会破坏与真实用户输入的匹配。例如：“давай подумаем” / “let's think about this”，而不仅仅是英文翻译。
使用方式
这些约定以规则文档形式存在，供开发者及其 AI 代理在工作流中参考和执行。主要使用方式包括：在创建文件前判断其应属于共享层还是本地层；在工作流中按类型将产物路由到 tmp/ 子目录或项目根目录；在需要提交时遵循分支与提交格式规则；在编写内部规则文档时使用英文并保留触发短语的原始语言。
适用场景
适用于任何 Git 仓库，尤其是多人协作、使用 AI 代理驱动多步骤工作流（规划、子代理实现、计划执行）的项目。也适用于需要区分团队规则与个人偏好的开发环境，以及有工单跟踪和发布分支管理需求的项目。
限制
该约定依赖开发者的自觉遵守和 AI 代理的提示约束，没有自动化强制机制。本地便签的自动加载存在固有限制，团队级机制无法覆盖被 gitignore 的个人文件。关于共享与个人的歧义判断没有固定信号，需要人工询问。工单前缀依赖外部配置文件，缺失时需询问用户。