oh-my-pi 贡献指南PR 流程、AI 辅助开发规范与 MIT 许可实践【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本指南基于 oh-my-pi 仓库根目录的 CONTRIBUTING.md 展开系统讲解这个Coding agent with the IDE wired in项目的社区贡献规范从 PR 提交前如何界定改动范围、为何不要为即将自己动手的工作开 Issue到 AI 辅助贡献必须满足的审查义务、PR 验收标准与贡献许可政策。读完本文你将完整掌握向 oh-my-pi 提交一个合格 PR 的全流程并了解项目维护者在评审时的实际关注点从而避免改了不少、却被一键关闭的常见返工。项目定位与贡献入口oh-my-pi 是一个终端内的编程 Agent 产品核心 CLI 是omp主包位于 packages/coding-agent配套的模型目录、Agent 运行时、TUI 渲染库、原生 Rust 加速层分布在 packages 与 crates 下。仓库根目录的 AGENTS.md 明确规定除非特别说明所有开发工作默认聚焦于packages/coding-agent/。CONTRIBUTING.md 是该项目唯一的贡献总入口它规定了三类事项何时需要提前讨论、PR 必须满足的硬性要求、以及代码归属与许可政策。与很多项目不同这份文档将大量篇幅用于约束AI 辅助提交——这与项目自身就是 Agent 产品高度相关项目维护者既欢迎 AI 参与开发又严格防止无人负责的自动提交污染代码库。开始之前小改动与大改动的分界线CONTRIBUTING.md 将改动按规模分为两类处理方式截然不同小改动可直接提 PRBug 修复、文档更新、范围狭窄的改进。这类改动不需要事前讨论可以直接进入 Pull Request 流程。大改动必须先讨论涉及新子系统、大规模 UI 改动、新增依赖、跨多个 package 的改动以及任何架构性/行为性变更。文档明确要求在动手写实现之前先到 Discord 讨论方案文档中给出的讨论渠道为discord.gg/4NMW9cdXZa。这里有一条关键提醒GitHub Issue 不能替代事前讨论且事前讨论并不保证 PR 会被合并。也就是说讨论是准入条件而非通行证最终是否合并仍取决于提交质量与维护者评审。这一小步快跑、大动先行的机制与仓库的物理结构一致项目由十几个 package 组成见 AGENTS.md 的包结构表跨包改动牵一发而动全身例如packages/ai、packages/catalog、packages/coding-agent之间存在严格的依赖约定模型/提供商策略必须放在 KDL 规则树而非 TypeScript 里随意跨包改动的代价远高于单包内的小修。不要为自己即将提交的工作开 IssueCONTRIBUTING.md 有一条容易被忽略但非常实际的规定如果你打算自己实现某个改动不要先为它创建 Issue。原因是仓库的自动化工具robomp会把可行动的 Issue 视为待认领工作并可能并行启动相同的修复从而造成重复劳动、浪费计算资源与维护者时间。正确的做法是报告问题、或提出自己不打算亲手实现的改动→ 开 Issue已存在相关 Issue 时→ 在 PR 中链接它而不是另开一个重复的 Issue打算自己实现→ 直接走 PR 流程大改动先讨论小改动直接提交。这条规则背后是 Agent 工作流特有的协作成本当一个仓库同时存在自动化代理与人类贡献者时Issue 既是问题清单也是工作队列二者不加区分会导致同一修复被抢跑两次。AI 辅助贡献工具可用但责任在提交者这是 CONTRIBUTING.md 的核心章节也最贴合 oh-my-pi 的 Agent 基因。项目态度明确欢迎 AI 作为工具参与但不接受无人值守的自动贡献。禁止的做法是给 Agent 一个模糊目标然后把它产出的一切原样提交。在打开 PR 之前贡献者必须完成四步人工闭环限定范围把 Agent 约束到已商定的范围拒绝无关改动逐文件审查审阅每一个被改动的文件理解最终行为亲自验证运行相关检查、亲手操练被改动的行为人工提交审查通过后由人提交 PR而不是让 Agent 自主发布。文档用一句话总结了责任边界无论代码由谁或什么生成你都要对代码负责You are responsible for the code, regardless of who or what generated it。PR 说明必须包含一句人写的解释每个 PR 的正文必须包含至少一句由你用自己的话撰写的句子说明改了什么、为什么。以下内容不能替代这句人工说明自动生成的摘要粘贴的 Agent 对话记录单独的 checklist。一句诚实的话就够了文档给出了示例I reviewed the full diff; this change fixes duplicate PR reviews by reusing the existing delivery guard.这句话的价值在于证明提交者确实审阅过 diff、理解改动意图而非盲目转发 Agent 的输出。验证要求bun check通过不等于行为正确CONTRIBUTING.md 明确警告bun check通过了本身不是充分的验证。bun check和自动化测试在相关时是预期动作但它们不能证明行为按预期工作。贡献者必须自己走通被改动的路径并在 PR 中报告确切的场景与结果改动类型必须完成的验证Bug 修复复现该 Bug并确认同一复现路径不再失败新功能启动产品端到端使用该功能UI 改动实际交互并检查渲染结果从仓库证据看bun check作为类型检查门禁有其具体定义packages/coding-agent/package.json 中check脚本是oxlint . oxfmt --check ... bun run check:typescheck:types走tsgo即 lint 格式 类型三层检查。项目规定永远不要直接调用tsc/npx tsc一律以bun run check为类型检查门禁。开发者常用命令速查CONTRIBUTING.md 将本地开发命令指引到 packages/coding-agent/DEVELOPMENT.md这份开发者地图给出了完整的本地开发循环命令表在packages/coding-agent/目录下运行或加--cwdpackages/coding-agent任务命令类型检查 lint门禁bun run check仅类型检查bun run check:types仅 lintbun run lint测试bun run test自动修复lint 格式化 promptsbun run fix构建dist/omp二进制bun run build另有两条与 Agent 产品强相关的注意事项改动 React 工具渲染器后需用bun run gen:tool-views重建涉及collab-web/src/tool-render/Rust 测试不要直接跑cargo test而要使用bun run test:rs内部以cargo nextest跑测试、再补一轮cargo test --doc。提交前后的质量红线来自 AGENTS.md虽然 CONTRIBUTING.md 是贡献主文档但仓库根目录的 AGENTS.md 补充了大量与可评审、可维护直接相关的硬性约束贡献者应一并遵守除非被要求绝不评论/创建 GitHub Issue绝不擅自 commit未被要求时不要执行提交动作生成的代码质量不用any除非万不得已、不用ReturnType、不用内联 importprompt 一律放在静态.md文件中用 Handlebars 做动态渲染禁止在代码里拼接 prompt 字符串日志可能运行在 TUI/RPC/SDK/worker 中的代码不得使用console.log/error/warn必须使用oh-my-pi/pi-utils的集中式logger日志写入~/.omp/logs/omp.YYYY-MM-DD.log并自动轮转测试纪律每个新测试必须捍卫一个具体的、可外部观察的契约行为、输出形态、状态迁移、错误映射或易回归的解析边界禁止静态回声测试、禁止expect(true).toBe(true)式占位、禁止对源码文本做 grep 断言。这些规则解释了 CONTRIBUTING.md 为何要求理解你提交的工作——项目用测试规范把行为正确提升为硬性门槛而非只看代码能否编译。贡献许可MIT无需 CLA/DCOoh-my-pi 的贡献许可政策Contribution licensing要点如下有意提交以纳入 OMPoh-my-pi的贡献默认按 MIT License 授权该政策不会重新授权第三方或 vendored 代码提交者必须有权提交自己的贡献并保留适用的版权、许可、署名与声明材料提交贡献不需要签署 CLAContributor License Agreement或 DCODeveloper Certificate of Origin。仓库根目录的 LICENSE 即为 MIT LicenseCopyright 2025 Mario Zechner、2025-2026 Can Bölük、2026 Stencil Labs, Inc.与文档所述一致。对于开发者而言这意味着你只需确保自己拥有所提交代码的权利贡献一经合入即按 MIT 条款被项目使用无需任何额外签约流程。评审评审行为与理解而非代码量Review 章节定义了 oh-my-pi 的评审哲学维护者评审的是所提交的行为和贡献者对它的理解而不是生成代码的数量。具体动作要求亲自回应评审反馈由你自己回应 review 意见且只采纳你已核实过的建议维护者会关闭 PR 的典型情形包括跳过了要求的事前讨论缺少人工撰写的解释说明包含未经审查的 Agent 输出混杂了无关的改动。最后一条保持每个 PR 只做一件逻辑改动one logical change per PR贯穿全文避免无关清理、顺手重构、生成噪音以及不在约定范围内的功能。当前开放状态担保制度vouch的试验性放宽CONTRIBUTING.md 与 README.md 都标注了同一则 NOTEPR 目前作为试验暂时向所有人开放。此前项目要求在合并 PR 前必须有成员担保vouch该要求在评估开放贡献效果期间暂时解除视结果而定担保制度可能回归。这意味着当前阶段是社区贡献的低门槛窗口期但贡献者仍须满足上述全部 PR 硬性要求。结语给 oh-my-pi 贡献者的行动清单综合 CONTRIBUTING.md 及其引用的仓库证据一个合格的 oh-my-pi 贡献流程可以浓缩为六步判定规模小改动直接提 PR涉及新子系统、跨包、新依赖的大改动先到 Discord 讨论不要抢跑自己要做的改动不开 Issue已有相关 Issue 就在 PR 中链接约束 Agent若用 AI 辅助限定范围、逐文件审查、亲自验证、人工提交并在 PR 中写一句自己的解释验证行为以bun run check通过为前提再亲手复现 Bug / 端到端使用功能 / 交互检查 UI并在 PR 里报告场景与结果单点聚焦每个 PR 只含一个逻辑改动不夹带无关重构回应评审亲自回复 review只采纳自己核实过的建议并留意 PR 暂时全开放、担保制度可能回归的政策变化。按此流程提交你的贡献将同时满足工具链门禁lint/类型/测试、行为验证与社区协作三重要求——这正是 oh-my-pi 作为一个由 Agent 驱动开发的项目对每一位贡献者无论人类还是 AI 辅助的完整期望。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
oh-my-pi 贡献指南：PR 流程、AI 辅助开发规范与 MIT 许可实践
oh-my-pi 贡献指南PR 流程、AI 辅助开发规范与 MIT 许可实践【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi本指南基于 oh-my-pi 仓库根目录的 CONTRIBUTING.md 展开系统讲解这个Coding agent with the IDE wired in项目的社区贡献规范从 PR 提交前如何界定改动范围、为何不要为即将自己动手的工作开 Issue到 AI 辅助贡献必须满足的审查义务、PR 验收标准与贡献许可政策。读完本文你将完整掌握向 oh-my-pi 提交一个合格 PR 的全流程并了解项目维护者在评审时的实际关注点从而避免改了不少、却被一键关闭的常见返工。项目定位与贡献入口oh-my-pi 是一个终端内的编程 Agent 产品核心 CLI 是omp主包位于 packages/coding-agent配套的模型目录、Agent 运行时、TUI 渲染库、原生 Rust 加速层分布在 packages 与 crates 下。仓库根目录的 AGENTS.md 明确规定除非特别说明所有开发工作默认聚焦于packages/coding-agent/。CONTRIBUTING.md 是该项目唯一的贡献总入口它规定了三类事项何时需要提前讨论、PR 必须满足的硬性要求、以及代码归属与许可政策。与很多项目不同这份文档将大量篇幅用于约束AI 辅助提交——这与项目自身就是 Agent 产品高度相关项目维护者既欢迎 AI 参与开发又严格防止无人负责的自动提交污染代码库。开始之前小改动与大改动的分界线CONTRIBUTING.md 将改动按规模分为两类处理方式截然不同小改动可直接提 PRBug 修复、文档更新、范围狭窄的改进。这类改动不需要事前讨论可以直接进入 Pull Request 流程。大改动必须先讨论涉及新子系统、大规模 UI 改动、新增依赖、跨多个 package 的改动以及任何架构性/行为性变更。文档明确要求在动手写实现之前先到 Discord 讨论方案文档中给出的讨论渠道为discord.gg/4NMW9cdXZa。这里有一条关键提醒GitHub Issue 不能替代事前讨论且事前讨论并不保证 PR 会被合并。也就是说讨论是准入条件而非通行证最终是否合并仍取决于提交质量与维护者评审。这一小步快跑、大动先行的机制与仓库的物理结构一致项目由十几个 package 组成见 AGENTS.md 的包结构表跨包改动牵一发而动全身例如packages/ai、packages/catalog、packages/coding-agent之间存在严格的依赖约定模型/提供商策略必须放在 KDL 规则树而非 TypeScript 里随意跨包改动的代价远高于单包内的小修。不要为自己即将提交的工作开 IssueCONTRIBUTING.md 有一条容易被忽略但非常实际的规定如果你打算自己实现某个改动不要先为它创建 Issue。原因是仓库的自动化工具robomp会把可行动的 Issue 视为待认领工作并可能并行启动相同的修复从而造成重复劳动、浪费计算资源与维护者时间。正确的做法是报告问题、或提出自己不打算亲手实现的改动→ 开 Issue已存在相关 Issue 时→ 在 PR 中链接它而不是另开一个重复的 Issue打算自己实现→ 直接走 PR 流程大改动先讨论小改动直接提交。这条规则背后是 Agent 工作流特有的协作成本当一个仓库同时存在自动化代理与人类贡献者时Issue 既是问题清单也是工作队列二者不加区分会导致同一修复被抢跑两次。AI 辅助贡献工具可用但责任在提交者这是 CONTRIBUTING.md 的核心章节也最贴合 oh-my-pi 的 Agent 基因。项目态度明确欢迎 AI 作为工具参与但不接受无人值守的自动贡献。禁止的做法是给 Agent 一个模糊目标然后把它产出的一切原样提交。在打开 PR 之前贡献者必须完成四步人工闭环限定范围把 Agent 约束到已商定的范围拒绝无关改动逐文件审查审阅每一个被改动的文件理解最终行为亲自验证运行相关检查、亲手操练被改动的行为人工提交审查通过后由人提交 PR而不是让 Agent 自主发布。文档用一句话总结了责任边界无论代码由谁或什么生成你都要对代码负责You are responsible for the code, regardless of who or what generated it。PR 说明必须包含一句人写的解释每个 PR 的正文必须包含至少一句由你用自己的话撰写的句子说明改了什么、为什么。以下内容不能替代这句人工说明自动生成的摘要粘贴的 Agent 对话记录单独的 checklist。一句诚实的话就够了文档给出了示例I reviewed the full diff; this change fixes duplicate PR reviews by reusing the existing delivery guard.这句话的价值在于证明提交者确实审阅过 diff、理解改动意图而非盲目转发 Agent 的输出。验证要求bun check通过不等于行为正确CONTRIBUTING.md 明确警告bun check通过了本身不是充分的验证。bun check和自动化测试在相关时是预期动作但它们不能证明行为按预期工作。贡献者必须自己走通被改动的路径并在 PR 中报告确切的场景与结果改动类型必须完成的验证Bug 修复复现该 Bug并确认同一复现路径不再失败新功能启动产品端到端使用该功能UI 改动实际交互并检查渲染结果从仓库证据看bun check作为类型检查门禁有其具体定义packages/coding-agent/package.json 中check脚本是oxlint . oxfmt --check ... bun run check:typescheck:types走tsgo即 lint 格式 类型三层检查。项目规定永远不要直接调用tsc/npx tsc一律以bun run check为类型检查门禁。开发者常用命令速查CONTRIBUTING.md 将本地开发命令指引到 packages/coding-agent/DEVELOPMENT.md这份开发者地图给出了完整的本地开发循环命令表在packages/coding-agent/目录下运行或加--cwdpackages/coding-agent任务命令类型检查 lint门禁bun run check仅类型检查bun run check:types仅 lintbun run lint测试bun run test自动修复lint 格式化 promptsbun run fix构建dist/omp二进制bun run build另有两条与 Agent 产品强相关的注意事项改动 React 工具渲染器后需用bun run gen:tool-views重建涉及collab-web/src/tool-render/Rust 测试不要直接跑cargo test而要使用bun run test:rs内部以cargo nextest跑测试、再补一轮cargo test --doc。提交前后的质量红线来自 AGENTS.md虽然 CONTRIBUTING.md 是贡献主文档但仓库根目录的 AGENTS.md 补充了大量与可评审、可维护直接相关的硬性约束贡献者应一并遵守除非被要求绝不评论/创建 GitHub Issue绝不擅自 commit未被要求时不要执行提交动作生成的代码质量不用any除非万不得已、不用ReturnType、不用内联 importprompt 一律放在静态.md文件中用 Handlebars 做动态渲染禁止在代码里拼接 prompt 字符串日志可能运行在 TUI/RPC/SDK/worker 中的代码不得使用console.log/error/warn必须使用oh-my-pi/pi-utils的集中式logger日志写入~/.omp/logs/omp.YYYY-MM-DD.log并自动轮转测试纪律每个新测试必须捍卫一个具体的、可外部观察的契约行为、输出形态、状态迁移、错误映射或易回归的解析边界禁止静态回声测试、禁止expect(true).toBe(true)式占位、禁止对源码文本做 grep 断言。这些规则解释了 CONTRIBUTING.md 为何要求理解你提交的工作——项目用测试规范把行为正确提升为硬性门槛而非只看代码能否编译。贡献许可MIT无需 CLA/DCOoh-my-pi 的贡献许可政策Contribution licensing要点如下有意提交以纳入 OMPoh-my-pi的贡献默认按 MIT License 授权该政策不会重新授权第三方或 vendored 代码提交者必须有权提交自己的贡献并保留适用的版权、许可、署名与声明材料提交贡献不需要签署 CLAContributor License Agreement或 DCODeveloper Certificate of Origin。仓库根目录的 LICENSE 即为 MIT LicenseCopyright 2025 Mario Zechner、2025-2026 Can Bölük、2026 Stencil Labs, Inc.与文档所述一致。对于开发者而言这意味着你只需确保自己拥有所提交代码的权利贡献一经合入即按 MIT 条款被项目使用无需任何额外签约流程。评审评审行为与理解而非代码量Review 章节定义了 oh-my-pi 的评审哲学维护者评审的是所提交的行为和贡献者对它的理解而不是生成代码的数量。具体动作要求亲自回应评审反馈由你自己回应 review 意见且只采纳你已核实过的建议维护者会关闭 PR 的典型情形包括跳过了要求的事前讨论缺少人工撰写的解释说明包含未经审查的 Agent 输出混杂了无关的改动。最后一条保持每个 PR 只做一件逻辑改动one logical change per PR贯穿全文避免无关清理、顺手重构、生成噪音以及不在约定范围内的功能。当前开放状态担保制度vouch的试验性放宽CONTRIBUTING.md 与 README.md 都标注了同一则 NOTEPR 目前作为试验暂时向所有人开放。此前项目要求在合并 PR 前必须有成员担保vouch该要求在评估开放贡献效果期间暂时解除视结果而定担保制度可能回归。这意味着当前阶段是社区贡献的低门槛窗口期但贡献者仍须满足上述全部 PR 硬性要求。结语给 oh-my-pi 贡献者的行动清单综合 CONTRIBUTING.md 及其引用的仓库证据一个合格的 oh-my-pi 贡献流程可以浓缩为六步判定规模小改动直接提 PR涉及新子系统、跨包、新依赖的大改动先到 Discord 讨论不要抢跑自己要做的改动不开 Issue已有相关 Issue 就在 PR 中链接约束 Agent若用 AI 辅助限定范围、逐文件审查、亲自验证、人工提交并在 PR 中写一句自己的解释验证行为以bun run check通过为前提再亲手复现 Bug / 端到端使用功能 / 交互检查 UI并在 PR 里报告场景与结果单点聚焦每个 PR 只含一个逻辑改动不夹带无关重构回应评审亲自回复 review只采纳自己核实过的建议并留意 PR 暂时全开放、担保制度可能回归的政策变化。按此流程提交你的贡献将同时满足工具链门禁lint/类型/测试、行为验证与社区协作三重要求——这正是 oh-my-pi 作为一个由 Agent 驱动开发的项目对每一位贡献者无论人类还是 AI 辅助的完整期望。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
