Higress 基于 issue-spec 的 AI 辅助贡献提案规范issue-spec-propose 技能全流程解析【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress本文围绕 Higress 仓库中面向 AI Agent 的 Claude Code 技能.agents/skills/issue-spec-propose/SKILL.md展开系统讲解在“AI 或编码代理实质性参与贡献”场景下如何通过 issue-spec CLI 完成 Proposal提案、QUESTION开放决策、SPEC需求规格、Design设计与 TASK任务的类型化产物编排。读完本文你将掌握 Higress 规定的类型化 ID 规范、七步提案工作流、项目级issue-spec/config.yaml约束以及从提案创建到验证 TASK 完结的完整命令行操作序列可直接用于向 Higress 仓库提交受门禁约束的 AI 辅助贡献。背景为什么 Higress 需要一套 issue-spec 提案门禁Higress 是一个构建于 Istio 与 Envoy 之上的云原生 API 网关控制面以 Go 扩展 Istio/pilot数据面由 Envoy 加 WASM 插件组成。当 AI 或编码代理实质性参与贡献——例如执行实质性分析/设计、选择实现或验证方案、产出或实质性改写代码/测试/文档/配置、解释测试结果、准备实质性 PR 内容——该贡献在开始实现前必须进入 Higress issue-spec 工作流。这一强制性门禁定义在 docs/developers/agent-assisted-contributions.md并在 AGENTS.md 中向所有在仓库中工作的 Agent 明确宣告。从仓库版本记录看该工作流的落地有清晰脉络2.2.4 版本初始化 issue-spec 工作流并新增七个 Claude Code Skills如issue-spec-propose、issue-spec-apply随后经历用最新 CLI 重新初始化、移除issue-spec-review/verify/archive三个技能命令、禁用 HTML 评审功能、统一技能路径等演进见 release-notes/2.2.4/README.md。issue-spec-propose正是这条演进链上负责“提案与设计”阶段的技能。该技能的元数据frontmatter明确了定位name: issue-spec-proposedescription: 为一次 issue-spec 变更创建或续写 Proposal、SPEC、QUESTION、Design 与 TASK 产物license: MIT、compatibility: Requires issue-spec CLImetadata: 作者为 issue-spec版本 1.0技能开头即约定当用户请求/issue-spec:propose、proposal、Design、SPEC、QUESTION 或 TASK 编写时触发本技能共享读取、provider 路由与恢复则交给issue-spec-workflow技能该技能目录同样存在于 .agents/skills/issue-spec-workflow/SKILL.md配套还有issue-spec-apply、issue-spec-github两个兄弟技能。类型化 ID 规范TYPE-issue三位序号SKILL 中最先强调、也最容易被忽略的是一条硬性 ID 规范Every new typed ID MUST beTYPE-issuethree-digit sequenceIssue 1 起始于QUESTION-1001Issue 44 起始于QUESTION-44001。解读为ID 由类型前缀QUESTION/SPEC/TASK/PROCESS 等、目标 Issue 编号、以及三位序号拼接而成。因此QUESTION-1001表示 Issue #1 上的第一个 QUESTIONQUESTION-44001表示 Issue #44 上的第一个 QUESTION序号只能在目标 Issue 与类型范围内分配001–999且在分配前必须先阅读该 Issue 上已存在的类型化评论避免撞号存量历史 ID不得重编号新建写入会拒绝错误的 Issue 前缀--allow-legacy-id仅用于有意的、兼容旧 ID 的创建场景不是常规写法。七步提案工作流Propose 阶段的权威执行顺序issue-spec-propose的核心是一份内置协议built-in protocol它覆盖项目文本、绝不重排或省略步骤、也不允许把悬而未决的决策移出类型化载体。七步顺序如下Step 1 · 校验配置与检索上下文校验工作流配置、搜索相关 Issue只打开选中的讨论。若 Issue 已处于后续阶段则直接续写该阶段而不是重复创建。Step 2 · 创建阶段 Issue未确认的调查/复现/分诊笔记应通过issue-spec issue create simple放在普通 Issue 中提案只能陈述已确认的问题与预期变更禁止把调查类 Issue 升级为提案也不得把 SPEC/Design 挂到调查 Issue 上。正式创建阶段 Issue 时必须携带具体 body 文件issue-spec issue create proposal --repo higress-group/higress --body-file file标题需遵循工作流rules.language与rules.language_instructions当规则要求本地化/非英文标题时必须为 Proposal、Design、Implement 显式传--title派生态标题会保留英文阶段前缀不可依赖否则使用标准的Proposal:、Design:、Implement:标题族。创建后不得再做纯风格性标题改写。当前仓库的 issue-spec/config.yaml 中并未配置language规则因此实际落库走标准标题族分支。Step 3 · 首轮 QUESTION 发现/创建把每一个真实的未决决策记录为阻塞型 QUESTIONissue-spec question create存在可信选项时附加选择模型choice model绝不把开放决策留在正文或投影 prose 里。同时也不要无中生有制造问题或重开已定论的选择——未决决策与“依赖证据”的事项要区分开。Step 4 · 生成规范 SPEC 评论issue-spec comment generate --type SPEC ...需求必须可测试并包含 WHEN/THEN 场景--allow-noncanonical是迁移期绕过手段不是常规编写方式。Step 5 · 持久化权威 Design保存自洽的 Design 正文执行它的首轮 QUESTION 发现/创建然后完成 TASK 规划。Step 6 · 生成 TASK 评论issue-spec comment generate --type TASK ...执行规划Execution Planning必须识别Design 不变的凝聚点与主要入口、受控的角色上下文压力、稳定接口、归属区域、共享触点、依赖关系、耦合度与验收后果。文件归属与并行度只是调度上下文不是语义上的 PROCESS 边界选择 Design 或 TASK 需要真实的非 Coordinator 实现工人执行模式标签既不授权 Coordinator 改代码也不会自动要求 PROCESS。Step 7 · 带覆盖关系的 TASK 落库每个 TASK 用--covers-issueupsert从而发布其完整的规范 SPEC 覆盖关系并校验规划关系。Proposal、Design、Implement、TASK、PROCESS 始终是可选的辅助载体绝不代表交付验收通过。项目工作流配置issue-spec/config.yaml的约束语义技能的 “Project Workflow” 一节与仓库根目录的 issue-spec/config.yaml 一一对应Workflow Source:builtin内置阶段序列Workflow Schema:issue-specWorkflow Config:issue-spec/config.yamlWorkflow Diagnostics: 项目工作流模板仅作声明式使用活跃的 Proposal/Design/Implement/SPEC/TASK/PROCESS/QUESTION 产物保留在所选 Issue 后端的原生存储中历史 REVIEW/VERIFY 产物仅作审计repository 模式的持久化规格只在实现分支上物化与校验。config.yaml 中rules定义了四条项目级约束materially_agent_assisted_gate策略合并后开始的实质性 AI/编码代理参与必须在 Higress 维护者显式批准 Proposal 与 Design Issue 后才开始实现被批准的 Design 与授权的实现 TASK 为相应 SPEC 提供实现血缘。同时定义了“已验证维护者/管理员例外”的完整前置条件仅当通过 GitHub.comgh认证身份且规范仓库 collaborator 权限role_name为maintain或admin、且 PR 作者与该 login 一致时才可用PR 需记录编号或 URL、login、返回的 role_name、PR 作者、正向 token 覆盖证明与绕过理由任何一次验证失败/缺失/不匹配都使例外失效接收或合并方维护者必须在未设置 token 覆盖的情况下独立复核实时证据。该例外不免除 bug 修复的运行时验证。verificationDesign 必须在实现验证开始前包含具体 Verification Plan对应验证 TASK 在请求维护者接受验证或评审前须以精确命令、结果、证据链接与哈希完成。design_carrier受门禁约束的贡献以被批准的 Design Issue 为权威设计载体可选的持久化能力规格独立存在仅在维护者要求时使用issue-spec/specs/plugin-qualified-capability/spec.md唯一小写连字符插件能力 slug既不替代也不复制 Design Issue本项目durable_specs保持未设置。enforcement_boundaryCLI 校验工作流配置、规范产物与声明的血缘维护者基于 PR 作者声明执行适用性、人工批准、证据质量、例外适当性、评审优先级、评审与合并等治理动作——该配置既不推断隐藏的代理使用也不授予批准或合并权。references指向两份关键文档docs/developers/agent-assisted-contributions.md门禁政策全文与 docs/developers/wasm-runtime-verification/README.mdWasm 插件运行时验证脚手架html_review.enabled: false则关闭了 HTML 评审功能。实战命令序列从提案创建到验证 TASK 完结agent-assisted-contributions.md 给出了与 SKILL 相配套的可移植 CLI 工作流不依赖私有 runner 或 agent 会话机制。整体脉络为认证与配置校验 → 检索既有 Issue → 创建阶段 Issue → 生成/落库类型化评论 → 状态检查与血缘校验。先做认证检查与工作流校验并检索相关 Issueissue-spec auth status --json issue-spec workflow validate --repo higress-group/higress --json issue-spec search issues --repo higress-group/higress \ --query relevant topic or symbol --state all --source all若相关 Proposal/Design Issue 已存在则续写否则从审阅过的 body 文件创建阶段 Issueissue-spec issue create proposal --repo higress-group/higress \ --change descriptive-change-name --body-file proposal.md issue-spec issue create design --repo higress-group/higress \ --change descriptive-change-name --proposal 123 --body-file design.md规范类型化评论由结构化 JSON 生成而非手写标记/布局并通过管道直接 upsert注意--covers-issue的使用issue-spec comment generate --type SPEC --id SPEC-123001 --status draft \ --scope proposal requirements --input-file spec.json \ | issue-spec comment upsert --repo higress-group/higress --issue 123 \ --type SPEC --id SPEC-123001 --status draft \ --scope proposal requirements --body-file - issue-spec comment generate --type TASK --id TASK-124001 --status draft \ --scope implementation --input-file implementation-task.json \ | issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124001 --status draft --scope implementation \ --body-file - --covers-issue 123 issue-spec comment generate --type TASK --id TASK-124002 --status draft \ --scope verification --input-file verification-task.json \ | issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --status draft --scope verification \ --body-file - --covers-issue 123状态语义SPEC 通常在需求与场景确定后由draft转confirmedTASK 走draft→ready→in-progress只有工作与证据完整才置为done。CLI 状态不是维护者批准。TASK 生成器把所有结构化清单项渲染为未勾选没有完成复选框输入因此完结一个 TASK 需要先取回其当前规范正文更新 summary 中的精确命令、结果、证据链接与哈希仅勾选实际完成的清单项并置可见状态为done再以相同 status/scope upsertissue-spec comment get --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --include-body --json issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --status done --scope verification \ --body-file verification-task-done.md --covers-issue 123检查规划状态以及若选择了可选的 Implement Issue校验三 Issue 血缘issue-spec status --repo higress-group/higress \ --proposal 123 --design 124 --json issue-spec verify-links --repo higress-group/higress \ --proposal 123 --design 124 --implement 125 --json需要说明的是PROCESS 评论同样是可选的仅用于具体的托管协调需求当前生成器支持 SPEC、TASK、PROCESS 三类评论历史 REVIEW/VERIFY 生成器、最终验证门禁与 Archive 交付门禁均已退役或仅作审计不得作为活跃工作流使用。边界与权威性阶段序列不可被项目配置改写SKILL 与 config.yaml 反复强调一条原则内置阶段序列与规范产物载体是权威的项目工作流上下文、规则与产物说明只能在既有步骤内增加约束不得重排或省略已启用的步骤也不得把真实的未决决策移出阻塞型 QUESTION 载体。启用的阶段顺序固定为先持久化阶段 Issue 正文再执行其首轮 QUESTION 发现/创建然后编写所选的下游类型化子产物——Issue 正文 prose 永远不承载开放决策。与之呼应AGENTS.md 中“Mandatory issue-spec gate for agent-assisted changes”一节把门禁要点浓缩为四条开始实现前须有维护者批准 Proposal 与 Designissue-spec 状态或 agent 断言都不是批准只通过 Design 授权的 TASK 实现并保持对 SPEC 的可追溯性Design 须在验证开始前包含具体 Verification Plan在声称成功或请求维护者验收/评审前创建并完成对应验证 TASK含精确命令、结果、证据链接与哈希。该文档同时界定豁免边界纯拼写/标点/空白/格式的小型文档修正可跳过工作流而代理参与的 bug 修复与实质性功能开发必须遵循门禁具备maintain/admin权限的认证用户可使用已验证维护者/管理员例外但 PR 作者必须匹配验证过的 login且每一条验证命令都必须以GH_TOKEN/GITHUB_TOKEN未设置的状态执行任何失败或不匹配都会使例外失效。总结把提案变成可审计的类型化产物issue-spec-propose的本质是把“一次 AI 辅助变更的提案与设计”从自由文本升级为带类型、带编号、带状态、带血缘的机器可校验产物流严格 ID 规范保证每个 QUESTION/SPEC/TASK 可精确定位内置七步顺序保证决策不被旁路--covers-issue保证 TASK 与其覆盖的 SPEC 关系可追踪config.yaml 的项目规则则把“维护者批准”“验证计划”“设计载体”“执行边界”固化为不可绕过的约束。对希望向 Higress 提交 AI 辅助贡献的开发者而言遵循 .agents/skills/issue-spec-propose/SKILL.md 的流程、对照 issue-spec/config.yaml 的规则、以 docs/developers/agent-assisted-contributions.md 的命令序列落地即可获得一条从提案到验证的完整、透明、可复核的贡献链路。相关技能issue-spec-apply、issue-spec-github、issue-spec-workflow与配套的 Wasm 运行时验证脚手架docs/developers/wasm-runtime-verification/README.md共同构成了 Higress 面向 Agent 的规范化开发工具集值得在提交 PR 前通读。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Higress 基于 issue-spec 的 AI 辅助贡献提案规范：issue-spec-propose 技能全流程解析
Higress 基于 issue-spec 的 AI 辅助贡献提案规范issue-spec-propose 技能全流程解析【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress本文围绕 Higress 仓库中面向 AI Agent 的 Claude Code 技能.agents/skills/issue-spec-propose/SKILL.md展开系统讲解在“AI 或编码代理实质性参与贡献”场景下如何通过 issue-spec CLI 完成 Proposal提案、QUESTION开放决策、SPEC需求规格、Design设计与 TASK任务的类型化产物编排。读完本文你将掌握 Higress 规定的类型化 ID 规范、七步提案工作流、项目级issue-spec/config.yaml约束以及从提案创建到验证 TASK 完结的完整命令行操作序列可直接用于向 Higress 仓库提交受门禁约束的 AI 辅助贡献。背景为什么 Higress 需要一套 issue-spec 提案门禁Higress 是一个构建于 Istio 与 Envoy 之上的云原生 API 网关控制面以 Go 扩展 Istio/pilot数据面由 Envoy 加 WASM 插件组成。当 AI 或编码代理实质性参与贡献——例如执行实质性分析/设计、选择实现或验证方案、产出或实质性改写代码/测试/文档/配置、解释测试结果、准备实质性 PR 内容——该贡献在开始实现前必须进入 Higress issue-spec 工作流。这一强制性门禁定义在 docs/developers/agent-assisted-contributions.md并在 AGENTS.md 中向所有在仓库中工作的 Agent 明确宣告。从仓库版本记录看该工作流的落地有清晰脉络2.2.4 版本初始化 issue-spec 工作流并新增七个 Claude Code Skills如issue-spec-propose、issue-spec-apply随后经历用最新 CLI 重新初始化、移除issue-spec-review/verify/archive三个技能命令、禁用 HTML 评审功能、统一技能路径等演进见 release-notes/2.2.4/README.md。issue-spec-propose正是这条演进链上负责“提案与设计”阶段的技能。该技能的元数据frontmatter明确了定位name: issue-spec-proposedescription: 为一次 issue-spec 变更创建或续写 Proposal、SPEC、QUESTION、Design 与 TASK 产物license: MIT、compatibility: Requires issue-spec CLImetadata: 作者为 issue-spec版本 1.0技能开头即约定当用户请求/issue-spec:propose、proposal、Design、SPEC、QUESTION 或 TASK 编写时触发本技能共享读取、provider 路由与恢复则交给issue-spec-workflow技能该技能目录同样存在于 .agents/skills/issue-spec-workflow/SKILL.md配套还有issue-spec-apply、issue-spec-github两个兄弟技能。类型化 ID 规范TYPE-issue三位序号SKILL 中最先强调、也最容易被忽略的是一条硬性 ID 规范Every new typed ID MUST beTYPE-issuethree-digit sequenceIssue 1 起始于QUESTION-1001Issue 44 起始于QUESTION-44001。解读为ID 由类型前缀QUESTION/SPEC/TASK/PROCESS 等、目标 Issue 编号、以及三位序号拼接而成。因此QUESTION-1001表示 Issue #1 上的第一个 QUESTIONQUESTION-44001表示 Issue #44 上的第一个 QUESTION序号只能在目标 Issue 与类型范围内分配001–999且在分配前必须先阅读该 Issue 上已存在的类型化评论避免撞号存量历史 ID不得重编号新建写入会拒绝错误的 Issue 前缀--allow-legacy-id仅用于有意的、兼容旧 ID 的创建场景不是常规写法。七步提案工作流Propose 阶段的权威执行顺序issue-spec-propose的核心是一份内置协议built-in protocol它覆盖项目文本、绝不重排或省略步骤、也不允许把悬而未决的决策移出类型化载体。七步顺序如下Step 1 · 校验配置与检索上下文校验工作流配置、搜索相关 Issue只打开选中的讨论。若 Issue 已处于后续阶段则直接续写该阶段而不是重复创建。Step 2 · 创建阶段 Issue未确认的调查/复现/分诊笔记应通过issue-spec issue create simple放在普通 Issue 中提案只能陈述已确认的问题与预期变更禁止把调查类 Issue 升级为提案也不得把 SPEC/Design 挂到调查 Issue 上。正式创建阶段 Issue 时必须携带具体 body 文件issue-spec issue create proposal --repo higress-group/higress --body-file file标题需遵循工作流rules.language与rules.language_instructions当规则要求本地化/非英文标题时必须为 Proposal、Design、Implement 显式传--title派生态标题会保留英文阶段前缀不可依赖否则使用标准的Proposal:、Design:、Implement:标题族。创建后不得再做纯风格性标题改写。当前仓库的 issue-spec/config.yaml 中并未配置language规则因此实际落库走标准标题族分支。Step 3 · 首轮 QUESTION 发现/创建把每一个真实的未决决策记录为阻塞型 QUESTIONissue-spec question create存在可信选项时附加选择模型choice model绝不把开放决策留在正文或投影 prose 里。同时也不要无中生有制造问题或重开已定论的选择——未决决策与“依赖证据”的事项要区分开。Step 4 · 生成规范 SPEC 评论issue-spec comment generate --type SPEC ...需求必须可测试并包含 WHEN/THEN 场景--allow-noncanonical是迁移期绕过手段不是常规编写方式。Step 5 · 持久化权威 Design保存自洽的 Design 正文执行它的首轮 QUESTION 发现/创建然后完成 TASK 规划。Step 6 · 生成 TASK 评论issue-spec comment generate --type TASK ...执行规划Execution Planning必须识别Design 不变的凝聚点与主要入口、受控的角色上下文压力、稳定接口、归属区域、共享触点、依赖关系、耦合度与验收后果。文件归属与并行度只是调度上下文不是语义上的 PROCESS 边界选择 Design 或 TASK 需要真实的非 Coordinator 实现工人执行模式标签既不授权 Coordinator 改代码也不会自动要求 PROCESS。Step 7 · 带覆盖关系的 TASK 落库每个 TASK 用--covers-issueupsert从而发布其完整的规范 SPEC 覆盖关系并校验规划关系。Proposal、Design、Implement、TASK、PROCESS 始终是可选的辅助载体绝不代表交付验收通过。项目工作流配置issue-spec/config.yaml的约束语义技能的 “Project Workflow” 一节与仓库根目录的 issue-spec/config.yaml 一一对应Workflow Source:builtin内置阶段序列Workflow Schema:issue-specWorkflow Config:issue-spec/config.yamlWorkflow Diagnostics: 项目工作流模板仅作声明式使用活跃的 Proposal/Design/Implement/SPEC/TASK/PROCESS/QUESTION 产物保留在所选 Issue 后端的原生存储中历史 REVIEW/VERIFY 产物仅作审计repository 模式的持久化规格只在实现分支上物化与校验。config.yaml 中rules定义了四条项目级约束materially_agent_assisted_gate策略合并后开始的实质性 AI/编码代理参与必须在 Higress 维护者显式批准 Proposal 与 Design Issue 后才开始实现被批准的 Design 与授权的实现 TASK 为相应 SPEC 提供实现血缘。同时定义了“已验证维护者/管理员例外”的完整前置条件仅当通过 GitHub.comgh认证身份且规范仓库 collaborator 权限role_name为maintain或admin、且 PR 作者与该 login 一致时才可用PR 需记录编号或 URL、login、返回的 role_name、PR 作者、正向 token 覆盖证明与绕过理由任何一次验证失败/缺失/不匹配都使例外失效接收或合并方维护者必须在未设置 token 覆盖的情况下独立复核实时证据。该例外不免除 bug 修复的运行时验证。verificationDesign 必须在实现验证开始前包含具体 Verification Plan对应验证 TASK 在请求维护者接受验证或评审前须以精确命令、结果、证据链接与哈希完成。design_carrier受门禁约束的贡献以被批准的 Design Issue 为权威设计载体可选的持久化能力规格独立存在仅在维护者要求时使用issue-spec/specs/plugin-qualified-capability/spec.md唯一小写连字符插件能力 slug既不替代也不复制 Design Issue本项目durable_specs保持未设置。enforcement_boundaryCLI 校验工作流配置、规范产物与声明的血缘维护者基于 PR 作者声明执行适用性、人工批准、证据质量、例外适当性、评审优先级、评审与合并等治理动作——该配置既不推断隐藏的代理使用也不授予批准或合并权。references指向两份关键文档docs/developers/agent-assisted-contributions.md门禁政策全文与 docs/developers/wasm-runtime-verification/README.mdWasm 插件运行时验证脚手架html_review.enabled: false则关闭了 HTML 评审功能。实战命令序列从提案创建到验证 TASK 完结agent-assisted-contributions.md 给出了与 SKILL 相配套的可移植 CLI 工作流不依赖私有 runner 或 agent 会话机制。整体脉络为认证与配置校验 → 检索既有 Issue → 创建阶段 Issue → 生成/落库类型化评论 → 状态检查与血缘校验。先做认证检查与工作流校验并检索相关 Issueissue-spec auth status --json issue-spec workflow validate --repo higress-group/higress --json issue-spec search issues --repo higress-group/higress \ --query relevant topic or symbol --state all --source all若相关 Proposal/Design Issue 已存在则续写否则从审阅过的 body 文件创建阶段 Issueissue-spec issue create proposal --repo higress-group/higress \ --change descriptive-change-name --body-file proposal.md issue-spec issue create design --repo higress-group/higress \ --change descriptive-change-name --proposal 123 --body-file design.md规范类型化评论由结构化 JSON 生成而非手写标记/布局并通过管道直接 upsert注意--covers-issue的使用issue-spec comment generate --type SPEC --id SPEC-123001 --status draft \ --scope proposal requirements --input-file spec.json \ | issue-spec comment upsert --repo higress-group/higress --issue 123 \ --type SPEC --id SPEC-123001 --status draft \ --scope proposal requirements --body-file - issue-spec comment generate --type TASK --id TASK-124001 --status draft \ --scope implementation --input-file implementation-task.json \ | issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124001 --status draft --scope implementation \ --body-file - --covers-issue 123 issue-spec comment generate --type TASK --id TASK-124002 --status draft \ --scope verification --input-file verification-task.json \ | issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --status draft --scope verification \ --body-file - --covers-issue 123状态语义SPEC 通常在需求与场景确定后由draft转confirmedTASK 走draft→ready→in-progress只有工作与证据完整才置为done。CLI 状态不是维护者批准。TASK 生成器把所有结构化清单项渲染为未勾选没有完成复选框输入因此完结一个 TASK 需要先取回其当前规范正文更新 summary 中的精确命令、结果、证据链接与哈希仅勾选实际完成的清单项并置可见状态为done再以相同 status/scope upsertissue-spec comment get --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --include-body --json issue-spec comment upsert --repo higress-group/higress --issue 124 \ --type TASK --id TASK-124002 --status done --scope verification \ --body-file verification-task-done.md --covers-issue 123检查规划状态以及若选择了可选的 Implement Issue校验三 Issue 血缘issue-spec status --repo higress-group/higress \ --proposal 123 --design 124 --json issue-spec verify-links --repo higress-group/higress \ --proposal 123 --design 124 --implement 125 --json需要说明的是PROCESS 评论同样是可选的仅用于具体的托管协调需求当前生成器支持 SPEC、TASK、PROCESS 三类评论历史 REVIEW/VERIFY 生成器、最终验证门禁与 Archive 交付门禁均已退役或仅作审计不得作为活跃工作流使用。边界与权威性阶段序列不可被项目配置改写SKILL 与 config.yaml 反复强调一条原则内置阶段序列与规范产物载体是权威的项目工作流上下文、规则与产物说明只能在既有步骤内增加约束不得重排或省略已启用的步骤也不得把真实的未决决策移出阻塞型 QUESTION 载体。启用的阶段顺序固定为先持久化阶段 Issue 正文再执行其首轮 QUESTION 发现/创建然后编写所选的下游类型化子产物——Issue 正文 prose 永远不承载开放决策。与之呼应AGENTS.md 中“Mandatory issue-spec gate for agent-assisted changes”一节把门禁要点浓缩为四条开始实现前须有维护者批准 Proposal 与 Designissue-spec 状态或 agent 断言都不是批准只通过 Design 授权的 TASK 实现并保持对 SPEC 的可追溯性Design 须在验证开始前包含具体 Verification Plan在声称成功或请求维护者验收/评审前创建并完成对应验证 TASK含精确命令、结果、证据链接与哈希。该文档同时界定豁免边界纯拼写/标点/空白/格式的小型文档修正可跳过工作流而代理参与的 bug 修复与实质性功能开发必须遵循门禁具备maintain/admin权限的认证用户可使用已验证维护者/管理员例外但 PR 作者必须匹配验证过的 login且每一条验证命令都必须以GH_TOKEN/GITHUB_TOKEN未设置的状态执行任何失败或不匹配都会使例外失效。总结把提案变成可审计的类型化产物issue-spec-propose的本质是把“一次 AI 辅助变更的提案与设计”从自由文本升级为带类型、带编号、带状态、带血缘的机器可校验产物流严格 ID 规范保证每个 QUESTION/SPEC/TASK 可精确定位内置七步顺序保证决策不被旁路--covers-issue保证 TASK 与其覆盖的 SPEC 关系可追踪config.yaml 的项目规则则把“维护者批准”“验证计划”“设计载体”“执行边界”固化为不可绕过的约束。对希望向 Higress 提交 AI 辅助贡献的开发者而言遵循 .agents/skills/issue-spec-propose/SKILL.md 的流程、对照 issue-spec/config.yaml 的规则、以 docs/developers/agent-assisted-contributions.md 的命令序列落地即可获得一条从提案到验证的完整、透明、可复核的贡献链路。相关技能issue-spec-apply、issue-spec-github、issue-spec-workflow与配套的 Wasm 运行时验证脚手架docs/developers/wasm-runtime-verification/README.md共同构成了 Higress 面向 Agent 的规范化开发工具集值得在提交 PR 前通读。【免费下载链接】higress AI Gateway | AI Native API Gateway项目地址: https://gitcode.com/GitHub_Trending/hi/higress创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考