oh-my-pi omp commit workflow 的 Agentic 提交系统提示词解析从工具编排到 Conventional Commit 智能生成【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读本文围绕 oh-my-piompcoding-agent 中omp commit workflow的 Agentic 提交智能体系统提示词展开逐段拆解其角色设定、工具调用纪律、Commit 文案规范与 Changelog 联动机制并结合packages/coding-agent/src/commit/下的真实源码工具实现、校验逻辑、会话编排与兜底策略进行交叉印证。读完本文你将完整掌握该提交工作流如何决策 git 信息 → 如何最小化工具开销 → 如何产出合格 Conventional Commit 与 Changelog的全链路设计并可直接借鉴其提示词工程与程序化校验相结合的实现思路。一、系统提示词的整体定位一个提交专家智能体omp commit workflow的 agentic 提交能力由系统提示词 system.md 定义。提示词首段为智能体设定了明确身份与最终目标You are omp commit workflows conventional commit expert. Your job: decide needed git info, gather via tools, then call exactly one:propose_commit(single commit)split_commit(multiple commits when changes are unrelated)这是一个典型的目标导向 工具约束型提示词智能体的全部工作收敛为一个二元决策——要么用propose_commit提交单一 commit要么在改动互不相关时用split_commit拆分为多个原子 commit。这种二选一的收口设计从提示词层面保证了每次会话都有一个确定性的终止动作。从源码看该提示词并不是孤立文本而是在 agent.ts 中通过模板渲染注入类型体系后作为会话系统提示词使用的const typesDescription prompt.render(typesDescriptionPrompt); const systemPrompt prompt.render(agentSystemPrompt, { types_description: typesDescription, });其中{{types_description}}占位符由 types-description.md 渲染填充二者共同构成完整的系统提示词。会话创建时还做了多项隔离设置enableLsp: false、enableMCP: false、skills: []、restrictToolNames: true即提交智能体是一个封闭的、仅能使用内置提交工具的受限会话避免无关能力干扰提交决策。二、工作流规则最小化工具开销的调用纪律提示词用六条编号规则硬性约束智能体的工具使用习惯1. Always call git_overview first. 2. Keep tool calls minimal: prefer 1-2 git_file_diff calls for key files (hard limit 2). 3. Use git_hunk only for large diffs. 4. Use recent_commits only if you need style context. 5. Use analyze_files only when diffs too large or unclear. 6. Do not use read.这六条规则的设计意图清晰git_overview是强制第一步它一次性返回暂存文件列表、diff stat 摘要与 numstat 条目是后续一切决策的信息基座。对应实现见 git-overview.ts其返回结构GitOverviewSnapshot包含files、stat、numstat、scopeCandidates、isWideScope、untrackedFiles与excludedFiles见 state.ts。git_file_diff硬性上限 2 次强制智能体只深入阅读关键文件避免在大仓库中对每个文件都拉取完整 diff控制 token 与延迟成本。git_hunk仅用于大 diff当某个文件 diff 过大时按 hunk 精确取段而不是整文件读取。recent_commits按需使用仅在需要参考历史提交风格subject 句式、scope 习惯时才调用。analyze_files兜底diff 太大或语义不明时才并行拉起 sonic 子智能体做深度分析。do not use read明确禁止通用读取工具防止智能体脱离提交专用信息通道去随意翻阅文件。在工具注册层面tools/index.ts 的createCommitTools按固定顺序装配了 8 个工具git_overview、git_file_diff、git_hunk、recent_commits以及条件启用的analyze_files最后是三个提交动作工具propose_changelog、propose_commit、split_commit。信息采集类工具在前、提交动作类工具在后与提示词的工作流顺序完全对应。三、Commit 文案规范程序化校验的硬约束提示词中段给出了详细的提交文案要求这是整个提示词中最具可执行性的部分且每一项都在源码中有对应的强制校验实现3.1 Summary 行规范- Summary line: past-tense verb, ≤ 72 chars, no trailing period. - Avoid filler words: comprehensive, various, several, improved, enhanced, better. - Avoid meta phrases: this commit, this change, updated code, modified files.对应实现位于 validation.tsSUMMARY_MAX_CHARS 72常量第 7 行与基础校验validateSummary一起保证 summary 行不超过 72 字符且不以句号结尾过去式动词开头validateSummaryRules提取首词用isPastTenseFirstWord判定若不满足直接报错Summary must start with a past-tense verb第 28-31 行填充词与元短语检测fillerWords [comprehensive, various, several, improved, enhanced, better]与metaPhrases [this commit, this change, updated code, modified files]逐词扫描 summary命中即产生 warning第 34-43 行。注意填充词命中是 warning 而非 error——提示词要求避免程序对偶发情况留有余地。3.2 Scope 与 Detail 行规范- Scope: lowercase, max two segments; only letters, digits, hyphens, underscores. - Detail lines optional (0-6). Each sentence ending in period, ≤ 120 chars.对应实现Scope 校验validateScope校验小写、最多两段、仅允许字母数字连字符下划线scope 的候选提取由 scope.ts 的extractScopeCandidates完成并在git_overview中基于 numstat 自动生成候选供智能体参考Detail 行 0-6 条MAX_DETAIL_ITEMS 6常量validation.ts 第 8 行当智能体提交的 detail 超过 6 条时capDetails会按优先级打分截断保留最重要的 6 条。打分规则值得玩味第 66-77 行安全类关键词security|vulnerability|exploit|cve100 分、破坏性变更breaking|incompatible90 分、性能performance|optimiz|latency|throughput80 分、Bug 修复bug|fix|crash|panic|regression|failure70 分、API/公开接口 50 分、用户相关 40 分、弃用/删除 35 分——这是一种用关键词优先级实现摘要内容重要性排序的轻量方案。3.3 Type 与改动内容的一致性校验validateTypeConsistencyvalidation.ts 第 79-127 行进一步校验 commit type 与真实改动文件是否匹配Type校验逻辑docs必须包含.md/.mdx/.adoc/.rst文档改动否则报错test必须包含 test/tests/tests目录或_test/.test/.spec文件ci必须包含.github/workflows/或.gitlab-ci改动build必须包含Cargo.toml/package.json/Makefile等构建文件refactor若 diff 中出现new file mode新增文件则 warning 提示考虑 featperf若缺少 benchmark 文件且无性能关键词产生 warning这套校验把提示词要求与仓库实际状态挂钩使智能体无法凭空声称类型显著提升提交信息的可信度。四、Conventional Commit 类型体系提示词通过{{types_description}}模板变量注入类型体系其内容定义在 types-description.mdTypes: feat, fix, refactor, perf, docs, test, build, ci, chore, style, revert. Format: type(scope): summary with past-tense summary.11 种类型覆盖了日常开发的主要变更形态。类型定义本身含每种类型的语义说明可进一步参考 commit-types.tspropose_commit与split_commit的参数 schema 中均通过commitTypeSchema对类型取值做了白名单校验见 schemas.ts。格式上强调type(scope): summary且 summary 用过去式——这与 Conventional Commits 规范一致同时normalizeSummaryvalidation.ts 第 13-16 行会先剥离智能体可能重复输出的type(scope):前缀stripTypePrefix、归一化 Unicode 并压缩空白再参与长度与句式校验防止格式双写导致的误判。五、工具矩阵详解从信息采集到提交落地提示词末尾的 Tool guidance 部分逐项说明了 8 个工具的职责结合源码可以还原每个工具的实际行为5.1 信息采集类工具git_overviewgit-overview.ts参数staged?默认 true是否使用暂存改动与include_untracked?unstaged 模式下是否包含未跟踪文件。实现中会过滤EXCLUDED_LOCK_FILES锁文件见 lock-files.ts生成类似git diff --stat的可视化统计每个文件最多 40 个/-符号并调用extractScopeCandidates输出 scope 候选。git_file_diffgit-file-diff.ts针对指定文件取 diff受提示词硬性上限 2 次约束。git_hunkgit-hunk.ts对大 diff 按 hunk 精确选取。recent_commitsrecent-commits.ts返回近期提交的 subject 与风格统计供智能体对齐仓库既有提交风格。analyze_filesanalyze-file.ts并行拉起 sonic 子智能体做深度文件分析对应提示词中的 spawn sonic subagents in parallel配套的子智能体提示词见 analyze-file.md。5.2 提交动作类工具propose_commitpropose-commit.ts参数为{ type, scope, summary, details, issue_refs }。执行时会依次做 summary 规则校验、validateAnalysis分析校验与validateTypeConsistency类型一致性校验全部通过才将proposal写入state否则返回valid: false与错误列表并附上约束信息maxSummaryChars: 72、maxDetailItems: 6供智能体自我修正。split_commitsplit-commit.ts用于改动互不相关时拆分为多个原子 commit。其changes支持三种文件选择方式{ path, kind: all }整文件{ path, kind: indices, indices: number[] }按 hunk 索引选取从 1 开始、必须为整数{ path, kind: lines, start, end }按行区间选取。校验非常严格不允许文件出现在多个 commit、不允许跨 commit 文件重叠、所有暂存文件必须被覆盖、hunk 索引与行区间必须合法且经vcs.validateHunkSelections与真实 diff 核对。commit 之间还支持dependencies声明依赖顺序由 topo-sort.ts 的computeDependencyOrder做拓扑排序校验禁止自依赖、越界与环。六、Changelog 联动机制提示词末尾专门列出 Changelog 要求If changelog targets provided, you MUST call propose_changelog before finishing. If you propose split commit plan, include changelog target files in relevant commit changes.对应机制分三层触发条件只有当外部传入changelogTargets即指定了需要更新的 CHANGELOG 文件时才强制调用propose_changelog工具实现propose-changelog.ts 的参数 schema 定义了 7 个标准分类Breaking Changes、Added、Changed、Deprecated、Removed、Fixed、Security与CHANGELOG_CATEGORIES白名单一致支持entries新增条目与deletions移除已有条目条目会自动 trim、去重、去掉句尾句号会话收口agent.ts 中的needsChangelog input.requireChangelog input.changelogTargets.length 0决定收口条件isProposalComplete要求同时满足已有 commit proposalpropose_commit 或 split_commit且changelog 需要时已有 changelogProposal才算完成。七、会话编排重试提醒与兜底策略7.1 完成度判定与重试runCommitAgentSession在智能体首轮输出后会循环检查isProposalComplete若未满足则最多重试 3 次每次注入一条system-reminder合成消息buildReminderMessage明确指出缺失项commit proposal 或 changelog entries与重试次数。这一机制把提示词要求与运行时强制结合即使智能体首轮遗漏关键调用也能通过程序化提醒拉回正轨。7.2 会话中的实时状态展示agent.ts还实现了交互式终端反馈订阅会话事件在工具执行时以✓ ToolName/✗ ToolName形式打印工具调用结果formatToolLabel将 snake_case 转为 PascalCase 显示并渲染工具参数树formatToolArgsBlock使用⎿/├/└分支符号最终输出● agent finished (N messages, M tools)统计。7.3 无智能体兜底当 agentic 流程失败时fallback.ts 提供确定性兜底inferTypeFromFiles根据文件路径模式推断类型测试文件→test、纯文档→docs、样式→style、纯配置→chore、其余→refactorgenerateFallbackSummary按类型生成verb file and N other(s)形式的摘要并附带Commit generated using fallback due to agent failure警告。这保证了提交流程在智能体异常时仍能产出可用结果。八、用户侧提示词会话的输入封装每次会话除系统提示词外还会注入 session-user.md 作为用户消息模板它包含三块可变内容user_context用户的额外上下文说明changelog_targets需要更新的 changelog 文件列表出现时强调 MUST 调用propose_changelogexisting_changelog_entries已有 Unreleased 条目允许通过deletions移除重复或已发布条目。模板末尾再次给出执行路径指引Inspect staged changes: git_* tools. Deeper per-file summaries: call analyze_files. Finish: propose_commit | split_commit.——与系统提示词的工作流规则首尾呼应构成完整的上下文闭环。九、设计要点总结提示词与程序双保险文案规范72 字符、过去式、填充词既有提示词约束也有validation.ts的硬校验兜底杜绝模型自由发挥工具调用最小化通过硬性次数上限git_file_diff≤ 2、分级工具diff → hunk → analyze_files和禁用read把每次提交的推理成本压到最低确定性收口所有路径最终收敛到propose_commit或split_commit二选一配合 3 次重试提醒与 fallback 兜底保证流程必然产出结果类型与内容联动validateTypeConsistency让 commit type 与真实文件改动互相印证从源头提升提交历史的可信度Changelog 一体化提交提案与 changelog 条目在同一会话内联生成并校验避免提交完了忘更新 changelog的常见遗漏。如需进一步深入可继续阅读以下关键文件system.md本文主角、agent.ts会话编排、validation.ts规范校验、split-commit.ts拆分提交以及 fallback.ts兜底策略。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oh-my-pi omp commit workflow 的 Agentic 提交系统提示词解析：从工具编排到 Conventional Commit 智能生成
oh-my-pi omp commit workflow 的 Agentic 提交系统提示词解析从工具编排到 Conventional Commit 智能生成【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi导读本文围绕 oh-my-piompcoding-agent 中omp commit workflow的 Agentic 提交智能体系统提示词展开逐段拆解其角色设定、工具调用纪律、Commit 文案规范与 Changelog 联动机制并结合packages/coding-agent/src/commit/下的真实源码工具实现、校验逻辑、会话编排与兜底策略进行交叉印证。读完本文你将完整掌握该提交工作流如何决策 git 信息 → 如何最小化工具开销 → 如何产出合格 Conventional Commit 与 Changelog的全链路设计并可直接借鉴其提示词工程与程序化校验相结合的实现思路。一、系统提示词的整体定位一个提交专家智能体omp commit workflow的 agentic 提交能力由系统提示词 system.md 定义。提示词首段为智能体设定了明确身份与最终目标You are omp commit workflows conventional commit expert. Your job: decide needed git info, gather via tools, then call exactly one:propose_commit(single commit)split_commit(multiple commits when changes are unrelated)这是一个典型的目标导向 工具约束型提示词智能体的全部工作收敛为一个二元决策——要么用propose_commit提交单一 commit要么在改动互不相关时用split_commit拆分为多个原子 commit。这种二选一的收口设计从提示词层面保证了每次会话都有一个确定性的终止动作。从源码看该提示词并不是孤立文本而是在 agent.ts 中通过模板渲染注入类型体系后作为会话系统提示词使用的const typesDescription prompt.render(typesDescriptionPrompt); const systemPrompt prompt.render(agentSystemPrompt, { types_description: typesDescription, });其中{{types_description}}占位符由 types-description.md 渲染填充二者共同构成完整的系统提示词。会话创建时还做了多项隔离设置enableLsp: false、enableMCP: false、skills: []、restrictToolNames: true即提交智能体是一个封闭的、仅能使用内置提交工具的受限会话避免无关能力干扰提交决策。二、工作流规则最小化工具开销的调用纪律提示词用六条编号规则硬性约束智能体的工具使用习惯1. Always call git_overview first. 2. Keep tool calls minimal: prefer 1-2 git_file_diff calls for key files (hard limit 2). 3. Use git_hunk only for large diffs. 4. Use recent_commits only if you need style context. 5. Use analyze_files only when diffs too large or unclear. 6. Do not use read.这六条规则的设计意图清晰git_overview是强制第一步它一次性返回暂存文件列表、diff stat 摘要与 numstat 条目是后续一切决策的信息基座。对应实现见 git-overview.ts其返回结构GitOverviewSnapshot包含files、stat、numstat、scopeCandidates、isWideScope、untrackedFiles与excludedFiles见 state.ts。git_file_diff硬性上限 2 次强制智能体只深入阅读关键文件避免在大仓库中对每个文件都拉取完整 diff控制 token 与延迟成本。git_hunk仅用于大 diff当某个文件 diff 过大时按 hunk 精确取段而不是整文件读取。recent_commits按需使用仅在需要参考历史提交风格subject 句式、scope 习惯时才调用。analyze_files兜底diff 太大或语义不明时才并行拉起 sonic 子智能体做深度分析。do not use read明确禁止通用读取工具防止智能体脱离提交专用信息通道去随意翻阅文件。在工具注册层面tools/index.ts 的createCommitTools按固定顺序装配了 8 个工具git_overview、git_file_diff、git_hunk、recent_commits以及条件启用的analyze_files最后是三个提交动作工具propose_changelog、propose_commit、split_commit。信息采集类工具在前、提交动作类工具在后与提示词的工作流顺序完全对应。三、Commit 文案规范程序化校验的硬约束提示词中段给出了详细的提交文案要求这是整个提示词中最具可执行性的部分且每一项都在源码中有对应的强制校验实现3.1 Summary 行规范- Summary line: past-tense verb, ≤ 72 chars, no trailing period. - Avoid filler words: comprehensive, various, several, improved, enhanced, better. - Avoid meta phrases: this commit, this change, updated code, modified files.对应实现位于 validation.tsSUMMARY_MAX_CHARS 72常量第 7 行与基础校验validateSummary一起保证 summary 行不超过 72 字符且不以句号结尾过去式动词开头validateSummaryRules提取首词用isPastTenseFirstWord判定若不满足直接报错Summary must start with a past-tense verb第 28-31 行填充词与元短语检测fillerWords [comprehensive, various, several, improved, enhanced, better]与metaPhrases [this commit, this change, updated code, modified files]逐词扫描 summary命中即产生 warning第 34-43 行。注意填充词命中是 warning 而非 error——提示词要求避免程序对偶发情况留有余地。3.2 Scope 与 Detail 行规范- Scope: lowercase, max two segments; only letters, digits, hyphens, underscores. - Detail lines optional (0-6). Each sentence ending in period, ≤ 120 chars.对应实现Scope 校验validateScope校验小写、最多两段、仅允许字母数字连字符下划线scope 的候选提取由 scope.ts 的extractScopeCandidates完成并在git_overview中基于 numstat 自动生成候选供智能体参考Detail 行 0-6 条MAX_DETAIL_ITEMS 6常量validation.ts 第 8 行当智能体提交的 detail 超过 6 条时capDetails会按优先级打分截断保留最重要的 6 条。打分规则值得玩味第 66-77 行安全类关键词security|vulnerability|exploit|cve100 分、破坏性变更breaking|incompatible90 分、性能performance|optimiz|latency|throughput80 分、Bug 修复bug|fix|crash|panic|regression|failure70 分、API/公开接口 50 分、用户相关 40 分、弃用/删除 35 分——这是一种用关键词优先级实现摘要内容重要性排序的轻量方案。3.3 Type 与改动内容的一致性校验validateTypeConsistencyvalidation.ts 第 79-127 行进一步校验 commit type 与真实改动文件是否匹配Type校验逻辑docs必须包含.md/.mdx/.adoc/.rst文档改动否则报错test必须包含 test/tests/tests目录或_test/.test/.spec文件ci必须包含.github/workflows/或.gitlab-ci改动build必须包含Cargo.toml/package.json/Makefile等构建文件refactor若 diff 中出现new file mode新增文件则 warning 提示考虑 featperf若缺少 benchmark 文件且无性能关键词产生 warning这套校验把提示词要求与仓库实际状态挂钩使智能体无法凭空声称类型显著提升提交信息的可信度。四、Conventional Commit 类型体系提示词通过{{types_description}}模板变量注入类型体系其内容定义在 types-description.mdTypes: feat, fix, refactor, perf, docs, test, build, ci, chore, style, revert. Format: type(scope): summary with past-tense summary.11 种类型覆盖了日常开发的主要变更形态。类型定义本身含每种类型的语义说明可进一步参考 commit-types.tspropose_commit与split_commit的参数 schema 中均通过commitTypeSchema对类型取值做了白名单校验见 schemas.ts。格式上强调type(scope): summary且 summary 用过去式——这与 Conventional Commits 规范一致同时normalizeSummaryvalidation.ts 第 13-16 行会先剥离智能体可能重复输出的type(scope):前缀stripTypePrefix、归一化 Unicode 并压缩空白再参与长度与句式校验防止格式双写导致的误判。五、工具矩阵详解从信息采集到提交落地提示词末尾的 Tool guidance 部分逐项说明了 8 个工具的职责结合源码可以还原每个工具的实际行为5.1 信息采集类工具git_overviewgit-overview.ts参数staged?默认 true是否使用暂存改动与include_untracked?unstaged 模式下是否包含未跟踪文件。实现中会过滤EXCLUDED_LOCK_FILES锁文件见 lock-files.ts生成类似git diff --stat的可视化统计每个文件最多 40 个/-符号并调用extractScopeCandidates输出 scope 候选。git_file_diffgit-file-diff.ts针对指定文件取 diff受提示词硬性上限 2 次约束。git_hunkgit-hunk.ts对大 diff 按 hunk 精确选取。recent_commitsrecent-commits.ts返回近期提交的 subject 与风格统计供智能体对齐仓库既有提交风格。analyze_filesanalyze-file.ts并行拉起 sonic 子智能体做深度文件分析对应提示词中的 spawn sonic subagents in parallel配套的子智能体提示词见 analyze-file.md。5.2 提交动作类工具propose_commitpropose-commit.ts参数为{ type, scope, summary, details, issue_refs }。执行时会依次做 summary 规则校验、validateAnalysis分析校验与validateTypeConsistency类型一致性校验全部通过才将proposal写入state否则返回valid: false与错误列表并附上约束信息maxSummaryChars: 72、maxDetailItems: 6供智能体自我修正。split_commitsplit-commit.ts用于改动互不相关时拆分为多个原子 commit。其changes支持三种文件选择方式{ path, kind: all }整文件{ path, kind: indices, indices: number[] }按 hunk 索引选取从 1 开始、必须为整数{ path, kind: lines, start, end }按行区间选取。校验非常严格不允许文件出现在多个 commit、不允许跨 commit 文件重叠、所有暂存文件必须被覆盖、hunk 索引与行区间必须合法且经vcs.validateHunkSelections与真实 diff 核对。commit 之间还支持dependencies声明依赖顺序由 topo-sort.ts 的computeDependencyOrder做拓扑排序校验禁止自依赖、越界与环。六、Changelog 联动机制提示词末尾专门列出 Changelog 要求If changelog targets provided, you MUST call propose_changelog before finishing. If you propose split commit plan, include changelog target files in relevant commit changes.对应机制分三层触发条件只有当外部传入changelogTargets即指定了需要更新的 CHANGELOG 文件时才强制调用propose_changelog工具实现propose-changelog.ts 的参数 schema 定义了 7 个标准分类Breaking Changes、Added、Changed、Deprecated、Removed、Fixed、Security与CHANGELOG_CATEGORIES白名单一致支持entries新增条目与deletions移除已有条目条目会自动 trim、去重、去掉句尾句号会话收口agent.ts 中的needsChangelog input.requireChangelog input.changelogTargets.length 0决定收口条件isProposalComplete要求同时满足已有 commit proposalpropose_commit 或 split_commit且changelog 需要时已有 changelogProposal才算完成。七、会话编排重试提醒与兜底策略7.1 完成度判定与重试runCommitAgentSession在智能体首轮输出后会循环检查isProposalComplete若未满足则最多重试 3 次每次注入一条system-reminder合成消息buildReminderMessage明确指出缺失项commit proposal 或 changelog entries与重试次数。这一机制把提示词要求与运行时强制结合即使智能体首轮遗漏关键调用也能通过程序化提醒拉回正轨。7.2 会话中的实时状态展示agent.ts还实现了交互式终端反馈订阅会话事件在工具执行时以✓ ToolName/✗ ToolName形式打印工具调用结果formatToolLabel将 snake_case 转为 PascalCase 显示并渲染工具参数树formatToolArgsBlock使用⎿/├/└分支符号最终输出● agent finished (N messages, M tools)统计。7.3 无智能体兜底当 agentic 流程失败时fallback.ts 提供确定性兜底inferTypeFromFiles根据文件路径模式推断类型测试文件→test、纯文档→docs、样式→style、纯配置→chore、其余→refactorgenerateFallbackSummary按类型生成verb file and N other(s)形式的摘要并附带Commit generated using fallback due to agent failure警告。这保证了提交流程在智能体异常时仍能产出可用结果。八、用户侧提示词会话的输入封装每次会话除系统提示词外还会注入 session-user.md 作为用户消息模板它包含三块可变内容user_context用户的额外上下文说明changelog_targets需要更新的 changelog 文件列表出现时强调 MUST 调用propose_changelogexisting_changelog_entries已有 Unreleased 条目允许通过deletions移除重复或已发布条目。模板末尾再次给出执行路径指引Inspect staged changes: git_* tools. Deeper per-file summaries: call analyze_files. Finish: propose_commit | split_commit.——与系统提示词的工作流规则首尾呼应构成完整的上下文闭环。九、设计要点总结提示词与程序双保险文案规范72 字符、过去式、填充词既有提示词约束也有validation.ts的硬校验兜底杜绝模型自由发挥工具调用最小化通过硬性次数上限git_file_diff≤ 2、分级工具diff → hunk → analyze_files和禁用read把每次提交的推理成本压到最低确定性收口所有路径最终收敛到propose_commit或split_commit二选一配合 3 次重试提醒与 fallback 兜底保证流程必然产出结果类型与内容联动validateTypeConsistency让 commit type 与真实文件改动互相印证从源头提升提交历史的可信度Changelog 一体化提交提案与 changelog 条目在同一会话内联生成并校验避免提交完了忘更新 changelog的常见遗漏。如需进一步深入可继续阅读以下关键文件system.md本文主角、agent.ts会话编排、validation.ts规范校验、split-commit.ts拆分提交以及 fallback.ts兜底策略。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考