git-flow-manager
Git Flow Manager
铁律:不要把一串无关改动塞进同一次提交,也不要在没有质量门结果时安排提交流程。
工作流
- Step 1: 划分变更批次 ⚠️ REQUIRED
- 1.1 按功能、测试、文档、配置变更拆分提交单元。
- 1.2 标记用户已有改动与当前任务改动,避免误暂存。
- Step 2: 安排提交流程
- 2.1 明确哪些提交必须先于其他提交进入仓库。
- 2.2 如果只是生成提交消息,交给 conventional-committer 执行。
- Step 3: 风险检查
- 3.1 先确认 quality-guardian 已完成必要检查。
- 3.2 识别可能引起冲突的共享文件和长生命周期分支风险。
- Step 4: 变更记录 (conditional)
- 4.1 需要 changelog 或 release note 时,按提交批次汇总。
- 4.2 说明哪些更改适合单独提交,哪些适合压缩。
反模式
- 为了省事把功能、测试、格式化和重命名全部混在一起。
- 不区分用户已有改动和当前任务改动。
- 提交顺序没有解释,后续无法稳定 cherry-pick 或回滚。
交付前检查
- 已按功能边界拆分提交计划。
- 已识别无关改动和潜在冲突点。
- 质量门状态清晰。
- 如需提交消息,已明确交给 conventional-committer。
More from caomeiyouren/cmyr-skills-agents
test-engineer
编写、补齐、运行和优化测试时使用,优先覆盖 Vitest 场景,也适用于组件逻辑、工具函数、状态管理和服务层的测试设计。用户提到 test、unit test、integration test、coverage、mock、Vitest、补测试时都应触发。
7full-stack-master
需要统筹需求澄清、上下文扫描、技术方案、前后端实现、UI 验证、测试、质量审查、文档同步和提交节奏时使用。它负责编排多技能协作,而不是亲自替代所有专业技能。用户提到 end-to-end workflow、全流程开发、从需求到提交、PDTFC+、多技能编排时都应触发。
7quality-guardian
运行并解读 lint、类型检查、测试等质量门时使用。它不只是执行命令,还要根据变更范围选择最小充分检查、分析失败原因,并给出是否允许继续提交或发布的判断。用户提到 lint、typecheck、tests、quality gate、验证改动时都应触发。
6security-guardian
对鉴权、权限、输入处理、数据写入、依赖配置、密钥、日志和外部调用进行安全审计时使用。用户提到 security、auth、permission、vulnerability、secret、injection、审计登录逻辑、权限合规时都应触发。
6conventional-committer
需要生成 Conventional Commit 提交消息并执行单次提交时使用。适用于 feat、fix、docs、refactor、test、build、ci、chore 等常规提交场景。先检查质量门,再分析 diff,再生成符合 commitlint 预期的消息。
6context-analyzer
在动手规划、修改、调试或回答复杂项目问题前使用。用于快速扫描项目结构、依赖、约束文档、关键文件和调用链,输出任务相关上下文,而不是直接改代码。用户提到 analyze context、scan repo、understand project、定位实现、找规范、排查调用链时都应触发。
5