Untitled

---
name: eat
description: |
  消化外部输入（URL/仓库/文档/代码片段）为可持久化的 Agent 上下文资产。
  输入：链接、代码、文档或任务意图。
  输出：落盘到 rules/skills/CLAUDE.md，需用户确认后执行。
  当用户分享技术文章链接、讨论新方法论、提到"记住这个做法"、或说
  "吸收/学习/记录"等意图时应主动使用此 Skill，即使未明确说 /eat。
---

# /eat — 外部知识"消化"技能（可控摄入，防垃圾化）

## 0. 目的与边界
/eat 用于把外部输入（URL、GitHub 仓库、README、技术文档、代码片段、别人的 Skill 目录等）转化为**可持久化、可复用、可审计**的个人上下文资产，最终只落在三处之一：
- 全局总纲类 → 更新 `CLAUDE.md`
- 行为约束类（必须/禁止）→ 写入或更新 `rules/`
- 能力流程类（端到端操作）→ 新建或扩展 `skills/`

/eat 不负责“临时问答”。它是一个**知识吸收与资产化管线**，强调质量、去冗余、可回滚。

## 1. 输入契约（用户提供什么）
用户可以提供以下任意一种或多种输入：
- 链接：文章/博客/文档/PR/issue/推文/网页
- 仓库：GitHub/GitLab 等仓库地址（或压缩包/目录）
- 代码：片段、脚本、配置、Prompt、Skill 目录
- 文档：Markdown、PDF（如环境支持读取）、内部规范文本
- 任务意图：用户希望“吸收”后解决什么问题、用于什么场景（可选但建议）

当用户未提供意图时，/eat 默认以“最大可复用性 + 最小侵入”策略提出方案，并在执行前要求确认。
在可获取输入内容的前提下，不要在产出“消化建议/变更计划”之前反复追问意图；应先按默认策略给出 1~3 个方案，然后只针对“是否落盘写入”做一次确认。

## 2. 产出契约（必须交付什么）
/eat 的标准产出包含两部分：**消化报告（可审阅）** + **落盘修改方案（可执行）**。

### 2.1 消化报告（必须）
报告必须包含以下字段（按顺序）：
1) 输入摘要：输入类型、来源、获取状态、范围（哪些文件/章节/模块）
2) 核心提炼：该输入的“关键思想/方法/流程/约束”是什么（只保留可复用部分）
3) 适用场景：在什么情况下会触发使用；预期收益
4) 影响扫描：将影响哪些现有资产（CLAUDE.md / rules / skills；具体到文件路径）
5) 冲突检测：是否可能与现有规则/技能冲突；如何化解（合并/替换/降级/加优先级说明）
6) 消化建议：选择以下之一或组合（见 3.1）
7) 变更计划：要改哪些文件、每个文件改什么（可审计粒度）
8) 验证方式：如何确认吸收有效（最小验证清单）

### 2.2 落盘修改（必须“先确认后执行”）
/eat 在给出“消化建议 + 变更计划”后，必须等待用户明确确认，才可以实际写入文件系统（除非用户明确授权自动执行）。

## 3. 决策框架：吃成什么形态？

落点选择与防垃圾化规则统一遵循 `rules/context-architecture.md`（§1 三去处、§2 分流决策、§3 防垃圾化硬规则）。此处不重复定义，仅补充 /eat 特有的判断：

### 3.1 /eat 特有的拒绝条件

除 context-architecture.md §3 的通用防垃圾规则外，/eat 额外拒绝：
- 输入不可获取且用户无法提供替代内容：输出阻塞原因与下一步最小动作，不落盘
- 输入质量差/来源不可信/过时明显：先提示风险，不直接落盘
- 与现有资产高冲突且无法给出清晰合并策略：先提出"冲突解法"，不落盘

## 4. 工作流（五步管线）
/eat 必须按以下五步执行，并显式输出每一步的结果：

### Step 1 — 输入识别与获取
- 判别输入类型：文章/仓库/代码/Skill 目录/混合
- 可访问性探测：是否需要登录/验证码/内网权限；若不可访问，必须明确阻塞原因（不要硬猜正文）
- 降级获取策略：优先让用户提供“文章大纲 + 关键段落”；其次让用户粘贴全文或导出为 Markdown/纯文本；再次提供可公开访问镜像链接
- 获取完整内容：若是仓库，优先读 README/关键目录；若是文章，提取结构化要点；若是代码，确定边界与依赖
- 记录“覆盖范围”：读了哪些文件/章节（用于审计）

### Step 2 — 深度分析（多维框架）
对输入进行多维评估，至少包含：
- 价值密度：真正可复用、可迁移的部分是什么？
- 抽象层级：总纲/规则/流程？分别有哪些候选条目？
- 触发条件：将来什么请求会用到它？
- 风险与前置：是否需要权限、凭据、外部系统？是否会引入安全/成本风险？

### Step 3 — 影响扫描（现有资产对齐）
- 扫描现有：`CLAUDE.md`、`rules/`、`skills/`（至少用目录与关键字判断）
- 找到最接近的落点：是否已有同类规则/技能？
- 生成“变更影响表”：新增/修改/替换/废弃候选项

### Step 4 — 消化建议（方案与取舍）
输出 1~3 个可选方案，并说明：
- 方案选择理由（按 3.2 的优先级）
- 对现有资产的改动最小化策略
- 冲突化解方式（合并/覆盖/新增特例/加优先级注释）
- 需要用户确认的点（尤其权限、外部调用、不可逆改动）

### Step 5 — 执行消化（确认后落盘）
用户确认后：
- 写入目标文件（新建或更新）
- 保持改动可审计：尽量小步、清晰注释
- 给出验证清单：如何证明吸收生效（比如下一次触发时应表现为何）
- 若环境启用 git：建议生成一次 commit（由用户或具备权限的流程执行）

## 5. 输出模板（强制格式）
/eat 的输出必须遵循以下结构（不允许省略标题）：

### [Eat] 输入摘要
- 类型：
- 来源：
- 获取状态：
- 覆盖范围：

### [Eat] 核心提炼
- 关键思想：
- 关键方法/流程：
- 关键约束：

### [Eat] 适用场景与触发条件
- 适用场景：
- 触发关键词/信号：

### [Eat] 影响扫描
- 可能影响的资产：
- 可能复用/冲突的条目：

### [Eat] 消化建议（1~3 个方案）
- 方案 A：
- 方案 B（可选）：
- 方案 C（可选）：

### [Eat] 变更计划（文件级）
- 文件 1：路径、修改点
- 文件 2：路径、修改点

### [Eat] 验证方式
- 最小验证清单：

### [Eat] 需要用户确认
- 明确列出需要确认的动作（写文件/改规则/建 Skill/外部调用/成本风险等）

## 6. 兼容与协作约定
- /eat 只负责“消化与落盘”；具体执行自动化（如爬取网页、克隆仓库、运行脚本）应调用其他 Skill 或工具。
- /eat 的核心 KPI：资产可复用性、冲突最小化、仓库整洁度、可审计性。