aodw-skill 0.7.18 → 0.7.22

package/docs/frontend-guidelines.md

@@ -1,266 +0,0 @@
-当“前端圣经”用的规范文档。
-内容包括：
-	•	用什么工具约束代码质量 & 目录结构
-	•	适配你现有栈（React 19 + TS + Vite + Tailwind + Radix + Zustand）
-	•	带目录结构、命名、代码风格 & AI 使用规则
-
-前端开发规范（面向 AI & 人类开发者）
-
-适用项目技术栈：
-	•	框架：React 18/19 + TypeScript + Vite
-	•	UI：Tailwind CSS + Radix UI + 自定义组件库
-	•	状态：Zustand
-	•	工具：ESLint + Prettier
-	•	使用场景：人类开发 + AI 工具（Cursor、Claude Code 等）
-
-⸻
-
-1. 工具与质量控制
-
-1.1 代码质量工具
-	•	ESLint：统一代码风格 & 代码质量
-	•	规则推荐：
-	•	@typescript-eslint（TS 规则）
-	•	eslint-plugin-react
-	•	eslint-plugin-react-hooks
-	•	eslint-plugin-import
-	•	eslint-plugin-jsx-a11y
-	•	eslint-plugin-tailwindcss（可选，用于 Tailwind 排序&校验）
-	•	Prettier：负责代码格式化（缩进、引号、分号等）
-	•	与 ESLint 配合使用：eslint-config-prettier 关闭 ESLint 中跟格式冲突的规则
-
-1.2 目录 / 分层相关工具（可选但推荐）
-	•	使用 TypeScript path alias + ESLint import 规则 管理模块边界：
-	•	paths：
-	•	@app/* → src/app/*
-	•	@pages/* → src/pages/*
-	•	@features/* → src/features/*
-	•	@shared/* → src/shared/*
-	•	配合 eslint-plugin-import 限制：
-	•	pages 只能从 features / shared 引用
-	•	features 不能直接引用其他 features 的内部实现（只能走公共入口）
-
-说明：
-目录结构本身没有“专门 lint 工具”，通常是通过
-约定好的目录 + import 规则 + path alias 来间接约束。
-
-1.3 文件大小 & 复杂度约束（ESLint）
-建议在 ESLint 中统一限制（给 AI 也要强调）：
-	•	单文件最大行数：
-	•	页面级组件：≤ 300 行（推荐 ≤ 250 行）
-	•	其他组件 / hooks / store：≤ 200 行
-	•	单个函数最大行数：≤ 60 行
-	•	复杂度控制：
-	•	complexity ≤ 10
-
-⸻
-
-2. 目录结构规范
-
-2.1 顶层结构
-frontend/
-  src/
-    app/                 # 应用入口、路由、全局 Provider
-    pages/               # 页面级（路由入口）
-    features/            # 可复用业务模块（跨页面）
-    shared/              # 跨业务通用：组件/工具/类型
-    config/              # 配置、环境相关
-    styles/              # 全局样式
-    assets/              # 静态资源
-
-2.2 详细结构说明
-src/
-  app/
-    router/              # 路由定义
-    providers/           # 全局 Provider（主题、QueryClient 等）
-    layout/              # 顶层布局（如 AppShell）
-  
-  pages/
-    ProjectEditorPage/
-      index.tsx          # 页面入口（路由组件）
-      Header.tsx
-      Sidebar.tsx
-      Canvas.tsx
-      Inspector.tsx
-      modals/
-        NodeCreateModal.tsx
-        NodeDeleteConfirmModal.tsx
-      hooks/
-        useProjectEditorData.ts
-        useProjectSelection.ts
-      store/
-        projectEditor.store.ts
-
-    ProjectListPage/
-      index.tsx
-      ...                # 结构类似，不展开
-
-  features/
-    project/
-      components/        # 项目相关可复用组件
-      hooks/             # 项目相关可复用 hooks
-      store/             # 项目相关 store（全局/跨页面）
-      api/               # 与项目相关的 API 封装
-
-    user/
-      components/
-      hooks/
-      store/
-      api/
-
-  shared/
-    components/          # 通用组件：Button、Card、Table、Dialog 等
-    hooks/               # 通用 hooks：useDebounce、useResizeObserver 等
-    store/               # 通用全局状态
-    utils/               # 工具函数：日期、格式化、日志
-    types/               # 通用类型/接口声明（如 PaginatedResult 等)
-
-  config/
-    env.ts               # 环境变量读取封装
-    apiClient.ts         # axios / fetch 封装
-
-  styles/
-    globals.css
-    tailwind.css
-
-规则：
-	•	pages/：按路由拆目录，每个页面一个文件夹。
-	•	features/：按业务域拆目录（project、user、auth…）。
-	•	shared/：只能依赖 shared 自身，不依赖 pages 或 features。
-	•	pages 可以依赖 features & shared；
-features 可以依赖 shared，但尽量不要彼此深度耦合。
-
-⸻
-
-3. 命名规范
-
-3.1 文件命名
-	•	React 组件文件：帕斯卡命名（大驼峰）
-	•	ProjectEditorPage/index.tsx
-	•	Header.tsx, ProjectTable.tsx
-	•	hooks 文件：useXxx.ts
-	•	useProjectEditorData.ts
-	•	useProjectSelection.ts
-	•	Zustand store：
-	•	xxx.store.ts（如 projectEditor.store.ts）
-	•	类型声明：
-	•	xxx.types.ts 或集中放在 shared/types 中
-	•	工具函数：
-	•	xxx.utils.ts 或放在 shared/utils 下
-
-3.2 组件 & 变量命名
-	•	组件：PascalCase
-	•	变量 / 函数：camelCase
-	•	常量：SCREAMING_SNAKE_CASE
-	•	hooks：以 use 开头，返回 [state, actions] 或对象
-
-⸻
-
-4. TypeScript 规范
-	•	启用严格模式："strict": true
-	•	禁止滥用 any：
-	•	使用 unknown + 类型收窄 或 合理定义接口
-	•	API 层优先使用：
-	•	DTO 类型（请求）
-	•	Response 类型（响应）
-	•	类型命名：
-	•	接口 / 类型：Project, ProjectDetail, UserProfile
-	•	不建议 IProject 这种前缀
-
-⸻
-
-5. React 编码规范
-
-5.1 组件类型
-	•	优先使用函数组件 + Hooks：
-	•	不使用 class 组件
-	•	每个文件聚焦一个主要组件：
-	•	如果一个文件内存在多个复杂组件 → 拆文件
-
-5.2 状态管理策略
-	•	页面局部状态：useState / useReducer
-	•	页面内复杂状态：页面专用 hooks/ + store/（Zustand）
-	•	跨页面共享业务状态：放在 features/*/store
-	•	全局通用状态：放在 shared/store
-
-原则：能局部就不全局，能 hook 就不 store。
-
-5.3 副作用 & 数据请求
-	•	所有数据请求封装在：
-	•	features/*/api
-	•	或页面专用 hooks：pages/*/hooks
-	•	不在组件中直接调用 fetch/axios
-→ 统一用 apiClient / 封装方法。
-
-⸻
-
-6. Tailwind & Radix 使用规范
-
-6.1 Tailwind
-	•	使用 className 写原子类，尽量保持每个组件的 className 长度可读；
-	•	复杂样式组合抽离到：
-	•	cn() 帮助函数结合条件类
-	•	或封装为组件，例如 <PrimaryButton />
-	•	不在逻辑代码里到处写硬编码颜色，优先用设计系统中的 token（在 Tailwind config 中定义）。
-
-6.2 Radix UI
-	•	Radix 组件作为“基础交互组件”，在 shared/components 中封装：
-	•	例如 Dialog、Popover、DropdownMenu 封装为：
-	•	SharedDialog.tsx
-	•	DropdownMenu.tsx
-	•	页面或业务组件不直接大量拼 Radix 基础元素，而是复用封装后的组件。
-
-⸻
-
-7. AI（Cursor / Claude 等）使用规则
-
-本节是专门给 AI 的“硬约束”，建议原封不动写进系统提示。
-
-7.1 基本要求
-AI 在本项目中写前端代码时必须遵守：
-	1.	目录与分层：
-	•	新页面 → 必须放到 src/pages/<PageName>/ 下；
-	•	可复用业务逻辑 → 放到对应 src/features/<domain>/ 下；
-	•	通用组件 / hooks / 工具 → 放到 src/shared/ 下；
-	•	不允许把所有代码都写在一个目录或一个文件里。
-	2.	文件大小：
-	•	页面入口组件（index.tsx）≤ 300 行；
-	•	普通组件 / hooks / store 文件 ≤ 200 行；
-	•	单个函数 ≤ 60 行；
-	•	如果一个功能实现会超过限制：
-	•	必须先设计拆分方案（组件 / hooks / store 列表）
-	•	再按文件逐步实现，而不是一次性生成巨型文件。
-	3.	实现流程：
-	•	第一步：先给出【目录与文件拆分方案】，解释每个文件的职责；
-	•	第二步：按“每次一个文件”的方式生成代码；
-	•	第三步：在已有大文件重构时，优先拆分成多个小文件，而不是继续追加代码。
-	4.	代码风格：
-	•	使用函数组件 + Hooks；
-	•	使用 TypeScript，类型尽量完整；
-	•	遁守 ESLint / Prettier 风格（缩进、分号、引号不需要显式指定，但生成的代码要保证能通过常规规则）。
-
-7.2 典型 AI Prompt 模板（示例）
-用于新页面开发：
-
-技术栈：React + TS + Vite + Tailwind + Radix + Zustand。
-目录结构与命名请严格遵守本项目的前端规范。
-目标：实现【XXX 页面】。
-
-步骤 1：先只输出该页面对应的目录和文件拆分方案，目标是：
-	•	页面入口：src/pages/<PageName>/index.tsx
-	•	拆分独立的子组件、hooks、store，确保：
-	•	页面入口文件行数 ≤ 300 行；
-	•	其他文件 ≤ 200 行；
-	•	单个函数 ≤ 60 行。
-
-步骤 2：在我确认拆分方案后，再逐个文件实现，每次只输出一个文件的完整代码。
-
-⸻
-
-8. 测试 & 可维护性（可选扩展）
-
-如果后面增加测试，可以约定：
-	•	所有关键组件 / hooks 都有对应测试文件：
-	•	ComponentName.test.tsx
-	•	useHookName.test.ts
-	•	测试文件放在同级目录或 __tests__ 子目录中。

package/docs/installation-variants.md

@@ -1,88 +0,0 @@
-# AODW 双版本安装方案
-
-本方案用于同时支持 legacy 与 next 两条路线，并确保互不影响。
-
-## 1. 安装目标
-
-- legacy：保持现有稳定方案
-- next：引入三层架构优化（manifest + workflow-guide + summaries）
-- 两套安装可并行存在，互不覆盖
-
-## 2. 安装命令
-
-### 2.1 legacy（稳定版）
-
-```bash
-npx aodw init
-```
-
-更新：
-```bash
-npx aodw update
-```
-
-卸载：
-```bash
-npx aodw uninstall
-```
-
-### 2.2 next（新方案线）
-
-```bash
-npx aodw-skill init
-```
-
-更新：
-```bash
-npx aodw-skill update
-```
-
-卸载：
-```bash
-npx aodw-skill uninstall
-```
-
-## 3. 安装路径与隔离
-
-### 3.1 legacy 目录
-
-- `.aodw/`  
-- 保持与现有 CLI 完全一致
-
-### 3.2 next 目录
-
-- `.aodw-next/`  
-- 不与 legacy 共享目录或文件
-
-## 4. 适配器隔离原则
-
-- legacy 继续写入原有适配器路径
-- next 使用独立适配器路径（避免覆盖）
-
-示例约定：
-- legacy：`.aodw/` + `AODW_Adapters/`
-- next：`.aodw-next/` + 独立命名文件（如 `aodw-next.mdc`）
-
-适配器文件命名示例（next）：
-- Cursor：`.cursor/rules/aodw-next.mdc`
-- Claude：`.claude/CLAUDE-NEXT.md`
-- Antigravity/Gemini：`.agent/rules/aodw-next*.md`
-- Gemini：`.gemini/GEMINI-NEXT.md`
-
-## 5. 并行使用策略
-
-1. legacy 线用于稳定生产项目
-2. next 线用于试验与新用户
-3. 两者升级互不影响
-
-## 6. 兼容性说明
-
-- 不强制依赖 Skills
-- 保持多平台可用性（Cursor / Claude / Gemini 等）
-
-## 7. 维护者打包说明
-
-- 发布脚本会根据当前分支自动选择渠道：legacy / next
-- `release/next` 或 `*-next*` 分支将发布 `aodw-skill`
-- 其他分支默认发布 `aodw`
-- next 渠道使用独立模板目录：`templates/.aodw-next`、`templates/AODW_Adapters_next`、`templates/docs-next`

package/docs/migration-guide-0.2.0.md

@@ -1,250 +0,0 @@
-# AODW 适配器重构 - 迁移指南
-
-**版本**: 0.1.x → 0.2.0  
-**发布日期**: 2025-12-06
-
----
-
-## 概述
-
-AODW 0.2.0 版本对 Antigravity 平台的适配器规则进行了重构，简化了命令结构，提升了可用性。
-
-### 主要变更
-
-- ✅ 规则数量从 16 个精简为 11 个（用户可见 9 个）
-- ✅ 按 RT 生命周期阶段重新组织命令
-- ✅ 排除维护者专用命令（不会分发到用户项目）
-- ✅ 符合"薄适配器"设计原则
-
----
-
-## 命令对照表
-
-### 旧版本 → 新版本 (v0.2.0)
-
-| 旧命令                                        | 新命令            | 变化说明                      |
-| --------------------------------------------- | ----------------- | ----------------------------- |
-| `/aodw-new`                                   | `/aodw-intake`    | 重命名，更符合立项流程语义    |
-| `/aodw-lite` + `/aodw-full` + `/aodw-upgrade` | `/aodw-decide`    | **合并**为一个决策命令        |
-| `/aodw-impact` + `/aodw-invariants`           | `/aodw-analyze`   | **合并**为分析阶段命令        |
-| `/aodw-tests` + `/aodw-module`                | `/aodw-implement` | **合并**为实现阶段命令        |
-| `/aodw-check`                                 | `/aodw-verify`    | 重命名，更清晰                |
-| `/aodw-done`                                  | `/aodw-complete`  | 重命名，更清晰                |
-| `/aodw-pause` + `/aodw-resume`                | `/aodw-control`   | **合并**为流程控制命令        |
-| `/aodw-open`                                  | `/aodw-open`      | **保持不变**                  |
-| `/aodw`                                       | `/aodw`           | **保持不变**（Kernel Loader） |
-
-### 移除的命令（仅维护者可见）
-
-| 命令               | 说明          | 影响                                          |
-| ------------------ | ------------- | --------------------------------------------- |
-| `/aodw-governance` | AODW 治理检查 | 不再分发给用户，仅在 AODW 仓库中使用          |
-| `/aodw-init`       | 初始化 AODW   | CLI (`npx create-aodw init`) 已处理，无需手动 |
-
----
-
-## 迁移步骤
-
-### 对于新用户
-
-无需任何操作，直接使用新版本即可：
-
-```bash
-npx create-aodw init
-```
-
-### 对于现有用户
-
-#### 选项 1：更新到最新版本
-
-```bash
-# 更新 AODW（会覆盖现有 .agent/rules 和 .agent/workflows）
-npx create-aodw init
-```
-
-**注意**：如果你自定义了规则文件，请先备份。
-
-#### 选项 2：继续使用旧版本
-
-如果你已经习惯了旧命令，可以继续使用 v3.1.0：
-
-```bash
-# 不运行 init 命令，保持现有配置
-```
-
-但建议尽快迁移到新版本，以获得更好的体验。
-
----
-
-## 新命令使用指南
-
-### 1. `/aodw-intake` - 创建新 RT
-
-**用途**: 替代原 `/aodw-new`
-
-**使用场景**:
-- 创建新功能
-- 修复 Bug
-- 性能优化
-- 代码重构
-
-**示例**:
-```
-你: "创建一个新RT，我想添加用户登录功能"
-AI: (自动运行 /aodw-intake)
-```
-
-### 2. `/aodw-decide` - 选择开发模式
-
-**用途**: 替代原 `/aodw-lite`, `/aodw-full`, `/aodw-upgrade`
-
-**使用场景**:
-- 选择 Spec-Full 或 Spec-Lite
-- 从 Spec-Lite 升级到 Spec-Full
-
-**示例**:
-```
-你: "这个改动比较复杂，用 Spec-Full"
-AI: (自动运行 /aodw-decide，选择 Spec-Full)
-```
-
-### 3. `/aodw-analyze` - 分析阶段
-
-**用途**: 替代原 `/aodw-impact`, `/aodw-invariants`
-
-**使用场景**:
-- 分析影响范围
-- 确定不变量
-
-**示例**:
-```
-你: "分析一下这个改动的影响"
-AI: (自动运行 /aodw-analyze，更新 impact.md 和 invariants.md)
-```
-
-### 4. `/aodw-implement` - 实现阶段
-
-**用途**: 替代原 `/aodw-tests`, `/aodw-module`
-
-**使用场景**:
-- 更新测试计划
-- 更新模块文档
-
-**示例**:
-```
-你: "代码写完了，更新一下测试和文档"
-AI: (自动运行 /aodw-implement)
-```
-
-### 5. `/aodw-verify` - 验证阶段
-
-**用途**: 替代原 `/aodw-check`
-
-**使用场景**:
-- 检查 RT 一致性
-- 验证文档与代码匹配
-
-**示例**:
-```
-你: "检查一下文档和代码是否一致"
-AI: (自动运行 /aodw-verify)
-```
-
-### 6. `/aodw-complete` - 完成 RT
-
-**用途**: 替代原 `/aodw-done`
-
-**使用场景**:
-- 合并代码
-- 完成 RT
-- 知识蒸馏
-
-**示例**:
-```
-你: "完成这个 RT"
-AI: (自动运行 /aodw-complete，合并分支)
-```
-
-### 7. `/aodw-control` - 流程控制
-
-**用途**: 替代原 `/aodw-pause`, `/aodw-resume`
-
-**使用场景**:
-- 暂停 AODW 流程
-- 恢复 AODW 流程
-
-**示例**:
-```
-你: "暂停一下 AODW"
-AI: (自动运行 /aodw-control，暂停流程)
-
-你: "继续 AODW"
-AI: (自动运行 /aodw-control，恢复流程)
-```
-
----
-
-## 常见问题 (FAQ)
-
-### Q1: 为什么要合并命令？
-
-**A**: 为了减少认知负担。原有 16 个命令过多，新版按 RT 生命周期阶段组织为 9 个，更易理解和使用。
-
-### Q2: 旧命令还能用吗？
-
-**A**: 旧命令已被移除。但新命令功能完全覆盖旧命令，只是名称和组织方式变化。
-
-### Q3: 我自定义了规则，升级会覆盖吗？
-
-**A**: 是的。如果你自定义了 `.agent/rules/` 下的文件，升级前请备份。
-
-### Q4: 新版本有什么好处？
-
-**A**: 
-- ✅ 命令更少，更易记
-- ✅ 符合 RT 工作流，更直观
-- ✅ 遵循薄适配器原则，更简洁
-- ✅ 排除维护者命令，更专注
-
-### Q5: 如何回退到旧版本？
-
-**A**: 
-```bash
-# 删除当前配置
-rm -rf .agent
-
-# 从备份恢复（如果有）
-cp -r .agent.backup .agent
-```
-
----
-
-## 技术细节
-
-### 薄适配器原则
-
-新版本严格遵循"薄适配器"设计原则：
-- 规则文件简洁（平均 367 字节）
-- 不重复核心规范内容
-- 通过引用指向详细文档
-
-### 三层架构
-
-```
-Layer 1 (.aodw/)          → 详细规则说明
-Layer 2 (.agent/rules/)   → 简洁触发器
-Layer 3 (global_workflows/) → 具体操作步骤
-```
-
-每层职责清晰，避免重复。
-
----
-
-## 获取帮助
-
-如有问题，请查看：
-- AODW 文档: `.aodw/README.md`
-- 实施计划: `docs/aodw-adapter-refactoring-plan.md`
-- 架构分析: `docs/aodw-rules-structure-analysis.md`
-
-或联系 AODW 维护者。

package/docs/platform-matrix.md

@@ -1,83 +0,0 @@
-# AODW 平台适配矩阵 (Platform Support Matrix)
-
-本文档详细定义了 AODW 在各个 AI 开发平台上的适配规范，是 CLI 实现的**唯一真理来源 (Single Source of Truth)**。
-重点明确了 **Frontmatter 配置**，以确保规则在各种环境下都能被稳定触发和执行。
-
-## 1. 核心概念
-
-*   **Scope (范围)**:
-    *   **Project**: 仅对当前项目生效。
-    *   **Global**: 对当前用户的所有项目生效。
-*   **Capability (能力)**:
-    *   **Rules**: 被动上下文规则 (System Prompt / Context)。
-    *   **Commands**: 主动触发的工作流 (Slash Commands)。
-
----
-
-## 2. Antigravity (Google)
-
-Antigravity 依赖 **Intent Classification** (意图识别) 来动态加载规则。
-
-| Scope                | Capability   | Path                         | Frontmatter Specification (必须严格遵守)                                                                                           |
-| :------------------- | :----------- | :--------------------------- | :--------------------------------------------------------------------------------------------------------------------------------- |
-| **Project & Global** | **Rules**    | `.agent/rules/aodw-*.md`     | ```yaml<br>---<br>trigger: model_decision<br>---<br>```<br>**说明**: `model_decision` 允许模型根据用户输入自动判断是否加载此规则。 |
-| **Project & Global** | **Commands** | `.agent/workflows/aodw-*.md` | ```yaml<br>---<br>description: [简短描述]<br>---<br>```<br>**说明**: `description` 用于帮助用户和模型理解此工作流的功能。          |
-
----
-
-## 3. Cursor (Anysphere)
-
-Cursor 依赖 `.mdc` 文件中的 `globs` 和 `alwaysApply` 字段来决定规则的生效范围。
-
-| Scope                | Capability   | Path                     | Frontmatter Specification (必须严格遵守)                                                                                                                                                                                                            |
-| :------------------- | :----------- | :----------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Project & Global** | **Rules**    | `.cursor/rules/aodw.mdc` | ```yaml<br>---<br>description: AODW Core Framework<br>globs: *<br>alwaysApply: true<br>---<br>```<br>**说明**: <br>1. `globs: *`: AODW 是底层框架，必须匹配所有文件。<br>2. `alwaysApply: true`: 必须始终激活，防止 AI 在未加载规则时生成违规代码。 |
-| **Project & Global** | **Commands** | `.cursor/commands/*.md`  | *Standard Markdown (No Frontmatter required)*<br>**说明**: Cursor 自动识别 `.cursor/commands/` 下的所有 `.md` 文件为 Slash Commands。                                                                                                               |
-
----
-
-## 4. Claude (Anthropic)
-
-Claude Code 主要依赖文件路径和内容结构，对 Frontmatter 依赖较少。
-
-| Scope                | Capability   | Path                    | Frontmatter Specification                                                                           |
-| :------------------- | :----------- | :---------------------- | :-------------------------------------------------------------------------------------------------- |
-| **Project & Global** | **Rules**    | `CLAUDE.md`             | *Standard Markdown*<br>**说明**: 文件内容必须包含明确的章节结构 (如 `# AODW Rules`, `# Commands`)。 |
-| **Project & Global** | **Commands** | `.claude/commands/*.md` | *Standard Markdown*<br>**说明**: 文件名即命令名。支持 `$ARGUMENTS` 占位符。                         |
-
----
-
-## 5. GitHub Copilot (Microsoft)
-
-Copilot 对 Prompt 文件有严格的元数据要求，否则可能无法正确执行或使用错误的模型。
-
-| Scope       | Capability         | Path                              | Frontmatter Specification (必须严格遵守)                                                                                                                                                                                   |
-| :---------- | :----------------- | :-------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **Project** | **Rules**          | `.github/copilot-instructions.md` | *Standard Markdown*<br>**说明**: 作为 System Prompt 注入，无特殊 Frontmatter。                                                                                                                                             |
-| **Project** | **Commands**       | `.github/prompts/*.prompt.md`     | ```yaml<br>---<br>model: gpt-4o<br>mode: chat<br>description: [简短描述]<br>---<br>```<br>**说明**: <br>1. `model: gpt-4o`: 强制使用高智商模型，确保复杂工作流 (Spec/Plan) 的执行质量。<br>2. `mode: chat`: 指定交互模式。 |
-| **Global**  | **Rules/Commands** | *Manual Config*                   | *N/A (CLI 暂不自动处理)*                                                                                                                                                                                                   |
-
----
-
-## 6. CLI 实现检查清单
-
-CLI 的 `FileProcessor` 必须在写入文件前执行以下 **Frontmatter 注入/校验逻辑**：
-
-1.  **Cursor Processor**:
-    *   目标文件: `*.mdc`
-    *   检查: 是否存在 `alwaysApply: true` 和 `globs: *`。
-    *   动作: 如果缺失或值为 `false`，强制覆盖为 `true` 和 `*`。
-
-2.  **Antigravity Processor**:
-    *   目标文件: `.agent/rules/*.md`
-    *   检查: 是否存在 `trigger: model_decision`。
-    *   动作: 如果缺失，强制注入。
-
-3.  **Copilot Processor**:
-    *   目标文件: `.github/prompts/*.prompt.md`
-    *   检查: 是否存在 `model` 和 `mode`。
-    *   动作: 强制注入 `model: gpt-4o` 和 `mode: chat`。
-
-4.  **Common**:
-    *   确保所有生成的 Markdown 文件都是 UTF-8 编码。
-    *   确保目录结构存在 (`mkdir -p`)。