在 GitLab 仓库中使用 glab 配置 Matt Pocock 工程技能套件Issue Tracker 全流程实战指南【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills本指南讲解 skills 仓库中 issue-tracker-gitlab.md 所定义的 GitLab 问题跟踪器约定当仓库的 issue 与 spec 存放于 GitLab Issues、并以glabCLI 为唯一操作入口时工程技能triage、wayfinder、to-tickets、to-spec等如何读写 issue、如何处理 merge request 的 triage 表面以及/wayfinder如何在地图map与子工单child ticket之上执行认领、阻塞、推进与解析。读完本文你将掌握在 GitLab 仓库内用glab完成从创建 issue 到维护依赖链再到解析工单的完整命令序列并能理解这套约定与 GitHub、本地 Markdown 跟踪器之间的差异。一、这份文档在技能体系中的位置issue-tracker-gitlab.md是 setup-matt-pocock-skills 技能在完成仓库初始化配置时写入docs/agents/的种子模板之一。setup-matt-pocock-skills是一次性的提示驱动prompt-driven技能运行时会依次处理三件事Issue trackerSection A确定 issue 存放位置。默认姿态是 GitHub使用gh但如果git remote -v指向 GitLabgitlab.com或自托管实例则推荐 GitLab 并使用glabCLITriage labelsSection B只有安装了triage技能才执行默认沿用五个规范角色标签Domain docsSection C默认单上下文布局根目录一个CONTEXT.mddocs/adr/。用户的决定被记录到docs/agents/issue-tracker.md而 GitLab 版就是本文主题的种子内容。整份文档的核心前提是这个仓库的 issue 和 spec 以 GitLab issue 形式存在所有操作一律通过glabCLI 完成仓库推断来自git remote -v——只要在克隆目录内运行glab会自动识别所属项目无需手工指定--repo。二、glab 基础操作约定日常 issue 全生命周期文档的 Conventions 一节给出了覆盖 issue 从创建到关闭的完整命令集全部以glab issue子命令形式出现操作命令要点创建 issueglab issue create --title ... --description ...多行描述使用 heredoc传--description -会打开编辑器读取 issueglab issue view number --comments-F json输出机器可读格式列出 issueglab issue list -F json配合--label过滤评论 issueglab issue note number --message ...GitLab 把评论称为note这是与 GitHub 最大的术语差异打/去标签glab issue update number --label .../--unlabel ...多个标签用逗号分隔或重复传 flag关闭 issueglab issue close number该命令不支持关闭评论需先用glab issue note发布说明再关闭值得注意的细节GitLab 的评论动词是note而非comment消息参数是--message而非--body关闭 issue 时必须先 note 后 close因为glab issue close本身不接受附带说明。这一约定保证了每一条关闭动作都有可追溯的文本记录正是后续 triage 流程能读取先前 triage 备注、不重复提问的前提参见 triage 技能 的 Resuming a previous session 一节。2.1 Merge requestPR 在 GitLab 中的等价物GitLab 将 GitHub 的 pull request 称为merge requestMR。glab mr系列命令与gh pr结构完全同形只需把pr换成mr、把comment/--body换成note/--messageglab mr create创建 MRglab mr view number --comments查看 MR 及评论glab mr note number --message ...在 MR 上评论glab mr diff number查看变更差异。2.2 与 GitHub 的关键差异双号码空间文档特别强调一个易踩的坑与 GitHub 共享 issue/PR 单一号码空间不同GitLab 对 issue 和 MR 分别编号。因此在 GitLab 中#42只要知道维护者指的是哪个表面issue 还是 MR就是无歧义的而在 GitHub 中裸#42可能是 issue 也可能是 PR需要先用gh pr view 42尝试、失败再回退到gh issue view 42见 issue-tracker-github.md。三、MR 作为 triage 表面可选开关文档为docs/agents/issue-tracker.md中的 GitLab 模板内置了一个标志MRs as a request surface: no.若本仓库将外部 MR 视为功能请求则改为yes/triage会读取该标志。setup-matt-pocock-skills的 SKILL.md 明确说明GitHub 与 GitLab 模板都携带此标志默认关闭初始化时不要主动打开只有当用户希望把外部 PR/MR 纳入 triage 队列时才手工改 flag。若置为yesMR 将走与 issue 完全相同的标签与状态机使用glab mr对应命令读取 MRglab mr view number --comments需要看变更时用glab mr diff number列出待 triage 的外部 MRglab issue list的 MR 版glab mr list -F json然后只保留作者不是项目成员/所有者的 MR贡献者提交的 MR而不是维护者正在进行的工作评论/打标签/关闭glab mr note、glab mr update --label/--unlabel、glab mr close。这与 triage 技能 的PR 是附带代码的 issue原则呼应同一套角色、同一套状态机仅发现阶段只过滤外部 MR——协作者的进行中 MR 不是 triage 工作。需要注意该过滤仅用于发现被显式点名的 MR 无论作者是谁都会进入 triage。四、技能语义约定两个固定操作的口径工程技能中会反复出现两句话issue-tracker-gitlab.md为它们给出了 GitLab 下的确定答案当技能说 publish to the issue tracker创建一条 GitLab issueglab issue create当技能说 fetch the relevant ticket运行glab issue view number --comments。这套一句话即一个确定动作的约定让to-tickets、triage、to-spec等技能无需关心底层是 GitHub、GitLab 还是本地 Markdown——它们只需读取docs/agents/issue-tracker.md即可获得正确命令。三个种子模板GitHub、GitLab、本地 Markdown在这两处保持了相同的措辞结构只是实现命令不同这正是可插拔设计的体现。五、Wayfinding 操作GitLab 上的地图与子工单/wayfinder技能见 wayfinder/SKILL.md用于把超过一个 Agent 会话容量的大任务以地图 决策工单的形式铺在 issue tracker 上逐个解析直到路线清晰。在 GitLab 上这套机制的具体落法是5.1 地图Map地图是一条打了wayfinder:map标签的 issue其正文承载 Notes / Decisions-so-far / Fog 三个区块glab issue create --label wayfinder:map地图是索引而非仓库它只列出已做的决策并链接到承载细节的工单从不复述决策内容。文档同时指出在支持原生 epic 的 GitLab 付费层地图也可以由 epic 承担但带标签的 issue 在任何层级都可用是最稳妥的默认选择。5.2 子工单Child ticket每个子工单是一条 issue要求描述顶部带Part of #map字样建立与地图的归属关系携带wayfinder:type标签类型为research/prototype/grilling/task与 wayfinder 技能的 Ticket Types 一一对应一旦被认领指派给推动地图的开发人员driving dev。5.3 阻塞Blocking优先使用 GitLab 原生阻塞链接GitLab 与 GitHub 一样拥有原生依赖关系这是唯一在 UI 上可见、可作为规范表示的方案。添加方式是利用 quick action作为一条 note 发出glab issue note child --message /blocked_by #blocker但文档明确标注了一个现实约束原生阻塞链接是 Premium/Ultimate 功能。在免费层或不可用时必须回退到在描述顶部的Blocked by: #n, #n行。无论哪种表示判据一致当所有阻塞者都关闭时工单解除阻塞。这一能原生就原生、否则正文约定兜底的降级策略与 GitHub 模板issue-tracker-github.md 中依赖不可用时的Blocked by兜底思路完全相同也与 wayfinder 中只有缺少原生依赖的 tracker 才回退到正文约定的原则一致。5.4 前沿查询Frontier query前沿 打开、未阻塞、未认领的边界工单是地图下一步可推进的集合。在 GitLab 上的查询逻辑为用glab issue list -F json限定到地图的子工单剔除任何存在打开阻塞者的工单判定方式二选一存在指向打开 issue 的原生blocked_by链接——通过glab api projects/:id/issues/:iid/links读取或者Blocked by行中存在打开 issue再剔除已有 assignee 的工单按地图顺序取第一条获胜。这条查询是 wayfinder Plan, dont do 哲学的落点只有解除阻塞的边界工单才允许被认领避免并发会话撞车。5.5 认领与解析认领Claimglab issue update n --assignee me并且这必须是会话的第一次写入——先认领再干活让并发会话能跳过它解析Resolve三步走glab issue note n --message answer发布解析结论 →glab issue close n关闭工单 → 在地图的 Decisions-so-far 追加一条上下文指针gist 链接。这与 wayfinder 技能解析评论 关闭 在地图追加指针的记录规范完全一致也再次印证了本文 2.0 节先 note 后 close约定的必要性——解析答案正是通过那条 note 留下的。六、将文档放回仓库语境它如何被消费issue-tracker-gitlab.md写好后落在docs/agents/issue-tracker.md由setup-matt-pocock-skills的 Write 阶段落盘其消费者包括triage 技能读取该文件判断本仓库是否把外部 PR/MR 作为请求表面以及把五个规范角色needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix映射到实际标签字符串——若未提供映射会提示用户运行/setup-matt-pocock-skillswayfinder 技能查阅其中Wayfinding operations一节决定地图、子工单、阻塞与前沿查询在本仓库的具体物理形态to-tickets、to-spec等技能通过 publish to the issue tracker / fetch the relevant ticket 两句话获取正确的读写命令。换句话说这份文档是工程技能在 GitLab 仓库中运行时的协议适配层技能侧只谈论抽象角色与操作文档侧负责把它们翻译成glab的确切命令与 GitLab 的机制细节note、quick action、原生阻塞链接、双号码空间。三份种子模板GitHub / GitLab / 本地 Markdown共用同一套抽象、各自实现若需要对比可继续阅读 issue-tracker-github.md 与 issue-tracker-local.md。使用前提与限制本文所有命令面向 GitLab 仓库gitlab.com或自托管需要本机安装glabCLI 并在克隆目录内执行以便自动推断项目原生阻塞链接依赖 GitLab 付费层能力免费层需按 5.3 节的正文约定回退docs/agents/*.md均可直接手工编辑重跑setup-matt-pocock-skills仅在切换跟踪器或需要完全重置时才必要。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 GitLab 仓库中使用 glab 配置 Matt Pocock 工程技能套件：Issue Tracker 全流程实战指南
在 GitLab 仓库中使用 glab 配置 Matt Pocock 工程技能套件Issue Tracker 全流程实战指南【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills本指南讲解 skills 仓库中 issue-tracker-gitlab.md 所定义的 GitLab 问题跟踪器约定当仓库的 issue 与 spec 存放于 GitLab Issues、并以glabCLI 为唯一操作入口时工程技能triage、wayfinder、to-tickets、to-spec等如何读写 issue、如何处理 merge request 的 triage 表面以及/wayfinder如何在地图map与子工单child ticket之上执行认领、阻塞、推进与解析。读完本文你将掌握在 GitLab 仓库内用glab完成从创建 issue 到维护依赖链再到解析工单的完整命令序列并能理解这套约定与 GitHub、本地 Markdown 跟踪器之间的差异。一、这份文档在技能体系中的位置issue-tracker-gitlab.md是 setup-matt-pocock-skills 技能在完成仓库初始化配置时写入docs/agents/的种子模板之一。setup-matt-pocock-skills是一次性的提示驱动prompt-driven技能运行时会依次处理三件事Issue trackerSection A确定 issue 存放位置。默认姿态是 GitHub使用gh但如果git remote -v指向 GitLabgitlab.com或自托管实例则推荐 GitLab 并使用glabCLITriage labelsSection B只有安装了triage技能才执行默认沿用五个规范角色标签Domain docsSection C默认单上下文布局根目录一个CONTEXT.mddocs/adr/。用户的决定被记录到docs/agents/issue-tracker.md而 GitLab 版就是本文主题的种子内容。整份文档的核心前提是这个仓库的 issue 和 spec 以 GitLab issue 形式存在所有操作一律通过glabCLI 完成仓库推断来自git remote -v——只要在克隆目录内运行glab会自动识别所属项目无需手工指定--repo。二、glab 基础操作约定日常 issue 全生命周期文档的 Conventions 一节给出了覆盖 issue 从创建到关闭的完整命令集全部以glab issue子命令形式出现操作命令要点创建 issueglab issue create --title ... --description ...多行描述使用 heredoc传--description -会打开编辑器读取 issueglab issue view number --comments-F json输出机器可读格式列出 issueglab issue list -F json配合--label过滤评论 issueglab issue note number --message ...GitLab 把评论称为note这是与 GitHub 最大的术语差异打/去标签glab issue update number --label .../--unlabel ...多个标签用逗号分隔或重复传 flag关闭 issueglab issue close number该命令不支持关闭评论需先用glab issue note发布说明再关闭值得注意的细节GitLab 的评论动词是note而非comment消息参数是--message而非--body关闭 issue 时必须先 note 后 close因为glab issue close本身不接受附带说明。这一约定保证了每一条关闭动作都有可追溯的文本记录正是后续 triage 流程能读取先前 triage 备注、不重复提问的前提参见 triage 技能 的 Resuming a previous session 一节。2.1 Merge requestPR 在 GitLab 中的等价物GitLab 将 GitHub 的 pull request 称为merge requestMR。glab mr系列命令与gh pr结构完全同形只需把pr换成mr、把comment/--body换成note/--messageglab mr create创建 MRglab mr view number --comments查看 MR 及评论glab mr note number --message ...在 MR 上评论glab mr diff number查看变更差异。2.2 与 GitHub 的关键差异双号码空间文档特别强调一个易踩的坑与 GitHub 共享 issue/PR 单一号码空间不同GitLab 对 issue 和 MR 分别编号。因此在 GitLab 中#42只要知道维护者指的是哪个表面issue 还是 MR就是无歧义的而在 GitHub 中裸#42可能是 issue 也可能是 PR需要先用gh pr view 42尝试、失败再回退到gh issue view 42见 issue-tracker-github.md。三、MR 作为 triage 表面可选开关文档为docs/agents/issue-tracker.md中的 GitLab 模板内置了一个标志MRs as a request surface: no.若本仓库将外部 MR 视为功能请求则改为yes/triage会读取该标志。setup-matt-pocock-skills的 SKILL.md 明确说明GitHub 与 GitLab 模板都携带此标志默认关闭初始化时不要主动打开只有当用户希望把外部 PR/MR 纳入 triage 队列时才手工改 flag。若置为yesMR 将走与 issue 完全相同的标签与状态机使用glab mr对应命令读取 MRglab mr view number --comments需要看变更时用glab mr diff number列出待 triage 的外部 MRglab issue list的 MR 版glab mr list -F json然后只保留作者不是项目成员/所有者的 MR贡献者提交的 MR而不是维护者正在进行的工作评论/打标签/关闭glab mr note、glab mr update --label/--unlabel、glab mr close。这与 triage 技能 的PR 是附带代码的 issue原则呼应同一套角色、同一套状态机仅发现阶段只过滤外部 MR——协作者的进行中 MR 不是 triage 工作。需要注意该过滤仅用于发现被显式点名的 MR 无论作者是谁都会进入 triage。四、技能语义约定两个固定操作的口径工程技能中会反复出现两句话issue-tracker-gitlab.md为它们给出了 GitLab 下的确定答案当技能说 publish to the issue tracker创建一条 GitLab issueglab issue create当技能说 fetch the relevant ticket运行glab issue view number --comments。这套一句话即一个确定动作的约定让to-tickets、triage、to-spec等技能无需关心底层是 GitHub、GitLab 还是本地 Markdown——它们只需读取docs/agents/issue-tracker.md即可获得正确命令。三个种子模板GitHub、GitLab、本地 Markdown在这两处保持了相同的措辞结构只是实现命令不同这正是可插拔设计的体现。五、Wayfinding 操作GitLab 上的地图与子工单/wayfinder技能见 wayfinder/SKILL.md用于把超过一个 Agent 会话容量的大任务以地图 决策工单的形式铺在 issue tracker 上逐个解析直到路线清晰。在 GitLab 上这套机制的具体落法是5.1 地图Map地图是一条打了wayfinder:map标签的 issue其正文承载 Notes / Decisions-so-far / Fog 三个区块glab issue create --label wayfinder:map地图是索引而非仓库它只列出已做的决策并链接到承载细节的工单从不复述决策内容。文档同时指出在支持原生 epic 的 GitLab 付费层地图也可以由 epic 承担但带标签的 issue 在任何层级都可用是最稳妥的默认选择。5.2 子工单Child ticket每个子工单是一条 issue要求描述顶部带Part of #map字样建立与地图的归属关系携带wayfinder:type标签类型为research/prototype/grilling/task与 wayfinder 技能的 Ticket Types 一一对应一旦被认领指派给推动地图的开发人员driving dev。5.3 阻塞Blocking优先使用 GitLab 原生阻塞链接GitLab 与 GitHub 一样拥有原生依赖关系这是唯一在 UI 上可见、可作为规范表示的方案。添加方式是利用 quick action作为一条 note 发出glab issue note child --message /blocked_by #blocker但文档明确标注了一个现实约束原生阻塞链接是 Premium/Ultimate 功能。在免费层或不可用时必须回退到在描述顶部的Blocked by: #n, #n行。无论哪种表示判据一致当所有阻塞者都关闭时工单解除阻塞。这一能原生就原生、否则正文约定兜底的降级策略与 GitHub 模板issue-tracker-github.md 中依赖不可用时的Blocked by兜底思路完全相同也与 wayfinder 中只有缺少原生依赖的 tracker 才回退到正文约定的原则一致。5.4 前沿查询Frontier query前沿 打开、未阻塞、未认领的边界工单是地图下一步可推进的集合。在 GitLab 上的查询逻辑为用glab issue list -F json限定到地图的子工单剔除任何存在打开阻塞者的工单判定方式二选一存在指向打开 issue 的原生blocked_by链接——通过glab api projects/:id/issues/:iid/links读取或者Blocked by行中存在打开 issue再剔除已有 assignee 的工单按地图顺序取第一条获胜。这条查询是 wayfinder Plan, dont do 哲学的落点只有解除阻塞的边界工单才允许被认领避免并发会话撞车。5.5 认领与解析认领Claimglab issue update n --assignee me并且这必须是会话的第一次写入——先认领再干活让并发会话能跳过它解析Resolve三步走glab issue note n --message answer发布解析结论 →glab issue close n关闭工单 → 在地图的 Decisions-so-far 追加一条上下文指针gist 链接。这与 wayfinder 技能解析评论 关闭 在地图追加指针的记录规范完全一致也再次印证了本文 2.0 节先 note 后 close约定的必要性——解析答案正是通过那条 note 留下的。六、将文档放回仓库语境它如何被消费issue-tracker-gitlab.md写好后落在docs/agents/issue-tracker.md由setup-matt-pocock-skills的 Write 阶段落盘其消费者包括triage 技能读取该文件判断本仓库是否把外部 PR/MR 作为请求表面以及把五个规范角色needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix映射到实际标签字符串——若未提供映射会提示用户运行/setup-matt-pocock-skillswayfinder 技能查阅其中Wayfinding operations一节决定地图、子工单、阻塞与前沿查询在本仓库的具体物理形态to-tickets、to-spec等技能通过 publish to the issue tracker / fetch the relevant ticket 两句话获取正确的读写命令。换句话说这份文档是工程技能在 GitLab 仓库中运行时的协议适配层技能侧只谈论抽象角色与操作文档侧负责把它们翻译成glab的确切命令与 GitLab 的机制细节note、quick action、原生阻塞链接、双号码空间。三份种子模板GitHub / GitLab / 本地 Markdown共用同一套抽象、各自实现若需要对比可继续阅读 issue-tracker-github.md 与 issue-tracker-local.md。使用前提与限制本文所有命令面向 GitLab 仓库gitlab.com或自托管需要本机安装glabCLI 并在克隆目录内执行以便自动推断项目原生阻塞链接依赖 GitLab 付费层能力免费层需按 5.3 节的正文约定回退docs/agents/*.md均可直接手工编辑重跑setup-matt-pocock-skills仅在切换跟踪器或需要完全重置时才必要。【免费下载链接】skillsSkills for Real Engineers. Straight from my .agents directory.项目地址: https://gitcode.com/GitHub_Trending/skills13/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考