Skill 全景镜（skill-mirror）
> 一句话：把一个 Skill 是什么讲清楚，再据此规范设计、融合、交付新 Skill。
触发场景
- 「这个 Skill 是干什么的？它有哪些功能？」——需要读懂一个已有 Skill
- 「帮我设计一个做 XX 的 Skill」——需要从想法到规范骨架
- 「把这两个 Skill 合并成一个更强的」——需要融合
- 「我要把它上架到 SkillHub」——需要合规自检 + 上架清单
硬边界
- 只做结构解析、设计编排、文档生成、合规自检，不替用户做业务决策
- 不读取私钥/助记词/凭据，不发起网络请求，不执行用户代码
- 信息不足时显式标注「待确认」，绝不编造功能或数据
- 纯静态：所有规则在
references/，可离线运行
三阶段工作流
- 阶段 A（读懂）：对一个已有 Skill 跑功能 1–14，输出能力全景卡
- 阶段 B（设计）：对一个新想法跑功能 16–17，输出规范骨架
- 阶段 C（融合交付）：对两个 Skill 跑功能 18 + 自检，输出完整 Skill C
18 项实际功能（有序，形成合力）
阶段 A：读懂一个 Skill（1–14，识别层）
- 身份识别——提取中文名、英文名(slug)、版本、作者
- 一句话定位——用大白话讲清「它是什么」
- 取名理由解析——还原命名方式（含义/来源/组合逻辑）
- 能力分类——归入创作/分析/开发/效率/金融研究/设计等大类
- 功能清单——列出全部实际功能点并连续编号
- 类比解释——用一个生活例子比喻它（「它是 XX 界的 XX」）
- 输入标准化——它接受什么输入（字段/类型/必填）
- 输出标准化——它产出什么（结构/字段/格式）
- 触发场景——什么时候该用它
- 目标用户——谁最适合用它
- 典型工作流——从输入到输出的标准步骤
- 依赖与前置条件——需要什么环境/数据/权限
- 边界声明 + 风险局限——它明确不做什么、可能出错的情形
- 关系图谱——与同类 Skill 可组合 / 可替代 / 上下游关系
阶段 B：设计一个新 Skill（16–17，处理层）
- 能力全景卡生成——把 1–14 汇总成一张可读卡片（对比/体检/完整度评分）
> 注：编号采用连续 1–18 编排，15 为 A/B 两阶段的汇总枢纽，16–18 为设计交付层，详见 references/merge-rules.md。
- 需求澄清 + 能力定义——把模糊想法拆成目标/用户/场景/能力边界
- 规范骨架生成——目录脚手架 + 命名规范（小写英文+中文名+SLUG）+ frontmatter + 工作流 + 输入输出契约 + 扩展点 + icon 设计指引
阶段 C：融合与交付（18，交付层）
- 融合与自检交付——吸收两个 Skill，按「去重→分层→补齐→排序→统一命名→收敛边界→连续编号→保留扩展点」的规则产出完整 Skill C，并输出上架清单（一级/二级分类、上架文案、可见性）+ 自检报告（中文名/英文名/描述/结构/禁止文件）
融合规则（功能 18 的核心）
| 规则 | 含义 |
|---|---|
| 去重 | 相同功能只保留更强的实现 |
| 分层 | 先「识别/解析」→ 再「处理/生成」→ 最后「输出/交付」 |
| 补齐 | A 缺的能力若 B 有，则补入 C |
| 排序 | 高频基础能力在前，扩展能力在后 |
| 统一命名 | A/B 术语不一致时 C 采用统一命名 |
| 收敛边界 | C 的「不做什么」合并 A 与 B 的边界 |
| 连续编号 | C 的功能从 1 连续编号，≥15 项时分组合并 |
| 保留扩展点 | 规则/数据拆到 references/，保证可复用、可扩展 |
输入输出契约
详见 manifest.json（input_schema / output_schema）与 references/self-check-list.md。
上架清单（提交 SkillHub 时填）
- 中文名：Skill 全景镜
- SLUG：skill-mirror
- 描述文：见本文件顶部
description - 版本号：1.0.0
- 一级分类：开发编程 / 二级分类：AI Skill 设计与文档
- 作者：张郃-开发者 张杨（yznocz）
- 可见性：public
免责声明
本 Skill 仅做结构梳理与上架合规辅助，不构成任何技术或商业建议；最终内容由使用者负责。
