用途：当使用者明确要求 Gitflow（main/master、develop、feature/、release/、hotfix/*）或项目已有 git flow 配置、明确声明采用该模型时，帮助定义分支结构、命名约定与合并规则。不应用于主动向未要求 Gitflow 的项目推荐该模型，也不用于解决进行中的合并冲突或设计交付流水线。
主要能力：确认是否明确采用 Gitflow；用 git branch -a 与 git config --get-regexp '^gitflow.' 检查现存分支与配置；确定长期分支名称与短生命周期分支前缀；把约定记录为项目规则（如 .specsfy/RULES.md）；指导各分支的开启、合并与关闭；协调 release/* 或 hotfix/* 合并到 main 时的版本标签；验证 develop 已回收相应修复。
使用方式与规则：所有 feature/、release/、hotfix/ 集成使用 git merge --no-ff；命名保持一致前缀与分隔符（feature/<slug>、release/<versao>、hotfix/<versao-ou-slug>）；release/* 只放缺陷修复、文档与发布准备；hotfix/* 在同一操作中合并到 main（打标签）并合回 develop 或打开的 release/*；合并确认后删除短生命周期分支。验证可用 git log --graph --oneline --all、git branch -a --merged develop、git branch -a --merged main、git tag --contains 等。
限制：资料未提供安装命令、收费、价格、平台与效果等信息。判断项目是否采用 Gitflow 需要一致的命名前缀、可追踪的 --no-ff 合并以及完整的发布/热修闭环，不能仅凭存在 develop 分支断定。对于每天多次持续部署的项目，需先与使用者评估 GitHub Flow 或 trunk-based 是否更合适。