尧图网站建设 
Remotion 的 Agent Skills 实战用 gh CLI 管理 GitHub Issues 2.0 的父子与阻塞关系【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion本篇基于 Remotion 仓库中的 Agent 技能文档 issue-management SKILL.md系统讲解如何使用 GitHub CLIgh的 Issues 2.0 关系能力管理 Issue 之间的父子parent/sub-issue与阻塞blocked-by/blocking关系。读完后你可以掌握关系标志位在不同版本gh中的验证方法、跨仓库引用格式、三种关系类型的完整命令集、机器可读的 JSON 校验方式以及一套可被自动化脚本复用的创建—关联—验证安全工作流。背景这个技能在 Remotion 工作流中的位置Remotion 仓库的.agents/skills/目录沉淀了一组面向 AI Agent 的协作技能Agent Skills覆盖提交代码、写文档、发布版本等日常操作。其中 issue 技能 负责创建和编辑 Issue本身标题命名规范、多行 Markdown 安全处理而本文主角 issue-management 技能 专门负责管理 Issue 之间的关系即 GitHub Issues 2.0 引入的 parent issue、sub-issue、blocked-by 和 blocking 四类关联。issue技能中明确写着遇到父子、阻塞关系时应转交issue-management技能并且优先使用新的gh issue create与gh issue edit关系标志位而不是手写 GraphQL mutation。这两条关系能力来自 GitHub CLI 官方仓库的 PRcli/cli#13057。由于该功能较新技能文档给出的第一条纪律是动手之前先确认本机gh版本真的支持这些标志位——如果标志位缺失先升级gh不要臆造不存在的旧命令。前置检查确认 gh 支持 Issues 2.0 关系标志位issue create与issue edit的关系标志位并非完全对称create 侧只有建立关系的三个参数edit 侧则有添加/移除六组参数。技能文档要求分别用--help过滤验证# 验证 create 支持--parent / --blocked-by / --blocking gh issue create --help | grep -E -- --parent|--blocked-by|--blocking # 验证 edit 支持--parent / --add-sub-issue / --add-blocked-by / --add-blocking gh issue edit --help | grep -E -- --parent|--add-sub-issue|--add-blocked-by|--add-blocking注意grep -E后面的--因为标志位本身以--开头必须先写结束符--把参数从选项解析中隔离出来否则grep会报错。这条命令本身就是技能文档中的原样示例可以直接复制执行。如果过滤结果为空说明当前gh版本过旧应升级后再继续切勿凭记忆编造替代命令。Issue 引用格式数字、URL 与逗号列表所有关系标志位都接受两种引用形式这是后续一切命令的基础当前仓库内的 Issue直接传编号。例如把 123 号 Issue 挂到 100 号 Issue 之下gh issue edit 123 --parent 100跨仓库关系必须传完整 Issue URL。技能文档给出的跨仓库示例是把 123 号 Issue 阻塞在另一个仓库的 456 号 Issue 上URL 形式是跨仓库引用唯一被支持的方式gh issue edit 123 --blocked-by https://github.com/remotion-dev/remotion/issues/456多个关联 Issue逗号分隔的列表不需要重复标志位gh issue edit 123 --add-blocked-by 200,201这个数字 URL 逗号列表的三合一引用规则适用于后文全部六组 edit 标志位和 create 的三个关系标志位。父子关系parent / sub-issue的完整操作GitHub Issues 2.0 的模型约束是一个 sub-issue 有且只有一个 parent issue。围绕这个约束技能文档覆盖了创建、改挂、摘除三种场景。新建时直接挂到父 Issue 下创建 Issue 的同时指定--parent省去先建后挂两步操作gh issue create \ --title Docs: Add issue management skill \ --body-file /tmp/remotion-issue-body.md \ --parent 100这里有两个细节值得注意标题Docs: Add issue management skill遵循了 Remotion 的 Issue 命名规范——影响整个文档面的工作用Docs:前缀影响某个包用remotion/包名:前缀影响整个 Studio 用Studio:前缀影响 monorepo 基建用Build:/CI:/Repo:前缀完整规范见 issue 技能Issue 正文通过--body-file从临时文件传入而不是在 shell 参数里写多行字符串——这是 Remotion 全仓库 Issue 操作的统一纪律原因见下文安全工作流一节。修改、摘除父 Issue对已存在的子 Issue# 设置或更换父 Issue参数可以是编号或 URL gh issue edit child-number --parent parent-number-or-url # 摘除父 Issue gh issue edit child-number --remove-parent由于子 Issue 只有一个父是硬约束重复执行--parent的效果是改挂move而不是新增——这也是下一节--add-sub-issue语义的来源。从父 Issue 侧管理子 Issue除了从子 Issue 侧上报父也可以从父 Issue 侧收纳子gh issue edit parent-number --add-sub-issue child-number-or-url gh issue edit parent-number --remove-sub-issue child-number-or-url技能文档在这里给出一条明确的语义警告--add-sub-issue在目标子 Issue 已有其他父 Issue 时会把该子 Issue移动到新父 Issue 下。不要在一条命令里同时编辑多个父 Issue 来添加同一个子 Issue——一个子 Issue 不能被含糊地挂到多个父 Issue 下。换句话说--add-sub-issue的add是纳入父 Issue 的子列表隐含语义是排他性移动这与 blocked-by/blocking 可以一对多形成对比。阻塞关系blocked-by / blocking阻塞关系回答的是另一个问题这条工作被谁卡住。技能文档区分了两种视角--add-blocked-by正在编辑的 Issue 等待另一个 Issue 完成。方向是我 ← 被谁阻塞# Issue 123 被 Issue 200 阻塞 gh issue edit 123 --add-blocked-by 200 # 移除该阻塞关系 gh issue edit 123 --remove-blocked-by 200--add-blocking正在编辑的 Issue 阻塞了另一个 Issue。方向是我 → 卡住了谁# Issue 123 阻塞 Issue 300 和 301逗号列表 gh issue edit 123 --add-blocking 300,301 # 只移除其中一条阻塞关系 gh issue edit 123 --remove-blocking 300这两组命令指向同一条边技能文档给出了等价的思维模型gh issue edit A --add-blocking B与gh issue edit B --add-blocked-by A表达的是同一条依赖边。选择哪条命令的标准很简单以你当前正在编辑的那一侧为准。如果手头正在改 A就用--add-blocking正在改 B就用--add-blocked-by避免对两个 Issue 各跑一次 edit。与父子关系不同阻塞关系支持创建即关联且可以同时携带两个方向的关系gh issue create \ --title Studio: Add timeline validation \ --body-file /tmp/remotion-issue-body.md \ --blocked-by 200,201 \ --blocking 300即新 Issue 同时声明我等待 200 和 201与我卡住了 300。查验关系人类视图、稳定文本行与 JSON 字段关系建好后必须验证技能文档提供了三档精度。人类可读视图gh issue view number当关系存在时输出中会附带 parent、sub-issues、blocked-by、blocking 的元数据区。非 TTY 输出的稳定关系行gh issue view在非 TTY管道环境下会输出形如key: value的稳定行可以用正则精确抽取五类关系gh issue view number | grep -E ^(parent|sub-issues|sub-issues-completed|blocked-by|blocking):注意这里比 edit 标志位多出一个sub-issues-completed行——GitHub 会统计父 Issue 下已完成子 Issue 的数量这是父子关系区别于阻塞关系的独有信号。JSON 字段脚本首选对脚本化处理应显式请求 JSON 字段而不是解析文本gh issue view number \ --json parent,subIssues,subIssuesSummary,blockedBy,blocking技能文档对返回结构做了精确说明subIssues、blockedBy、blocking是connection 对象形如{ nodes: [...], totalCount: N }subIssuesSummary专门承载完成度计数对应人类视图里的sub-issues-completed。这个nodes/totalCount结构在 Remotion 仓库的自动化脚本里被当作正确性契约使用——后文会看到脚本会主动断言两者相等。安全工作流创建 → 关联 → 验证 → 回写技能文档最后给出了四步安全操作序列其中第一步的动机在 issue 技能 中有更完整的解释1. 新建 Issue 正文一律用 --body-file 传入不要在 shell 里拼多行字符串 2. 用对应的 gh issue create / gh issue edit 关系标志位建立关联 3. 用 gh issue view number 或 gh issue view number --json parent,subIssues,subIssuesSummary,blockedBy,blocking 验证 4. 之后若再编辑 PR 或父 Issue 正文把含糊的 checklist 文案替换成具体 Issue 编号第一步的具体原因在 shell 参数里写--body Line one\n\nLine two这类内容时\n可能被原样提交为两个可见字符而不是真实换行导致 GitHub 上渲染出一行带字面\n的乱码。Remotion 的约定是先写临时文件Agent 操作时优先用文件写入工具而非 heredoc再--body-file编辑后还能用gh issue view number --json body --jq .body回读正文确认其中是真实空行而非转义序列。第四步是关联之后的收尾动作如果 PR 或父 Issue 的描述里原本写着- [ ] 后续补充 X 功能这类含糊条目而该工作已经被拆成独立 Issue 追踪就应改写成The ... skill is tracked separately in sub-issue #8158, not in this PR.这种带具体编号的表述避免清单与 Issue 图两处各自演化、互相失联。纵深佐证关系数据如何驱动仓库内的自动化审计issue-management技能的命令面尤其是 JSON 字段并非孤立存在Remotion 仓库里有两套只读/半只读的自动化脚本直接建立在这套关系数据之上它们是最有说服力的消费者。审计未入 masterplan的 Issuefind-unplanned-issues 技能 附带一个 Bun 脚本 find-unplanned-issues.ts用于审计哪些 open Issue 游离于 masterplan以标题含masterplan为识别特征层级之外bun .agents/skills/find-unplanned-issues/scripts/find-unplanned-issues.ts从源码看它的实现与本文前面讲的每一环严格对应数据入口是gh issue list --state open --limit N --json number,title,parent,state,url脚本 L139-L149即列出 显式 JSON 字段的标准姿势沿parent指针递归向上爬升父链findParentChainL172-L192中途用seen集合检测环——这是子 Issue 只能有一个父的模型在图遍历上的必然要求父链成环属于数据异常爬不到的父节点通过gh issue view url --json number,title,parent,state,url补取并缓存hydrateIssueL155-L170报告区分两类发现no parent完全没有父与no masterplan ancestor有父但父链走不到 masterplan支持--repo owner/repo、--limit、--json以及给 CI 用的--check模式发现未入计划 Issue 时以退出码 1 结束全部合规则 0。脚本还维护了一份豁免清单L30-L33编号 8375 的长期 CI flake 跟踪 Issue 被刻意允许独立存在。这体现了审计规则 人工豁免的治理方式。技能文档也点明了该脚本的前置条件需要一个支持parentJSON 字段的已认证gh——与本文开头先验版本的纪律首尾呼应审计只读数据修复动作则被明确要求回到issue-management技能执行并在每次修改后验证关系。从 masterplan 中修剪已关闭的子 Issue第二个脚本 prune-closed-masterplan-issues.ts 演示了subIssues连接对象和改完即验证纪律在写操作中的完整运用# 默认预览 masterplan 根Issue #9081下所有已关闭的后代 bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts # 指定其他根 / 机器可读报告 bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts --root issue-url bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts --json从源码结构看它的流程值得拆解完整性断言viewIssue每次读取 Issue 后都会检查subIssues.nodes.length ! subIssues.totalCount并直接失败L143-L147——把connection 对象带nodes和totalCount这一 JSON 契约变成了可执行的正确性检查防止分页截断导致漏看子 Issue广度优先发现整棵树discoverTreeL173-L207并发度 8同时对重复/环状的 sub-issue 报错最深先处理已关闭 Issue 按深度降序排序L260-L262保证删除父级之前其下所有已关闭子级已清理保留未完成工作--apply时若某个已关闭 Issue 下还有 open 子 Issue先用gh issue edit child --parent grandparent-url把开放子 Issue 提升一层再用--remove-parent摘除该已关闭 Issue并调用verifyParent逐条复核applyRemovalL222-L256——这正是 issue-management 技能第 3 步验证在批量场景下的强化版任何一步 parent 与预期不符立即中止安全开关设计默认 dry-run--json与--apply互斥L96-L98--root必须通过 GitHub Issue URL 正则校验L100-L102并且拒绝移除根 Issue 本身L223-L225。技能文档的告诫也很直接不要为了测试脚本而传--apply它真的会改动线上 Issue 关系。这两个脚本合起来说明parent/sub-issue 关系在 Remotion 的日常工程实践中不只是看板装饰而是被当作可编程的树形结构使用——审计靠向上爬parent链清理靠向下遍历subIssues连接而每一次写操作都被读回验证包裹。速查表与要点回顾场景命令要点验证 gh 版本gh issue create/edit --help \| grep -E -- flags新建即挂父gh issue create --title ... --body-file ... --parent p新建即声明阻塞gh issue create ... --blocked-by 200,201 --blocking 300改挂/摘除父gh issue edit child --parent p/--remove-parent父侧收纳/移除子gh issue edit parent --add-sub-issue c/--remove-sub-issue c阻塞/反方向--add-blocked-by与--add-blocking描述同一条边以正在编辑的一侧为准人类查验gh issue view n含sub-issues-completed完成计数脚本查验gh issue view n --json parent,subIssues,subIssuesSummary,blockedBy,blocking其中subIssues/blockedBy/blocking均为{nodes, totalCount}最后浓缩几条不可省略的纪律关系标志位先验版本再使用缺失就升级gh子 Issue 只有一个父--add-sub-issue是排他性移动跨仓库引用只能写完整 URL正文一律--body-file每次修改关系后用gh issue view人类或 JSON读回验证。遵循这套流程Issue 图就会像 Remotion 仓库的审计脚本所依赖的那样始终是一棵可遍历、可验证、可自动维护的树。延伸阅读issue 技能标题规范与多行正文处理、find-unplanned-issues 技能masterplan 审计、审计脚本、修剪脚本。【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Remotion 的 Agent Skills 实战：用 gh CLI 管理 GitHub Issues 2.0 的父子与阻塞关系
Remotion 的 Agent Skills 实战用 gh CLI 管理 GitHub Issues 2.0 的父子与阻塞关系【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion本篇基于 Remotion 仓库中的 Agent 技能文档 issue-management SKILL.md系统讲解如何使用 GitHub CLIgh的 Issues 2.0 关系能力管理 Issue 之间的父子parent/sub-issue与阻塞blocked-by/blocking关系。读完后你可以掌握关系标志位在不同版本gh中的验证方法、跨仓库引用格式、三种关系类型的完整命令集、机器可读的 JSON 校验方式以及一套可被自动化脚本复用的创建—关联—验证安全工作流。背景这个技能在 Remotion 工作流中的位置Remotion 仓库的.agents/skills/目录沉淀了一组面向 AI Agent 的协作技能Agent Skills覆盖提交代码、写文档、发布版本等日常操作。其中 issue 技能 负责创建和编辑 Issue本身标题命名规范、多行 Markdown 安全处理而本文主角 issue-management 技能 专门负责管理 Issue 之间的关系即 GitHub Issues 2.0 引入的 parent issue、sub-issue、blocked-by 和 blocking 四类关联。issue技能中明确写着遇到父子、阻塞关系时应转交issue-management技能并且优先使用新的gh issue create与gh issue edit关系标志位而不是手写 GraphQL mutation。这两条关系能力来自 GitHub CLI 官方仓库的 PRcli/cli#13057。由于该功能较新技能文档给出的第一条纪律是动手之前先确认本机gh版本真的支持这些标志位——如果标志位缺失先升级gh不要臆造不存在的旧命令。前置检查确认 gh 支持 Issues 2.0 关系标志位issue create与issue edit的关系标志位并非完全对称create 侧只有建立关系的三个参数edit 侧则有添加/移除六组参数。技能文档要求分别用--help过滤验证# 验证 create 支持--parent / --blocked-by / --blocking gh issue create --help | grep -E -- --parent|--blocked-by|--blocking # 验证 edit 支持--parent / --add-sub-issue / --add-blocked-by / --add-blocking gh issue edit --help | grep -E -- --parent|--add-sub-issue|--add-blocked-by|--add-blocking注意grep -E后面的--因为标志位本身以--开头必须先写结束符--把参数从选项解析中隔离出来否则grep会报错。这条命令本身就是技能文档中的原样示例可以直接复制执行。如果过滤结果为空说明当前gh版本过旧应升级后再继续切勿凭记忆编造替代命令。Issue 引用格式数字、URL 与逗号列表所有关系标志位都接受两种引用形式这是后续一切命令的基础当前仓库内的 Issue直接传编号。例如把 123 号 Issue 挂到 100 号 Issue 之下gh issue edit 123 --parent 100跨仓库关系必须传完整 Issue URL。技能文档给出的跨仓库示例是把 123 号 Issue 阻塞在另一个仓库的 456 号 Issue 上URL 形式是跨仓库引用唯一被支持的方式gh issue edit 123 --blocked-by https://github.com/remotion-dev/remotion/issues/456多个关联 Issue逗号分隔的列表不需要重复标志位gh issue edit 123 --add-blocked-by 200,201这个数字 URL 逗号列表的三合一引用规则适用于后文全部六组 edit 标志位和 create 的三个关系标志位。父子关系parent / sub-issue的完整操作GitHub Issues 2.0 的模型约束是一个 sub-issue 有且只有一个 parent issue。围绕这个约束技能文档覆盖了创建、改挂、摘除三种场景。新建时直接挂到父 Issue 下创建 Issue 的同时指定--parent省去先建后挂两步操作gh issue create \ --title Docs: Add issue management skill \ --body-file /tmp/remotion-issue-body.md \ --parent 100这里有两个细节值得注意标题Docs: Add issue management skill遵循了 Remotion 的 Issue 命名规范——影响整个文档面的工作用Docs:前缀影响某个包用remotion/包名:前缀影响整个 Studio 用Studio:前缀影响 monorepo 基建用Build:/CI:/Repo:前缀完整规范见 issue 技能Issue 正文通过--body-file从临时文件传入而不是在 shell 参数里写多行字符串——这是 Remotion 全仓库 Issue 操作的统一纪律原因见下文安全工作流一节。修改、摘除父 Issue对已存在的子 Issue# 设置或更换父 Issue参数可以是编号或 URL gh issue edit child-number --parent parent-number-or-url # 摘除父 Issue gh issue edit child-number --remove-parent由于子 Issue 只有一个父是硬约束重复执行--parent的效果是改挂move而不是新增——这也是下一节--add-sub-issue语义的来源。从父 Issue 侧管理子 Issue除了从子 Issue 侧上报父也可以从父 Issue 侧收纳子gh issue edit parent-number --add-sub-issue child-number-or-url gh issue edit parent-number --remove-sub-issue child-number-or-url技能文档在这里给出一条明确的语义警告--add-sub-issue在目标子 Issue 已有其他父 Issue 时会把该子 Issue移动到新父 Issue 下。不要在一条命令里同时编辑多个父 Issue 来添加同一个子 Issue——一个子 Issue 不能被含糊地挂到多个父 Issue 下。换句话说--add-sub-issue的add是纳入父 Issue 的子列表隐含语义是排他性移动这与 blocked-by/blocking 可以一对多形成对比。阻塞关系blocked-by / blocking阻塞关系回答的是另一个问题这条工作被谁卡住。技能文档区分了两种视角--add-blocked-by正在编辑的 Issue 等待另一个 Issue 完成。方向是我 ← 被谁阻塞# Issue 123 被 Issue 200 阻塞 gh issue edit 123 --add-blocked-by 200 # 移除该阻塞关系 gh issue edit 123 --remove-blocked-by 200--add-blocking正在编辑的 Issue 阻塞了另一个 Issue。方向是我 → 卡住了谁# Issue 123 阻塞 Issue 300 和 301逗号列表 gh issue edit 123 --add-blocking 300,301 # 只移除其中一条阻塞关系 gh issue edit 123 --remove-blocking 300这两组命令指向同一条边技能文档给出了等价的思维模型gh issue edit A --add-blocking B与gh issue edit B --add-blocked-by A表达的是同一条依赖边。选择哪条命令的标准很简单以你当前正在编辑的那一侧为准。如果手头正在改 A就用--add-blocking正在改 B就用--add-blocked-by避免对两个 Issue 各跑一次 edit。与父子关系不同阻塞关系支持创建即关联且可以同时携带两个方向的关系gh issue create \ --title Studio: Add timeline validation \ --body-file /tmp/remotion-issue-body.md \ --blocked-by 200,201 \ --blocking 300即新 Issue 同时声明我等待 200 和 201与我卡住了 300。查验关系人类视图、稳定文本行与 JSON 字段关系建好后必须验证技能文档提供了三档精度。人类可读视图gh issue view number当关系存在时输出中会附带 parent、sub-issues、blocked-by、blocking 的元数据区。非 TTY 输出的稳定关系行gh issue view在非 TTY管道环境下会输出形如key: value的稳定行可以用正则精确抽取五类关系gh issue view number | grep -E ^(parent|sub-issues|sub-issues-completed|blocked-by|blocking):注意这里比 edit 标志位多出一个sub-issues-completed行——GitHub 会统计父 Issue 下已完成子 Issue 的数量这是父子关系区别于阻塞关系的独有信号。JSON 字段脚本首选对脚本化处理应显式请求 JSON 字段而不是解析文本gh issue view number \ --json parent,subIssues,subIssuesSummary,blockedBy,blocking技能文档对返回结构做了精确说明subIssues、blockedBy、blocking是connection 对象形如{ nodes: [...], totalCount: N }subIssuesSummary专门承载完成度计数对应人类视图里的sub-issues-completed。这个nodes/totalCount结构在 Remotion 仓库的自动化脚本里被当作正确性契约使用——后文会看到脚本会主动断言两者相等。安全工作流创建 → 关联 → 验证 → 回写技能文档最后给出了四步安全操作序列其中第一步的动机在 issue 技能 中有更完整的解释1. 新建 Issue 正文一律用 --body-file 传入不要在 shell 里拼多行字符串 2. 用对应的 gh issue create / gh issue edit 关系标志位建立关联 3. 用 gh issue view number 或 gh issue view number --json parent,subIssues,subIssuesSummary,blockedBy,blocking 验证 4. 之后若再编辑 PR 或父 Issue 正文把含糊的 checklist 文案替换成具体 Issue 编号第一步的具体原因在 shell 参数里写--body Line one\n\nLine two这类内容时\n可能被原样提交为两个可见字符而不是真实换行导致 GitHub 上渲染出一行带字面\n的乱码。Remotion 的约定是先写临时文件Agent 操作时优先用文件写入工具而非 heredoc再--body-file编辑后还能用gh issue view number --json body --jq .body回读正文确认其中是真实空行而非转义序列。第四步是关联之后的收尾动作如果 PR 或父 Issue 的描述里原本写着- [ ] 后续补充 X 功能这类含糊条目而该工作已经被拆成独立 Issue 追踪就应改写成The ... skill is tracked separately in sub-issue #8158, not in this PR.这种带具体编号的表述避免清单与 Issue 图两处各自演化、互相失联。纵深佐证关系数据如何驱动仓库内的自动化审计issue-management技能的命令面尤其是 JSON 字段并非孤立存在Remotion 仓库里有两套只读/半只读的自动化脚本直接建立在这套关系数据之上它们是最有说服力的消费者。审计未入 masterplan的 Issuefind-unplanned-issues 技能 附带一个 Bun 脚本 find-unplanned-issues.ts用于审计哪些 open Issue 游离于 masterplan以标题含masterplan为识别特征层级之外bun .agents/skills/find-unplanned-issues/scripts/find-unplanned-issues.ts从源码看它的实现与本文前面讲的每一环严格对应数据入口是gh issue list --state open --limit N --json number,title,parent,state,url脚本 L139-L149即列出 显式 JSON 字段的标准姿势沿parent指针递归向上爬升父链findParentChainL172-L192中途用seen集合检测环——这是子 Issue 只能有一个父的模型在图遍历上的必然要求父链成环属于数据异常爬不到的父节点通过gh issue view url --json number,title,parent,state,url补取并缓存hydrateIssueL155-L170报告区分两类发现no parent完全没有父与no masterplan ancestor有父但父链走不到 masterplan支持--repo owner/repo、--limit、--json以及给 CI 用的--check模式发现未入计划 Issue 时以退出码 1 结束全部合规则 0。脚本还维护了一份豁免清单L30-L33编号 8375 的长期 CI flake 跟踪 Issue 被刻意允许独立存在。这体现了审计规则 人工豁免的治理方式。技能文档也点明了该脚本的前置条件需要一个支持parentJSON 字段的已认证gh——与本文开头先验版本的纪律首尾呼应审计只读数据修复动作则被明确要求回到issue-management技能执行并在每次修改后验证关系。从 masterplan 中修剪已关闭的子 Issue第二个脚本 prune-closed-masterplan-issues.ts 演示了subIssues连接对象和改完即验证纪律在写操作中的完整运用# 默认预览 masterplan 根Issue #9081下所有已关闭的后代 bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts # 指定其他根 / 机器可读报告 bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts --root issue-url bun .agents/skills/find-unplanned-issues/scripts/prune-closed-masterplan-issues.ts --json从源码结构看它的流程值得拆解完整性断言viewIssue每次读取 Issue 后都会检查subIssues.nodes.length ! subIssues.totalCount并直接失败L143-L147——把connection 对象带nodes和totalCount这一 JSON 契约变成了可执行的正确性检查防止分页截断导致漏看子 Issue广度优先发现整棵树discoverTreeL173-L207并发度 8同时对重复/环状的 sub-issue 报错最深先处理已关闭 Issue 按深度降序排序L260-L262保证删除父级之前其下所有已关闭子级已清理保留未完成工作--apply时若某个已关闭 Issue 下还有 open 子 Issue先用gh issue edit child --parent grandparent-url把开放子 Issue 提升一层再用--remove-parent摘除该已关闭 Issue并调用verifyParent逐条复核applyRemovalL222-L256——这正是 issue-management 技能第 3 步验证在批量场景下的强化版任何一步 parent 与预期不符立即中止安全开关设计默认 dry-run--json与--apply互斥L96-L98--root必须通过 GitHub Issue URL 正则校验L100-L102并且拒绝移除根 Issue 本身L223-L225。技能文档的告诫也很直接不要为了测试脚本而传--apply它真的会改动线上 Issue 关系。这两个脚本合起来说明parent/sub-issue 关系在 Remotion 的日常工程实践中不只是看板装饰而是被当作可编程的树形结构使用——审计靠向上爬parent链清理靠向下遍历subIssues连接而每一次写操作都被读回验证包裹。速查表与要点回顾场景命令要点验证 gh 版本gh issue create/edit --help \| grep -E -- flags新建即挂父gh issue create --title ... --body-file ... --parent p新建即声明阻塞gh issue create ... --blocked-by 200,201 --blocking 300改挂/摘除父gh issue edit child --parent p/--remove-parent父侧收纳/移除子gh issue edit parent --add-sub-issue c/--remove-sub-issue c阻塞/反方向--add-blocked-by与--add-blocking描述同一条边以正在编辑的一侧为准人类查验gh issue view n含sub-issues-completed完成计数脚本查验gh issue view n --json parent,subIssues,subIssuesSummary,blockedBy,blocking其中subIssues/blockedBy/blocking均为{nodes, totalCount}最后浓缩几条不可省略的纪律关系标志位先验版本再使用缺失就升级gh子 Issue 只有一个父--add-sub-issue是排他性移动跨仓库引用只能写完整 URL正文一律--body-file每次修改关系后用gh issue view人类或 JSON读回验证。遵循这套流程Issue 图就会像 Remotion 仓库的审计脚本所依赖的那样始终是一棵可遍历、可验证、可自动维护的树。延伸阅读issue 技能标题规范与多行正文处理、find-unplanned-issues 技能masterplan 审计、审计脚本、修剪脚本。【免费下载链接】remotion Make videos programmatically with React项目地址: https://gitcode.com/GitHub_Trending/re/remotion创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考