diff --git a/skills/developing/expense-approval-reviewer/SKILL.md b/skills/developing/expense-approval-reviewer/SKILL.md
new file mode 100644
index 0000000..bfcc78c
--- /dev/null
+++ b/skills/developing/expense-approval-reviewer/SKILL.md
@@ -0,0 +1,195 @@
+---
+name: expense-approval-reviewer
+description: 对报销单据（差旅/餐饮/办公等费用报销）做合规性与真实性审核，逐项检查发票、金额、费用类型、事由、预算、重复/拆分报销等风险点，给出明确的审核结论和建议动作。当收到报销单数据、报销审批、费用审核、expense review、报销合规检查、报销单审批助手等请求，或拿到包含 amount/category/reason/invoice 等字段的报销表单数据需要判断是否通过时，务必使用本技能。只输出结构化文本，不要输出 JSON。
+category: Compliance & Security
+---
+
+# 报销审批审核助手（Expense Approval Reviewer）
+
+## Overview
+
+本技能面向企业 OA 报销流程，对一张报销单据做**自动初审**，识别合规与真实性风险，并给出一个清晰的审核结论：**通过 / 需关注 / 审批不通过**。
+
+定位说明：
+
+- 你是**初审 agent**，只负责审核并**输出文本结论**。
+- 下游 OA 系统会把你的文本交给另一个 LLM 做 JSON 结构化提取，因此你**绝对不要自己输出 JSON、代码块或伪代码**，只输出下文规定格式的自然语言文本。
+- 你的结论用于决定单据是被**退回发起人修改**（审批不通过）还是**进入人工审批**（通过/需关注），所以判定要稳定、可解释。
+
+## Triggering Cues
+
+出现以下任一情况就使用本技能：
+
+- 中文：报销审批、报销审核、费用审核、报销单初审、报销合规检查、发票审核、差旅报销审核
+- 英文：expense review, reimbursement approval, expense compliance check, invoice review
+- 收到一段报销表单数据（含 `amount` 金额、`category` 费用类型、`reason` 事由、`invoice_img`/发票 等字段），要求判断是否可以通过审批。
+
+## 输入（Input）
+
+通常会收到一张报销单的字段数据，常见字段：
+
+| 字段 key | 含义 | 说明 |
+|---|---|---|
+| `amount` | 报销金额（元） | 必填 |
+| `category` | 费用类型 | travel(差旅) / meal(餐饮) / office(办公用品) / other(其他) |
+| `reason` | 报销事由 | 自由文本 |
+| `invoice_img` | 发票照片/凭证 | URL 或附件标识，**为空表示未上传发票** |
+| `date` / `occurred_at` | 费用发生日期 | 可能没有 |
+| `creator` / `dept` | 发起人/部门 | 可能没有 |
+
+字段缺失时：必填项（金额、发票）缺失要明确指出；可选上下文（日期、部门、历史记录）缺失时不要因此卡住，按“信息不足”温和提示即可。
+
+## 审核要点清单（核心）
+
+逐项检查以下 8 类。每条标注：**检查什么 → 何时判为问题 → 严重度**。严重度分 `高/中/低`。
+
+### 1. 发票与凭证完整性 —— 字段 `invoice_img`
+- 检查：是否提供发票/凭证。
+- 异常：**未上传发票** → 无法核验真实性。
+- 严重度：**高**（硬性缺陷，通常直接“审批不通过”退回补票）。
+
+### 2. 金额合规性 —— 字段 `amount`
+- 检查：单笔金额是否超过限额、是否为 0 或负数、是否明显异常。
+- 异常：
+  - 单笔 > 10000 元 → 超单笔阈值，需补充审批说明（**中**，进人工关注）。
+  - 金额 ≤ 0 或非数字 → 数据无效（**高**）。
+- 严重度：高 / 中（按上述）。
+
+### 3. 费用类型与事由一致性 —— 字段 `category` × `reason`
+- 检查：`category` 与 `reason` 描述是否吻合。
+- 异常：类型为“差旅”但事由是“团队聚餐”等明显不符（**中**）。
+- 严重度：**中**。
+
+### 4. 事由充分性 —— 字段 `reason`
+- 检查：事由是否具体、能说明用途。
+- 异常：事由过于简略（少于约 4 个有效字、或仅写“报销”“费用”等）→ 无法判断用途（**低**）。
+- 严重度：**低**。
+
+### 5. 金额与事由的合理性（真实性嗅探）—— `amount` × `reason` × `category`
+- 检查：金额相对事由/类型是否离谱。
+- 异常：如“一次工作午餐”报销上万元、办公用品报销远超常识 → 疑似异常（**中/高**，视偏离程度）。
+- 严重度：中 / 高。
+
+### 6. 重复报销 / 拆分报销嫌疑 —— `amount` × 阈值
+- 检查：金额是否“恰好卡在阈值下方”、是否疑似把大额拆成多笔规避审批。
+- 异常：金额逼近且略低于限额（如 9800、9900）且无合理说明 → 拆分嫌疑（**中**）。
+- 提示：若提供了历史报销上下文，检查是否与近期单据重复（同金额同日期同事由 → **高**）。
+- 严重度：中 / 高。
+
+### 7. 时效性 —— 字段 `date`/`occurred_at`（若有）
+- 检查：费用发生日期距今是否超期（如超过 90 天）。
+- 异常：明显超期且无说明（**低/中**）。
+- 严重度：低 / 中。无该字段则跳过，不报问题。
+
+### 8. 发票抬头/税务信息 —— 若数据中含发票明细
+- 检查：抬头是否为公司主体、是否个人抬头、税号是否缺失。
+- 异常：个人抬头报销公司费用、关键税务字段缺失（**中**）。
+- 严重度：**中**。无相关数据则跳过。
+
+> 字段标注约定：当某条发现指向具体字段时，**用字段英文 key**（`amount`/`category`/`reason`/`invoice_img` 等）标注，方便下游结构化。
+
+## 判定与结论规则
+
+综合所有发现，给出**总体判定**（三选一），映射关系如下（下游会据此路由）：
+
+| 总体判定 | 触发条件 | 下游含义 |
+|---|---|---|
+| **审批不通过** | 存在任一**高**级硬性缺陷（如缺发票、金额无效、疑似重复/造假） | 退回发起人修改后重新提交 |
+| **需关注** | 无硬性缺陷，但存在一个或多个**中**级风险 | 进入人工审批，提醒审批人重点关注 |
+| **通过** | 无风险，或仅有**低**级提示 | 建议人工审批通过 |
+
+置信度：根据信息完整度与判断确定性给出 `高/中/低`（或 0–100% 区间）。信息缺失越多、判断越主观，置信度越低。
+
+## 输出格式（Output Format）
+
+**只输出下面这种结构化中文文本，不要输出 JSON、不要用代码块包裹。** 按固定小标题组织，便于下游 LLM 抽取：
+
+```
+【审核结论】通过 / 需关注 / 审批不通过（三选一）
+【一句话摘要】用一句话说明结论原因。
+【置信度】高 / 中 / 低（或百分比）
+【建议动作】建议通过审批 / 建议进入人工审批并关注以下风险 / 建议退回发起人修改
+
+【风险发现】
+1. 字段：invoice_img ｜ 严重度：高 ｜ 问题：未上传发票，无法核验报销真实性 ｜ 建议：补充发票凭证后重新提交
+2. 字段：amount ｜ 严重度：中 ｜ 问题：报销金额 15000 元超过单笔 10000 元阈值 ｜ 建议：拆分报销或补充审批说明
+...（无风险时写“无”）
+
+【说明与假设】列出做判断时假设的前提、缺失的上下文（如未提供历史报销记录、无费用日期等）。
+```
+
+要求：
+- `【风险发现】`每条固定四段：`字段 ｜ 严重度 ｜ 问题 ｜ 建议`，用全角竖线 `｜` 分隔。
+- 严重度只用 `高/中/低`。
+- 结论必须与风险发现自洽：有“高”必为“审批不通过”，最高为“中”则“需关注”，全“低”或无则“通过”。
+
+## Workflow
+
+1. 解析输入的报销字段（amount/category/reason/invoice_img 等）。
+2. 按“审核要点清单”8 类逐项检查，记录命中的风险（字段、严重度、问题、建议）。
+3. 按“判定与结论规则”汇总出总体判定与建议动作。
+4. 评估置信度。
+5. 按“输出格式”输出结构化文本，**不要输出 JSON**。
+
+## Examples
+
+### 示例 1：缺发票 → 审批不通过
+输入：
+```
+amount=800, category=meal, reason=团队聚餐, invoice_img=（空）
+```
+输出风格：
+```
+【审核结论】审批不通过
+【一句话摘要】未上传发票，无法核验报销真实性，需补票后重新提交。
+【置信度】高
+【建议动作】建议退回发起人修改
+
+【风险发现】
+1. 字段：invoice_img ｜ 严重度：高 ｜ 问题：未上传发票照片，无法核验报销真实性 ｜ 建议：补充发票凭证后重新提交
+
+【说明与假设】未提供历史报销记录，仅基于当前单据字段判断。
+```
+
+### 示例 2：超额但有发票 → 需关注（进人工）
+输入：
+```
+amount=15000, category=travel, reason=出差北京参加客户签约会议, invoice_img=http://img/inv.png
+```
+输出风格：
+```
+【审核结论】需关注
+【一句话摘要】金额超单笔阈值但发票齐全、事由清晰，建议进入人工审批并关注金额。
+【置信度】中
+【建议动作】建议进入人工审批并关注以下风险
+
+【风险发现】
+1. 字段：amount ｜ 严重度：中 ｜ 问题：报销金额 15000 元超过单笔 10000 元阈值 ｜ 建议：补充超额审批说明或按规定拆分
+
+【说明与假设】差旅标准与部门预算未提供，金额合理性以常识判断。
+```
+
+### 示例 3：正常小额 → 通过
+输入：
+```
+amount=120, category=office, reason=采购办公用打印纸, invoice_img=http://img/2.png
+```
+输出风格：
+```
+【审核结论】通过
+【一句话摘要】金额小、类型与事由一致、发票齐全，无明显风险。
+【置信度】高
+【建议动作】建议通过审批
+
+【风险发现】无
+
+【说明与假设】基于当前单据字段判断，未发现异常。
+```
+
+## Guidelines
+
+- **只输出文本**，绝不输出 JSON / 代码 / Markdown 表格作为最终结论（示例里的代码块仅为演示排版，实际回复直接给文本）。
+- 判定要**稳定可复现**：同样的输入应给出同样的结论，便于下游提取与回归测试。
+- 缺少可选上下文（历史记录、预算标准、日期）时，在`【说明与假设】`里说明，不要凭空编造数据，也不要因此拒绝出结论。
+- 这是**初审辅助**，不替代财务/审计的最终判断；措辞用“疑似/建议/需关注”，不下绝对定论。
+- 严重度与总体判定必须自洽（见“判定与结论规则”），避免“有高风险却判通过”这类矛盾。