用途：当工作区存在来源不明的未提交改动、需要整理为一串干净、线性的原子提交时使用。核心判定标准是 bisect 测试：若 git bisect 单独落在这个提交上，项目仍能构建、跑测试并部署，且提交标题只描述一个内聚的改动。由此得出两条分组规则：取最小可构建且可部署的单元，不拆到中间提交无法编译或测试；也不要把两个无关改进塞进同一提交。两者冲突时优先取更小的提交，并用最少脚手架（如 stub、no-op 默认值）保持树是绿的。
工作流分五个阶段。一、调查：先看工作区全貌，运行 git status --short、git diff --stat、git diff、git diff --cached、git log -10 --oneline；已有暂存改动时决定保留还是用 git reset HEAD 取消暂存，不用破坏性重置，不确定时询问用户。二、研究：把 diff 当作别人写的代码，逐文件读完整 diff，必要时读周边代码，标注每个 hunk 的变更类型与依赖关系，形成逻辑改动清单。三、分组：一个逻辑改动对应一个提交；按构建依赖排序，基础先行；重构单独成提交；生成文件随触发它的改动一起提交；纯格式化单独成提交；文档、测试与代码若属同一改动则放一起；同一文件含多个逻辑改动时用 hunk 级提交。四、提交：文件级用 cortex git commit "消息" 文件...；hunk 级用 cortex git patch --diff，可通过临时 diff 文件或 stdin 管道（--diff -）传入，文件位置参数是允许列表，超出会拒绝提交。提交消息遵循 Conventional Commits（feat/fix/refactor/docs/test/chore/build），并先看 git log -10 --oneline 匹配项目风格。五、验证：用 git status、git log -N --oneline、git diff HEAD~N..HEAD --stat 检查每个提交差异是否内聚、消息是否单一、顺序是否满足依赖；若提交有误，不用破坏性操作改历史，改用后续修复提交或先上报用户再讨论 rebase。
注意事项：不要擅自提交非本人编写的脏文件，先向用户说明；不要直接用 git add，会绕过安全检查；不要用 git reset --hard、git checkout -- 或 git stash drop 清理未提交工作；不要为了拆小而破坏构建；不要把修复与其测试分开；原有顺序有原因时不要重排。资料未提供该技能的价格、收费方式与具体平台支持信息。