codex 团队协作开发流程git 管理版本以及随时回退当前版本Agents.md 项目与全局规约理想漂亮准确计算的 数据看板信息图Goal 长期任务模式辅助插件codex 多人协作开发 · 真实项目流程单工作树多工作树内化成选择题 skillGitLab 安全提交向导文档驱动开发 测试驱动开发组合工作流 skillgit 管理版本以及随时回退当前版本输入把当前项目保存成一个版本只做本地提交不要推送先保存避免改着改着坏了不能恢复。git 能回退某版本代码但不能回退到数据库数据。Agents.md 项目与全局规约Agents.md自定义内容1.修改代码时优先保持项目现有结构不要过度设计2.不要主动引入新依赖除非确实必要3.不要自动执行 git push4.只有我明确要求时才提交 commit5.改完代码后说明改了哪些文件、为什么改、如何验证6.遇到不确定的地方先基于现有代码做最小改动7.采用测试驱动开发文档驱动开发8.在gitcommit~前务必读取 git-commit-convention.mdgit-commit-convention.md#AI 提交信息生成规范##0.前置分支强制校验模块 ###0.1变量填写位置 【当前分支填写处】current_branch____________使用时请在横线位置填入真实Git分支名称为空代表无有效分支 ###0.2执行优先级 触发生成提交信息、执行提交操作前**第一步必须读取上方current_branch分支变量完成校验**未校验禁止执行后续任何代码变更解析、commit文案生成逻辑。 ###0.3分支校验判定规则1.❌ 禁止直接提交保护分支匹配即校验失败main、master、prod、release2.✅ 允许提交的合规分支类型满足任意一条即校验通过-前缀分支feature/*、bugfix/*、hotfix/*、dev/*、test/* - 人名分支以大写英文字母开头的人物姓名命名分支例YSS、SXH、ZRL 3. 异常情况current_branch 空白/乱码无效字符判定校验失败终止全部流程。 ### 0.4 校验固定输出文案 - 校验通过分支校验完成当前分支{填入的分支名}符合提交规范开始解析代码变更 - 校验失败分支校验不通过当前分支{填入的分支名}该分支不允许直接提交代码请切换至规范开发分支后重试 ## 1. 触发条件 用户下达「生成提交信息」「执行提交」指令时优先执行0章节分支校验校验通过后严格遵循本规范输出提交文案。 ## 2. 变更读取规则 1. 依据 git diff --staged / git diff 解析全部待提交代码变更内容 2. 变更文件数量大于5个时先汇总所有文件路径、划定改动影响范围再生成规范提交信息。 ## 3. 强制标准提交结构核心 仅输出符合下述模板的单条或多条提交记录仅正文提及文件名称时使用代码块包裹整体提交文本不额外套代码块 type(scope): subject [可选补充正文body详细说明改动逻辑] [可选脚注footer关联工单/标注破坏性变更] ### 3.1 type 改动类型必填严格单选 仅选用下表词汇禁止使用 update、modify、change 等模糊笼统描述 - feat新增用户侧功能、前端页面、对外接口等用户可见变更 - fix修复线上、测试环境存在的业务缺陷、逻辑bug - docs仅调整项目文档、代码注释、README、Wiki说明文本 - style纯格式调整不改动业务逻辑缩进、空格、分号、代码格式化 - refactor代码重构优化无bug修复、无新增功能变量重命名、公共方法抽取、冗余代码删减 - perf专项性能优化提升执行速度、降低内存/带宽占用 - test新增、调整单元测试、集成测试、测试用例 - build调整构建配置、第三方依赖包、项目打包脚本Vite/Webpack/pip/npm配置 - ci修改自动化流水线配置GitHub Actions、GitLab CI、Jenkins等 - chore杂项配置调整不涉及业务源码、测试文件更新.gitignore、版本号、配置文件 - revert回滚历史某次提交记录 ### 3.2 scope 作用域选填 1. 优先填写改动对应模块名、组件名、核心文件名不带文件后缀 2. 多模块无关改动可省略scope或使用 * 作为通用标识。 ### 3.3 subject 主题必填强约束规则 1. 统一使用中文撰写适配国内团队协作规范 2. 采用动词开头祈使句式使用原形动词禁止后缀「了」「过」 3. 全文无末尾句号、顿号收尾 4. 文字长度上限50个中文字符简洁直白不写冗余概括。 ### 3.4 body 正文说明选填 1. 核心说明改动原因、业务背景不重复复述代码改动内容 2. 对比旧逻辑缺陷、本次优化带来的收益 3. 微小简单改动文字修正、空格调整可省略正文 4. 单行文字长度不超过72个中文字符。 ### 3.5 footer 脚注选填 1. 破坏性兼容变更接口/数据表结构/函数入参发生不兼容改动时type后缀添加 !脚注首行固定 BREAKING CHANGE: 变更详细描述 2. 关联工单需求绑定GitLab Issue、TAPD需求单格式为 Closes #单号修复对应需求、Refs #单号关联参考需求 3. 禁止添加协同作者字段Co-Authored-By 相关内容一律不出现。 ## 4. 变更拆分逻辑规则 读取多文件diff后按以下逻辑拆分/合并提交记录 1. 合并规则多文件归属同一业务逻辑单元如业务逻辑文件对应测试文件统一合并为单条提交 2. 拆分规则多组文件分属完全独立、无关联改动如A模块bug修复 B模块依赖升级必须拆分为多条独立提交按改动主次顺序依次输出 3. type快速判定规则 - 删减代码、无新增功能refactor / fix - 新增对外接口、页面功能feat - 仅修改CI流水线配置文件ci - 修改package.json版本、.gitignorechore 4. 破坏性变更识别函数名称、接口请求地址、入参出参结构、数据表字段调整必须标记 ! 并补充BREAKING CHANGE说明。 ## 5. 标准输出示例 ### 示例1人名分支校验通过完整输出 【当前分支填写处】current_branch ZhangSan 分支校验完成当前分支ZhangSan符合提交规范开始解析代码变更 fix(登录): 修复手机号含首尾空格时校验拦截问题 重写手机号正则校验逻辑增加首尾空格自动剔除处理解决粘贴手机号误带空格无法提交的问题。 Closes #1024 ### 示例2前缀开发分支校验通过 【当前分支填写处】current_branch bugfix/login-verify 分支校验完成当前分支bugfix/login-verify符合提交规范开始解析代码变更 ### 示例3保护分支校验失败输出 【当前分支填写处】current_branch main 分支校验不通过当前分支main该分支不允许直接提交代码请切换至规范开发分支后重试 ### 示例4多组无关改动拆分多条提交 feat(报表): 新增Excel报表导出接口 新增/api/report/export接口支持自定义日期范围导出CSV业务数据。 --- feat(用户): 头像上传前增加图片自动压缩逻辑 前端检测超过2MB头像文件自动压缩至1080*1080分辨率减少服务器存储占用。 ### 示例5破坏性不兼容变更 refactor!(数据库): User表ID字段由int整型改为UUID格式 BREAKING CHANGE所有调用用户ID的外部微服务需同步调整数据存储与解析逻辑。 ## 6. 禁止行为约束 ❌ 跳过【当前分支填写处】的current_branch校验步骤直接生成提交信息 ❌ 分支校验失败后仍产出commit提交文案 ❌ subject使用「修改代码」「更新文件」等无价值笼统描述 ❌ 格式化修复style类改动与业务功能、bug修复合并为同一条提交需分开拆分 ❌ 未读取diff、未分析代码改动凭空编造提交信息 ❌ 提交信息内添加各类表情符号无团队特殊约定时 ❌ 在主题括号内标注开发作者姓名 ❌ 输出Co-Authored-By等协同作者相关备注内容 ❌ 忽略空白current_branch变量直接执行提交流程。理想漂亮准确计算的 数据看板设计流程要让codex读取所有文件资料再给出一些关键指标再画图后修订。启动规划模式1.先读所有资料确认数据之间对得上如多少字段、多少行数、数据干净与否、数据质量和表、表格和表格之间对得上2.基于对得上的关系挖掘出有价值的分析3.我最关注的是 总xx、总xx、各个xx你也可以分析其他指标4.给出一份看板方案放哪些关键指标配哪些图表验算1.先不执行方案需要验证方案的数据正确性按你给出的方案把里面要用的关键指标都算出来2.指标顺序按照计算复查程度从易到难排序3.每个指标给出指标名称、使用来源、字段、计算公式、人工验证方法、当前结果信息图codex 使用Image Gen skill。纯图像生成1.使用纯图像模型生成图像不要代码生成、SVG2.做一张中文信息图中文需清晰且不变形16:9适配电脑查看3.主题是4.风格现代、清爽、专业代码生成1.使用代码生成图像2.做一张中文信息图中文需清晰且不变形16:9适配电脑查看3.主题是4.风格现代、清爽、专业混合生成使用混合生成1.图像模型生成背景或者插画2.代码负责文字和排版3.文字要与AI生成的图片配合协调4.做一张中文信息图16:9适合电脑看主题是5.风格要现代、清爽、专业6.中文文字需要清晰且不变形ppt生成pptx 技能Presentations1.先定主线今年围绕什么目标做了哪些事带来了什么结果沉淀了什么方法明年准备怎么提升2.把内容提炼成PPT成果表达从原始叙事中提炼目标、动作、结果、影响用数据和结论表达价值3.先做页纲拆成每一页的标题、核心信息、数据、页面表达方式4.确定视觉风格有公司规定模版就用公司规定没有就找找好看的模版默认模版是 纯白不怎么好看5.生成 PPTX每页只讲一个重点少放大段文字多用数字、表格、对比与简短结论6.逐页检查生成后必须检查文字有没有挤、有没有重叠、表格是否可读、数据有没有前后不一致、有没有模版占用文字残留7.多轮优化第一版看结构结构没问题再优化其他维度Goal 长期任务模式Goal 模式长期任务模式。适合多约束、多工具配合需要反复检查的任务输出完整交付的长期任务。围绕目标持续推进直到完成按验收标准逐项确认是否达标目标不清晰导致执行方向不稳我的codex是 0.154.0 版本直接输入就能启动/goal 修复当前项目中的bug如果找不到这个命令那需要自己配置codex 版本 0.1.28编辑配置文件vi config.toml如果你的配置文件里还没有 [features] 这个字段直接在文件末尾加上这两行就行[features]multi_agenttrue remote_connectionstrue goalstrue重启 Codex启动后直接输入/goal 修复当前项目中的bug辅助插件github 代码协作、PR审查、项目维护Codex Security 扫描代码安全问题辅助确认漏洞Figma 读取设计稿辅助UI实现Linear 项目管理Sentry 排查线上问题Computer Use 操控电脑界面Resume-Matcher 简历优化定制精修codex 多人协作开发 · 真实项目流程从git的主分支创建一个功能分支作为本次开发的独立环境改动不会影响主线理解需求与方案可用 规格驱动工具Spec-Kit、规范驱动工具OpenSpec开发与测试可用 SuperPowers 测试驱动开发、Codex Security 扫描漏洞提交本地改动提交要清晰、聚焦推送到 git 的功能分支发起 PR 审查创建 Pull Request描述改动内容、改动范围和diff发起审查和合并流程安全合并单工作树接收到代码后先做一次开发前的基线检查先做一次开发前的基线检查不要修改业务代码。 请确认1.当前 git 分支和远程仓库是否正确2.工作区是否干净有没有未提交改动3.后端和前端依赖是否已安装4.后端、前端能否正常启动5.后端测试、前端测试是否通过 如果检查过程中发现是本地环境缺失导致的问题比如缺少依赖、虚拟环境未安装完整可以直接按照项目文档或者依赖文件补齐环境。 如果需要修改项目源码或配置文件先说明原因等我确认后再修改 最后给出一个精准结论现在是否适合二次开发二次开发请帮我创建一个用于本次二次开发的功能分支。 本次开发目标是改造【】使用分支叫【你取对应的名字】。 要求1.先确认当前 git 工作区是干净的。2.基于当前主分支创建并切换到这个新分支。3.创建完成后告诉我当前分支名称4.不要修改业务代码5.不要提交 commit6.不要推送代码需求分析生成一份计划# 启动规划模式 需求如下...1.生成一份高质量的 proposal.md把模糊需求拆成清晰的目标、明确的边界和可执行的验收规则 高质量的 proposal.md 不是把需求点逐条堆在一起而是按照“目标 → 范围 → 验收”的顺序逐步收敛先说明目标为什么做再说明范围做什么、不做什么最后说明如何判断完成-目标要交代任务背景、预期结果和判断标准。-范围为目标提供执行边界也要写出必要的技术约束。-明确写出范围可以避免 AI 自行扩大改动。-验收标准要把范围转换成可以观察和验证的结果并覆盖关键边界。-验收标准要同时说明操作顺序、可观察结果和边界状态。-验收项还应该尽量量化。2.提交前检查这8项每次编写需求规范后可以逐项检查-目标明确不了解项目背景的人能否仅通过“目标”部分理解任务要解决的问题-范围有界是否同时写清楚要做什么和不做什么-验收可测每一条验收标准是否都能转化为可执行的测试或人工检查-指标量化涉及性能、尺寸或容量时是否提供了明确数值和条件-边界覆盖是否说明了数据缺失、接口故障、空输入等异常场景-不过度规定代码细节是否避免把库选择、类结构和实现分支全部写死-术语一致同一个概念是否始终使用同一个名称例如统一使用“LLM”不要在全文交替使用“大模型”和“大语言模型”。-AI 可执行把这份规范交给一个全新的 AI 会话后AI 是否能理解任务做什么、不做什么以及做到什么程度3.使用AskUserQuestion多轮追问工具像苏格拉底一样帮助我完善需求4.写成 最小修改详细全面丰富安全的计划方案xx_plan.md5.使用 蜂群多智能体模式对方案和需求做审核、对抗、精细分析、对比、安全维度6.每个计划结束时给我列出尚未解决的问题列表如果有的话7.开发完成后应该如何测试按照计划执行执行后验收测试没问题创建本地版本提交信息写清楚 精细到点并告诉我版本编号本地提交完成后我们还不能马上推送功能分支。这里先同步 main是为了让 PR 尽量基于最新主线创建减少后续才发现冲突的概率推送前先获取远程 主线 的最新状态并检查当前 功能分支 是否落后于远程主线。如果远程main没有新的变化功能分支可以直接进入推送前确认如果远程main已经有新的提交处理方式是把最新mainmerge 到当前 功能分支再重新运行测试再判断是否具备推送条件请帮我同步远程 main并准备推送当前功能分支。 要求1.确认当前分支是 xxx功能分支。2.拉取远程 main 的最新代码。3.如果远程 main 有新提交再将最新 main 合并到当前 xxx功能 分支。4.如果出现冲突先说明冲突文件和原因等我确认后再处理。5.如果执行了合并合并完成后重新运行相关测试如果没有新提交也请运行相关测试确认可推送。6.测试通过后告诉我当前分支是否可以推送。7.不要自动推送除非我再次确认。请将当前 xx功能 分支推送到我的 Gitlab 仓库。 要求1.推送分支 xx。2.不要直接合并到 main。3.推送完成后告诉我远程分支地址。4.如果可以创建 PR请先给我 PR 标题和 PR 描述草稿等我确认后再创建。 可以参考下面的模版你也可以自己补充-关联的问题编号如果没有就写 None-说明这次改了什么-选择改动类型-列出具体改动-说明怎么测试-如果有界面变化或关键代码片段可以补截图或片段没有可以留空、勾选已经完成的检查项、-补充信息如果模板已有占位内容按页面提示保留或补充-你的补充关键核心维度5.不要自动合并 PR多工作树本地的 main 和远程的 main并不同步更新。先保证本地 main 和远程 main 保持一致。后面所有新的功能分支都应该基于这个最新的 main 创建而不是基于旧版本继续开发。请先帮我同步当前项目的 main 分支到远程最新状态并做一次基础开发基线检查。 要求1.先确认当前 Git 仓库状态。2.如果当前不在 main 分支请先确认工作区是否干净再切换到 main。3.拉取远程 main 的最新代码。4.确认本地 main 是否已经包含上一章合并进来的申请追踪页面改动。5.告诉我当前 main 分支的最新 commit hash。6.按照项目当前启动方式启动后端和前端服务。7.检查后端健康接口是否正常。8.检查前端页面是否可以正常访问。9.尽量运行和申请追踪页面相关的测试如果测试较多可以优先运行最相关的测试。10.如果有前端 lint 或格式检查也请运行一次。11.最后给我一个结论当前最新 main 是否适合作为多分支协同开发的起点。12.不要创建新分支。13.不要修改业务代码。14.不要提交 commit。15.不要推送代码。内化成选择题 skillGitLab 安全提交向导免费下载https://download.csdn.net/download/qq_41739364/93732624如果打开网页404是因为刚刚上传还在审核。文档驱动开发 测试驱动开发组合工作流 skillAI 编程最大的问题就是不确定、验收需要大量人工工作。那我们只需要在开发前用文档约束在开发完成后用大量测试用例测试就可以大幅度提升 AI 编程的可靠性。复杂工程项目AI编程三件套工作流规格驱动工具Spec-Kit应用规范驱动工具OpenSpec应用SuperPowers 测试驱动开发 并发多Agent开发工程化应用编程项目开发全流程定位意图和想法 - 规范文档 - 技术设计 - 任务拆解 - 编码实现 - 质量轻量文档驱动开发 openspec规范文档 - 技术设计 - 任务拆解全周期文档驱动开发 spec-kit规范文档 - 归档/交付全周期测试驱动开发 superpowers技术设计 - 归档、交付三者可以相互协作最好是 spec-kit 更全面 superpowers。这三个你可以不用学习了我打包成了一个技能OpenSpec Spec Kit Superpowers 组合工作流Superpowers 具备多智能体并行开发能力但当前通用组合工作流默认是一个控制器下的安全串行实现只有相互独立、环境隔离、文件不重叠的任务才允许真正并行。组合工作流默认偏向安全串行。当前组合协议是控制器维护唯一规格和任务图-同一计划中一次只有一个实现者写代码-每个任务完成后独立审查-最后统一集成、全量验证 它允许并行的事情主要是-只读代码调查-多个独立故障的根因分析-已完成任务的评审-不同仓库、不同 Change、不同 Worktree 且文件范围不重叠的实现 不允许并行的事情是-两个 Agent 改同一文件-两个 Agent 改同一 migration 链-同时更新同一份 tasks.md-同时操作同一数据库、锁文件、生成文件或共享环境-后者依赖前者接口、但接口尚未冻结
