结论先行
Skill 源码目录可以自己选;自动发现入口需要遵循 Codex 的目录约定。推荐把源码放入独立 Git 仓库,再将单个 skill 文件夹软链接到 ~/.agents/skills/。
独立维护
源码脱离某个业务仓库,修改、评审和版本记录集中进行。
跨项目可用
用户级入口指向源码,切换项目仍能使用同一个 skill。
按需同步
本地先验证改进,再提交并推送;其他电脑拉取后采用新内容。
$HOME/.agents/skills,并明确支持 skill 文件夹软链接。
适用于能访问这些本地文件的 Codex 环境。若要让其他人通过安装入口分发使用,可以再封装为 plugin;见 官方插件打包文档。
问题背景
在项目 A 里整理出一套写文档的方法后,项目 B 也需要使用。如果每个项目各复制一份,修正一次流程就要到处同步;不同副本还可能逐渐出现差异。把方法放到个人目录能扩大使用范围,但还需要一个便于编辑、回看历史和跨电脑同步的源码仓库。
因此,需要把维护源码的位置与Codex 找到 skill 的入口连接起来。软链接相当于文件系统中的指针:从发现入口打开文件,实际读取的是源码目录内的文件。
- 源码仓库
- 你在编辑器中打开的独立项目,保存 SKILL.md 和配套资源。
- 发现入口
- 让 Codex 找到 skill 的目录;它可以只放一个指向源码的链接。
- 项目约定
- 当前业务仓库的输出路径、模板、命令和交付要求。
- 版本同步
- 用 Git 记录修改,通过 GitHub 在多台电脑间传递提交。
下面以通用写作 skill technical-writing 为例。示例仓库名 my-skills、GitHub 所有者 YOUR_ACCOUNT 都是占位值,按自己的情况替换。
详细内容
STEP 01确定源码与发现入口
| 目录 | 用途 | 本文建议 |
|---|---|---|
~/workspace/my-skills/ | 自己选定的源码仓库 | 在这里编辑、提交、推送;放在业务仓库之外。 |
~/.agents/skills/ | 用户级 skill 入口 | 为需要跨项目使用的 skill 建立链接。 |
项目/.agents/skills/ | 项目相关的 skill 入口 | 保留只适用于该项目的工作流程。 |
项目范围内,Codex 会沿当前工作目录向上扫描到仓库根目录的 .agents/skills。本地出现 ~/.codex/skills 或插件缓存目录,并不意味着它们适合直接充当你的源码仓库;新建个人入口时,按当前官方文档采用 ~/.agents/skills。
~/workspace/my-skills/ # Git 仓库
└── skills/
└── technical-writing/
├── SKILL.md # 必需
├── references/ # 可选:参考规范
├── scripts/ # 可选:确定性操作
└── assets/ # 可选:模板与素材
~/.agents/skills/
└── technical-writing
→ ~/workspace/my-skills/skills/technical-writing一个仓库可以维护多个 skill,每个 skill 对应独立文件夹。链接应指向包含 SKILL.md 的文件夹。
skills.config 在官方配置参考中用于单个 skill 的启用/禁用控制。不能仅凭它带有 path 字段,就将其理解为任意目录扫描配置。本文使用有明确文档支持的软链接方案。
STEP 02创建一个最小可用 skill
以下命令假设 ~/workspace/my-skills 是新建的独立仓库,终端使用 macOS / Linux 的 Bash 或 Zsh。先创建目录并初始化 Git:
mkdir -p "$HOME/workspace/my-skills/skills/technical-writing"
git -C "$HOME/workspace/my-skills" init -b main随后在编辑器中创建 skills/technical-writing/SKILL.md。下面是本文设计的可复用起点:
---
name: technical-writing
description: 将工程讨论、实现方案或排查经验整理为技术文档;用户要求写文档、写文章或沉淀实践时使用,遵循当前项目的格式与发布约定。
---
# 技术文档编写
1. 读取当前任务适用的 AGENTS.md,确认输出格式、目录、
文章模板与目录登记要求;用户的明确要求优先。
2. 读取项目指定的规范与范例。缺少必要信息时,先检查现有
文档结构;仍无法确定的交付位置或格式,再询问用户。
3. 区分已验证事实、方案建议和示例。涉及工具机制、版本或
配置时核对官方资料,并给出支持关键结论的链接。
4. 按项目模板组织内容;项目未约定结构时,可采用
“结论、背景、操作步骤、验证方式、参考资料”。
5. 检查命令、路径和示例是否前后一致,并将敏感信息替换为
通用占位符。仅在项目要求时维护文档目录与多语言入口。
6. 核对成品结构和相关链接;有视觉要求时检查展示效果。
报告交付文件、验证结果与仍需处理的问题。name 和 description 是必需的元数据;触发描述应写清任务范围。参考规范、脚本和模板可按需要增加,并从正文链接到它们。这里无需预先创建空目录。
STEP 03链接到用户级目录并验证
先确认源码存在,再建立入口。下面同时检查普通路径与软链接,避免重复执行时覆盖已有内容,或在现有目录中误建一层链接。
skill_source="$HOME/workspace/my-skills/skills/technical-writing"
skill_link="$HOME/.agents/skills/technical-writing"
if [ ! -f "$skill_source/SKILL.md" ]; then
printf '%s\n' "未找到源码中的 SKILL.md,请先完成上一步。"
elif [ -e "$skill_link" ] || [ -L "$skill_link" ]; then
printf '%s\n' "入口已存在,请先核对它的目标:"
ls -ld "$skill_link"
else
mkdir -p "$HOME/.agents/skills" &&
ln -s "$skill_source" "$skill_link"
fireadlink "$HOME/.agents/skills/technical-writing"
cat "$HOME/.agents/skills/technical-writing/SKILL.md"预期输出中,链接指向你选定的源码目录,读到的内容与编辑器中的文件一致。然后在一个业务项目的 Codex 会话中显式调用:
$technical-writing 将刚才的工程讨论整理为文档,遵循当前项目约定。官方说明 Codex 会自动检测 skill 修改;未显示更新时可重启。验证新版本时建议开启新会话,并确认读取的是这份源码,避免把旧对话上下文误认为最新文件内容。
依据:创建与更新 skill。新会话验证是本文的操作建议。源码目录移动后需要修正入口;换电脑后也要重新建立本机链接。若要让 Codex 修改独立 skill 仓库,可直接把该仓库作为当前工作项目打开,文件访问仍受会话权限约束。
STEP 04推送到 GitHub,并在其他电脑同步
先在 GitHub 创建一个空的 my-skills 仓库。采用下面的首次推送流程时,远端先不初始化 README 等文件。把 YOUR_ACCOUNT 替换为实际所有者,并完成 GitHub 的 Git 身份认证。
cd "$HOME/workspace/my-skills"
git status --short
git add skills/technical-writing/SKILL.md
git diff --cached
git commit -m "feat: add reusable technical-writing skill"
git remote add origin https://github.com/YOUR_ACCOUNT/my-skills.git
git push -u origin main这里提交的是实际 skill 文件。用户级软链接是本机安装入口,不需要放进源码仓库。如果源码来自已有 GitHub 仓库,直接 clone,再建立链接即可,无需再次 init 或添加 origin。
流程依据:GitHub · Adding locally hosted code to GitHub。另一台电脑:克隆一次,再建立自己的链接
mkdir -p "$HOME/workspace"
git clone https://github.com/YOUR_ACCOUNT/my-skills.git \
"$HOME/workspace/my-skills"克隆后执行 STEP 03 的链接配置。此后更新前先查看本地状态;存在未提交修改时先提交或妥善保存,再拉取:
git -C "$HOME/workspace/my-skills" status --short
git -C "$HOME/workspace/my-skills" pull --ff-only--ff-only 只接受快进更新;本地与远端提交已分叉时会停止,需要先决定如何整合两边的修改。它不负责自动处理所有冲突。
STEP 05建立可验证的迭代循环
“持续迭代”来自真实任务反馈:发现缺失的判断条件,修改相应规则,再用代表性任务验证。建议一次改进一个明确问题,把项目特例留在项目约定中。
编辑源码,说明本次要改善的任务与判断。
在不同项目试用,检查触发、输出及项目适配。
检查 diff,提交验证过的修改,再推送同步。
| 动作 | 本地文件 | 版本记录 / 其他电脑 |
|---|---|---|
| 保存 SKILL.md | 链接指向的文件随即改变 | 尚未生成 Git 提交,也未同步远端 |
| git commit | 保存当前选中的修改快照 | 只增加本地提交 |
| git push | 无需为本机加载额外复制 | 将本地提交推送到远端 |
| 另一台电脑 git pull | 更新该电脑的本地检出 | 该电脑的链接继续指向更新后的文件 |
共享一个工作目录意味着各项目采用该目录的当前内容,尚未提交的修改也可能被后续任务读到。如果需要试验版本与稳定版本并存,可以使用两个独立检出,并分别采用明确区分的 skill 名称和入口。
验证要覆盖“该用”和“不该用”的情况
- 明确要求编写技术文档:能否触发并读取项目模板?
- 同样的写作任务换到另一个项目:是否采用了新项目的路径与格式?
- 仅要求解释一个术语:是否避免无依据地创建整篇文件?
- 项目缺少输出约定:能否提出必要问题,而不是沿用上一个项目的目录?
cd "$HOME/workspace/my-skills"
git diff -- skills/technical-writing
git add skills/technical-writing/SKILL.md
git diff --cached
git commit -m "refactor: clarify project-specific writing rules"
git push新增参考文件或脚本时,将相应文件一起加入提交。Git 记录的是你做出的改进;使用次数本身不会自动修改 skill 文件。
STEP 06把通用流程与项目约定分开
能被多个项目发现,只解决了可访问性。要真正复用,还要移除写死的业务仓库路径、站点视觉和发布文件位置。以项目专用的 write-doc 为例,可以按下面的边界提取通用能力。
| 内容 | 建议归属 | 示例 |
|---|---|---|
| 资料核对、事实与建议区分、操作步骤检查 | 通用 skill | 核实关键机制,检查命令与引用。 |
| 输出格式与文章保存位置 | 项目 AGENTS.md 或指定规范 | 本站要求 HTML 并放入 common/public/。 |
| 主站主题、Banner、页面组件 | 项目模板 | 复用当前站点样式与导航。 |
| 首页登记与中英文简介 | 项目发布约定 | 说明要修改哪些目录入口与翻译文件。 |
| 与项目无关的检查脚本或模板 | 通用 skill 的配套资源 | 按输入参数运行,避免写死业务路径。 |
通用 skill 中应明确要求读取当前项目规范,并用 skill 自身位置定位随包参考资料、用当前项目根目录定位交付文件。若自行设计配置文件,要在 skill 中说明文件名、字段与读取时机;它不会因为存在就自动成为 Codex 的标准配置。
例如通用版叫 technical-writing,项目专用版保留 write-doc。同名 skill 不会自动合并,不应依赖“项目版一定覆盖全局版”的假设。
常见问题:沿“源码 → 链接 → 调用”排查
| 现象 | 优先检查 | 处理方向 |
|---|---|---|
| 源码有了,其他项目找不到 | 用户级链接是否存在,目标内是否包含 SKILL.md | 先执行 STEP 03 的 readlink 与 cat,再检查元数据。 |
| 入口已存在 | 它是目录、正常链接还是断链 | 先核对现有目标与内容;不要直接强制覆盖。 |
| 链接目标中出现字面量 ~ | 是否使用了 "~/workspace/..." | 终端示例使用 "$HOME/workspace/..."。 |
| 修改后仍表现得像旧版本 | 调用的 skill 名称、实际读取路径、旧会话内容 | 确认文件已保存,开启新会话;仍未显示时重启。 |
| 已 push,另一台电脑没变化 | 另一台电脑是否拉取、是否链接到该检出 | 检查状态并 pull,然后重新验证。 |
| 能找到 skill,却输出到错误目录 | 通用正文是否残留项目专用路径 | 将路径移入当前项目规范,补充跨项目用例。 |
| 移动仓库后无法读取 | readlink 是否仍指向原位置 | 核对并重建本机入口,源码继续由 Git 管理。 |
总结归纳
REUSABLE WORKFLOW
一份源码,项目适配,版本可追溯。
把 skill 当作持续维护的工程资产:独立仓库存源码,用户级软链接提供入口,项目约定决定交付细节。真实任务推动改进,Git 记录版本,GitHub 同步提交。
首次完成创建与链接后,日常工作就是修改 → 验证 → commit → push;其他电脑通过 pull 获取更新。面向更广泛的可安装分发时,再采用插件包装。
官方依据与参考
核对日期:2026-09-28。官方资料支持工具机制与命令语义;仓库布局、写作流程和项目分工是本文的实践建议。文中个人路径与仓库所有者均使用通用示例。
- [01]OpenAI · Build skills ↗
加载目录、软链接、调用方式、更新检测与同名行为。
- [02]OpenAI · Configuration Reference ↗
skills.config 的启用与禁用用途。
- [03]OpenAI · Build skills for plugins ↗
SKILL.md 格式、配套资源与行为验证。
- [04]GitHub · Adding locally hosted code to GitHub ↗
本地仓库连接远端与首次推送。
- [05]Git · git pull ↗
拉取更新、快进与分叉处理。
- [06]OpenAI · Package your plugin ↗
需要可安装分发时的后续包装方式。