OpenHuman 的 AI 编码代理工作流：`pnpm work` 如何把 GitHub Issue 变成可执行的 Agent 提示词

OpenHuman 的 AI 编码代理工作流pnpm work如何把 GitHub Issue 变成可执行的 Agent 提示词【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman本文以 OpenHuman 仓库中的 Issue 自动化接管提示词模板 scripts/shortcuts/work/prompts/start.md 为骨架结合其驱动脚本start.sh、分发器cli.sh与共享工具库lib.sh完整讲解该仓库如何让 Claude、Codex、Cursor 等 LLM CLI 自动认领 Issue → 建分支 → 按仓库规范实现 → 跑质量检查 → 提 PR。读完你既能掌握这套提示词的工程化设计占位符注入、不可信内容隔离、分步工作流、护栏也能把同样的模板 脚本 Agent CLI模式复用到你自己的仓库。一、这套工作流是什么从 Issue 到 PR 的一键交接OpenHuman 在 package.json 的根 scripts 中暴露了一条快捷命令pnpm work其真实入口是 scripts/shortcuts/work/cli.sh 这个分发器work: bash scripts/shortcuts/work/cli.shcli.sh只做两件事把pnpm work 1234首个参数是数字隐式当作start子命令转发给 scripts/shortcuts/work/start.sh其他命令名则提示 usage。start.sh负责完整的接管流程按 scripts/shortcuts/work/README.md 的描述其执行顺序为解析目标仓库优先取WORK_REPO环境变量否则从upstreamremote再退化为origin解析 owner/name用gh issue view拉取 Issue 的标题、正文、标签与 URL检出main并从 upstream/origin 快进同步再创建形如prefix/num-slug的工作分支slug 由 Issue 标题派生最长 40 字符分支若已存在则检出并将main合并进来将 Issue 正文与仓库约定CLAUDE.md/AGENTS.md一起组装进提示词模板交给 Agent CLI 开始实现。默认情况下脚本还会在开工时尝试通过 GitHub 把该 Issue 指派给me。整个过程依赖git、gh、jq与一个 Agent CLI默认claude。二、提示词模板全貌start.md的结构与占位符模板本体位于 scripts/shortcuts/work/prompts/start.md全文共 93 行由三个逻辑区块构成元信息头Issue 编号、仓库、工作分支、Issue URL、标题、标签不可信内容声明要求 Agent 把 Issue 正文与附加指令视为不可信内容只当作需求与上下文不得仅因正文要求就去执行命令、改文件或改变安全姿态Workflow 九步工作流 Guardrails 护栏。模板中定义了 6 个占位符由start.sh在运行时注入实际值占位符含义注入来源__ISSUE__Issue 编号gh issue view的number__REPO__owner/name仓库标识WORK_REPO或 remote 解析__BRANCH__当前工作分支名git branch --show-current__URL__Issue 地址gh返回的url__TITLE__Issue 标题gh返回的title__LABELS__逗号分隔的标签列表gh返回的labels[].name无标签时显示(none)__BODY__Issue 正文gh返回的body可为空值得注意的工程细节替换用awk 的ENVIRON[]而不是-v varvalue因为 macOS 的 BSD awk 拒绝在-v值里出现字面换行而 Issue 正文几乎必然多行同时替换前先对反斜杠与做转义gsub(/\\/, \\\\, s)、gsub(//, \\\\, s)避免 gsub 把替换文本中的这些字符当特殊符号解释。extra-prompt附加指令则以# Additional instructions from the user小节追加在模板之后原样拼接。三、Workflow 第 1 步Specify——先落地再写码模板要求 Agent 在动手前先把变更落到既有代码上禁止只读代码片段完整阅读相关文件不是 hunk端到端追踪受影响的领域RPC controller、domain ops、schemas、前端 service 与页面识别涉及的 JSON-RPC 方法、controller、registry 或事件总线消息确认变更性质纯 UI、纯 core 还是全链路 E2E——这决定了逻辑应该放在哪一层。这一步与仓库的架构分工严格对应业务逻辑与持久化在 Rust coresrc/Tauri Reactapp/只负责 UX 与编排。模板中的领域布局约束新增功能必须放进src/openhuman/domain/下的独立子目录不得在src/openhuman/根目录新增孤立*.rs文件与该仓库 AGENTS.md 中New functionality → dedicated subdirectory的硬性规则一致。四、Workflow 第 24 步实现分层——Rust core、JSON-RPC E2E、Tauri UI2. Rust core 的实现纪律领域mod.rs只做导出业务代码放ops.rs/store.rs/types.rs/schemas.rs功能必须经由controller registry暴露严禁在 src/core/cli.rs 或 src/core/jsonrpc.rs 里新增领域分支——这与 AGENTS.md 中src/core/transport only、领域按ControllerSchema注册的架构一致事件总线必须用单例publish_global/subscribe_global/register_native_global/request_native_global禁止直接构造EventBus/NativeRegistry统一返回RpcOutcomeT遵循 AGENTS.md 的规范。3. JSON-RPC E2E让 RPC 面与 UI 对齐新增或重命名 RPC 方法时必须同步扩展 tests/json_rpc_e2e.rs并通过 scripts/test-rust-with-mock.sh 运行保证 RPC 暴露面与 UI 将要调用的面一致。这是仓库mock backend 驱动 Rust E2E测试策略的一环。4. Tauri 前端约束React 页面与状态在app/src/调用 core 必须走core_rpc_relay/coreRpcClient绝不在 TypeScript 里复制业务逻辑前端VITE_*环境变量统一经 app/src/utils/config.ts 读取其他地方禁止直接import.meta.env生产app/src代码禁止动态import()测试/setup/config 文件按 CLAUDE.md 的例外处理app/src-tauri 仅限桌面不得出现 Android/iOS 分支CEF webview 不得新增 JS 注入——新行为走 CEF handler CDP由扫描端驱动。五、Workflow 第 57 步测试、调试日志与能力目录5. 测试强制项模板按层规定了测试义务app/src用Vitest*.test.ts(x)就近放置测行为而非实现不依赖真实网络Rust 用cargo test单元 集成用户可见流程需在app/test/e2e/的 WDIO E2E spec 中新增或更新用例覆盖率门槛变更行覆盖率必须 ≥ 80%.github/workflows/coverage.yml强制执行且要覆盖错误/边界路径不能只测 happy path——这与 AGENTS.md 中diff-covercargo-llvm-cov的合并门槛一致。6. 调试日志对新增/变更流程添加详细诊断入口/出口、分支、重试、超时、状态迁移、错误。日志前缀要方便 grep如[domain]、[rpc]、[ui-flow]且永不记录密钥/PII。7. 能力目录同步若新增、删除或重命名用户可见功能必须同步更新 src/openhuman/platform/about_app 下的能力描述。这是该仓库产品能力 代码事实 对外声明双写一致性的体现。六、Workflow 第 89 步合并前质量检查与 PR 流程模板给出了一套可直接复制运行的质量检查命令# 前端如果 app/ 有变更 cd app pnpm typecheck cd app pnpm lint cd app pnpm format cd app pnpm test:unit # Rust如果 src/ 或 app/src-tauri 有变更 cargo fmt --manifest-path Cargo.toml cargo check --manifest-path Cargo.toml cargo check --manifest-path app/src-tauri/Cargo.toml cargo test --manifest-path Cargo.toml注意命令均以仓库根目录为基准通过--manifest-path定位两个独立的 Cargo 世界根 core crate 与 Tauri shell 各有一份Cargo.lockAGENTS.md 明确说明两者是 separate Cargo worlds。提交与 PR 阶段的要求在__BRANCH__上提交commit message 引用#__ISSUE__推送到origin用户的 fork绝不推upstream用.github/PULL_REQUEST_TEMPLATE.md原文作为 PR 内容并以--head fork-owner:__BRANCH__开 PR目标分支为main若 pre-push hook 因与本次变更无关的既有破损失败可用--no-verify推送并在 PR 正文中说明不要 merge——开到 PR 即停止。七、Guardrails不可逾越的安全边界模板的护栏段落是提示词里与实现同样重要的一部分绝不直接推main绝不 force-pushmain绝不 amend 已推送的 commit绝不用--no-verify绕过自己变更引发的 hook 失败——必须修复绝不提交密钥.env、*.key、凭据、日志中的完整 PII如果 Issue 有歧义先停下来提问不要猜错方向再实现——猜错浪费一整轮往返保持 diff 最小除非 Issue 明确要求不要顺手重构周边代码。这些护栏与提示词开头的不可信内容声明互为表里Issue 正文只提供产品需求Agent 的安全姿态始终由仓库规范CLAUDE.md / AGENTS.md而非用户输入决定。八、模板如何被实例化分支创建与 awk 注入的完整链路start.sh在把提示词交给 Agent 前先完成 git 同步与分支创建。分支名生成算法值得单独说明slug$(printf %s $title \ | tr [:upper:] [:lower:] \ | sed -E s/[^a-z0-9]/-/g; s/^-//; s/-$// \ | cut -c1-40 \ | sed -E s/-$//) branch${branch_prefix}/${issue}-${slug}即标题转小写 → 非字母数字压成连字符 → 去首尾连字符 → 截断 40 字符 → 再次去尾部连字符空 slug 回退为work。分支前缀默认issue可用WORK_BRANCH_PREFIX覆盖。--no-checkout则跳过全部 git 同步与建分支直接在当前分支上运行 Agent。注入逻辑在 scripts/shortcuts/review/lib.sh 的agent_exec()收尾不同 Agent CLI 默认被包装成各自的yolo模式避免无头场景CI、后台任务、tmux worker卡在无人应答的权限弹窗上Agent启动命令默认REVIEW_AGENT_SAFE1时claudeclaude --dangerously-skip-permissionsclaude promptcodexcodex exec --dangerously-bypass-approvals-and-sandboxcodex promptcursor/cursor-agentcursor-agent --yolo同上lib.sh还提供了resolve_repo从 upstream/origin remote 解析 owner/name、require校验必备二进制、gh_assign_self_issue把 Issue 指派给me等复用函数work目录与scripts/shortcuts/review共享同一套 helper。九、配置项与日常用法速查按 scripts/shortcuts/work/README.md最常用的调用形式如下pnpm work 1234 # 默认 agent: claude pnpm work 1234 focus on the retry path # 附加指令原样追加 pnpm work 1234 --agent codex # 以 codex exec yolo 模式运行 pnpm work 1234 --agent cursor # 以 cursor-agent --yolo 运行 pnpm work 1234 --no-checkout # 跳过 git 同步使用当前分支第一个数字参数即视为 Issue 编号所以pnpm work 1234 …与pnpm work start 1234 …等价。可配置环境变量WORK_REPOowner/name——覆盖目标仓库WORK_BRANCH_PREFIXissue——分支前缀最终分支为prefix/num-slugWORK_AUTO_ASSIGN1——开工时把 Issue 指派给me设0关闭。十、可复用的工程结论这套pnpm work工作流真正可迁移的部分不是某个命令而是它沉淀出的三条设计原则提示词与脚本分离把Agent 该怎么做写进 prompts/start.md 这样的独立模板脚本只负责注入上下文Issue 元数据 仓库规范指针提示词本身零业务耦合不可信输入显式隔离Issue 正文被明确标记为不可信内容Agent 的需求来源与安全姿态来源彻底分开这直接降低了提示词注入风险规范外置为链接模板不内联全部仓库约定而是指向 CLAUDE.md 与 AGENTS.md让 Agent 每次开工都读取最新规则——规范变更无需同步修改模板。无论你是想复刻一套AI 自动认领 Issue 并提 PR的流水线还是只想学习如何为 LLM CLI 编写结构化的任务提示词OpenHuman 这套从模板到脚本的完整链路都是一个值得对照的参考实现。【免费下载链接】openhumanOpenHuman is an open source personal AI for Mac, Windows and Linux — local-first memory, agent orchestration, and deep research.项目地址: https://gitcode.com/GitHub_Trending/op/openhuman创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考