メニュー
修改 Skill / Rule / Agent 文件的操作规范。当 AI 或用户需要新增、修改、删除 .cursor/skills/ 或 .cursor/rules/ 或 .cursor/agents/ 中的任何文件时触发。修改前必须遵循本规范，未经本规范允许不可直接改写 Skill/Rule/Agent。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/TashanGKD/tashan-cursor-skills --skill skill-ruleコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
SOC 職業分類に基づく
| name | skill-rule-修改规范 |
| description | 修改 Skill / Rule / Agent 文件的操作规范。当 AI 或用户需要新增、修改、删除 .cursor/skills/ 或 .cursor/rules/ 或 .cursor/agents/ 中的任何文件时触发。修改前必须遵循本规范，未经本规范允许不可直接改写 Skill/Rule/Agent。 |
Skill、Rule、Agent 是 AI 行为的「操作系统」。修改它们比修改功能代码风险更高——一行错误的规则会影响所有未来任务的执行，而且问题难以溯源。
修改 Skill/Rule/Agent 和修改生产代码一样，需要相同严格的流程。
三型作用域：
.cursor/skills/：Skill 文件（步骤化流程，按场景触发）.cursor/rules/：Rule 文件（全局约束，alwaysApply 或条件触发）.cursor/agents/：Agent 文件（独立上下文执行单元，如 verifier / user-simulator）三型文件均受本规范约束，无例外。判断应建哪型，参照
Skill体系设计原则_v1.0.md §2.5 统一决策树。
本 Skill 的步骤设计基于以下文档的核心概念。若不理解这些概念，步骤无法正确执行。
| 层级 | 文档 | 需要理解的概念 |
|---|---|---|
| D0 认知根（必读） | _内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md | §2.2 Rule本质（普遍约束<300词）；§2.3 Skill本质（任务流程）；§2.4 Agent本质（隔离执行）；§2.5 三型统一决策树；§4 文档体系与知识层次 |
| D3 规范参考 | _内部总控/认知结构/L1_系统性文档/系统架构思维维度/系统对象全量分类表_20260320.md | 类型A（Rule）/ B（Skill）/ C（Agent）的完整定义与存放位置 |
| D4 运行时数据 | 目标 Skill/Rule/Agent 文件（执行时确定） | 待修改对象的当前版本和现有内容 |
核心概念速查： ① ceremony(B) = 备份→三问→最小化修改→变更记录→更新索引 ② alwaysApply Rule = 每次对话注入，违反即错误（应≤4个，目前过多是已知技术债） ③ Skill趋薄化 = 知识迁移到 K-objects，Skill 只保留导航+触发+守门
在回答三问之前，先判断本次操作属于哪个级别：
Level 1 补丁型：修改已有组件的局部内容（一个步骤/注意事项/触发词措辞）
→ 走本规范的「三问 + 备份 + 修改 + 变更记录 + 索引」流程
→ 不需要 skill-designer 引导，直接执行
Level 2 新增型：新建独立 Skill/Agent/Rule，与现有系统无显著交互
→ 先走 skill-designer 的 Step 1-5（含关卡A + 关卡C）
→ 完成后回到本规范 Step 4-6（备份 + 写入 + 变更记录 + 索引）
Level 3 集成型：新建组件，与多个现有组件有触发词重叠或调用关系
→ 先走 skill-designer 的 Step 1-7（含关卡A + 关卡B + 关卡C）
→ 完成后回到本规范 Step 4-6
Level 4 系统型：重构多个现有组件的交互关系
→ 先走 skill-designer 完整八步
→ 需要在 Step 3（产品定义）完成后，暂停等待用户二次确认规模
Level 判断有疑问时：加载 skill-designer Skill，由它引导判断。
在动笔之前，必须能清楚回答以下三问。答不出来，不允许开始修改。
1. 这次修改的根因是什么？
→ 是 AI 执行中发现了真实的执行漏洞？
→ 还是用户/AI 凭感觉觉得"应该加点什么"？
→ 根因必须来自真实事件（某次任务执行的具体问题），不能是假设
2. 修改后，会影响哪些已有的执行路径？
→ 哪些任务会因为这个改动而改变行为？
→ 有没有可能让之前正常工作的流程变得不正常？
3. 怎么验证改完之后规则确实生效且没有副作用？
→ 能不能构造一个具体的场景来验证新规则？
→ 用什么方法检查没有破坏已有约束？
Step 1 Read: 被修改的 Skill/Rule 文件（了解现状）
Step 1.5 Read: _内部总控/认知结构/L1_系统性文档/系统架构思维维度/Skill体系设计原则_v1.0.md
→ 重点阅读：§4.3.5「认知根原则」，确认本次修改有认知根支撑
→ 带着以下问题进入 Step 2：「本次修改是否与该 Skill 的认知根一致？
是否会让这个 Skill 更难追溯到认知结构？」
Step 2 Read: 相关联的 Skill/Rule（检查是否有冲突风险）
→ 如果改测试工程师 Skill，要读 role-menu.mdc
→ 如果改 role-menu.mdc，要读所有被引用的 Skill
Step 3 回答「修改前三问」，写在修改记录里
Step 4 执行修改（见操作规范）
Step 5 执行闭环验证（见验证规范）
Step 6 写修改记录（见留痕规范）
只改需要改的，不顺手改其他。
✅ 允许：针对具体问题修改对应章节
✅ 允许：新增一个新章节/新条目
✅ 允许：删除一个被验证无效或有害的规则
❌ 禁止：「顺手」重新整理整个文件的格式
❌ 禁止：一次修改超过 3 个独立的规则点（拆分成多次修改）
❌ 禁止：在没有根因的情况下「完善」措辞
为什么：每次改动范围越小，出问题时越容易定位根因。
修改任何 Skill/Rule 之前，必须先留痕。
操作（Skill）：
Copy-Item .cursor/skills/[skill-name]/SKILL.md
→ .cursor/skills/[skill-name]/history/SKILL_v旧版_YYYYMMDD.md
操作（Rule）：
Copy-Item .cursor/rules/[rule-name].mdc
→ .cursor/rules/history/[rule-name]_YYYYMMDD.mdc
操作（Agent 子智能体）：
新建 agent → 无需备份（文件不存在）
修改 agent → Copy-Item .cursor/agents/[agent-name].md
→ .cursor/agents/history/[agent-name]_YYYYMMDD.md
没有先留痕就修改 = 无法回滚 = 不允许操作。
Agent 子智能体的特殊规则：
.cursor/agents/ 目录下的 .md 文件与 Skill/Rule 同等重要，修改时遵循相同流程.cursor/agents/history/deprecated/ 目录，并更新索引新规则不能与现有规则产生矛盾。
检查清单：
□ 新规则是否与 role-menu.mdc 中的强制规则冲突？
□ 新规则是否与同一个 Skill 内的其他规则矛盾？
□ 新规则是否假设了其他 Skill 的某个行为，而那个 Skill 没有保证这个行为？
□ **能力独立性检查（2026-03-20 新增）**：
- 本次修改是否在流程层/角色层 Skill 里新增了 API 调用、外部工具调用？
如果是 → 先查 SKILL-INDEX 能力层分类，确认是否已有对应能力层 Skill。
有 → 引用，不嵌入
无 → 先建能力层 Skill，再引用
- 本次修改是否引入了 API Key / 模型名 / Endpoint URL？
如果是 → 必须引用 `_内部总控/凭证/` 配置文件，不得硬编码
□ 如果两个规则都适用，AI 应该遵守哪个？（模糊 = Bug）
有冲突 → 先解决冲突，再写新规则；不能「新旧并存」。
当新建一个 alwaysApply: true Rule 时，必须强制回答以下问题：
□ 这条 Rule 是否包含「AI 应该怎么做」的知识内容（不只是「不能做什么」）？
→ YES：必须同时创建或指向配套 Skill，将正向知识内容放入 Skill
→ NO（纯禁止清单）：只创建 Rule 即可
□ 是否已存在覆盖此领域的 Skill？
→ 已存在：在 Rule 的 Step 2 中引用该 Skill
→ 不存在：必须新建 Skill（Level 2 流程），不允许把知识内容堆在 Rule 里
根因：Rule = 约束层（防违规），Skill = 知识层（怎么做对）。 把知识内容放进 Rule 会导致：
典型场景（触发本检查）：
允许例外（不需要配套 Skill 的 Rule）：
knowledge-integrity-rules（R1-R15 认知护栏）auto-experience-hook（结束时执行固定动作）multi-project-file-guard（防路径混淆）修改 Skill/Rule 后，不能只靠「读起来对」来判断是否有效。必须构造验证场景。
触发条件：修改的 Skill 满足以下任一条件：
cognitive- 开头_内部总控/认知结构/ 目录下的文件强制要求：
sandboxes/认知结构/ 或 sandboxes/Skill体系/），记录现有行为的 Phase 1 预想 + Phase 2 实际_内部总控/skill-system-design/SANDBOX-FORMAT.md 标准格式沙盘精度要求（认知体系适用「最精确、最复杂」标准）：
构造一个如果没有这个规则 AI 会犯错的场景，验证加了规则后 AI 确实行为不同。
示例（验证关卡C 的「AI 自测视角切换」规则）：
场景：AI 刚写完一段代码
预期：AI 应该明确宣告「切换为测试工程师视角」再测试
验证：在对话里触发这个场景，检查 AI 是否按新规则行动
选 1-2 个依赖被修改 Skill 的常见任务，验证它们仍然正常工作。
示例（验证测试工程师 Skill 修改后）：
场景：触发一次正常的关卡C
预期：关卡C 的已有行为（Bug 报告格式、产品偏差分类）不变
验证：走一遍关卡C，确认原有行为没有被破坏
人工读一遍同一 Skill 内所有规则，检查有没有「两条规则都适用但指向不同行为」的情况。
每次修改完成后，必须执行以下两步，缺一不可：
每次修改完成后，在对应 Skill 文件底部追加一条变更记录。
格式：
---
## 变更记录
### YYYY-MM-DD HH:MM — [变更标题]
**根因**：[一句话描述触发本次修改的真实事件]
**修改内容**：
- 新增：[章节/条目名] → [一句话描述内容]
- 修改：[章节/条目名] → [从什么改成了什么]
- 删除：[章节/条目名] → [为什么删除]
**验证结果**：
- 正向验证：[场景] → [结果：通过/未通过]
- 负向验证：[场景] → [结果：通过/未通过]
**已知风险**：[如有，描述可能的副作用及观察方式]
修改任何 Skill 后，必须同步更新 .cursor/skills/skill-index/SKILL-INDEX.md：
操作清单：
□ 找到对应 Skill 在索引中的行
□ 更新版本号（规则见下方）
□ 更新「最近更新」日期为今日
□ 如果本次修复了已知问题，状态改为 ✅ 已验证
□ 在索引底部「变更记录」追加一行：[日期] | [Skill目录名] | v旧→v新 | [修改一句话摘要]
版本号规则：
只有一种情况：紧急修复一个正在造成系统性错误的规则。
允许跳过：版本留痕（可事后补）、闭环验证（可事后补）
不允许跳过：修改前三问（必须回答）、留痕记录（必须写）
本 Skill 是所有其他 Skill 修改的前置条件，优先级高于被修改的 Skill 本身。
即：即使某个 Skill 本身说「可以随时更新」，修改它之前也必须先过本 Skill 的流程。
根因：在修改测试工程师 Skill 时，发现没有任何规范约束「如何修改 Skill」本身。这导致本次修改是在没有留痕、没有验证的情况下进行的——恰好违反了本 Skill 要建立的原则。
修改内容：
验证结果：
已知风险：history/ 目录需要手动创建，首次使用时需要先建目录
根因：建立了 Skill 总索引（SKILL-INDEX.md）和 skill-capture-closure Skill 后，修改规范需要强制要求「每次修改 Skill 必须同步更新索引」，否则索引与实际状态会产生漂移。
修改内容：
验证结果：
已知风险：Step B 的执行依赖 SKILL-INDEX.md 存在。若索引文件被移动，需同步修改本规范中的路径引用
根因：产品框架 Human-Readable + Agent-Operable 原则适用于 Skill 开发，Skill 有两类用户（人类设计者 + AI执行者）。建立 skill-designer Skill 后，修改规范需要在三问之前增加「复杂度级别判断」步骤——Level 1 走原有流程，Level 2+ 先经过 skill-designer 的双视角设计验证流程。
修改内容：
验证结果：
验证状态：🔵 待验证
根因：本次批量新建了 6 个子智能体文件（.cursor/agents/*.md），原规范只覆盖 .cursor/skills/ 和 .cursor/rules/，agents 目录处于规范空白区。需要明确 agent 文件的留痕要求（新建无需备份、修改需备份、废弃需归档）。
修改内容：
验证结果：
已知风险：.cursor/agents/history/deprecated/ 目录需首次使用时手动创建
根因：修改 cognitive-ask Skill 时，只做了非正式验证场景描述，未运行 SANDBOX-FORMAT 两阶段沙盘。用户指出：所有涉及认知体系的 Skill 修改，必须做「最精确、最复杂」的正式沙盘。规范中「闭环验证」一节只要求非正式验证，是结构性漏洞。
修改内容：
验证结果：
根因：Skill体系设计原则_v1.0.md §4.3.5（认知根原则）要求所有 Skill 修改需确认与认知根一致，但 skill-rule-修改规范 在执行时从未读取该 L1 文档（CS-016 沙盘确认）。
修改内容：
备份路径：history/SKILL_v1.5_20260322.md
根因：description 和文件标题只声明覆盖 .cursor/skills/ 和 .cursor/rules/，Agent 文件（.cursor/agents/）未显式纳入。修改 verifier.md/user-simulator.md 等 Agent 时可能不触发本规范，与「认知根原则」和「三型均需规范修改流程」的意图不符。
修改内容：
.cursor/agents/，「Skill 或 Rule 文件」→「Skill / Rule / Agent 文件」# Skill / Rule / Agent 修改规范备份路径：history/SKILL_v1.6_20260322_before_agent-scope.md
验证状态：🔵 待验证（修改 .cursor/agents/ 中任一文件时，此规范应被触发）
根因：2026-03-20 真实事件——创建 frontend-brand-guard.mdc Rule 时，AI 只生成了约束层（Rule），没有自主判断需要同步创建知识层（Skill）。用户不得不主动指出：「应该把所有可复用的内容写到 Skill 里」。根本原因：skill-rule-修改规范 的「修改操作规范」章节只有「最小化原则/版本留痕/规则冲突检查」三条，没有要求检查「新 Rule 是否需要配套 Skill」。
修改内容：
修改操作规范 第 4 条「Rule-Skill 配套完整性检查」alwaysApply: true Rule 时，强制判断是否包含正向知识内容 → 有则必须同时创建或引用配套 Skill验证结果：
knowledge-integrity-rules 类纯元认知 Rule 时，不强制要求 Skill（例外条款覆盖）已知风险：「是否包含正向知识内容」的判断仍依赖 AI 的理解，边界模糊时默认建 Skill（成本低，有益无害）
验证状态：🔵 待验证（下次新建 alwaysApply Rule 时观察）
根因：Skill 只有机械步骤，没有指向背景概念文档。AI 执行时不理解 Rule/Skill/Agent 三型本质及设计原则来源（连接缺口）。
修改内容：
验证状态：🔵 待验证
备份路径：history/SKILL_v1.6_20260323_before_nav.md