2026年10月7日，GitHub 用户 adamleithp 向 PostHog/posthog 提交 PR #113513，提议在 .agents/skills/ 下新增名为 ship-it-factory 的项目 skill。页面显示该 PR 仍为 Open，尚未合并，拟将 5 个提交从分支 posthog/ship-it-factory-skill 合入 master。PR 描述称，stamphog 会拒绝超过大小门限的 PR，默认是 800 行实质改动和 30 个文件，大改动因此只能等人工审查；这个 skill 想让 agent 把一次改动拆开，并送到 Trunk 合并队列。
PR 的 Problem 一节写道：工程师手里若有很大的改动，并没有单一流程把它做成 stamphog 能够批准的 PR。stamphog 会拒绝任何超过大小门限的 PR，默认门限为 800 行实质改动和 30 个文件，超限改动只能等待人工审查。
据 PR 描述，agent 可以把一次改动送到 Trunk 合并队列，顺序是：先把改动冻结在本地引用 refs/ship-it-factory/source；再按 stamphog 上限测量并分组，每组用 git restore --source=<ref> -- <files> 开一个 PR；然后把 PR 标为就绪，等必需检查全部通过后加上 stamphog 标签；stamphog 批准后向用户确认一次，再在每个 PR 上评论 /trunk merge。堆叠 PR 只评论最上层。
描述称，scripts/stamphog_budget.py 是唯一的辅助脚本。它导入 stamphog 引擎的 gates.py 和 policy.py，使大小预算、AGENT_APPROVALS.md 中的授权和禁止类别与线上审查一致，并检查 plan.json：每个路径只出现在一个分组内，重命名的新旧路径在同一分组。
PR 还写明，按照 AGENTS.md 的要求，没有用户明确批准时，skill 不会把 PR 送进合并队列。属于禁止类别的分组会转给人工审查，而不是加标签。同一 skill 也已放在 PostHog skills store，名称为 ship-it-factory，因此 PostHog Desktop 可以在这个 PR 合并前加载它。描述列出的替代路径还包括 PostHog MCP 工具 stamphog-review-runs-create，以及 trunk CLI。
页面上的 Agent 上下文标注 Autonomy 为 Human-driven (agent-assisted)，Agent 为 PostHog Desktop（pi harness），模型为 claude-opus-5-5。文末注明该 PR 由 PostHog Desktop 创建。这次改动不受功能开关控制；文档一节写的是无单独文档更新，skill 本身就是文档。
PR 的测试说明称，检查由 agent 完成，没有人做过真正开 PR 的端到端运行。在 worktree 的临时 source ref 上，一个 900 行文件在 800 行上限处失败；migration 文件被报告为 migrations 禁止类别；测试文件和 README.md 被豁免；未知路径和被拆开的重命名会使方案失败。更早一版在同样的引擎调用下，让 products/desktop/ 下一个 950 行文件通过了该范围 1000 行的授权。git restore --source 还原过一个分组中的修改、删除和重命名。hogli lint:skills、ruff check、ruff format、mypy 和 oxfmt --check 已通过。作者注明没有单独测试文件，并称最接近的覆盖是 stamphog 引擎自身的 test_gates.py 与 test_policy.py；预算脚本调用这些引擎函数，并只从 Pipeline._check_size 复制了按范围循环的那一段。
Agent 上下文还写道，一轮更严的代码质量审查把第一版从五个文件减到两个：本地 source ref 取代了 stash 提取脚本，gh pr checks --required 的退出码取代了状态脚本，操作步骤并入 SKILL.md，预算脚本去掉了引擎规则的备用副本。大小检查大约复制了 review_pr.py 里 Pipeline._check_size 的十行，因为该方法需要完整的 PRData。把纯辅助函数放进 gates.py 可以去掉这份复制，但引擎改动总是需要人工审查，因此被标为后续事项。
截至该 PR 页面所示，状态仍为 Open。adamleithp 于 10 月 7 日加上 skip-agent-review 标签，标签文字为跳过 Greptile 的自动 agent 审查，用于琐碎或 chore 类 PR。trunk-io 机器人同日留言称，该 PR 已由 GitHub 用户 Adam Leith 提交到 Merge，待分支保护规则全部通过后才会进入合并队列。GitHub Actions 的 CI 报告称，PR 被分到非后端车道 agents，不运行后端 Python 测试，并且可以与其他车道的 PR 并行合并；Python 与 TypeScript 重复检查均为 clean。注释密度为新增代码行的 2%（108 行中的 2 行），该项检查不阻止合并。
CodeRabbit 后来的 walkthrough 把优先级标为 Low，合并风险标为 Moderate，并称新流程可能覆盖本地修改、用错来源改动，或把人工批准当成 stamphog 的批准，认为这些问题应在依赖它准备并排队 PR 之前修正。同一审查把安全架构风险标为 Low，并称没有演示出审查绕过或生产环境被攻破。parameterai 机器人针对提交 39b4113 给出 “Risk: No findings”，称相对上次审查的增量是去掉脚本的 PEP 723 依赖块，并为 git merge-base 增加非零退出检查与浅克隆提示。页面还显示，合并至少需要 1 个批准审查；coderabbitai 与 greptile-apps 留下了审查评论。该分支页面注明尚未部署。10 月 8 日的提交说明写到，PostHog Desktop 的检出常常是浅克隆，git merge-base 在历史不够时会失败，因此 Step 1 会加深浅克隆，预算脚本改为提示这一修复，而不是抛出 traceback。
