skill-meta（元技能）Skill 是什么？如何下载安装？

元技能Skill：用一次 /meta 对话，把「想改系统」变成可执行任务

它是什么：skill-meta 是一个「交互式系统构建器」，挂在 /meta 命令后面，负责把「我想给 .claude 系统加个命令/技能/代理」这种模糊想法，转成结构化、可执行的任务。
核心机制：它本身是薄包装器，真正的构建工作交给 meta-builder-agent 子代理完成，自己只负责模式判定、上下文准备、结果校验与后飞行（如创建了任务则做 git 提交）。
三种模式：不带参数进入交互式访谈；带普通文本走提示分析；带 --analyze 走只读系统盘点。
最大差异点：技能内部实现后飞行模式，减少了「技能返回—协调器—再继续」之间的反复提示问题，流程一次跑完。
适合谁：正在用 Claude Code 类工作流维护 .claude/ 目录（命令、技能、代理、任务体系）的开发者与团队。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名叫元技能Skill，英文名 skill-meta，技能 ID 为 12890。「元」的含义是「关于系统本身的系统」——它不直接写业务代码，而是帮你改造和扩展 .claude/ 这套工作环境本身。

它解决什么问题？

在没有这类技能之前，给 .claude/ 增加一个命令、一个技能或一个代理，通常要经历：翻文档看组件该怎么选、照着模板手写文件、自己想清楚任务拆几步、再手动建任务目录和状态文件。整个过程既容易漏步骤，也很难保证格式统一。skill-meta 把这些收敛成一次对话：你描述目标，它判定模式、加载对应指南、产出任务分解，并在需要时把任务落到 specs/ 目录下。

一键安装的思路与步骤

技能详情中并未给出具体的安装命令与下载地址，因此下面给出通用流程，具体命令、入口地址与是否收费请以官方说明为准：

确认安装前提：你已经在使用具备技能（Skill）机制与子代理（Subagent）机制的 AI 编程环境，且项目内存在 .claude/ 目录体系（包含 agents/、skills/、context/ 等结构）。因为该技能需要调用 meta-builder-agent 子代理，子代理不存在时技能无法完成委托。
确认工具权限：该技能声明的允许工具为 Task、Bash、Edit、Read、Write。其中 Task 是调用子代理的关键，缺少它技能会在「调用子代理」这一步失败。
获取并安装：在技能市场 / 技能管理入口中，按技能 ID 12890 或英文名 skill-meta 检索并安装，安装后确认技能文件落到项目的 skills 目录下（具体路径以官方说明为准）。
验证是否生效：最轻量的验证方式是执行 /meta --analyze。如果技能生效，它会进入只读分析模式，返回一份包含命令、技能、代理、活动任务数量的系统盘点结果；如果命令无响应或提示找不到技能，说明安装位置或子代理配置有问题。
再做一次交互式冒烟测试：直接执行 /meta，看是否能进入访谈流程。能进入即代表模式判定、上下文准备、子代理调用的主链路已经打通。

该技能的主要功能和特点

统一入口、三种模式自动分流：没有参数时进入交互式访谈；传入一段普通文本时按提示分析处理；传入 --analyze 时进入只读系统分析。判定逻辑在技能内部完成，用户不需要记多套命令。
7 阶段交互式访谈：交互模式下由子代理通过提问工具引导你完成需求澄清，把「我想要个导出命令」这类模糊诉求，逼问成边界清晰的组件设计。
任务自动落地：非分析模式会创建任务条目，包括 TODO.md、state.json 与任务目录，产物路径形如 specs/430_create_export_command/，后续可以直接被研究、实施、测试等流程接手。
只读分析不产生副作用：--analyze 模式只盘点现状并给建议，不创建任务，适合在动手改造前先摸清家底。
薄包装器 + 内部后飞行：技能本体保持极薄，组件指南由子代理按需加载，避免上下文膨胀；子代理返回后，技能自己完成校验与后飞行操作（如创建了任务则执行 git 提交），再一次性返回，减少「继续」提示的中断感。
标准化的返回契约：返回结构包含 status、summary、artifacts、metadata、next_steps，状态覆盖 tasks_created、analyzed、cancelled、completed、partial、failed、blocked，便于上层流程自动化判断。
明确的错误与超时策略：参数格式错误立即失败；子代理报错原样透传；用户主动取消按「完成」而非「失败」处理；交互会话默认超时 7200 秒，超时返回部分状态。

和普通工具比强在哪？ 普通做法是「让 AI 直接帮我写几个配置文件」，产出物与既有任务体系是割裂的；而这个技能产出的是符合系统既有规范的组件 + 可被流程接续的任务条目，并且自带模式判定、元数据交换和状态回传，属于「接入了工程流程」而不是「生成了一段文本」。

如何使用该技能？

第 1 步：判断你该用哪种模式

还没想清楚要做什么 → 不加参数，走交互式访谈。
已经有一段需求描述 → 直接把描述作为参数传入，走提示分析。
只想看看系统现在长什么样 → 加 --analyze。

第 2 步：交互式模式的具体用法

执行 /meta（不带参数）。技能判定 mode=interactive，随后由子代理通过提问工具逐阶段澄清：你要加的是命令、技能还是代理，命名与触发条件是什么，需要哪些工具权限，验收标准是什么。你只需按提问作答，中途在确认阶段可以反悔。

输入示例（对话式回答，不是命令行参数）：

我想加一个 /export 命令，能把当前任务的产物导出成 Markdown，支持指定输出目录。

第 3 步：提示模式的用法

执行 /meta 为导出功能补一套测试任务。技能判定 mode=prompt 并保留你的原始提示，直接分析请求、给出任务拆解建议，省掉访谈环节，适合需求已经足够明确的情况。

第 4 步：分析模式的用法

执行 /meta --analyze。这是只读操作，artifacts 为空数组，metadata.component_counts 中会给出命令数、技能数、代理数与活动任务数，next_steps 提示你「查看分析并在需要时运行 /meta 创建任务」。

第 5 步：读懂输出

交互/提示模式任务创建成功时，返回的 status 为 tasks_created，summary 是一句不超过约 100 个令牌的摘要，artifacts 数组里每个元素包含 type（如 task）、path（如 specs/430_create_export_command/）与说明，metadata 中包含 session_id、agent_type、delegation_depth、delegation_path、mode、tasks_created。next_steps 会明确告诉你下一步该跑什么，例如「运行 /research 430 以开始第一个任务的研究」。

第 6 步：处理异常返回

看到 cancelled 表示你在确认阶段取消了，未创建任何任务，可以直接重跑；看到 partial 通常是子代理超时，需要收窄需求范围后重试；看到 failed 多半是参数格式或前置配置问题，按返回的摘要排查。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
skill-meta（元技能Skill）	交互式系统构建器，改造 `.claude/` 体系	三模式分流、7 阶段访谈、任务目录与状态文件生成、内部后飞行提交、标准化返回契约	需具备技能与子代理机制、需 `Task` 等工具权限	给工作流新增命令/技能/代理，或对系统做体检	优势：产出直接接入任务流程，规范统一，一次对话走完；不足：依赖 `meta-builder-agent` 子代理，学习「元」概念有门槛
手工维护配置文件	直接照着文档写 `.claude/` 下的文件	完全自定义	零安装，但需要熟悉组件选择、编写规范与目录约定	极简单的一次性改动	优势：无额外依赖，完全可控；不足：易漏步骤、格式易错、不生成任务，无法被后续流程接续
通用对话式 AI 助手	让 AI 直接生成配置内容	生成命令、技能、代理的文本草稿	门槛低，能对话即可	快速拿到一份可改的草稿	优势：上手最快；不足：不了解你的系统现状，常需人工搬运与二次校对，不产出任务与元数据
模板/脚手架式初始化工具	用预设模板批量生成结构	目录与文件模板批量落地	需理解模板变量与目录约定	新项目从零搭建骨架	优势：批量、一致；不足：缺少访谈式澄清与差异化设计，改造已有系统时灵活度不够

选型建议：只做一次性小改动，手工即可；要新搭骨架，用模板工具更快；要让改动进入团队的任务与研究流程并保持规范一致，skill-meta 更合适。

该技能的典型应用场景与实际体验情况

场景一：想加一个命令，但说不清边界 后端开发者希望加一个 /export 命令导出任务产物，但不确定应该做成命令还是技能、要不要配套代理。他用 /meta 走交互式访谈，被逐条追问导出格式、输出目录、是否需要参数校验，最终拿到 2 个任务目录：一个实现、一个测试。体验：上手难度中等，第一次会觉得「问题好多」，但正是这些追问避免了后面返工；注意访谈中要如实回答，含糊作答会得到含糊的任务拆解。

场景二：接手别人的项目，先做系统体检 新加入的维护者面对一堆命令和技能不敢乱动，先跑 /meta --analyze。返回结果显示有 9 个命令、9 个技能、6 个代理、15 个活动任务，status 为 analyzed。体验：零风险、秒级见效，是接手陌生工作流的最优第一步；注意分析模式不创建任务，别指望它顺手改东西。

场景三：需求写清楚了，跳过访谈直接拆任务 技术负责人把需求写成一整段话作为参数传入，走提示分析模式直接拿任务分解。体验：比访谈快，但对提示质量敏感——需求里没写验收标准，任务拆解就会偏粗。建议提示中至少包含「加什么、给谁用、怎么算完成」三要素。

场景四：任务创建后的自动收尾 子代理返回任务目录后，技能自己完成校验与后飞行（如创建了任务则执行 git 提交），再一次性返回结果。体验：不再需要在技能返回和协调器之间反复确认「继续」，流程连贯性明显更好；注意后飞行涉及 git 操作，团队应提前约定提交规范与分支策略。

该技能能为用户带来的价值

把「想法」变成「工单」的转化成本大幅下降：原本需要翻文档、想拆解、手建目录的一串动作，压缩成一次对话加若干次回答。
降低规范门槛：组件选择指南、命令/技能/代理的创建指南由子代理按需加载，使用者不需要先通读全部规范再动手，新人也能产出符合项目约定的结构。
减少返工与漏项：7 阶段访谈本质是一次前置设计评审，把工具权限、触发条件、验收标准提前钉死，避免「写完才发现方向不对」。
让改动可被流程接续：产出的是 specs/ 下的任务目录与状态文件，附带 next_steps 指引，能直接接上研究、实施、测试等环节，而不是一段孤立文本。
可量化的过程收益：任务数量、组件数量、会话 ID、委托路径都被写入返回元数据，团队可以据此统计「系统改造的频次与规模」，把工作流演进变成可观测指标。
长期价值：随着命令、技能、代理不断累积，--analyze 提供的现状盘点能力会越来越值钱——它是防止工作流「越长越乱」的定期体检手段。

常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认成功？ A：在技能管理入口按技能 ID 12890 或英文名 skill-meta 检索安装，具体入口与命令以官方说明为准。前提是环境已支持技能与子代理机制，且项目内存在 .claude/ 目录与 meta-builder-agent 子代理，同时技能需要 Task、Bash、Edit、Read、Write 权限。验证方式是执行 /meta --analyze，若能返回系统盘点结果即安装成功。

Q2：收费吗？ A：技能详情中未涉及定价信息，是否收费、是否有额度限制请以官方说明为准。需要注意的是，交互式模式下子代理会进行多轮问答并可能触发较长会话（默认超时 7200 秒），这会消耗相应模型调用额度。

Q3：适合谁用？我就想改一个配置文件，值得用吗？ A：适合正在维护 .claude/ 体系（命令、技能、代理、任务流程）的开发者与团队，尤其是需要让改动进入任务流程、保持规范一致的场景。如果只是一次性的极小改动，手工编辑反而更快；当你希望「改完之后还有人知道下一步做什么」，它的价值才显现出来。

Q4：为什么调用子代理必须用 Task 而不是 Skill？ A：因为 meta-builder-agent 是位于 .claude/agents/ 的子代理，而不是 .claude/skills/ 下的技能。技能调用工具只能触发技能目录里的技能，用它去调代理会失败。这个坑在该技能的说明中被明确标注，属于高频错误点。

Q5：中途取消或超时会怎样？ A：在确认阶段主动取消会返回 cancelled 状态，按完成而非失败处理，且不会创建任何任务，随时可以重跑。子代理超时（交互式会话默认 7200 秒）则返回 partial 部分状态，建议收窄需求范围、拆分后再发起。