with one click
repo-append-request-skill
// 当 RepoScope 收到 append-feature 或 append-design 追加请求时,使用这个技能做限定范围分类与路由;它只生成 Append Request 路由结果,不执行目标变更、范围扩展、设计或实现。
// 当 RepoScope 收到 append-feature 或 append-design 追加请求时,使用这个技能做限定范围分类与路由;它只生成 Append Request 路由结果,不执行目标变更、范围扩展、设计或实现。
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | repo-append-request-skill |
| description | 当 RepoScope 收到 append-feature 或 append-design 追加请求时,使用这个技能做限定范围分类与路由;它只生成 Append Request 路由结果,不执行目标变更、范围扩展、设计或实现。 |
本技能在 RepoScope 下处理外部追加请求,对应 Harness 控制面中的追加请求 intake / route 阶段。
它只支持一个 skill、两个 mode:
append-featureappend-design本技能的职责是把追加请求分类为一个明确路由,并输出 Append Request 路由结果。它不修改 repo 目标,不创建或扩展 worktrack,不写设计文档,不执行实现,也不改写 Harness Control State。如果分类结果需要审批或后续执行,应把边界显式返回给 Harness 或 programmer。
当用户提出的请求语义是"在现有 repo 目标或当前 worktrack 之外追加一项 feature 或 design"时,使用本技能:
append-feature:追加一个功能、行为、交互、接口、能力或实现工作append-design:追加一个设计分析、方案、架构判断、UX / protocol design 或实现前设计步骤不使用的情况:
Goal Charter,且用户要求直接进入目标变更流程(用 repo-change-goal-skill)schedule-worktrack-skill)init-worktrack-skill)repo-whats-next-skill)本技能至少读取:
append-feature / append-designRepo Goal / CharterRepo Snapshot / StatusHarness Control StateWorktrack Contract 摘要只在判断"scope expansion"是否成立时读取活跃 worktrack 产物。活跃 worktrack 产物的唯一合法角色是判定 scope expansion 边界;将 worktrack 队列当成 repo 级待办列表的行为禁止出现。
分类结果必须是以下五类之一:
当追加请求会改变 repo 长期参考信号时,分类为 goal change:
Engineering Node Map 中的节点类型或默认 baseline policyGoal Charter 明显冲突,必须先重设目标才可执行路由结果:
recommended_next_route: repo-change-goal-skillrecommended_next_scope: RepoScopeapproval_required: true当追加请求位于当前 repo 目标内,但不是现有活跃 worktrack 的已批准范围时,分类为 new worktrack:
Goal Charter 的 Engineering Node Map 找到候选节点类型路由结果:
recommended_next_route: init-worktrack-skillrecommended_next_scope: WorktrackScopeapproval_required 取决于该追加请求是否已经获得 programmer 授权suggested_node_type 与理由,最终绑定由 init-worktrack-skill 完成当追加请求试图把一个新目标塞进当前活跃 worktrack 时,分类为 scope expansion:
范围内路由结果:
recommended_next_route: scope-expansion-approvalrecommended_next_scope: WorktrackScopeapproval_required: true仅当追加内容超出了修复当前 worktrack 的已批准验收缺口范围时,才应归为 scope expansion;否则唯一合法行为是路由回当前 worktrack scheduling / dispatch。
当请求只需要形成设计判断或方案,不要求立刻进入实现时,分类为 design-only:
append-design 默认优先考虑本类,除非请求明确要求设计后继续实现路由结果:
recommended_next_route: design-only-worktrackrecommended_next_scope: WorktrackScopeapproval_required 取决于是否已经批准建立该设计 worktrack当请求要求先设计、再在设计结论被接受后实现时,分类为 design-then-implementation:
append-feature 的实现前置条件是新增设计结论路由结果:
recommended_next_route: design-then-implementation-worktrackrecommended_next_scope: WorktrackScopeapproval_required 取决于两阶段授权是否已明确design_phase 与 implementation_phasegoal change 与其他类别,优先分类为 goal change。scope expansion 与 new worktrack,且用户要求纳入当前活跃 worktrack,优先分类为 scope expansion 并要求审批;否则分类为 new worktrack。append-design 同时可独立设计也可设计后实现,只有在用户明确授权实现或实现是请求不可分割的一部分时,才分类为 design-then-implementation。new worktrack 与 scope expansion,返回 classification_confidence: low,建议 保持并观察 或请求最小缺失信息,擅自扩范围的行为必须返回 blocked。append-feature 或 append-design。goal change。Engineering Node Map 提取候选节点类型;无法提取时暴露缺口。Append Request 路由结果,可使用 templates/append-request.template.md。append-feature 的输出仅限于分类路由结果;将其自动解释为已批准的新 worktrack 的行为禁止出现。append-design 的输出仅限于分类路由结果;将其自动解释为已批准的实现工作的行为禁止出现。approval_required: true 并说明审批范围。approval_required、continuation_ready 与 continuation_blockers 必须一致:仅当不需要新审批时,设置 continuation_ready: true 才合法;需要新审批时必须设置 continuation_ready: false。classification_confidence: low 或存在阻塞性最小缺失信息时,必须设置 continuation_ready: false 并列出 blocker。continuation_ready 才可为 true;goal change 与 scope expansion 默认停在审批边界。使用这个技能时,产出一份 Append Request 路由结果,至少包含:
mode原始追加请求分类结果分类置信度分类理由目标影响活跃 worktrack 影响建议下一路由建议下一范围suggested_node_type设计阶段边界实现阶段边界权限边界最小缺失信息可继续结构化字段至少包含:
append_modeappend_classificationclassification_confidencerecommended_next_routerecommended_next_scopesuggested_node_typeapproval_requiredapproval_scopeapproval_reasoncontinuation_readycontinuation_blockers使用当前 .aw/goal-charter.md、.aw/repo/snapshot-status.md、.aw/control-state.md、用户追加请求与必要的活跃 worktrack 摘要作为依据。
当需要整理 Append Request 路由结果 时,使用 templates/append-request.template.md 作为格式参考。