Communitygithub.com

技能管理

管理本地技能 — 列出、添加、删除、搜索、编辑、设置向导

技能管理 是什么?

这是一个用于管理 oh-my-claudecode 本地技能的元技能,提供了一套类 CLI 的子命令,帮助用户高效地维护技能库。它支持列出所有可用技能(按内置、用户、项目三种范围分类),通过交互式向导创建新技能,删除或编辑已有技能,以及按内容、触发器、名称或描述搜索技能。该技能还包含一个完整的设置向导,用于检查目录结构、扫描技能清单并提供快速操作菜单(如添加、导入、扫描对话模式)。适用于 Claude Code 等 AI 代理平台,显著提升了技能的组织和维护效率。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Yeachan-Heo/oh-my-claudecode/tree/main/skills/skill

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

技能管理 CLI

用于管理 oh-my-claudecode 技能的元技能,通过 CLI 式命令进行操作。

子命令

/skill list

显示所有可用技能,按范围分类。

行为:

  1. 扫描插件 skills/ 目录中内置的技能(只读)
  2. 扫描 ${CLAUDE_CONFIG_DIR:-~/.claude}/skills/omc-learned/ 下的用户技能
  3. 扫描 .omc/skills/ 下的项目技能
  4. 解析 YAML 前置元数据
  5. 以表格形式显示:
内置技能(与 oh-my-claudecode 捆绑):
| 名称              | 描述                         | 范围     |
|-------------------|------------------------------|----------|
| visual-verdict    | 结构化视觉问答判决           | 内置     |
| ralph             | 持久化循环                   | 内置     |

用户技能 (~/.claude/skills/omc-learned/):
| 名称              | 触发器           | 质量 | 使用次数 | 范围 |
|-------------------|------------------|------|---------|------|
| error-handler     | fix, error       | 95%  | 42      | 用户 |
| api-builder       | api, endpoint    | 88%  | 23      | 用户 |

项目技能 (.omc/skills/):
| 名称              | 触发器           | 质量 | 使用次数 | 范围   |
|-------------------|------------------|------|---------|--------|
| test-runner       | test, run        | 92%  | 15      | 项目   |

降级: 如果质量/使用数据不可用,显示“N/A”

内置技能说明: 内置技能与 oh-my-claudecode 捆绑,可发现和读取,但不能通过 /skill remove 或 /skill edit 删除或编辑。


/skill add [name]

用于创建新技能的交互式向导。

行为:

  1. 询问技能名称(如果命令中未提供)
    • 验证:小写字母、仅连字符、无空格
  2. 询问描述
    • 简洁、清晰的一句话
  3. 询问触发器(逗号分隔的关键词)
    • 示例:“error, fix, debug”
  4. 询问参数提示(可选)
    • 示例:“ [options]”
  5. 询问范围:
    • user → ${CLAUDE_CONFIG_DIR:-~/.claude}/skills/omc-learned/<name>/SKILL.md
    • project → .omc/skills/<name>/SKILL.md
  6. 创建技能文件,使用模板:
---
name: <name>
description: <description>
triggers:
  - <trigger1>
  - <trigger2>
argument-hint: "<args>"
---

# <Name> 技能

## 目的

[描述此技能的功能]

## 何时激活

[描述触发条件和场景]

## 工作流

1. [步骤 1]
2. [步骤 2]
3. [步骤 3]

## 示例

/oh-my-claudecode: example-arg


## 备注

[附加上下文、边缘情况、注意事项]
  1. 报告成功,并显示文件路径
  2. 建议: “使用 /skill edit <name> 编辑自定义内容”

示例:

用户:/skill add custom-logger
助手:正在创建新技能 'custom-logger'...

描述:增强日志记录,支持结构化输出
触发器(逗号分隔):log, logger, logging
参数提示(可选):<level> [message]
范围(user/project):user

✓ 已在 ~/.claude/skills/omc-learned/custom-logger/SKILL.md 创建技能
→ 编辑:/skill edit custom-logger

/skill remove

按名称删除技能。

行为:

  1. 在两个范围中搜索技能:
    • ${CLAUDE_CONFIG_DIR:-~/.claude}/skills/omc-learned/<name>/SKILL.md
    • .omc/skills/<name>/SKILL.md
  2. 如果找到:
    • 显示技能信息(名称、描述、范围)
    • 请求确认: “删除 '' 技能(来自 )?(yes/no)”
  3. 如果确认:
    • 删除整个技能目录(例如 ${CLAUDE_CONFIG_DIR:-~/.claude}/skills/omc-learned/<name>/)
    • 报告:"✓ 已从 中移除技能 ''"
  4. 如果未找到:
    • 报告:"✗ 未在用户或项目范围中找到技能 ''"

安全: 未经用户明确确认绝不删除。

示例:

用户:/skill remove old-logger
助手:在用户范围内找到技能 'old-logger':
  描述:旧版日志工具
  范围:用户 (~/.claude/skills/omc-learned/)

是否删除 'old-logger' 技能?(yes/no)

用户:yes
助手:✓ 已从用户范围中移除技能 'old-logger'

/skill edit

交互式编辑现有技能。

行为:

  1. 按名称查找技能(搜索两个范围)
  2. 通过 Read 工具读取当前内容
  3. 显示当前值:
    当前技能 'custom-logger':
    - 描述:增强日志记录,支持结构化输出
    - 触发器:log, logger, logging
    - 参数提示:<level> [message]
    - 范围:用户
    
  4. 询问要更改的内容:
    • description - 更新描述
    • triggers - 更新触发器关键词
    • argument-hint - 更新参数提示
    • content - 编辑完整的 Markdown 内容
    • rename - 重命名技能(移动文件)
    • cancel - 退出而不修改
  5. 对于所选字段:
    • 显示当前值
    • 询问新值
    • 更新 YAML 前置元数据或内容
    • 写回文件
  6. 报告成功,并显示更改摘要

示例:

用户:/skill edit custom-logger
助手:当前技能 'custom-logger':
  - 描述:增强日志记录,支持结构化输出
  - 触发器:log, logger, logging
  - 参数提示:<level> [message]

您想要编辑什么?(description/triggers/argument-hint/content/rename/cancel)

用户:triggers
助手:当前触发器:log, logger, logging
新触发器(逗号分隔):log, logger, logging, trace

✓ 已更新 'custom-logger' 的触发器

/skill search

按内容、触发器、名称或描述搜索技能。

行为:

  1. 扫描所有技能(两个范围)
  2. 匹配查询(不区分大小写)对:
    • 技能名称
    • 描述
    • 触发器
    • 完整的 Markdown 内容
  3. 显示匹配结果及上下文:
找到 3 个技能匹配“typescript error”:

1. typescript-fixer(用户)
   描述:修复常见 TypeScript 错误
   匹配:“typescript error handling patterns”

2. error-handler(用户)
   描述:通用错误处理工具
   匹配:“Supports TypeScript and JavaScript errors”

3. lint-fix(项目)
   描述:自动修复 lint 错误
   匹配:“TypeScript ESLint error resolution”

排名: 优先匹配名称/触发器,其次是内容匹配

示例:

用户:/skill search api endpoint
助手:找到 2 个技能匹配“api endpoint”:

1. api-builder(用户)
   描述:生成 REST API 端点
   触发器:api, endpoint, rest

2. backend-scaffold(项目)
   描述:搭建后端服务
   匹配:"Creates API endpoint boilerplate"

/skill info

显示技能的详细信息。

行为:

  1. 按名称查找技能(搜索两个范围)
  2. 解析 YAML 前置元数据和内容
  3. 显示完整详情:
技能:custom-logger
范围:用户 (~/.claude/skills/omc-learned/custom-logger/)
描述:增强日志记录,支持结构化输出
触发器:log, logger, logging
参数提示:<level> [message]
质量:95%(如果可用)
使用次数:42 次(如果可用)
文件路径:/home/user/.claude/skills/omc-learned/custom-logger/SKILL.md

--- 完整内容 ---
[整个 Markdown 内容]

如果未找到: 报告错误并建议使用 /skill search

示例:

用户:/skill info custom-logger
助手:技能:custom-logger
范围:用户
描述:增强日志记录,支持结构化输出
触发器:log, logger, logging
文件:~/.claude/skills/omc-learned/custom-logger/SKILL.md

--- 内容 ---
# Custom Logger 技能

## 目的
增强日志记录,支持结构化 JSON 输出...
[其余内容]

/skill sync

在用户范围和项目范围之间同步技能。

行为:

  1. 扫描两个范围:
    • 用户技能:${CLAUDE_CONFIG_DIR:-~/.claude}/skills/omc-learned/
    • 项目技能:.omc/skills/
  2. 比较并分类:
    • 仅在用户中的技能(不在项目中)
    • 仅在项目中的技能(不在用户中)
    • 共有的技能(两者都有)
  3. 显示同步机会:
同步报告:

仅在用户中的技能(5 个):
  - error-handler
  - api-builder
  - custom-logger
  - test-generator
  - deploy-helper

仅在项目中的技能(2 个):
  - test-runner
  - backend-scaffold

共有技能(3 个):
  - frontend-ui-ux
  - git-master
  - planner

选项:
  [1] 将用户技能复制到项目
  [2] 将项目技能复制到用户
  [3] 查看差异
  [4] 取消
  1. 处理用户选择:
    • 选项 1:选择要复制到项目的技能
    • 选项 2:选择要复制到用户的技能
    • 选项 3:显示共有技能的并排差异
    • 选项 4:退出

安全: 未经确认绝不覆盖

示例:

用户:/skill sync
助手:找到 5 个仅在用户中的技能和 2 个仅在项目中的技能。

将 'error-handler' 从用户复制到项目?(yes/no/skip)
用户:yes
助手:✓ 已将 'error-handler' 复制到 .omc/skills/

将 'api-builder' 从用户复制到项目?(yes/no/skip)
用户:skip
...

/skill setup

用于设置和管理本地技能的交互式向导(原 local-skills-setup)。

行为:

步骤 1:目录检查与设置

首先,检查技能目录是否存在,必要时创建它们:

# 检查并创建用户级技能目录
USER_SKILLS_DIR="${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/omc-learned"
if [ -d "$USER_SKILLS_DIR" ]; then
  echo "用户技能目录已存在:$USER_SKILLS_DIR"
else
  mkdir -p "$USER_SKILLS_DIR"
  echo "已创建用户技能目录:$USER_SKILLS_DIR"
fi

# 检查并创建项目级技能目录
PROJECT_SKILLS_DIR=".omc/skills"
if [ -d "$PROJECT_SKILLS_DIR" ]; then
  echo "项目技能目录已存在:$PROJECT_SKILLS_DIR"
else
  mkdir -p "$PROJECT_SKILLS_DIR"
  echo "已创建项目技能目录:$PROJECT_SKILLS_DIR"
fi

步骤 2:技能扫描与清单

扫描两个目录并显示全面的清单:

# 扫描用户级技能
echo "=== 用户级技能 (~/.claude/skills/omc-learned/) ==="
if [ -d "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/omc-learned" ]; then
  USER_COUNT=$(find "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/omc-learned" -name "*.md" 2>/dev/null | wc -l)
  echo "技能总数:$USER_COUNT"

  if [ $USER_COUNT -gt 0 ]; then
    echo ""
    echo "找到的技能:"
    find "${CLAUDE_CONFIG_DIR:-$HOME/.claude}/skills/omc-learned" -name "*.md" -type f -exec sh -c '
      FILE="$1"
      NAME=$(grep -m1 "^name:" "$FILE" 2>/dev/null | sed "s/name: //")
      DESC=$(grep -m1 "^description:" "$FILE" 2>/dev/null | sed "s/description: //")
      MODIFIED=$(stat -c "%y" "$FILE" 2>/dev/null || stat -f "%Sm" "$FILE" 2>/dev/null)
      echo "  - $NAME"
      [ -n "$DESC" ] && echo "    描述:$DESC"
      echo "    修改时间:$MODIFIED"
      echo ""
    ' sh {} \;
  fi
else
  echo "目录未找到"
fi

echo ""
echo "=== 项目级技能 (.omc/skills/) ==="
if [ -d ".omc/skills" ]; then
  PROJECT_COUNT=$(find ".omc/skills" -name "*.md" 2>/dev/null | wc -l)
  echo "技能总数:$PROJECT_COUNT"

  if [ $PROJECT_COUNT -gt 0 ]; then
    echo ""
    echo "找到的技能:"
    find ".omc/skills" -name "*.md" -type f -exec sh -c '
      FILE="$1"
      NAME=$(grep -m1 "^name:" "$FILE" 2>/dev/null | sed "s/name: //")
      DESC=$(grep -m1 "^description:" "$FILE" 2>/dev/null | sed "s/description: //")
      MODIFIED=$(stat -c "%y" "$FILE" 2>/dev/null || stat -f "%Sm" "$FILE" 2>/dev/null)
      echo "  - $NAME"
      [ -n "$DESC" ] && echo "    描述:$DESC"
      echo "    修改时间:$MODIFIED"
      echo ""
    ' sh {} \;
  fi
else
  echo "目录未找到"
fi

# 汇总
TOTAL=$((USER_COUNT + PROJECT_COUNT))
echo "=== 汇总 ==="
echo "所有目录中的技能总数:$TOTAL"

步骤 3:快速操作菜单

扫描后,使用 AskUserQuestion 工具提供以下选项:

问题:“您想对本地技能做什么?”

选项:

  1. 添加新技能 - 启动技能创建向导(调用 /skill add)
  2. 列出所有技能及详情 - 显示全面的技能清单(调用 /skill list)
  3. 扫描对话中的模式 - 分析当前对话中值得提取为技能的模式
  4. 导入技能 - 从 URL 或粘贴内容导入技能
  5. 完成 - 退出向导

选项 3:扫描对话中的模式

分析当前对话上下文,识别可能值得提取为技能的模式。查找:

  • 最近的调试会话,包含非显而易见的解决方案
  • 需要调查的棘手错误
  • 代码库特定的解决方法
  • 需要时间解决的错误模式

报告发现结果,并询问用户是否要将任何内容提取为技能(调用 /skillify;/learner 已弃用但保持兼容)。

选项 4:导入技能

要求用户提供:

  • URL:从 URL 下载技能(例如 GitHub gist)
  • 粘贴内容:直接粘贴技能 Markdown 内容

然后询问范围:

  • 用户级 (~/.claude/skills/omc-learned/) - 所有项目可用
  • 项目级 (.omc/skills/) - 仅当前项目

验证技能格式并保存到所选位置。


/skill scan

快速扫描两个技能目录的命令(/skill setup 的子集)。

行为: 仅运行 /skill setup 中步骤 2 的扫描,不包含交互式向导。


技能模板

在通过 /skill add 或 /skill setup 创建技能时,提供常见技能类型的快速模板:

错误解决方案模板

---
id: error-[唯一标识]
name: [错误名称]
description: [特定上下文中特定错误的解决方案]
source: conversation
triggers: ["错误消息片段", "文件路径", "症状"]
quality: high
---

# [错误名称]

## 洞察
此错误的根本原因是什么?您发现了什么原理?

## 为什么重要
如果您不知道这一点,会出什么问题?什么症状导致了这里?

## 识别模式
您如何知道何时适用?有哪些迹象?
- 错误消息:"[确切错误]"
- 文件:[特定文件路径]
- 上下文:[何时发生]

## 解决方案

...

(已截断以进行翻译)

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

agent-doc-discipline

Writing-time discipline for documents agents consume (the five surfaces, specs, tickets, .omc/skills/) — every rule checkable and carrying a why, steps before reference, one meaning in one home, no restating what the environment already says. Mandatory at drydock seed generation and the launch C5 sediment pass; opt-in for any other agent-facing doc edit. The companion of minimal-code-discipline: that one disciplines code, this one disciplines papers.

ai-slop-cleaner

Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

ask

Process-first advisor routing for Claude, Codex, Gemini, Antigravity, Grok, or Cursor via `omc ask`, with artifact capture and no raw CLI assembly

ask-navigator

Shipyard

autopilot

Full autonomous execution from idea to working code

autoresearch

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

cancel

Cancel any active OMC mode (autopilot, ralph, ultragoal, swarm, ultrapilot, pipeline, team) and clean up retired legacy state

configure-notifications

Configure notification integrations (Telegram, Discord, Slack) via natural language

debug

Diagnose the current OMC session or repo state using logs, traces, state, and focused reproduction

deepinit

Deep codebase initialization with hierarchical AGENTS.md documentation

deep-interview

Socratic deep interview with mathematical ambiguity gating before explicit execution approval

drydock

Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards) across 5 surfaces (CLAUDE.md, skills, design-system, mcp/cli, shared context) so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.

execute

Carry an approved task through to working, verified code

external-context

Invoke parallel document-specialist agents for external web searches and documentation lookup

graph

Deterministic orchestration graph runtime - declarative DAG pipelines with journal-based crash recovery

harbor

Harbor intake for external work — the captain only handles unresolved decisions. Sweeps incoming issues and PRs, verifies every claim before disposition, reuses every decision already made, and hands the maintainer a docket whose pending items each carry one question with options, recommendation, impact and evidence. Agent-autonomous for facts and for actions covered by standing authorization; signed for every new judgment. Never merges.

hud

Configure HUD display options (layout, presets, display elements)

launch

Shipyard

loft

Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches

minimal-code-discipline

YAGNI-ladder coding discipline for writing changes — existence-first, reuse before writing, dependency ladder, shortest correct diff, with non-negotiables that must never be minimized away

相关技能