Menu
变更守卫 — 分析用户变更请求与现有文档的一致性，决定处理路径。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
项目走查 — 在隔离沙盒中以指定执行模式（缺省 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>