Menü
变更守卫 — 分析用户变更请求与现有文档的一致性，决定处理路径。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
项目走查 — 在隔离沙盒中以指定执行模式（缺省 standard 全阶段）把一个小型示例项目跑通整条 SDLC 工作流（初始化→核心执行链路→分支→异常→终止清理），逐路径观察各阶段/门禁/降级/恢复的真实行为，产出『框架本身 + 走查流程本身』两类改进建议，并把走查流程自身的改进经自更新协议回灌本 skill 迭代。与 framework-review 形成动静对偶：后者静态审元资产，本 skill 动态端到端自测。当用户想验证一次框架部署是否真能跑通、为非 Claude-Code 平台做行为级冒烟、或自测 workflow-framework-generator 生成的框架时使用。
测试 — 测试策略规划、测试编写与执行、覆盖率分析、缺陷记录。当需要规划测试策略、编写或执行测试套件、分析覆盖率或记录缺陷时使用。本 skill 不改源码（缺陷修复由 debug 负责），单任务 RED/GREEN 单元测试由 tdd-engine 负责，testing 聚焦集成/E2E 与覆盖盲区补充。
代码评审 — 任务粒度评审 (review) 与项目级健康度扫描 (scan) 双入口；代码质量检查、规范合规验证、安全漏洞检测、腐化指标扫描。当任务卡 GREEN 完成 / Sprint 发布前 / 用户要求扫描代码腐化时使用此 skill。审查范围限 src/ 业务代码：文档审查由 doc-review 负责；框架元资产 (.cataforge/) 审查由 framework-review 负责；Sprint 完成度由 sprint-review 负责。
统一上下文 I/O — 按需读取章节/实体、查询追溯关系、生成与写入、门禁校验。文档生命周期的单一入口；后端(知识图谱/文件)由框架按配置方案透明路由,调用方只表达意图。按操作分支见 references/。
功能走查 — 对交付项目的功能实现做验收式动态走查，两层正交判定：①功能是否兑现 spec（missing/drift/bug/pass）；②代码本身是否健康（复用 COMMON-RULES §统一问题分类体系的 code category）。用真实数据路径起真实服务复现，专捞门禁全绿仍漏的跨模块集成缝隙。当项目功能交付后需验收、Sprint 发布前做功能级复核、或用户要求走查某功能域时使用。与 framework-walkthrough 动静对偶：后者在沙盒自测框架 SDLC，本 skill 验收交付项目的功能实现。
框架元资产审查 — 对 .cataforge/ 下的 agents/skills/hooks/rules + workflow 拓扑做内容质量与一致性审查。与 platform-audit 形成内审/外审对偶；与 code-review/doc-review 服务于业务产物不同，本 skill 专审框架自身配置。当用户提到框架腐化、SKILL.md/AGENT.md 质量、agent 引用孤立、SKILL/MANIFEST 漂移、Workflow 完整性、model_tier 合规时使用。
| name | change-guard |
| description | 变更守卫 — 分析用户变更请求与现有文档的一致性，决定处理路径。 |
| argument-hint | <change_description: 用户变更描述> |
| suggested-tools | file_read, file_glob, file_grep |
| depends | ["context"] |
| disable-model-invocation | false |
| user-invocable | false |
<change-analysis> 结构化分析结果，供orchestrator路由决策提取变更的核心意图:
数据源（自动）：对每个已识别的实体 ID 取追溯链——cataforge kg trace <id> --direction both --output json 取上下游追溯（PRD→ARCH→UI-SPEC→DEV-PLAN 全链路），配合 --coverage 取全局 Feature 覆盖矩阵，一次性定位"哪个 Feature 已有 / 缺实现 / 缺测试"；追溯后端不可达时经 context 检索已有文档逐级核对。后端选择由框架路由，无需在此判断。
按以下结构逐级检查:
记录每级文档的匹配结果:
covered: 变更已被文档明确描述partial: 文档涉及相关领域但未完全覆盖该变更missing: 文档中无相关内容conflicting: 变更与文档现有描述矛盾根据文档覆盖度结果分类:
| 覆盖度结果 | 变更类型 | 说明 |
|---|---|---|
| 所有相关文档均 covered | clarification | 变更已有文档支撑，仅需澄清实现细节 |
| 至少一级文档 partial/missing，无 conflicting | enhancement | 变更扩展已有行为，需修订受影响的文档 |
| 存在 conflicting，或 PRD 级 missing | new_requirement | 变更引入新功能或与现有设计矛盾，需从PRD开始cascade |
clarification 类型直接 drift_level = n/a、action = proceed，跳过下方深度分析。对 enhancement 和 new_requirement 类型，进一步分析:
Drift Level (偏移等级) 判定锚点:
| Level (action) | 判定锚点 | 示例 |
|---|---|---|
| n/a (proceed) | clarification 类型，所有相关文档均 covered，无任何 ID 增删改 | 澄清措辞 |
| L1 (proceed) | 仅修改文档措辞，不新增/删除/修改任何 F-xxx/M-xxx/API-xxx/E-xxx/T-xxx ID | 修改字段描述、补充注释 |
| L2 (amend_then_proceed) | 修改现有 ID 的定义或新增 ID，但不涉及 arch#§1 架构概览中的系统边界 | 增加API参数、修改验证规则、调整UI交互 |
| L3 (cascade_amendment) | 涉及 arch#§1 系统边界变更、新增/删除顶层模块、或技术栈变更 | 新增模块、改变数据模型 |
受影响文档 (affected_docs):
doc_id#section 引用路由动作 (action): 见 ORCHESTRATOR-PROTOCOLS §Change Request Protocol。
返回结构化结果供orchestrator解析:
<change-analysis>
<type>clarification|enhancement|new_requirement</type>
<drift_level>n/a|L1|L2|L3</drift_level>
<coverage>
<prd status="covered|partial|missing|conflicting">匹配的F-NNN/AC-NNN列表</prd>
<arch status="covered|partial|missing|conflicting">匹配的M-NNN/API-NNN列表</arch>
<ui_spec status="covered|partial|missing|conflicting|n/a">匹配的UC-NNN/P-NNN列表</ui_spec>
<dev_plan status="covered|partial|missing|conflicting|n/a">匹配的T-NNN列表</dev_plan>
</coverage>
<affected_docs>doc_id#section, ...</affected_docs>
<action>proceed|amend_then_proceed|cascade_amendment</action>
<rationale>分类理由的简要说明</rationale>
</change-analysis>